PDF复制粘贴文字错误？请先诊断文本层
PDF看起来可能正常，但复制出来的文字或数字却是错的。使用四个示例文件来识别文本层问题，并选择可验证的修复方法。
如果PDF看起来正常，但粘贴出来的文字是错误的，请停止将粘贴的版本作为你的源文本。首先将一小段内容与可见页面进行对比：一个名字、一句话和一个数字。下一步取决于文件是没有可提取的文本、字符映射错误、隐藏的OCR文本层不准确，还是存在阅读顺序问题。对整个文档运行OCR并非对所有这四种情况都适用的正确第一步。
最危险的错误不是乱码。而是看似合理的文字：页面上写着 18个笔记本 ，而提取出的文字却是 13个笔记本。我们创建了四个可下载的PDF，以便在不使用任何人的私密文档的情况下，使这种区别变得清晰可见。
从一个小的复制并对比检查开始
保持原文件不变并打开一个工作副本。将一个简短的选择粘贴到纯文本编辑器中，然后逐个字符地将其与页面进行对比。在不同的页面上重复此操作，如果可行的话，在第二个PDF阅读器中也进行重复。这是一个诊断检查，而不是其余文档正确的证据。
| 现象 | 排查方向 | 首选的有用操作 |
|---|---|---|
| 无法选中任何内容，或者粘贴结果为空 | 页面可能仅包含图像 | 检查阅读器选中的是页面图像还是文本 |
| 字母持续发生变化，尽管在页面上看起来很正常 | 字符编码或提取映射 | 对比其他阅读器的输出；寻找原始源文件或更好的导出格式 |
| 大多数单词可读，但名称或数字错误 | 文本层不准确，包括旧的OCR | 将提取的段落与可见的扫描件进行对比 |
| 字母正确，但分栏、标题或脚注出现的顺序错误 | 布局与阅读顺序提取 | 单独测试单列或单个段落 |
| 复制功能已被禁用 | 文档权限或阅读器行为 | 检查文件的权限并向来源索取可用的副本 |
这些只是线索，而不是根据单一症状识别所有 PDF 内部机制的方法。Adobe 的 内容复用指南 区分了纯图片内容与复制限制。这两者都不应自动被视为文本层受损。 pypdf 提取指南 则分别描述了图像、文本提取，以及表格和间距处理方面的难点。
对于长篇书籍或报告，请记录每个问题出现的 PDF 页码。干净的封面并不能说明附录、扫描插页或双栏章节是否能被正确复制。
四个 PDF：页面显示内容与提取结果的对比
我们的测试页包含四行原始文本，其中包括：
该归档文件包含 18 个笔记本。
项目 B-204 于 5 月 6 日到达。
我们制作了一个正常的数字 PDF，并故意构建了三个替代版本。然后，我们使用 Poppler 和 pypdf 提取了它们的文本。两个提取器对该测试中的每个文件都返回了相同的文本。
| 下载 PDF | 构建方式 | 实际提取结果 |
|---|---|---|
| 正确的数字文本 | 带内嵌字体的正常可见文本 | 18 notebooks; B-204; 6 May |
| 错误的 Unicode 映射 | 在不改变可见字形的情况下更改了提取映射 | 13 notebooks；几个小写的 a 字符变成了 x |
| 错误的正文隐藏文本 | 在页面图像上方故意放置了错误的不可见文本 | 13 notebooks; B-2O4; 8 May |
| 纯图像页面 | 使用了没有文本层的相同页面图像 | 文本输出为空 |
一个看起来正常的数字页面可能会复制出错误内容
在我们的对比中，前两个 PDF 呈现出相同的像素，但提取出的文本却不同。在第二个文件中，我们有意更改了一个 ToUnicode 映射：用于将存储的字符代码映射到 Unicode 文本的信息。可见的数字仍然是 8，而提取结果返回的是 3。 pypdf CMap 文档 说明了这种映射机制。
这展示了一种故障机制，并不是说每个乱码 PDF 都存在相同的缺陷。仅凭缺失的 ToUnicode 条目并不能作为我们的诊断结果，手动编辑映射也不是面向普通读者的通用修复方法。
可搜索的扫描件可能包含错误的单词
第三个和第四个 PDF 的呈现效果彼此也完全相同。一个包含错误的不可见文本；另一个则完全没有。在第三个文件中，提取过程悄悄更改了一个数量和一个日期。代码 B-2O4 包含字母 O，而不是图像中显示的数字 0 。
这些错误是我们自己插入的，用来模拟隐藏文本层可能包含的不匹配情况。OCR 引擎 并没有 生成这些错误。第四个文件则呈现出相反的情况：一个可读的页面图像，但这些文本提取器没有任何内容可供返回。这与 pypdf 记录的局限性一致：它提取现有的 PDF 文本，但不识别图像内部的单词。
此项测试确立了什么——以及它没有确立什么
2026 年 9 月 10 日，我们使用 Poppler 26.08.0 和 pypdf 6.10.0 检查了四个单页文件。视觉对比使用了 144 dpi 的 Poppler。像素一致性保持在 这两组内部，而非跨越所有四个文件：基于图像的那一组经过了额外的渲染步骤。
这是一个受控演示，而非 OCR 准确度基准测试。它不测试多语言识别、复杂布局、Acrobat 修复、OCRmyPDF 修复或 BookTranslator 上传。这些是具有已知缺陷的构造示例，而非盲测评估。
相关的 原始文本和像素结果, 复现说明以及 生成器 已随文件一同提供。它们使用了未经修改的 Noto Sans 字体及其附带的开源字体许可证。
选择干扰最小的下一步方案
以下修复路径源自官方文档和实际诊断。它们 并非上述四个文件实验的修复结果。请在副本上进行操作，并在替换任何重要内容之前验证输出结果。
如果你有源文档，请先尝试重新导出
从原始文字处理、出版或排版文件重新生成的 PDF 是首选方案。请仔细对比出错的段落。不要假设有了新文件名或导出成功就意味着文本已经正确。
对于从存档或出版商处获取的资料，请检查是否存在其他包含文本的版本。保持版本和页码引用一致：不同版本的更清晰文件可能无法保留你需要的段落。
如果扫描件有少量识别错误，请检查这些词汇
Acrobat 在 扫描和 OCR → 纠正识别的文本下记录了一个工作流。它允许你根据扫描图像检查标记的可疑词汇，并纠正识别出的文本。请遵循 Adobe 当前的纠错说明 以操作你所用版本的界面。
不要将空的可疑列表视为完整性测试。请独立对比你将引用或翻译的姓名、日期、标识符和数量。我们故意出错的 13 notebooks 示例说明了为什么可读输出是不够的。
如果隐藏文本大面积错误，请区分重新做（redo）与强制（force）
对于使用命令行工具的读者，OCRmyPDF 为已经包含文本的页面记录了不同的路径：
--redo-ocr会移除现有的不可打印 OCR 文本并重新识别，同时将可打印文本排除在 OCR 之外。--skip-text会跳过包含文本的页面。这并不是对现有错误文本层的修复。--force-ocr会将页面内容光栅化，并对生成的图像运行 OCR。
这些行为描述于 OCRmyPDF 的现有文本错误文档中。在第 17 版中，也可以通过 --mode获得等效的选项；旧的标志仍然保留为别名。
这其中存在代价和例外。重做（Redo）无法识别每种历史 OCR 排列方式；某些文件会在技术上可打印的文本上放置不透明图像。强制（Force）会将可打印文本和矢量内容转换为像素并展平交互式内容。重做和强制还会丢弃现有的结构树，而不是重建它。请在选择其中任何一个之前查看 OCRmyPDF 的高级文档 。
因此，修复后的提取并非无障碍（accessibility）检查。如果文档需要标题、阅读顺序或无障碍图形，请使用单独的 已翻译的 PDF 无障碍检查.
如果页面或语言不同，切勿假定一种设置适用于所有情况
列出哪些页面已经包含可信的数字文本，哪些页面需要识别。在配置 OCR 之前，请检查受影响页面上的语言。我们的 混合语言 PDF OCR 指南 涵盖了语言选择；这与确定旧文本层是否错误是不同的决定。
如果根本没有文本层，请转到 扫描版 PDF 工作流。反复尝试另一个纯文本提取器并不能让 pypdf 识别图像中的文字。
在使用替换文本之前进行验证
使用 可下载的文本层检查表 ，以便将可见参考、先前的提取和替换提取并排保存。从已知故障开始，然后测试不同的段落和任何明显不同的页面布局。
- 字词： 逐字比较名称和不熟悉的术语。
- 数字： 检查数量、小数点、日期以及诸如
B-204. - 顺序： 跨换行符阅读完整的段落；分别检查分栏和附近的标题。
- 覆盖范围： 确认没有遗漏您需要的页面和段落。
- 文件行为： 重新打开保存的替换文件并重复复制测试。如果您依赖书签、链接或可访问结构，请一并检查。
通过选择的段落只能证明这些段落的情况，并不能保证整个文件的准确性。请保留原始页面图像作为参考，尤其是在纠正引文或不熟悉的语言时。
只有在可以信任源文件后再进行翻译
如果您的目标是引用段落或做笔记，经过验证的提取可能就是终点。您不需要翻译服务来完成该任务。
如果您需要用另一种语言阅读整个文档，请将验证过的文件作为 PDF 翻译的起点。BookTranslator 的 OCR 模式从识别的内容中重建翻译后的 PDF；它并不承诺修复任何现有的文本层或完全复制原始页面布局。
在翻译步骤中保留参考页面。此处检查过的相同数量和标识符属于 最终的 PDF 翻译 QA 阶段。流畅的翻译本身无法告诉您其源文本本应说 18 而不是 13.
