读外文 PDF 这件事几乎每个做技术、做研究、做外贸单证的人都绕不开。真正让人头疼的从来不是“看不懂”而是看得懂却读得慢一篇三十页的双栏论文公式、图表、脚注、参考文献层层嵌套复制一段正文丢进翻译框出来的是公式炸成乱码、段落顺序彻底打乱、上下标全丢的残骸。想要一份既保留原版排版、又能读懂意思的译本过去要么靠人工重排要么忍受整页截图 OCR 出来的错字。pdf2zh 这类工具之所以在圈子里被反复提起核心就在于它把“解析—翻译—重排”这条链路做成了可复用的流水线输出的是排版基本忠实原文、公式和表格不散架、还能同时给你单语版和双语对照版的两个 PDF。这篇内容我打算从安装环境一路讲到参数调优和踩坑排查面向的是手上有英文文献、技术手册、外文标准文档需要处理的人刚入门的小白能照着命令直接跑通已经用过一两次、觉得效果时好时坏的老手也能在后半部分找到排错思路和成本估算方法。1. PDF 翻译的真正难点卡住的是复原不是翻译1.1 复制粘贴为什么永远做不好这件事很多人对 PDF 翻译的第一层误解是把它当成“文本翻译问题”。实际上 PDF 从诞生那天起就不是为了承载“文本”而设计的它承载的是“绘制指令”。你在阅读器里看到的一段话在文件内部可能被拆成几十个独立的文本块每个块带着自己的坐标、字体、字号、旋转角度、字距微调。阅读器按坐标把这些块画到页面上肉眼看上去是连贯的段落可一旦你选中复制取出来的顺序取决于文件里对象的排列而不是视觉上的阅读顺序。这就是为什么双栏论文复制出来经常左右栏串行也是为什么公式里的积分号和上下限会跑到句子末尾去。更麻烦的是字体子集。生成 PDF 时很多软件只嵌入用到的字符子集并且把字符编码改成自定义映射。你复制出来的“文本”在文件里可能压根不是 Unicode而是一串私有编码。这类文件在翻译工具里会直接变成方块或者乱码跟翻译质量毫无关系纯粹是取词环节就断了。理解这一层你就能明白后面所有工具选型的逻辑谁能把 PDF 的“版面结构”还原出来谁才有资格谈翻译质量。1.2 pdf2zh 的处理链路拆成三段看pdf2zh 的定位是命令行工具思路可以拆成三段来看。第一段是版面解析把 PDF 页面拆成若干“可翻译单元”同时识别出哪些区域是不可动的——图片、矢量图形、公式块、表格线框。这一步决定了后面排版能不能保住。第二段是文本翻译把每个单元的文本内容送去翻译后端这里的后端是可插拔的你可以接在线通用翻译接口、也可以接大模型接口、还可以接本地推理服务。第三段是重排与回写把译文按原单元的边界框重新塞回页面字号不够就缩、行数变多就调行距实在放不下就溢出到旁边的空白区。这个设计和“整页扔给 OCR 再整页重新排版”是两条完全不同的路。后者的产物是一篇新文档版式跟原文没关系了前者的产物是“原文的替身”你翻到第 12 页看到的图 3跟原文第 12 页的图 3 是同一个位置。做文献综述的人应该能立刻体会到这个差别的价值引用页码、对照图表、跟同行讨论“你看第三页那个式子”全都不需要重新建立坐标。1.3 几类常见方案摆在一起比一比方案排版保留公式处理处理速度适用场景复制文本到翻译框无基本全毁快纯文字短段落、邮件、网页整页截图 OCR 翻译弱需重排识别错误率高中等扫描件、图片型 PDF在线文档翻译服务中等部分保留取决于队列商务合同、通用文档pdf2zh 这类版面感知工具较强保留为图形不动中等偏慢论文、技术手册、标准文档表格里最后一行才是这篇要展开的主角。它的优势不在于翻译得更“信达雅”而在于它知道哪些东西不该动。公式、化学结构式、电路图、流程框图这些内容一旦被当成文本送去翻译结果必然是灾难把它们识别为图形区域原样保留反而让译文可用性大幅提升。2. 环境准备三条安装路线与选型逻辑2.1 路线一用包管理器直接装最省事的路径是用 Python 的包管理工具从包索引仓库拉取。我一般推荐用 uv 而不是裸 pip原因是这类工具依赖树不小uv 的解析和缓存速度快很多装完不会把全局环境搞脏。基本形态是先建一个独立虚拟环境再在里面安装uv venv .venv source .venv/bin/activate uv pip install pdf2zhWindows 下激活脚本换成对应目录下的可执行文件即可。装完直接敲pdf2zh --help能打出帮助信息就说明入口脚本挂上了。这一步最容易出问题的地方是 PATH如果提示找不到命令多半是虚拟环境没激活或者脚本装进了用户级目录但那个目录不在 PATH 里。我的习惯是永远在项目目录下建虚拟环境不搞全局安装出问题直接删目录重来比排查依赖冲突快得多。如果你的机器上有多个 Python 版本务必确认虚拟环境用的是 3.10 以上。低版本在解析某些用了新语法特性的依赖时会直接报错而且报错信息往往指向一个跟你操作毫无关系的模块很容易让人误判。2.2 路线二容器化运行隔离依赖当你的系统里已经有一堆互相打架的 Python 环境或者需要在多人共用的服务器上跑批量任务容器方案会更稳。思路很简单拉一个带完整运行时的镜像把本地 PDF 目录挂载进容器命令照常在容器里执行。好处是依赖全部封在镜像内不会污染宿主机坏处是要处理文件权限和挂载路径映射尤其是输出目录的写权限Linux 下经常出现容器里写出来的文件属主是 root、宿主机上改不动的情况。处理办法是在启动容器时显式指定用户 ID 和组 ID或者在跑完之后统一改一次权限。这一点看着琐碎但在做几百篇批量翻译时很关键——脚本跑到一半因为写不进文件而中断排查起来相当浪费时间。2.3 硬件门槛到底卡在哪一步很多人以为这类工具吃显卡实际测下来纯翻译流程里最耗资源的是版面解析那一步的模型推理。如果你只用在线翻译后端显卡不是必需品CPU 也能跑只是慢一份三十页的论文用中端 CPU 大概几分钟到十几分钟量级具体取决于页面复杂度和是否启用了额外的版面识别能力。真正需要显卡的场景是“翻译后端也放在本地”——也就是大模型推理自己扛。这时候显存需求取决于模型规模七 B 级别的量化模型在消费级显卡上能跑但吞吐很低几十页文档排着队跑一晚上是常态。我的建议很明确先把在线后端跑通确认整条链路和输出效果符合预期再考虑本地化。上来就折腾本地部署很容易在环境问题上耗掉全部耐心连工具本身好不好用都没验证到。另外提醒一句磁盘空间要留够。解析中间产物、字体子集、双份输出文件一篇论文占几十兆是正常的批量处理时临时目录很快就能吃满。3. 翻译后端选型质量、速度、成本的三方权衡3.1 三类后端的能力边界pdf2zh 把翻译后端做成了可切换的插件式结构通过参数指定用哪一家。粗分下来是三类。第一类是通用在线翻译接口特点是快、便宜甚至免费、术语稳定但长句处理和上下文中的人称、被动语态转换比较死板遇到专业术语经常给出通用领域的释义。第二类是大模型接口长句连贯性和术语理解明显更好能根据上下文把缩写还原成完整表达代价是按量计费长文档成本会累积。第三类是本地推理服务把模型跑在自己机器上隐私最好、长期成本最低但首次部署麻烦、速度受硬件制约。我的实际搭配是这样的正文类、叙述性强的章节用大模型后端参考文献列表、附录的表格、参数表这类内容用通用接口批量过一遍就够了没必要为了一堆数字和作者名付费。工具本身支持按页码范围分段处理你可以把同一篇文档拆成两三次跑分别指定不同的后端最后手动合并——虽然麻烦一点但在成本敏感的场景下很值得。3.2 成本估算怎么算才靠谱按量计费的后端成本取决于字符数而不是页数。经验值是一页标准双栏论文的正文大约三千到五千字符含公式和图表说明的页面会少一些。这里有个换算要提醒中文译文的字符数通常比英文原文少三到四成但计费一般按输入输出双向算所以别只按原文长度估。粗算公式是这样总成本约等于输入字符数 × 输入单价加上输出字符数 × 输出单价其中输出字符数按输入的 0.7 倍估。一篇三十页的文档字符量在两万到十万之间浮动具体看排版密度。跑之前建议先拿前五页试一次看看实际消耗再决定要不要全量跑。我见过有人一口气把几百页的手册扔进去结果账单出来才发现里面的目录和索引页占了将近三成字符纯属浪费——这类页面完全可以跳过不翻或者用页码参数把它们排除掉。3.3 术语一致性靠术语表不靠模型自觉翻译长文档最怕的是同一个术语前后译法不同。第二章叫“吞吐量”第五章变成“通过量”读者会很困惑。指望模型自己保持一致是不现实的每一段都是独立请求它看不到前面译过什么。解决办法有两个一是准备一份术语对照表在支持自定义提示的后端里把这些固定映射塞进去二是先在文档里做一次全文检索把核心术语列出来翻译完成后逐一检查译法是否统一发现偏差就批量替换。第二种办法笨但有效。我处理技术手册时一般会先花十分钟把出现频率最高的二十个术语抓出来做成一个简单的替换脚本译完之后跑一遍。这一步的收益比调任何参数都高因为它直接影响可读性。特别注意产品名、型号、单位符号——型号通常不该翻译单位符号要保持原样这两个地方被“翻译”了会闹笑话。4. 核心参数逐个拆解一条命令跑通一篇论文4.1 最小可用命令和它产出的东西最精简的用法就是给一个输入文件pdf2zh paper.pdf默认行为是按配置里的源语言和目标语言处理全文在输入文件同目录下生成两个 PDF一个单语版原文内容被替换成译文一个双语版通常是原文与译文对照或者是译文按段落附在原文旁。文件名一般带后缀区分比如paper-mono.pdf和paper-dual.pdf。我一开始也不理解为什么要出两份。用久了才体会到这两个版本的用途完全不同单语版适合通读和打印页面干净双语版适合精读和校对尤其是你需要确认某个技术细节的原始表述时能立刻左右对照。做技术文档审校的人应该会喜欢双语版因为术语翻译有争议时可以直接看原文。4.2 语言对和页码范围两个最常用的开关语言对通过两个参数指定一个是源语言一个是目标语言用语言代码表示比如英文到中文就写-li en -lo zh。源语言尽量别偷懒写自动检测虽然工具可能支持但检测错一次整篇就白翻了。中文和日文、韩文之间有大量共用汉字自动检测在这几种语言上翻车概率不低明确指定最保险。页码范围参数用来只处理某几页接受单个页码或者区间多个区间可以用逗号分隔。这个参数的价值被严重低估了。它至少有三个用途试跑验证效果、跳过封面目录和参考文献、把超长文档拆成几段分别处理。我处理一百页以上的手册时习惯按章节拆成五到八段每段跑完立刻检查发现问题只重跑那一段不用整篇重来。pdf2zh manual.pdf -li en -lo zh -p 1-20 -o ./out4.3 输出目录、并发数和排版保留相关的开关输出目录参数决定产物落在哪批量处理时一定要显式指定否则文件散落在各处很难管理。并发参数控制同时处理的任务数默认值偏保守页码多的文档可以适当调高但要看你用的翻译后端有没有速率限制——免费接口调太快通常会被限流表现是大量请求失败或者返回空内容。排版相关的开关里最值得关注的是字体处理。译文用的是中文字符而原 PDF 里嵌的英文字体不包含这些字形工具需要做字体替换或者追加字体子集。这里常见的坑是某些 PDF 用了特别刁钻的嵌入方式替换后中文显示成方块或者豆腐块。遇到这种情况先试试换一个字体参数指定一个系统里确定存在的字体如果还不行就考虑放宽对排版的要求让它以更宽松的方式重排。还有一个容易忽略的点是公式保护。部分版本对公式区域的处理方式是识别为图形后原样保留这个行为通常不需要额外配置但如果你发现某些行内公式被当成普通文本翻译了说明版面解析没识别出来可以考虑先用 PDF 编辑工具把那几行标记出来单独跳过或者在参数里调整识别灵敏度。4.4 批量处理写个循环比什么都实在工具本身不一定带批量目录扫描但写个 shell 循环就够了mkdir -p ./out for f in ./papers/*.pdf; do name$(basename $f .pdf) pdf2zh $f -li en -lo zh -o ./out -p 1-40 echo $name done done这个脚本加了进度回显跑批量时很重要——几百个文件排队处理没有输出你根本不知道跑到哪了。更进一步可以加错误捕获把失败的文件名记到一个日志里跑完统一重试for f in ./papers/*.pdf; do if ! pdf2zh $f -li en -lo zh -o ./out 2 ./error.log; then echo $f ./failed.txt fi done批量处理还有个隐形问题命名冲突。如果两个子目录里有同名文件输出会互相覆盖。解决办法是把输出路径带上原目录的相对路径或者干脆一个文件一个输出子目录。5. 实操现场一篇双栏论文从解析到成品的全过程5.1 第一步先判断这份 PDF 有没有文本层拿到任何 PDF我的第一个动作不是直接跑翻译而是用阅读器试着选中一段正文复制出来。能复制出通顺的英文说明有文本层走正常流程复制出来是空白、或者是一堆乱序字符、或者压根选不中那就是扫描件或者字体编码有问题的文件得先做预处理。扫描件的处理路径完全不同需要先做 OCR 把文字层叠加上去再交给翻译工具。这一步的识别质量直接决定最终效果因为版面解析看到的是 OCR 给出的文字块。中低质量的 OCR 会把1和l、0和O搞混专业术语更是错得离谱翻译出来自然一塌糊涂。我的经验是扫描件先花点时间做一次高质量 OCR比事后修译文省力得多。5.2 第二步解析阶段到底发生了什么跑起来之后工具先做的是页面元素分类。它需要判断哪些区块是正文段落、哪些是标题、哪些是图注、哪些是表格。双栏排版在这里是个考验因为一页里有左右两条独立的阅读流解析器必须先把栏分开再在每栏内部按纵向顺序拼接段落否则就会串行。这一步出错的表现很有特征译文读起来像是把左右两栏的行交替拼在一起语义完全断裂。遇到这种情况先确认原 PDF 是不是用了非常规的分栏方式比如三栏、或者栏内还有嵌套的文本框。有些期刊的排版确实会玩花样工具识别不了属于正常现象这时候可以考虑把页面裁切后分栏处理。表格是另一个难点。工具一般会把表格整体识别为一个不可翻译区域而原样保留这其实是合理的策略——表格里的文字如果被逐格翻译列宽会全部崩掉反而更难读。所以我处理含大量表格的文档时心理预期就是“表格保留原文正文翻译”需要读懂表格内容时再单独处理。5.3 第三步译完之后怎么校对效率最高全篇逐字校对是不现实的我的做法是分层检查。第一层看结构翻到中间几页确认图表位置没偏移、页码对得上、目录条目还在。第二层看关键段落摘要、引言最后一段、方法部分的核心描述、结论——这几处的翻译质量基本能代表全文水平。第三层看术语把事先列出的高频术语在译文里搜一遍确认译法统一。双语版在这里的价值就体现出来了。读到某句译文觉得别扭时直接对照原文判断是译文生硬还是原文本身表述就绕。有些英文长句是作者故意写得复杂译文跟着复杂其实是对的不该改有些是模型没理解从句关系那就需要人工介入。分得清这两种情况校对效率能提高一大截。5.4 成品验收清单跑完之后我会按这几项过一遍任何一项不过关就回到相应环节调整页数与原文一致没有缺页或多页图表位置与原文对应编号未错乱公式区域未被翻译仍为原始图形中文字体渲染正常无方块、无重叠段落顺序符合阅读逻辑双栏未串行页眉页脚、页码未被误翻参考文献列表的处理方式符合预期最后一项要特别说明。参考文献里的作者名、期刊名、年份翻译了反而是负担。有些版本默认会跳过参考文献区域有些不会。如果发现被翻了用页码范围把它排除掉最省事。6. 踩坑实录与排查速查表6.1 安装和启动阶段的典型故障现象可能原因处理方式提示找不到命令虚拟环境未激活或入口脚本不在 PATH重新激活环境或用完整路径调用安装过程卡在编译依赖缺少系统级编译工具链装好编译工具或改用预编译包启动报模块导入错误依赖版本冲突新建干净虚拟环境重装运行中内存占用飙升页面复杂度过高用页码范围分段处理容器内输出文件无法修改挂载目录权限映射问题指定用户 ID 启动或事后改权限安装问题九成出在环境不干净。我的固定做法是每接一个新任务就新建一个项目目录虚拟环境建在里面跑完整个目录归档下次要用直接复用不跟别的项目混。6.2 翻译阶段的失败模式最常见的是请求失败。表现是部分页面译文为空、或者整篇只翻了前几页就停住。原因通常有三类后端接口限流、密钥额度耗尽、网络请求超时。排查顺序是先看日志里的错误码再手动发一个最小请求验证后端是否可用最后调低并发数重试。并发数这个参数是双刃剑调高能提速但免费额度下很容易触发限流反而更慢。第二类是译文质量断崖式下跌。同一篇文档前面翻得好好的后面突然变成机翻腔。这种情况多半是中途切换了后端或者某个后端额度用尽自动降级了。跑长文档时建议盯着日志确认全程用的是同一个后端。第三类是重复翻译或漏翻。页面里如果有跨页的段落解析器可能把它当成两个独立单元各翻一遍读起来就是重复。这种只能人工处理找到位置删掉一段。6.3 版面错乱的三种成因和对策版面问题是最影响观感的按成因分三种。第一种是文本框溢出译文比原文长塞回原来的框里放不下字号被缩到极小或者文字压到图形上。对策是允许工具在必要时扩展文本框或者干脆接受稍微宽松的排版别死抠原位置。第二种是阅读顺序错乱双栏、多栏、侧边栏混排时容易发生。对策是预处理阶段把侧边栏、注释区裁掉只留主内容区。第三种是字体缺失中文渲染成方块。对策是指定一个确定存在的字体文件。6.4 扫描件和特殊文档怎么处理扫描件的预处理顺序是先 OCR 加文字层、再检查文字层质量、最后翻译。OCR 阶段建议保留原始图像层只叠加文字这样翻译工具做版面解析时还能看到原始的图形边界。纯图像 PDF 直接翻译结果基本不可用。还有一种特殊情况是加密 PDF。有编辑权限限制的文件工具读不了内容得先用其他手段解除限制。这类操作要注意文件的来源和使用授权只处理自己有权限处理的内容。7. 进阶把这个工具接进日常工作流7.1 图形界面和脚本化的取舍这个工具有一个内置的本地网页界面启动后浏览器打开就能用上传文件、选参数、点按钮适合偶尔用一次的场景。但我更推荐把命令行跑熟原因是可复现、可批量、可写进脚本。网页界面每次都要手动选一堆参数跑十篇文档就是十次重复劳动命令行写成一个函数传文件名进去就行。7.2 和笔记、阅读器配合的用法我的工作流是这样的新收到一篇文献先跑双语版快速扫一遍判断值不值得精读值得精读的把单语版导入阅读器做标注标注时遇到术语疑问再回查双语版标注完的内容整理进笔记系统术语和关键结论单独摘出来。这套流程里翻译只是第一道粗筛真正的价值在于它把“读不读”这个决策的成本降到了几分钟。如果你的阅读器支持按页跳转和书签建议在翻译前给原文加上章节书签输出的译本一般会继承这些结构后续定位会方便很多。最后分享一个我自己反复验证的小技巧处理不确定效果的文档时永远先用页码范围跑前三页看完再全量。这三页的成本几乎为零但能帮你提前发现字体问题、栏位问题、后端问题——比跑完三十页再返工划算太多。另外术语表这件事值得养成习惯每处理一个新领域就积累一份攒到第三份的时候你会发现译文质量的天花板其实是由术语一致性决定的而不是由你选了多贵的翻译后端。
