上次处理完一批PDF之后我以为短期内不会再碰它了。结果没过多久业务侧又递过来一批更麻烦的全部是扫描版PDF每页就是一整张图文字既不能选中也不能搜索复制出来基本是乱码或者干脆空白。更要命的是这个批次有几百个文件、上千页靠人工重新录入根本不现实。于是就有了这次PDF处理的续篇——核心任务是把图片型扫描PDF自动转成带隐藏文字层的可检索PDF处理后能全文搜索、能选中复制页面长相和原来完全一致。整个流程拆开看就三件事渲染、识别、回写。这篇文章会把这套流程从方案选型到实际踩坑完整走一遍适合需要批量处理扫描PDF的朋友参考。1. 症状确认先判断这批PDF是有字还是有图1.1 三分钟快速分辨PDF类型先别急着上工具。拿到这批PDF我第一件事不是写脚本而是确认它们到底属于哪一类。按内部结构划分常见的是三种纯文本型PDF有文字对象能选中、能搜索直接提取内容就行。图片型PDF整页是一张图像没有任何文字对象需要OCR。混合型PDF一部分页面是文字层一部分是扫描图最常见于封面扫描正文导出的组合件。判断方法很简单随便打开一个PDF阅读器用选择文本工具在页面里拉一下。能选中文字的多半不是纯图片型选不中的大概率是。不过这个判断不够严谨有些阅读器会在扫描图像下方悄悄做一遍临时识别给你一种好像能选的错觉。更可靠的办法是用脚本提取文本层import fitz doc fitz.open(样例扫描件.pdf) for page_number in range(min(3, len(doc))): text doc[page_number].get_text() print(f第 {page_number 1} 页文本长度: {len(text)})如果文本长度是0说明这一页没有任何文字对象基本可以判定为图片型PDF。前三页都是如此那整个文件大概率就是纯扫描件。这一步看似啰嗦但非常关键因为能不能提取文本直接决定后面所有方案的选择。我之前接过一个需求对方信誓旦旦地说PDF里全是扫描图结果脚本一跑发现只有封面是扫描图后面几十页全是文字层那就完全不需要OCR一个文本提取脚本就结束了。所以花三分钟做类型判断往往能节省后面半小时甚至更久。1.2 文字层缺失意味着什么用稍微技术一点的眼光看PDF页面内容由若干内容流组成常见对象包括矢量路径、文字对象、图像XObject。扫描版PDF的每一页结构通常特别简单一张矩形图像铺满整个页面其他什么都没有。文字本质上只是像素点阵里的明暗分布PDF阅读器并不知道这是一段文字它只感知到这里有一块颜色不同的区域。所以网上那些把扫描PDF另存为Word的办法成功率很低原因就在这软件无论怎么优化都无法从纯像素中直接还原出可编辑的字符。能把像素重新变成文字的只有一条路——OCR光学字符识别。想清楚这点后处理思路立刻明确了先让程序理解图像里的字再把理解结果作为文字层写回PDF里。还有一个容易忽略的点扫描件普遍比文字型PDF大很多因为图像数据量大。OCR之后叠加文字层文件体积不会有明显变化有时还能顺手压一下图像体积但这要看原始扫描质量压缩太狠反而影响后续使用。我这次没有做任何图像压缩保持原始页面作为底图识别文字只作为带索引功能的上层存在安全第一。2. 方案取舍为什么选择本地脚本 OCR引擎而不是在线工具2.1 批量规模决定了手段处理PDF的手段很多但批量规模会直接淘汰掉一大批不合适的方法。我先评估过在线转换工具。单传几个文件确实方便点几下就能出结果。但这类工具一般都有单次上传页数限制而且整个文档要先上传到对方服务器再下载结果几百个文件轮下来光是上传下载就非常浪费时间。更别说这里处理的是业务归档材料里面有不少敏感信息不可能为了省事把文件往外传。也考虑过商业软件。功能确实全界面也友好但批量授权和现有工作流的结合反而是瓶颈。这个需求属于阶段性的生产任务不是长期稳定流程为一个短期任务买一套授权实在不划算。最后决定用本地脚本方案Python PyMuPDF 负责渲染和回写PaddleOCR 负责文字识别。跑在自己机器上数据不出内网批量控制完全由脚本掌握断点续跑、指定页面试跑都很方便。唯一要付出的成本是前期搭环境和调模型只要文档结构不是特别离谱这个成本完全能接受。2.2 OCR引擎怎么选选OCR引擎之前先列一下实际需求以中文为主夹杂少量英文和数字排版基本是印刷体不是手写最看重的是检索准确率和坐标定位能力。能本地部署的开源OCR方案主流就两大类。一类是老牌的Tesseract轻量、跨平台、语言包齐全另一类是深度学习路线的PaddleOCR中文识别效果明显更好。Tesseract对清晰印刷体英文很稳中文场景则对字体、字号、噪声更敏感同一页中文文本往往要反复调参才能达到能用的水平。PaddleOCR在中文上的优势是模型层面的训练语料和模型结构更适合中文场景基本开箱就能达到比较满意的效果。对坐标定位这个需求PaddleOCR也有天然优势。它不仅返回识别结果还会给出每个文本框四个顶点的坐标和置信度这对后续把识别文本按原位置回写到PDF至关重要。Tesseract也能给坐标但格式和它自己的引擎特性组合起来不如PaddleOCR顺手。所以主引擎定为PaddleOCRTesseract作为兜底备选用于某些特殊扫描质量下PaddleOCR识别不出来的情况。实际用下来PaddleOCR在中文扫描件上的表现确实符合预期这个我后面细说。2.3 双层PDF的最终形态整个处理完成之后每个PDF页面其实包含两层内容底层是原始的扫描图像上层是按文字坐标插入的透明文字填充和描边都不可见但依然可以被阅读器搜索、选中和复制。这个结构有个很形象的类比就像把一张报纸的成片和它的文字稿叠放在同一个透明文件夹里眼睛看到的是照片手指却能在照片上找到对应的文字。最关键的技术细节在于上层文字使用的是TextRenderMode3也就是既不填充颜色也不描边的渲染模式。普通文本是可见的即便把颜色设置成白色也只是视觉上看起来没了在某些阅读器或特殊背景下渲染时可能还会露出痕迹而render_mode3直接控制的是绘制行为——不填充、不描边从图形学层面让文字彻底不可见。但它仍然存在于内容流里因此照样可以被选中、复制和检索。采用双层结构而不是把识别出来的文字直接替换掉原图最大的好处是保真。扫描件本身有版面、印章、手写批注等元素OCR不可能百分之百还原这些视觉特征用原始图像做底图能确保人眼看到的和原文件一模一样文字层只负责机读。这对归档类场景尤其重要——机器能检索人看的还是原样。3. 核心实现渲染、识别、合成三步走的处理脚本3.1 环境准备环境这块我不想写得太啰嗦但有几个坑值得单独点名。我用的是Python 3.9以上版本建议建一个独立虚拟环境别直接装在系统Python里。依赖核心就三个pip install pymupdf pip install paddlepaddle pip install paddleocr其中paddlepaddle是深度学习框架体积比较大几百MB起步安装时间取决于机器性能耐心等就行。如果机器有NVIDIA显卡可以考虑装GPU版本OCR速度能快一个数量级没有GPU用CPU跑也不是不行就是慢一些。装完之后一个典型的版本冲突问题就可能出现paddleocr对numpy、opencv这些基础库有版本要求如果环境里已经装了别的版本pip会提示依赖冲突。我这次的办法是先在一个干净环境里把paddle系列装好再装其他库。顺序反过来的话容易被pip的依赖解析搞得焦头烂额。首次调用PaddleOCR时会自动下载检测、识别、方向分类等模型文件缓存到用户目录下的指定路径。如果机器处于内网或者无法访问外部模型下载地址的环境就需要提前把模型文件放到对应缓存目录里。要留意的是模型缓存目录必须可写否则程序会卡在下载阶段没反应。我第一次跑的时候就因为目录权限问题卡了几分钟后来手动指定缓存路径才解决。3.2 单页处理流程整体流程可以概括为渲染页面为高分辨率位图交给OCR识别再把识别结果按坐标写回PDF。核心代码如下import fitz from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) # 启用方向分类语言为中文 def process_page(page, dpi200): # 1. 渲染当前页为位图 pix page.get_pixmap(dpidpi) img_bytes pix.tobytes(png) page_rect page.rect # 2. OCR识别 result ocr.ocr(img_bytes, clsTrue) if not result: return # 3. 将识别文本按坐标写回同一页 scale_x page_rect.width / pix.width scale_y page_rect.height / pix.height for line in result: box line[0] # 文本框四个顶点坐标图像像素坐标系 text line[1][0] # 识别文本 if not text.strip(): continue # 取文本框中心点转换到PDF坐标系 img_center_x (box[0][0] box[2][0]) / 2 img_center_y (box[0][1] box[2][1]) / 2 pdf_x img_center_x * scale_x pdf_y page_rect.height - img_center_y * scale_y # 以不可见模式写入文本 page.insert_text( (pdf_x, pdf_y), text, fontsize12, fontnamechina-s, # 内置简体中文字体 render_mode3, # 3: 不填充也不描边文字不可见但可选中 )这段代码看起来简单但有三个细节决定了它能不能真正跑通。第一是字体。insert_text如果不指定中文字体默认字体很可能不支持中文写进去的文本会变成乱码或者直接报错。PyMuPDF内置了china-s这种基础中文字体字形虽然朴素但对于隐藏文字层来说完全够用反正人不看它。如果对字体有更高要求可以手动加载字体文件但没必要。第二是坐标转换。OCR返回的坐标原点在图像左上角Y轴向下PDF页面坐标原点在左下角Y轴向上。直接拿OCR坐标往PDF里塞写出来的文字会垂直翻转全跑到错误位置。所以要先按页面点尺寸和像素尺寸算出缩放比再翻转Y坐标。我见过不少半成品脚本识别和回写都做了唯独这一行坐标换算写错最后在阅读器里选中的文字全部偏到页面底部。第三是TextRenderMode。为什么强调用render_mode3而不是把文字颜色设置成白色前面说了白色只是视觉上看不见但文字仍然参与渲染某些阅读器反选或者打印时可能露出痕迹。render_mode3则从绘制层面直接让文字不可见这是做双层PDF的标准做法。3.3 批量执行与进度管理单页流程跑通之后接下来要处理一整批文件。这里最忌讳的是写一个循环然后一把梭跑完跑一半崩了前面处理的成果全丢。我的建议是加日志、加断点、按文件分批。在脚本里我按照输入目录-输出目录结构组织扫描件放在input目录生成结果统一输出到output目录文件名保持不变另外生成一个processing.log文件记录每页识别的状态和异常信息。遇到OCR返回空结果的页只记录警告不中断整个流程。更深一层的考虑是断点续跑。如果某个几百页的大文件跑到200页时程序崩了重新处理整个文件会浪费大量时间。处理这种大PDF时我按文件拆分处理并在每页处理完后把进度和日志同步写入文件。这样即使中途挂了也能通过日志定位到具体是哪一页、什么原因需要的话重跑时可以直接跳过已经完成的页面。还有个实用的小技巧正式批量跑之前先在每个文件里随机挑两三页单独跑一遍确认OCR质量和坐标对齐没问题再放量跑全部页面。这个试跑成本非常低但能提前发现大量问题——比如某个批次的扫描件全局都有倾斜、某类文档的字体不在模型识别范围内。我这次在上千页之前先跑了一个20页的小批量验证基本避免了批量跑完再翻车的尴尬。4. 识别质量和性能的实测情况4.1 DPI对准确率的直接影响渲染PDF页面时使用的DPI直接决定了OCR看到的图像清晰度这个参数对结果的影响经常被低估。我用同一批文档实测过几个档位规律非常明显渲染DPI小字号中文体验识别错误率处理速度72字迹模糊笔画合并很高基本不可用极快150小字勉强可读中等快200印刷体清晰可辨较低中300小字放大后边界清晰最低慢实际生产中200dpi是性价比很高的起点。印刷体文档如果字体不小150dpi就能跑出不错的结果如果文档里有小字号脚注、表格里的密集数字建议直接用300dpi。但也不是越高越好原始扫描件本身分辨率不足时盲目调高渲染DPI只会放大噪点识别率不升反降。可以先200dpi试跑几页把识别结果肉眼扫一遍再决定要不要统一升到300。这里有个值得多说的细节渲染后的像素尺寸和OCR模型训练时的输入尺寸并不完全一致。PaddleOCR内置的检测模型会把输入图缩放到固定尺寸附近DPI太高导致渲染图特别大时一方面占用内存多另一方面OCR内部缩放反而丢失细节。所以DPI也不是无脑拉高让渲染图的短边控制在一个合理范围比如1500到2500像素通常比较合适。我这次大部分文档用200dpi跑遇到图特别小的老扫描件才单独提到300。4.2 中文与版式问题处理中文OCR的坑主要集中在三个方面竖排文字、多栏错序、特殊字符。竖排文字最让人头疼。旧书、规章制度里常有竖排标题PaddleOCR启用方向分类器后大多数竖排内容能被识别出来并恢复顺序但识别结果偶尔会和正文混在一起。如果文档里竖排内容很多可以额外检查一下OCR输出的方向置信度再根据置信度决定是否需要旋转图像后重新识别。多栏错序在论文、报纸、双语文件里特别常见。OCR默认按行从左到右输出遇到两栏排版时容易把左栏下半段刚读完就跳到右栏导致输出文本顺序混乱。对全文搜索这个需求来说这种错序影响不大因为检索只看关键字是否出现在文本层里但如果想把识别结果导出成可读的纯文本或者做段落级校对就需要自己写排序逻辑先按文本块的纵向坐标聚成行再在同一行内按横向坐标排序最后按栏位重组。这个逻辑不复杂但写起来要细心。特殊字符方面需要抽查。中文标点基本稳影响较大的是数字和英文之间的混淆比如0和O、1和l。扫描质量稍差时这类错误会明显增加。虽然不影响搜索场景但如果涉及金额、编号这类敏感信息建议对识别文本跑一遍正则校验把数字字段单独抓出来人工核对一遍。我这次处理的是归档合同类材料对合同编号字段专门做了比对抽验确认无误才交付。4.3 大批量处理的内存控制上千页的任务如果脚本写得粗糙跑着跑着内存飙升是常见问题。我这次的实际策略有三条。一是尽量缩短对象生命周期。PyMuPDF渲染出pixmap之后用了就释放OCR返回的result列表如果比较大处理完立即删除并手动触发一次垃圾回收不要让上一页的识别结果一直占用内存等下一页处理完才释放。二是控制同时打开的PDF数量。按文件逐个处理处理完一个就关闭一个。我之前试过一次性把所有PDF都加载进列表结果几百个文件直接占掉几个GB内存还没开始识别机器就卡死了。逐个打开、处理、关闭之后内存占用可以稳定在1GB以内。三是CPU推理的产能估算。PaddleOCR纯CPU模式处理一页大概1到3秒加上渲染和回写一个300页的PDF走完整个流程大约需要15到20分钟。一千页的批次预计要一个多小时。如果没有GPU批量任务最好拆成若干小批次安排在机器空闲时段跑不要一个脚本把全部文件串起来跑一整夜——真到半夜出问题排查成本非常高。5. 结果验证、兜底处理与工具化沉淀5.1 四种方式验证输出质量处理完一批我不会直接交付。验证分四层进行从快到慢。第一层直接看能不能搜到。在PDF阅读器里输入几个当前批次的高频词看命中数量和页面位置是否合理。这一步能快速排除大范围的坐标错位问题。如果搜索命中的页面和关键词所在的页码对不上说明回写环节大概率有bug。第二层用脚本提取新PDF的全部文本按页统计非空文本量。如果某些页面文本量异常低标记出来人工检查。这一步能发现OCR漏识别和空页问题也能顺带发现整批文件里混入了非扫描件但处理方式不同的异常文件。第三层抽样目测坐标对齐。打开处理后的PDF用阅读器选中一段识别出来的文本观察选框是否正好落在对应图像文字上方。偏差超过一两个字符的位置说明坐标转换可能有bug需要再检查缩放比例和Y轴翻转。这个检查看似粗糙却是最容易暴露坐标映射问题的环节。第四层针对数字、编码类内容做正则过滤抽查。比如把识别文本里的合同编号、手机号、日期字段统一提取出来和原始已知值比对。OCR对纯数字的识别错误率通常比汉字高所以涉及关键编号时必须单独抽验。我这次抽查了50条合同编号识别准确率达到了98%以上剩下的个位数错误也在人工校对阶段被修正了。5.2 特殊页面的兜底方案就算模型调得再顺总会有几页是识别黑洞比如整页印章、手写批注覆盖正文、大幅倾斜的老扫描件。这些页面不必强求百分之百准确但要想清楚怎么处理。整页印章和手写内容OCR基本识别不出来生成的文字层为空是正常的。这类页面通常是合同里的盖章页、签字页本身也不需要全文检索标注低置信度即可不影响整批交付。大幅倾斜的页面建议在OCR之前增加一步旋转校正。用图像处理工具检测页面文本区域的角度然后旋正图像能明显提高识别率。我这次在脚本里加了一个判断分支如果页面所有文本块的平均置信度低于某个阈值就自动做一次旋转校正再重新识别一次。这个策略对倾斜扫描件很有用但对整体模糊的页面帮助不大。分辨率极低的老扫描件是最麻烦的。可以先做灰度化、对比度增强再送OCR这比直接识别原始扫描图有效得多。如果增强之后还是不行就退回人工处理别和它死磕。批量任务不需要追求每一页都完美关键是知道哪些页面需要人工介入并把这些页面标记出来集中处理。我这次共识别了接近两千页最后单独挑出来的低置信度页面不到十页整体处于可控范围。5.3 把脚本改造成通用工具处理完这批文件我顺手把脚本参数化改造成了一个可以复用的命令行工具输入目录、输出目录、DPI、识别语言、是否生成中间日志全部通过参数控制。下次再遇到扫描件需求直接一条命令跑完不用再翻脚本改路径。这个工具我现在还在用每次接新的扫描件任务先花五分钟确认文件类型和批量规模然后套上这个流程就能直接开工。沉淀下来的通用价值其实不只是脚本本身而是整个处理流程的骨架类型判断—试跑验证—批量执行—质量抽验。这个流程几乎可以套用到所有PDF批量处理任务上哪怕是完全不同的PDF操作比如提取图片、拆分合并、批量加页眉页脚这套节奏都适用。它逼着你在动手前先想清楚文件是什么结构、预期输出是什么样、出了问题怎么定位而不是拿一个脚本闷头跑。最后就着这次经历说句实在话处理批量PDF最深的体会是开始动手前先花三分钟确认文档到底属于哪一类比什么都重要。PDF处理里的大多数坑其实都源于没有先想清楚文件结构就盲目上了工具。下次你再接到PDF处理需求先问自己一句这是有字的还是有图的往往就能避开一半以上的麻烦。