翻译
如何翻译文档而不丢失其格式
翻译后的文档格式会被破坏，是因为大多数工具将您的文件还原为纯文本，翻译后再猜测所有内容的位置。这就导致了表格散乱、列合并、页眉丢失。解决方法是使用能识别文档真实结构的翻译引擎，并将引擎与文件类型相匹配：Office文件、PDF和代码在不同的引擎上都能被完美翻译。本指南解释了为什么格式会损坏，以及如何为每个任务选择合适的引擎。
更新于 2026年8月27日 · 8 分钟阅读
您上传了一份排版整洁、已经完稿的文档。但得到的却像是经过碎纸机粉碎后又被胶带粘在一起的东西。文字翻译得完全正确，但是付款表格却被拆分到了两页，两列的排版现在变成了一条长长的文本带，页眉也融入了正文之中。现在您面临着一个小时的排版清理工作，这比翻译本身节省的时间还要多。
这是文档翻译中最常见的抱怨，而且几乎从来不是关于语言质量的。这是关于结构的。一旦您了解了为什么会发生这种情况，修复方法就很简单了，通常归结为一个决定：您将文件发送给哪个引擎处理。
为什么翻译会破坏格式
一个基础的翻译器按顺序做三件事：从您的文件中提取文本，翻译该文本，然后将其倒回。问题在于第一步丢失了什么。当文本被提取出来时，排版信息留在了原处，所以工具必须猜测如何重新组装页面。正是这些猜测破坏了表格和分列。
PDF文件让情况变得更糟。与Word文件不同，PDF并不算是一种真正的“文档”。它是一组指令，描述了标记在页面上的位置，而不是这些标记的含义。它没有内置的、可靠的“这是一个表格”或“这是第二列”的概念。因此，当翻译器拆解PDF时，它必须在重建它之前推断其结构，如果这个推断有丝毫错误，排版就会崩溃。
“保持格式”实际上意味着什么
并非所有的格式破坏都是一样的，也并非所有的工具都在同一个地方出错。当人们说翻译“保持了格式”时，他们通常是指以下这些元素完好无损地保留了下来：
- 表格：行、列、合并单元格和边框保持不变，翻译后的文本放置在正确的单元格中。
- 页眉和页脚：页码、标题和页眉在每一页上都得以保留。
- 多列排版：两列和三列的页面不会折叠成单一的文本流。
- 强调和层级：粗体、斜体、标题级别和列表缩进都被保留，而不是被抹平。
- 图片和标题：图片保持在原位，旁边的文字也被翻译了。
有些工具在文本样式上做得很完美，但却破坏了表格。另一些工具保留了图片，但却弄平了您的分列。我们的目标是找到一个能同时处理好所有这些问题的工具，当该工具翻译的是文件真实结构而不是将其扁平化后的副本时，这种可能性要大得多。
真正的解决方案：将引擎与文件相匹配
这是几乎所有指南都会跳过的部分。在保持格式方面，没有哪个翻译引擎是绝对最好的。只有最适合每种文件类型的引擎。一个能完美翻译DOCX的工具可能会完全拒绝PDF；一个在PDF上表现完美的工具可能会有严格的大小限制。诀窍不在于寻找一个神奇的引擎，而在于为您眼前的任务选择合适的引擎。
这正是为什么 DocTranslating 允许您为每个文件单独选择引擎，而不是强迫所有文件都通过一个管道处理。以下是四个引擎的实际比较，以便您自己进行匹配。
| 引擎 | 最适合 | 文件类型 | 大小限制 | 注意事项 |
|---|---|---|---|---|
| Microsoft Azure | Office文件 (Word, PowerPoint, Excel) | DOCX, PPTX, XLSX, HTML, MD, TXT | 20 MB | 不直接支持PDF |
| Google Cloud | 表现最稳定的全能选手，包括PDF | PDF, DOCX, PPTX, XLSX | 10 MB | 大小限制最严格 |
| DeepL | 在多数语言对中翻译质量最高 | DOCX, PPTX, XLSX, TXT, HTML, SRT 等等 | 30 MB | 在排版密集的PDF上偶尔会出现格式问题 |
| Gemini | 代码文件和多语言混合文档 | PDF和代码（JS, TS, Python等） | 100 MB（25页限制） | 对长PDF有页数限制 |
处理顽固 PDF 的 Office 文件技巧
如果您的PDF在翻译后总是面目全非，专业人士通常会使用一种可靠的变通方法：不要直接翻译PDF。先将其转换为Word，然后翻译Word文件（Word的结构清晰，正是Azure的强项），如果需要，再转换回PDF。虽然多了一步，但因为Word文件确实存储了它的结构而不仅仅是外观，所以这样做的结果比直接翻译PDF要好得多。
这样做之所以有效，原因很简单：Word 文件将其格式存储为结构，因此翻译后仍能保持完好；而 PDF 只存储外观，必须重新构建，往往就会出错。
扫描文档怎么办？
有一种情况这些方法都无法直接奏效：扫描版PDF。扫描件是页面的照片，因此根本没有可供翻译的文本，只有像素。在翻译之前，必须先识别文本并从图像中提取出来。这就是OCR（光学字符识别）。
DocTranslating 的 OCR 工具可以处理这个问题，它能从扫描件中读取超过50种语言的文本，包括手写体。因此，扫描的合同或存档的证书都能像其他文档一样被翻译。如果您想了解完整的步骤，这里有一份关于如何从扫描版PDF中提取文本的专门指南。
发送文件前的核对清单
无论您使用哪个引擎，在将结果发送给客户或办公室之前，花两分钟检查一下。将原件和翻译件并排打开，检查以下几点：
- 表格是否仍然对齐，正确的文本是否在正确的单元格内？
- 每页的页眉、页脚和页码是否都在？
- 多列或两列的部分是否仍然保持分列？
- 是否有任何内容溢出了文本框或超出了页边距（通常是由于文本膨胀导致）？
- 粗体、斜体和标题级别是否仍在它们应有的位置？
现在发现一个错位的表格只需要片刻时间。如果等客户指出来后再去解决，代价就要大得多。
总结
当满足这两个条件时，排版格式就能在翻译中幸存下来：该工具处理的是文档的真实结构，而不是扁平化的副本；且该引擎真正支持您提交的文件类型。将Office文件交给Azure，PDF交给Google，对质量要求极高的任务交给DeepL，而代码或多语言文件交给Gemini，大多数重新排版的噩梦就会自然消失。
是平台新用户？DocTranslating 使用完全指南为您演示了如何上传文件、选择引擎以及下载翻译后的文档。
常见问题解答
如何翻译PDF而不丢失格式？
使用专为PDF构建且保留排版格式的翻译器，而不是将文件扁平化为纯文本的翻译器。在DocTranslating上，Google Cloud是处理PDF最稳定的引擎。对于难以处理的PDF，通常最稳妥的做法是先将其转换为Word，翻译Word文件，然后再转换回PDF，因为Word文件明确地存储了其结构，而PDF仅存储其外观。
哪个引擎最适合Word、PowerPoint和Excel文件？
Microsoft Azure在处理Office格式时最强。它能让DOCX、PPTX和XLSX文件看起来和原件一样，因为它翻译的是文档的底层结构，而不是从头开始重建排版。
为什么我的文档翻译是正确的，但排版看起来却乱七八糟？
因为翻译准确性和格式排版是两个不同的问题。大多数工具提取出文本进行翻译，然后试图猜测如何把页面重新拼凑起来。文字是对了，但猜测的排版却崩溃了：表格散乱，列合并，页眉丢失。使用能够识别文件真实结构的工具就可以避免这种情况。
我可以翻译扫描版PDF吗？
可以，但这需要额外的一步。扫描件是一张图像，所以如果不使用OCR从页面上读取出文字，就没有可翻译的文本。DocTranslating的OCR工具能识别50多种语言的文本，包括手写体，能将扫描件变成可翻译的文档。
对于代码或混合多种语言的文档，我应该使用哪个引擎？
Gemini。它是这四个引擎中唯一能够翻译代码文件（JavaScript, TypeScript, Python等）的，也是唯一能够处理混合了多种源语言的文档的引擎。它接受最大100 MB的文件，但限制在25页以内。