和模型聊天聊出来的二进制汉化方法论（实战版）

---

> 本文整理自一次从 Dehancer OFX 插件汉化的长谈——一个汉化老玩家的手艺，被逐条问出来、再写成规则。> 这套方法不是学院派的，是从以前「一天两三个插件」的实战磨出来的，到今天加上了人机协作的部分。

---

一、心法：先搞清楚为谁翻译

1. 用户画像决定翻译标准

- 科班、专业人士不需要汉化，他们看得懂原版。- 真正需要汉化的是「做这行但不是科班」的人：会操作，但英文术语是拦路虎。- 所以标准是：**准确但不装逼**——科班人才懂的准确 + 非科班一看就懂的表达。- 两头都不讨好，只有中间那撮人才是你的用户。

2. 准确性是用来堵内行的嘴，但不是给内行看的

- 内行不看汉化，但他们会第一个发现错误。- 术语错，用户看不懂；术语太专业，用户也用不上。- 译文两头服务：给用户看得懂，给内行挑不出错。

3. 功能性验证：拿不准就拖素材

- 翻译前先搞懂画面：拖一个素材进去，看这个参数到底改了什么，再决定怎么翻。- 比如： - Push / Pull → **迫冲 / 减冲**（暗房工艺术语，不懂胶片的人翻不出来） - Film Gate → **片门**（摄影机的标准中文名词） - Vignette Feathering → **应用于暗角的羽化值**（帮助提示中的汉化，不仅仅是名词短语） - Fringe Removal Radius → **去彩边半径**（彩边是影视圈对色差的俗称，观众一看就懂）

4. 术语策略：直译打底，语境校准，压缩收尾

- 汉化字典只认识词，不认识画面。同一个词在不同上下文语感完全不同： - Density：色彩密度 / 密度校正 / 打印密度，各有各的说法。- 字典只作参考，不作枷锁：怕的是字典把上下文抹平。- 压缩的前提是理解：敢把长句缩成短语，是因为确定意思没丢。 - 「懂」和「敢删」是一体两面。

---

二、找串：字符串考古学

1. 先探测编码，再谈别的

- GBK：汉字 2 字节；UTF-8：汉字 3 字节；UTF-16：汉字 2 字节（1:1 替换，不涨长度）。- 工具的「编码」列比「地址」列更重要。一旦编码错了，后面全错。

2. 一个串可以有多个身份

- 帮助文本可能同时是下拉项的来源：程序用「指针 + 偏移」引用字符串中间的一段。- 实例：`"White Balance". One of: As Shot, Auto, Daylight, Cloudy, Shade, Tungsten, Fluorescent, Flash, Custom` ——UI 上的「自定义」其实是这串尾部的子串。- 工具显示「一条字符串」，UI 显示「一个下拉项」，两者都对，但工具永远不会告诉你这个秘密。

3. 单词会藏在长句里

- 实例：UI 显示 "Color Density"，二进制里是 `printCorrectionColorDensity`。- 对策：按 UI 上看到的词去搜**子串**，而不是搜整串。

4. 字符串池可能是乱的

- 一个插件可能混着多个字符串世界：OFX 界面串、图像元数据库（Exiv2）、PostScript 片段、相机数据库、过滤词表……链接器把它们扔进同一个大池子，还按内部顺序重排。- 本地化工具的「分组」可能会骗人，但「地址」是真的。- 找不到规律时，老老实实一个一个搜。不是工具不行，是文件天生不给本地化工具活路。

---

三、翻译：带着字节预算翻译

1. **字数 = 字节预算**：目标编码定下后，每条串的预算就定了。 - GBK 时代「File→文件」4 对 4，不涨；UTF-8 时代「File→文件」6 对 9，每句都超长。 - 先算差额再动手：超长的列清单，有余量的列清单。2. **压缩原则**：在不丢意思的前提下压成短语：控件装得下，用户读得快。3. **格式符保护**：`%s` `%d`、`&` 快捷键、`\n`、占位符，一个都不能动。4. **术语一致性 vs 语境准确性**：先语境，后一致；同一个词在不同地方可以有不同译法，但要确保每个地方都对。

