How-to

如何翻译扫描版 PDF 文件

扫描版 PDF 本质上是文本的图片，而不是真实的文本。这就是为什么包括谷歌翻译（Google Translate）在内的大多数翻译工具都会拒绝处理它们、返回空白文件，或显示“无法翻译此文件”的错误。要翻译扫描版 PDF，您需要在翻译前通过 OCR（光学字符识别）技术提取文本。DocTranslating 在其翻译流程中会自动运行 OCR，支持 100 多种语言，并将翻译后的文本重新嵌入到与原始 PDF 完全一致的副本中。为了确保重要文档的准确性，建议先在 PDFEquips 上检查 OCR 的识别结果，以免文本提取错误与翻译错误叠加，导致误导性结果。

更新于 2026年6月5日 · 8 分钟阅读

如果您曾将扫描版 PDF 上传到免费的在线翻译器，却只收到一个空白文件、诸如 “无法翻译此文件” 的报错，或者一份完全没有任何文本的翻译副本——请放心，这并不是您的操作问题。大多数在线翻译工具（包括谷歌翻译的免费文档上传功能）并不会对上传的扫描内容运行 OCR。本指南将为您解释其中的原因、翻译扫描版 PDF 真正需要的核心技术，以及如何在不丢失文档原始排版布局的情况下实现完美翻译。

为什么普通的翻译方法对扫描版 PDF 失效？

普通的 PDF 文件（例如从 Word、文本编辑器或浏览器导出的文件）包含一个隐形的文本层，翻译工具可以直接读取它。然而，扫描版 PDF 则完全没有这个文本层。当您扫描一份纸质文档时，扫描仪或手机摄像头捕获的实际上是每一页的照片（图片）。虽然结果看起来是文字，但对计算机而言，它仅仅是一个图像——底层没有任何可提取的数字文本。这就是为什么您通常无法在扫描版 PDF 中用鼠标选中文字：因为根本没有字符可供选择，只有像素。

大多数翻译工具都默认文档已经自带了文本层。当它们找不到文字时，就会以一种令人困惑的方式报错。常见的“症状”包括：

• 翻译器返回一个空白文件，或者一份与原文件完全相同、未经过任何语种翻译的副本。
• 系统弹出提示：“无法翻译此文件” 或 “无法识别此文档”。
• 只有后期数字化嵌入的元素（如页码、水印或表单字段）被成功翻译。
• 下载按钮保持灰色（不可点击状态），或者流程显示已完成但没有生成任何可用的内容。
• 同一个文件在某款工具中可以运行，但在另一款工具中却莫名其妙地失败，且没有任何明确的解释。

您真正需要的是：OCR 技术 + 智能翻译

翻译扫描版 PDF 在底层其实包含一个两步走的过程，即使由同一个工具同时处理这两个任务：

1. OCR 步骤：读取每一页的图片，提取出能够识别的文本——包括单词、数字和基本的排版骨架。
2. 翻译步骤：获取这些提取出的文字，进行语种翻译，然后将翻译好的文本精准地写回到一个全新的文档副本中。

当您上传扫描版 PDF 时，DocTranslating 会在后台自动执行这两个步骤，您无需自己先手动去进行 OCR。但有一个核心事实需要提前知晓：翻译的最终质量完全取决于 OCR 提取出的文本质量。模糊的扫描件会导致 OCR 识别出的文本出现错漏，而带有错漏的文本经过翻译引擎处理后，往往会使错误成倍放大。最终生成的文档读起来可能很通顺，但里面可能隐藏着微妙的词义错误，因此重要文档在投入正式使用前绝对值得仔细核对。

分步指南：如何翻译扫描版 PDF

1. 1

   打开 DocTranslating 并上传您的扫描版 PDF

   将文件拖放到上传区域，或点击浏览进行选择。工具会自动检测到该文件是 PDF；您不需要做任何特殊的设置来标记它是扫描件——系统会根据需要自动触发 OCR 流程。

2. 2

   设置您的原始语言（源语言）和目标语言

   选择文档目前所使用的语言以及您希望翻译成的语种。对于扫描版 PDF，建议明确指定源语言，而不是依赖“自动检测（Auto-detect）”——因为与干净的数字文本相比，自动检测功能在面对 OCR 提取出的文本时准确率会有所下降。

