【免费下载链接】VI-Translate
你有没有遇到过这种情况：把一份 PDF 论文丢给翻译工具，正文倒是翻了，可公式里的上下标乱成一团、代码被当成英文硬翻、表格单元格错位？问题出在：翻译引擎根本不区分"哪段该翻、哪段不能动"。开源项目VI-Translate（PDF Translate）用公式占位符（Formula Placeholder）+ 保护区域（Protected Region）两套机制，让公式、代码、表格在翻译前后原封不动，只翻真正的人话。
一、普通翻译工具为什么会把公式、代码翻错？
翻译服务眼里，所有文字都是"句子"。它会忠实地翻译每一个词，包括：
- 数学符号：
x²、∑、≤被理解成乱码或拼错； - 代码标识符：
getElementById()被"意译"成一个不存在的词； - 上下标：
F1/b0这类堆叠记号被拆散重排。
结果就是：正文能读，但专业内容全毁。VI-Translate 的思路恰恰相反——先找出不能动的部分，把它们从翻译流程里隔离出来。
二、VI-Translate 的三道防线
整个保护流程可以拆成三步，核心代码都在pdf2zh/引擎里。
1. 第一步：靠"字体指纹"识别公式和代码
PDF 里的每一段文字都带着字体名。VI-Translate 用一组正则规则去匹配字体，判断它是不是"公式字体"或"代码字体"。这个函数叫is_formula_font()，位于 pdf2zh/rules.py：
FORMULA_FONT_PATTERN = re.compile( r"(CM[^R]|MS.M|XY|MT|BL|RM|EU|LA|RS|LINE|LCIRCLE|TeX-|rsfs|txsy|wasy|" r"stmary|.*Mono|.*Code|.*Sym|.*Math|.*Typewriter|Cousine|Consolas|Menlo|" r"Monaco|Inconsolata|Source.?Code|Fira.?Code|DejaVu.?Sans.?Mono|" r"Liberation.?Mono|Courier)" )一眼看懂它在抓两类东西：
| 类别 | 典型字体 | 含义 |
|---|---|---|
| 公式 / TeX | CM（Computer Modern）、TeX-、STIX、rsfs、wasy | 论文里排版的数学公式 |
| 等宽 / 代码 | Consolas、Menlo、Courier、Mono、Code | 程序代码、命令行 |
💡 命中规则的文字会被直接标记为"必须保护"，连翻译请求都不会进入——这是第一道也是最便宜的防线。
2. 第二步：用"公式占位符"把不能动的部分藏起来
有些公式用的不是特殊字体，而是普通字体 + 数学符号，或者混在正文里（比如F1/b0）。这种情况光靠字体认不出来，于是 VI-Translate 在编码阶段把这段文字替换成一个占位标签。
内部先用形如{v0}的标记，发送翻译前再编码成成对的<b0></b0>（翻译器友好的形式），由encode_formula_placeholders()完成，定义在 pdf2zh/translator.py：
原文: 根据公式 {v0} 可知，结果满足…… 发送: 根据公式 <b0></b0> 可知，结果满足……翻译引擎只看到<b0></b0>这种"无意义"的标签，它无法翻译、也不会改写，于是原样带回。真正被翻译的，只有标签之间的散文文字。
同样被保护的不止公式：Android 端还会把
x^2、e-5这类指数表达式单独包进占位符（见 FormulaPlaceholder.kt），避免上标被重排。
3. 第三步：翻译回来后严格校验 + 还原
译文回来后不能直接信任。restore_formula_placeholders()（pdf2zh/translator.py）会做两件事：
- 比对占位符：把原文与译文里的占位符按顺序拉出来逐一比对。只要翻译器改动、删除或乱序了任何一个标签，立刻抛出
FormulaPlaceholderError； - 还原标记：校验通过后，把
<b0></b0>换回{v0}，交给渲染层把公式按原始 PDF 算子重绘回原位。
加粗 / 斜体样式用同一套机制保护：<s1>、<s2>、<s3>通过栈匹配校验嵌套（validate_style_tags()，pdf2zh/translator.py），保证译文里"斜体还是斜体、加粗还是加粗"，不会交叉错位。
三、保护区域：表格、代码、图片为什么也安全
除了行内公式，VI-Translate 还有一批整块保护区域，它们根本不进翻译流程，而是作为"受保护布局区"保留。这套行为被写成一份产品契约，见 references/preservation-rules.md：
- 公式与代码：公式字形保留为原始 PDF 算子，翻译期间仅以占位符表示；等宽代码字体（Consolas、Courier、Menlo…）整块保护。
- 表格：只有当 PyMuPDF 能把单元格网格对齐到至少一半检测区域时才逐格翻译；无法可靠切分的表格整表保留原文，宁可留白也不乱翻。
- 孤立公式、图注、插图：一律作为受保护区域，位置不动。
- 目录、索引、符号表、参考文献：这类"位置即含义"的结构整页保留，避免把页码、编号翻进正文。
一句话总结这套理念：凡是不确定的，就原样保留，并如实报告为"部分翻译"，绝不假装翻完了。
四、占位符被翻译器"搞坏"了怎么办？（Fail-Safe）
这是这套设计最聪明的地方。假设某次网络波动或翻译模型抽风，把<b0></b0>悄悄改成了别的东西——传统工具要么崩溃，要么输出一页乱码 PDF。
VI-Translate 的选择是：宁可这一小段不翻，也不破坏整份文件。校验一旦失败，该段直接保留原文，并在日志里给出原因（占位符损坏 / 样式标签变化）。对应行为在 pdf2zh/rules.py 的保护规则和契约文档 references/preservation-rules.md 中都有明确规定：
"A damaged or reordered placeholder leaves its segment untranslated instead of corrupting the PDF."（损坏或乱序的占位符会让该段保留原文，而不是把 PDF 弄坏。）
五、动手看看：源码阅读与上手指引
想深入这套机制，按下面的路径读起来最快：
| 想了解 | 从哪里入手 |
|---|---|
| 公式 / 代码字体识别 | pdf2zh/rules.py 的is_formula_font() |
| 占位符编码 / 还原 / 校验 | pdf2zh/translator.py |
| 主翻译流程如何保护段落 | pdf2zh/converter.py 中的append_formula/replay_protected |
| 产品级保护契约（行为说明） | references/preservation-rules.md |
| Android 端指数 / 样式校验 | FormulaPlaceholder.kt |
| 回归测试（验证保护确实生效） | tests/test_preservation_rules.py、tests/test_inline_formula_layout.py |
命令行快速体验（无需安装 Python，下载桌面版解压即可用）：
# 从源码运行，用 Google 引擎翻译并保留公式 / 代码 / 表格 python scripts/translate_pdf.py INPUT.pdf --output-dir OUT写在最后
VI-Translate 让"公式、表格和代码不会被翻错"的答案其实很朴素：先把不能动的找出来，用占位符藏进翻译流程之外，回来再严丝合缝地校验并还原，实在不行就保留原文。没有魔法，只有一道字体指纹 + 一套占位符 + 一份"不确定就留白"的安全契约。
这套机制正是它区别于普通 PDF 翻译工具的核心——翻得动的翻得漂亮，翻不动的，绝不装模作样。
【免费下载链接】VI-Translate
相关推荐
draw.io Desktop：3 步免费搭起跨平台图表编辑器，Visio 文件直接打开
draw.io Desktop：3 步免费搭起跨平台图表编辑器，Visio 文件直接打开 上次同事发来一个 .vsdx 流程图，想在 Mac 上打开，要么掏钱买
桌面应用图形学Rust 编译器错误 E0121 详解：为什么类型占位符 `_` 不能出现在 item 签名中
Rust 编译器错误 E0121 详解：为什么类型占位符 _ 不能出现在 item 签名中 在 Rust 中，下划线 _ 是类型推断的占位符，但它的合法使用范围
编程语言编译器语言运行时标准库WeMD 一键复制公众号链路深度拆解：5个保真原理，公式图表不翻车
WeMD 一键复制公众号链路深度拆解：5个保真原理，公式图表不翻车 WeMD 是一款更优雅的 Markdown 公众号编辑器，主打"Markdown 写作、一键
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
