中文互联网上流传着一首很没道理的打油诗：「手持两把锟斤拷，口中疾呼烫烫烫。脚踏千朵屯屯屯，笑看万物锘锘锘。」据维基百科「中文乱码」条目、百度百科「锟斤拷」与萌娘百科等公开资料，这四句其实分别对应三类不同的编码事故。果壳网早年那则问答里还有个更逗的后续：一位网友回忆大一上机课，照着书抄的程序跑出一排「烫烫烫」，他真以为电脑过热在报警，弯腰把插头拔了。这类笑话在技术圈传了十几年，后来连游戏台词都拿它玩梗；对译员来说，它好笑之外还有点扎心——文件有时不是被翻错的，是在到手之前就已经坏了。
四句各有来历。「锟斤拷」出自字符集转换：Unicode 遇到无法表示的字符，会用替换字符 U+FFFD 顶上，它在 UTF-8 里编码为 EF BF BD；当这样的字节连续出现、又被按 GBK 两两拆开读，就成了锟（EFBF）、斤（BDEF）、拷（BFBD）。关键在于它是「有损」的：替换字符一出现，原来的字节已被丢掉，事后无论怎么转码都回不来。「烫烫烫」和「屯屯屯」来自另一处：Visual C++ 调试模式会把未初始化的栈填成 0xCC、堆填成 0xCD，在 GBK 里 0xCCCC 正好是「烫」、0xCDCD 是「屯」；早年命令行程序用代码页 437 的制表符「═」（0xCD）画窗口边框，换到代码页 936，边框就成了一串「屯屯屯」。最后一句「锘锘锘」是 UTF-8 文件开头的字节顺序标记 BOM（EF BB BF）被按 GBK 读，前两字节解成「锘」，于是 http 显示成「锘县 ttp」、public 变成「锘縫 ulic」。四句诗把三种互不相干的故障凑成一幅武侠画面，好笑就好笑在这里。
这不是译错，是源文件已经坏了
把乱码当成「译得不准」是常见的误会。翻译处理的是意义和措辞，乱码处理的是字节被换了一种解释方式：同样的 EF BF BD，按 UTF-8 读是一个替换字符，按 GBK 读是三个汉字，谁都没翻错，是读法从一开始就选错了。更麻烦的是有损那一类——U+FFFD 意味着原始字符在转换时已被丢弃，屏幕上那几个汉字看着像内容，其实只是坑的形状。这时候凭上下文「猜回原字」，跟凭空补一句原文没有的话没有区别。译员能做的第一件事不是补救，是判断：这是编码问题、字体问题，还是提取问题；然后回源，请对方重发一份可复制、编码明确的原始文件，而不是在坏掉的文本上继续加工。顺带说一句，这类事故与语言水平无关，再熟的译员也挡不住一个存错格式附件。
方框、豆腐块、问号，不是同一回事
屏幕上的空白也分几种。字体里没有某个字，会显示成空心方框，圈内叫 tofu，换字体或嵌入字形就能解决，文字数据本身是好的；PDF 与扫描件提取出来的错字、漏笔画、把「己」认成「已」这类，属于识别环节的问题，要回到清晰原件核对；而满屏「锟斤拷」是字节级损坏，只能回源。三者的处置完全不同，混在一起处理最常见的后果是：明明只是缺字体，却整份重译一遍，白忙一场；明明已经丢数据，却挑了个看起来通顺的字填进去。先分类，再动手，是这行最不显眼也最值钱的一个习惯。
证件稿最怕「顺手补一笔」
笑话归笑话，落到日常稿件就没那么轻松了。姓名、证件号、签发机关、有效期、印章文字，一旦在乱码或缺字处断掉，最忌讳按常见写法补齐：一个偏旁、一个数字、一个连字符，都可能让整叠材料互相矛盾，受理方退回来的理由往往只是「与原件不符」。稳妥做法是原样标记待核、单独列一张疑问清单、回原件逐项确认；确实拿不到清晰原件的，宁可注明情况也别替原件下结论。这条规矩和公司篇里说的「锁专名表、不猜着补」是同一条，只是从递交端换到了译员桌上。做证件类稿件久了会形成一种近乎迷信的谨慎：越是看起来「肯定是这个字」的地方，越要回去看一眼原件。
四个不花时间的习惯
说到底都是些笨办法：收到文件先原样另存一份，绝不在原件上覆盖；确认编码与字体，交付统一用不带 BOM 的 UTF-8，需要保留其他编码时另行说明；术语表与专名表单独存一份纯文本，跟稿件分开保管；交付前用最朴素的方式把姓名、编号、日期、金额肉眼过一遍，别只看排版漂亮的成品。行业篇讲的是高价值产品出口时一整套文本要互相对齐，而这一篇讲的其实是它的前提——文件先得是完整的。那句打油诗之所以能笑十几年，是因为每个跟文字打交道的人，都在某个下午见过满屏的「烫烫烫」；笑完记得问一句：这份源文件，谁替你核过原文？