---

四、落地：编码转换与大挪移

1. 原地流（最稳）

- 字符串不动，程序永远找得到它，没有漏改引用的风险。- **超写**：译文比原文长，直接覆盖原位，头部或尾部追空隙。- **腾挪**：把不重要的长句翻短，挤出空间，给超长的串用。- 适用：引用方式特殊、改不了指针的串。这是手动汉化最不容易翻车的流派。

2. 搬家流（空间无限，但要改引用）

- 英文原件留原地，中文副本写进空白区，只把**显示引用**改指中文，逻辑引用一个不碰。- 适用：一个串被两处引用（一处显示、一处逻辑）时的标准解法：复制一份，而不是拆一份。- 风险：漏改一个引用就乱码或崩溃。所以能原地就原地。

3. 容量规划

- 超长清单 ↔ 余量池自动配对；余量不够时，找「翻短收益最大」的长句下手。- 多出来的字节优先往填充区（节对齐空隙、00 填充）里吃。- 实例：「自定义」9 字节替换「Custom」6 字节，+2 字节被后面的填充吸收，零损伤。

4. 编码转换的坑

- GBK 译文直接抄进 UTF-8 版必出乱码：汉字 2 字节 → 3 字节，物理上塞不回原位。- 转码必须重新做，不能照搬旧翻译。不是手艺退步，是数学变了。- 语义转换避免超长：「不透明度」→「透明度」，语义上无损，但节省空间。

---

五、安全：引用、自检与记录

1. 区分两种引用

- **显示引用**：弹窗 / 菜单 / 输出文本，翻译只影响看到的字。- **逻辑引用**：拿字符串去比较、查表、当 key 写存档，翻译会让功能悄悄坏掉。- 判断法：对字符串地址下内存访问断点，看谁在读它、读它做什么。- 「翻译了出 bug、不翻译没事」= 这串有逻辑用途，先找到全部引用再动手。

2. 自检

- 改完重新解析 PE：节表、导入表、重定位表有没有被改坏。- 手动改的时候这步最容易被跳过，而它恰恰是翻车高发区。

3. 改动记录（最重要的习惯）

- 旧偏移 → 新偏移、新旧字节对照，一条条记下来。- 用途一：软件出新版，对 diff 重放改动，不用从头再摸一遍。- 用途二：本身就是第二重指纹，比水印更难洗。

---

六、署名与底线

1. 署名水印

- 在译文里埋一个**全文件唯一**的私有串（非必须，但如果你想要追责 / 免责）。- 常规情况下一般放 About；字符串池太乱时放哪都行；验明正身。- 在意想不到的地方署名：别人拿去卖钱，搜字符串即可确认出处；想洗掉它反而可能弄坏程序。

2. 底线

- 记住你的初心：这是一个用爱发电的事情。- 如果汉化的文件来源本就不合法，不要二次变现。- 灰色地带也分层次：个人学习自用为上，无偿分享次之，收费变现最黑。

---

七、人机协作流水线（2026 版）

人出判断，机器出体力：

| 步骤 | 人（判断） | 机器（体力） ||---|---|---|| 1. 定范围 | 在工具里找要翻的串，给地址 | 按地址核验、列候选清单 || 2. 翻译 | 字典 + 语境定稿，只审不查 | 批量翻译、格式符保护、术语表对齐 || 3. 编码 | 决定目标编码 | 探测原编码、统一转换、算每条字节差额 || 4. 挪移 | 拍板哪些不能动 | 容量规划、腾挪配对、生成改动记录 || 5. 验收 | 实测：跑一遍看效果 | PE 自检、引用完整性检查 |

---

> 判断权永远在人：哪些串值得翻、翻完会不会撑爆控件、哪些地方真的不能动。> 机器只是把「找串、转码、腾挪、记录」这些累活接过去。> 汉化不难，但是累，累的活就该交给机器。