PDF复制乱码先分清错字和缺字

同样叫“PDF 复制乱码”排查动作可能完全不同。屏幕上的字已经显示错了和原页清楚却取出错误内容是两种需要区分的情况。我用一份自己生成的单页通知练习排查时先把页面文字和抽取结果摆在一起看。这个区分很有用。没有先确定哪一步出错就去换字体、改编码或者开 OCR很难判断到底改好了什么。通知里的内容都是为这次排查生成的测试文案没有使用真实单位发的材料。原稿的 5 行包含中文日期和一行英文留下的源文案刚好可以作每次提取后的对照。我保留一份正常 PDF再做两种改动删除字体的 ToUnicode 映射以及把“假”的映射改成“真”。这里只改了文字对应关系且没有修改字形。实验是在 2026 年 9 月 30 日做的结论也只覆盖这一组文件。先看提取结果丢了什么删除映射的那份文件很容易看出异常。在 PyMuPDF 1.26.5 的提取结果中原来能统计到的 56 个汉字变成了 0 个英文和不少数字仍然存在。这份并非空白的结果很容易让只检查有没有文字的人觉得提取已经成功。我又按相同方法把未经清理的原始字符串保存下来。控制字符也是线索。先删掉它们会让我失去观察提取器实际返回内容的机会。这里最容易弄混的是“看不见”和“没有内容”。有些字符被提取出来后没有正常字形。编辑器可能显示方块也可能几乎看不出占位。本次样本的实际输出包含控制字符就不能笼统地描述成复制后得到了一串方块。要分清这两种情况可以先用编辑器的不可见字符显示功能观察再看所用工具导出的原始文本。换一种显示方式后才露出的符号只是诊断线索。正文还没有修好。我还检查了经常被用来识别坏文本的替换字符 UFFFD得到的数量是零。这个检测漏了。这份中文已经不能直接使用的结果让我不敢再把“没出现黑菱形问号”当作放心使用的理由。更可靠的起点是从原页挑一句自己读得懂的文字逐个比对输出而不是只在结果里搜索某个典型乱码符号。汉字还在也可能已经错了第二份改动更隐蔽原页仍然显示“放假通知”提取后却成了“放真通知”。通知里的另一个“假”也跟着变了一共 2 处文字受影响。汉字数量没有减少的同时也没有出现肉眼一看就觉得不对的随机符号。问题在这里。只统计中文比例甚至再检查文本长度这份结果都有机会混过去。读一眼关键用词就能发现不对。图里三栏列出的是本地实验实际保存的提取内容不是在模拟某款产品的界面。看第三栏的“放真”再看汉字计数就能理解为什么计数正确还不够。三份 PDF 在 MuPDF 1.26.10 中按相同条件渲染的图逐像素相同。每张图都是 893×1263 px 的事实和逐像素比较结果只能证明这次渲染没有外观差异。它没有替文本输出作担保也不代表我测过所有阅读器。换路线以后仍要认原文把故障定位到取字之后我才继续试补救。我用的是 图映 ImgIng 的 PDF 内容提取在同一份缺映射通知上对照开启和关闭图片文字识别的结果。两次完全一致的输出中依然找不到原本应该出现的中文标题和通知内容。按钮已经开了也不等于它重识别了整页。至少对这个纯文字样本不能把这条路线记成成功。后来用已有的清晰页面 PNG 做图片 OCR五行文字恢复到可读状态后还需要继续拿源文案核对其中几个日期是否一致。但这里有个前提PNG 来自外部渲染图映本次 PDF 转图片报了错误不能把两个环节说成一条顺畅跑完的流程。恢复出的中文空格还和源文案有区别。只要文字时也许可以接受这点差异。要保留排版或精确空白就得另设验收条件。这次让我记住的排查顺序很朴素先截取原页的一句文字作为参照再保留抽取原样最后才做清理或换路线。不要急着覆盖旧结果。处理自己的 PDF 时可以从姓名、日期和标题各挑一处核对。如果只是显示成方块就还需要检查粘贴软件的显示能力字符本身已经从“假”变成“真”时继续换显示字体就不是在验证同一件事了。