测试边界与前提说明
本文讨论的是Word 文档（.docx）翻译后格式保留的问题。测试样本为一篇约 15 页的中文 Word 文档，包含标准正文段落、3 个表格（含合并单元格）、5 张内嵌图片、若干脚注以及目录域代码。没有一种方案在所有文档结构下都表现最优——不同文档的排版复杂度、图片密度、表格嵌套层数都会改变结果。本文的目的不是推荐某个工具，而是帮你判断在什么情况下优先尝试哪种思路。
以下三种方案各有适用边界，你可以根据自己的文档结构和可投入的时间来评估。
方案一：另存为 PDF → 翻译 → 导出 Word（PDF 中转）
这是目前实操中格式保留最稳定的一条路径，核心逻辑是：用 Word 自带的「另存为 PDF」把 .docx 转成结构固化的 PDF，再用支持 PDF 翻译并导出 Word 的工具完成转换。
操作步骤
样本测试结果
| 正文段落排版 | 段落间距与首行缩进基本保留 |
| 表格（含合并单元格） | 表格结构完整，合并单元格未拆分 |
| 内嵌图片 | 位置和尺寸保留，但部分图片偏移 2–3 像素 |
| 目录域代码 | 丢失——翻译后变成纯文本，不可刷新 |
| 脚注 | 编号与正文对应正确，位置正常 |
优缺点
优势：PDF 格式固化后，排版被"锁住"，翻译工具不需要处理 Word 内部的复杂 XML 结构，格式保留度在三方案中最高。
主要限制：目录域代码、交叉引用、宏等 Word 特有功能在转换过程中丢失；翻译完成后想修改文本内容，需要手动调整排版。
这条路更适合那些排版已经定稿、不需要后续大量编辑的文档，比如合同、标书、产品手册终稿。
方案二：直接上传 .docx 到在线翻译工具
部分在线翻译工具宣称支持 .docx 文件直接上传翻译，不经过 PDF 中转。
操作步骤
样本测试结果
同一份 15 页测试文档，在三个不同的在线翻译工具上测试（结果取表现最好的那次，非平均）：
| 正文段落 | 段落结构保留，但部分字号和行距被重置为默认值 |
| 表格 | 简单表格正常；含合并单元格的表格出现列宽偏移 |
| 图片 | 基本保留，但图片的「文字环绕」属性丢失，变为「嵌入型」 |
| 文本框 | 严重错位——文本框内容翻译了，但位置漂移到页面边缘 |
| 页眉页脚 | 翻译成功，但字体回退为默认字体 |
优缺点
优势：一步完成，不需要导出 PDF 再上传的中转步骤；翻译后的 .docx 可以直接编辑，对于还需要继续修改的文档更友好。
主要限制：Word 文档的排版复杂度直接影响结果——简单报告类文档表现尚可，但含文本框、分栏、嵌入对象的复杂文档问题较多。根本原因在于 .docx 的底层是 Open XML，文本分布在大量 XML 节点中，翻译工具需要正确地只替换文本内容而不破坏 XML 结构，这在工程上比处理扁平的 PDF 更难。
如果你手里的 Word 文档排版比较简单（主要是正文段落 + 简单表格，没有文本框和分栏），可以直接试这条路径；如果排版复杂，建议先另存 PDF。
方案三：Python 脚本提取文本 → 调用翻译 API → 重建文档
如果不想受在线工具的格式损失限制，可以自己写脚本控制流程。
核心思路
代码示例
from docx import Document
from docx.shared import Pt, RGBColor
import requests
def extract_runs(paragraph):
"""提取段落中每个 run 的文本和格式"""
runs_data = []
for run in paragraph.runs:
runs_data.append({
"text": run.text,
"bold": run.bold,
"italic": run.italic,
"font_name": run.font.name,
"font_size": run.font.size,
"color": run.font.color.rgb if run.font.color and run.font.color.rgb else None
})
return runs_data
def translate_text(text, source_lang="zh", target_lang="en"):
"""调用翻译 API（示例 endpoint）"""
resp = requests.post(
"https://api.example.com/translate",
json={"text": text, "source": source_lang, "target": target_lang},
timeout=30
)
if resp.status_code == 200:
return resp.json().get("translated_text", text)
return text
def restore_runs(paragraph, runs_data, translated_text):
"""将翻译后的文本写回，保留格式"""
# 简化处理：将整段翻译文本写入第一个 run，后续 run 清空
if runs_data:
first_run = runs_data[0]
paragraph.runs[0].text = translated_text
for attr in ["bold", "italic", "font_name", "font_size"]:
val = first_run.get(attr)
if val is not None:
setattr(paragraph.runs[0], attr, val)
if first_run.get("color"):
paragraph.runs[0].font.color.rgb = first_run["color"]
# 清空其余 runs
for i in range(1, len(paragraph.runs)):
paragraph.runs[i].text = ""
def translate_docx(input_path, output_path):
"""主流程：翻译 Word 文档"""
doc = Document(input_path)
for para in doc.paragraphs:
if not para.text.strip():
continue
runs_data = extract_runs(para)
translated = translate_text(para.text.strip())
restore_runs(para, runs_data, translated)
# 处理表格
for table in doc.tables:
for row in table.rows:
for cell in row.cells:
for para in cell.paragraphs:
if para.text.strip():
translated = translate_text(para.text.strip())
para.runs[0].text = translated if para.runs else translated
doc.save(output_path)
print(f"翻译完成，已保存至 {output_path}")
if __name__ == "__main__":
translate_docx("sample_zh.docx", "sample_en.docx")
代码的局限性（务必了解）
优缺点
优势：完全控制翻译流程，可以接入任意翻译 API，格式控制粒度最细，适合需要批量处理且对格式要求高的场景。
主要限制：开发和调试成本高，复杂文档的完整重建可能需要几百行代码；每次 Word 版本更新或文档结构变化都可能需要调整脚本。
这条路适合有开发资源、需要批量处理大量同类型文档的场景，比如技术文档团队的文档国际化流水线。
三种方案对比总览
下表基于同一份 15 页中文 Word 测试文档（含表格、图片、脚注、目录域代码），目标语言英文：
| 正文格式保留 | 高（间距/缩进基本不变） | 中（字号/行距可能重置） | 取决于代码覆盖度 |
| 表格保真度 | 高（合并单元格不乱） | 中（复杂表格列宽偏移） | 中（嵌套表格支持有限） |
| 图片与环绕 | 中（位置保留，环绕变嵌入） | 低（环绕属性丢失） | 不处理（需 OCR 单独做） |
| Word 特性保留 | 低（域代码/宏丢失） | 低（域代码/宏丢失） | 极低（几乎全丢失） |
| 翻译后可编辑性 | 中（PDF 转换后编辑受限） | 高（直接编辑 .docx） | 高（直接编辑 .docx） |
| 操作复杂度 | 低（两步操作） | 最低（一步完成） | 高（需写代码调试） |
| 适合文档类型 | 排版已定稿的正式文档 | 排版简单的报告/论文 | 同类型文档批量处理 |
优先试用建议
-
如果你最在意排版保真度，且文档已经定稿不打算大幅修改：可以先试方案一（PDF 中转）。这条路对表格、图片、段落间距的保留效果目前最稳定，但要做好目录域代码丢失的心理准备。
-
如果你的文档排版简单、还需要反复编辑：方案二（直接上传 .docx）最省事。上传前可以把文本框内容手动移到正文、取消分栏，减少格式丢失点。注意检查翻译后字体是否回退。
-
如果你需要批量处理几十上百份同类文档，且有开发能力：投入时间写一套方案三的脚本是值得的。建议先从小批量（5–10 份）开始测试，验证脚本对你们文档格式的覆盖率，再上量。
需要强调的是：以上建议有前提条件。如果你的文档既包含复杂排版又需要高度可编辑，目前没有单一方案能完美兼顾——你可能需要组合使用（例如先走方案一拿到基础翻译，再在 Word 中手动微调格式），或者接受一定程度的格式损失。
做翻译前后的格式检查清单
无论选择哪种方案，建议翻译前后做好以下检查：
建议做样本测试时，用一份 3–5 页的代表性文档先跑一遍，对照原文逐一比对，确认方案可行后再批量操作。
FAQ
Q1：为什么 Word 翻译后排版总是乱？
根本原因是 .docx 的底层是 Open XML——文本、格式、图片、表格等信息分布在大量的 XML 节点中。翻译工具需要在替换文本的同时保持 XML 结构不被破坏。表格、文本框、分栏等元素在 XML 中不是线性排列的，翻译时容易出现节点对应错误，导致排版错乱。
Q2：扫描件或图片里的文字怎么翻译？
如果 Word 文档里嵌入了扫描图片（而不是可编辑的文字），任何翻译方案都先需要 OCR（光学字符识别）把图片中的文字提取出来。可以先用 OCR 工具把图片文字转成可编辑文本，替换掉原来的图片，再用上述三种方案之一翻译。如果图片不多，手动提取可能比 OCR 更可控。
Q3：翻译后表格列宽变了怎么办？
方案一（PDF 中转）这个问题最轻。方案二和方案三都可能出现列宽偏移。临时的补救方法是：在翻译前记下原始表格的列宽（可以在 Word 的「表格属性」中查看具体数值），翻译后手动调回。批量操作时，可以用 python-docx 在脚本中硬编码列宽。
Q4：如何判断用哪种方案更合适？
看三个维度：排版复杂度（表格嵌套层数、是否有文本框和分栏）、可编辑性需求（翻译后是否还要改）、文档数量（单份还是批量）。排版简单 + 需要编辑 → 方案二；排版复杂 + 已定稿 → 方案一；数量大 + 格式要求高 + 有开发资源 → 方案三。
Q5：在线翻译工具上传文档有隐私风险吗？
有。上传文档到在线工具意味着你的文档内容会经过第三方服务器。如果文档包含敏感信息（合同条款、客户数据、商业计划等），建议优先选择方案三（本地脚本 + 翻译 API）或方案一（确认所选工具的隐私政策中明确不存储文档内容）。上传前建议脱敏处理或使用测试文档先验证流程。
专注AI文档翻译技术、出海本地化实战与翻译工具选型评测
