PDF文本提取踩坑记录——为什么你的翻译工具读到的内容和你肉眼看到的不一样

前阵子帮同事处理一批英文技术文档的翻译用的PyMuPDF提取文本再丢给翻译API结果翻完发现有些段落完全对不上。排查了两天才搞明白原因写出来给踩同样坑的人省点时间。问题复现一份看起来很正常的PDF用肉眼看内容清清楚楚。但用代码提取出来的文本跟视觉上看到的顺序不一致甚至有些字根本没提取到。提取出来的文本段落顺序是乱的。有些在页面上看到的文字提取结果里根本没有。原因PDF的文本层和视觉层是两回事PDF内部存储文本的方式跟你在屏幕上看到的不一定一致。常见的情况有几种。情况一文本块顺序不对PDF用text block组织内容每个block有自己的坐标。渲染时按坐标排列但提取时如果不指定排序方式可能按block在文件中的存储顺序返回而不是按视觉上的从上到下、从左到右。加sortTrue之后大部分情况下顺序就对了。但不是所有PDF都吃这套。情况二隐藏文本层这是最坑的一种。有些PDF看起来是图片扫描件转的但背后其实带一层隐藏的OCR文本。你肉眼看到的是图片代码提取到的是OCR结果——而OCR结果可能有错字、漏字、顺序混乱。判断方法这种情况下的隐藏文本质量完全取决于当初OCR的精度。如果OCR做得差提取出来的文本本身就是错的后面不管怎么翻译都是错上加错。情况三字体编码问题有些PDF用了自定义字体编码提取出来的文本是一堆乱码或者问号。这种情况在日文、韩文PDF里比较常见。遇到这种情况PyMuPDF基本没辙得上OCR。实际处理方案我把踩坑之后的处理流程整理了一下。这段代码不完美有些边界情况没处理比如多栏排版、页眉页脚干扰但日常用够了。如果不想自己折腾上面这些坑排查完之后我才发现整份PDF翻译这个场景其实已经有现成工具处理得不错了。后来遇到英文文档翻译需求我直接把PDF拖进PDFTranslatorpdftranslator.org整份翻它内部帮你处理了文本提取、排版保持这些事翻完拿到的PDF跟原文档结构一致不用自己写pipeline。当然如果你的需求是批量处理、定制化翻译、或者需要接入自己的翻译模型自己搭pipeline还是有必要的。但如果就是想把一份英文PDF翻成中文看没必要从零造轮子。