3. 3

   选择 Gemini 翻译引擎

   对于扫描版 PDF，Gemini 是目前最强大的选择。作为基于大语言模型（LLM）的引擎，当 OCR 产生部分文字破损或模糊时，它能够结合整段的上下文语境来推断出合理的词义；而像 DeepL 这种基于句子级别的传统引擎，则会直接把破损的错字照搬进翻译结果中。您还可以编写“自定义指令（Custom Instructions）”来保持整个文档中专业术语的一致性。

4. 4

   启动翻译，随后务必仔细检查翻译结果

   开始翻译流程，待文件准备就绪后将其下载，并与原文件逐页进行对比。要特别注意数字、日期、人名、地址以及任何关键的法律内容——这些地方通常是 OCR 识别错误的重灾区，因为翻译引擎在这里缺乏足够的语言上下文来进行自我纠错。

针对扫描版 PDF，哪款翻译引擎效果最好？

DocTranslating 上所有支持 PDF 上传的引擎都会对扫描内容运行 OCR 技术，但它们在处理不完美的 OCR 原始数据时，表现却大相径庭。没有任何一项 OCR 技术能保证 100% 的准确率——核心在于，当翻译引擎看到一个残缺不全的单词时会怎么处理。

在翻译前如何尽可能优化 OCR 的识别质量？

OCR 的最终成效几乎完全取决于您输入的原始文件。一份清晰、端正且分辨率足够高的扫描件能带来近乎完美的 OCR 文字；而一份黯淡、歪斜或低清的扫描件，无论用什么神仙工具，其 OCR 结果都会大打折扣。在上载文件前，以下几点优化非常值得一试：

• 如果可以接触到原始纸质文件，请以 300 DPI 或更高的分辨率重新扫描。低分辨率会让字体边缘模糊，导致 OCR 识别软件频繁看错字。
• 纠正歪斜的页面——OCR 引擎默认文本是在水平直线上排列的，倾斜的角度会严重干扰机器读取。
• 对颜色过浅或发灰的扫描件调高对比度（Contrast），让文本黑白分明，从而与背景划清界限。
• 务必确认文件没有设置密码保护——加密的 PDF 在解密前是处于完全锁定状态、无法读取的。
• 手动锁死源语言设置，特别是针对非拉丁字体的语言（如阿拉伯语、中文、俄语、印地语）。在面对 OCR 提取出的文本时，自动检测语言的功能远没有面对原生数字文本时那么灵敏。

特殊极端案例与当前的局限性

手写体文档（Handwritten Documents）

印刷体文本的 OCR 技术目前已经非常成熟和可靠。然而，针对手写体（Handwritten）文本的 OCR 识别则是一个业界公认的巨大难题，且目前的识别准确率在整个科技行业内普遍参差不齐——这并非单一工具的瓶颈。如果您的扫描版 PDF 属于手写笔记，请做好后期需要进行大量人工手动修正的准备。对于任何敏感的法律或商务文件，手动录入（听写转录）要比依赖机器 OCR 靠谱得多。

体积过大或页数过多的扫描件

Gemini 翻译引擎对单个文件有着最大 25 页和 100 MB 的严格限制。面对超出此限制的长篇扫描大件，您需要采用以下变通工作流：

从右至左书写语言（RTL）的扫描版 PDF

如果您正准备翻译一份由阿拉伯语、希伯来语或波斯语编写的扫描版 PDF，目前有一个已知的技术痛点需要注意：PDF 文本提取层可能会按照视觉渲染顺序（Visual draw order）而非逻辑阅读顺序（Logical reading order）导出 RTL 内容。这意味着，在翻译还没开始前，OCR 提取出的文字顺序就已经是颠倒或混乱的了。RTL 的 Word 和 PowerPoint 文件表现完美，而从其他语言翻译成 RTL 语言也完全正常——唯独以 RTL 语言为源文件的扫描版 PDF 会受到此技术限制的影响。如果您能拿到可编辑的原始文件，请尽量翻译原始文件。我们目前正在全力攻克这一 PDF 底层难题，但暂未百分之百完美解决。