简介：Restorator 2009 是一款面向软件开发者、翻译人员和普通用户的专业汉化与本地化工具，可深入 EXE、DLL、RES 等程序资源文件，对菜单、对话框、图标、位图等进行可视化编辑，即使没有编程背景也能相对轻松地上手。压缩包为 RAR 格式，整体仅 3MB，下载便捷。目前已有 201 人学习/下载。借助这款工具，用户不仅能完成文本资源的直观替换与批量搜索，还能调整控件布局以适配不同语言，对比多版本资源以管理汉化进度，并依靠自动编码识别避免乱码；预览功能可实时查看修改效果，最终支持导出翻译与生成汉化补丁，适合个人或团队进行软件界面汉化与本地化定制。
1. 汉化工具 Restorator 2009：为什么老工具至今还能打
遇到一个只有英文界面的绿色小软件，最直接的想法是用十六进制编辑器搜字符串、手工替换。真这么改过的人都知道，翻车概率极高，一个字节的偏移错位就能让程序直接启动失败。Restorator 2009 是汉化工具里口碑很稳的一档：它把 PE 文件里的字符串表、对话框、菜单、版本信息等资源按类型和 ID 排列成树状结构，双击就能改，保存后直接写回原文件。它不负责翻译，但负责把中文干净利落地写回 exe 而不破坏程序结构。适合软件汉化入门者、做本地化交付的开发者，以及需要给老工具补中文界面的运维同事。
2. 先搞懂 PE 资源模型：字符串表、对话框、菜单与版本信息的汉化顺序
Restorator 不是文本替换器，是 PE 资源编辑器。PE 文件除了代码段，还包含一个资源段，里面按「类型 → ID → 语言」三层组织。类型包括字符串表、对话框、菜单、位图、图标、版本信息等。Restorator 2009 左侧的资源树就是把这个三层结构可视化出来。汉化时你改的是资源段，不是代码段，这是它能安全改写的关键。如果连这个模型都不建立起来，后面很容易出现「明明改了字符串，程序里却没有任何变化」的怪事。
2.1 字符串表与版本信息：风险最低，先动这两个
字符串表，左侧资源树里显示为 String Table，是 PE 资源类型编号 6。双击进去，右侧是一个表格，列大概是编号、语言和值，值那一列就是程序界面里实际显示出来的英文原文。修改时只动值列，编号和语言列不要碰。字符串表存储按 16 个为一组，ID 1 到 16 是一块，17 到 32 是下一块，所以找长文本时用 Ctrl+F 直接搜值文本，比手动翻块快得多。值里偶尔带\n或\t这样的转义，翻译时别误删，删了换行就没对齐了。
版本信息，Restorator 里显示为 Version Information，主要管 Windows 资源管理器里看到的文件描述、产品名称、版权行，以及软件「关于」对话框里的那几行。这个资源的结构是固定的，头部是版本号和数据长度，后面才是字符串键值对。汉化版本信息没有任何布局风险，改了最多是显示中文还是英文的问题，不会让程序崩溃。所以我的习惯是：所有汉化任务都先干这两个，字符串表打底，版本信息收尾确认。它们出错的影响面最小，也能让后续动对话框时心里有底。
2.2 对话框与菜单：坐标陷阱与字体高度
对话框资源是汉化里最容易翻车的地方，不是翻译难，是放不下。对话框控件的位置和宽度用的是 DLU 单位，不是像素。横向一个 DLU 大约等于对话框平均字符宽度的四分之一，纵向约等于字符高度的八分之一。这套体系按英文字母宽度设计，中文字符是全角，显示宽度大约是英文的两倍多。一个宽 50 DLU 的按钮，放「Settings」绰绰有余，放「个性化设置」就明显溢出，文字会被裁掉或顶到边框上。
改对话框之前，先看这个对话框用的字体。很多英文旧程序默认字体是 MS Sans Serif 8 号，中文系统里没有这个字体，Windows 会拿宋体顶替，而宋体的行高比 MS Sans Serif 大，原来的按钮高度就不够，出现上下裁边。处理办法有两个：一是双击对话框资源进可视化编辑，把控件拉宽两三倍甚至更多；二是把对话框字体改成「宋体, 9」或「微软雅黑, 9」，保存后重新调整控件间距。两件事都要做，只拉宽不调字体，中文行高可能仍然不够。
菜单汉化相对温和，但有一个细节：英文菜单里大量出现&File、&Edit这种写法，&是快捷键指示符，Alt+F 就靠它触发。翻译成「文件(&F)」时要注意，&必须保留一个，且在中文里通常放在括号里，否则界面显示得怪，快捷键也会失效。菜单里的分隔线、子菜单层级都不要动，只改条目文本。判断一个菜单项改没改错，就看它翻译后是否仍然跟着原来的 ID。
2.3 汉化顺序建议
我压箱底的一张操作顺序表，按风险从低到高排：
| 顺序 | 资源类型 | 风险等级 | 原因 |
|---|---|---|---|
| 1 | 版本信息 | 低 | 不参与界面布局，改错不影响运行 |
| 2 | 字符串表 | 低 | 纯文本替换，不影响坐标 |
| 3 | 菜单 | 中 | 只改文本，但别丢快捷键& |
| 4 | 对话框 | 高 | DLU 坐标和字体高度都可能是坑 |
| 5 | 图标 / 位图 | 高 | 替换出错会破坏资源完整性 |
顺序不是拍脑袋定的，是从事故概率倒推的。版本信息和字符串表改坏了，最坏结果是显示错字或个别地方空白，程序还能跑。对话框一旦改坏，按钮错位、文字截断，甚至整个窗体打不开，排查起来返工量很大。图标位图属于资源替换，Restorator 2009 这块能力不算强，真需要换图标我一般交给专门的图标工具。按这个顺序推，中途验证一次，汉化的返工率能压到很低。
3. Restorator 2009 实战：从打开 PE 文件到保存汉化包
工具本身很轻，不需要安装，下载解压后直接运行主程序。打开 exe 之前，我建议先做两件小事：把原文件复制一份到别的目录，并记录原始哈希。汉化翻车时，哈希能帮你判断手里的文件到底是不是原版。Restorator 2009 对中文路径的支持一般，工程目录最好用纯英文路径，避免个别路径解析问题。
3.1 打开目标文件：先备份，再看资源树
备份这一步别省。用 PowerShell 几行命令把原文件和哈希一起留住：
$src = "D:\localize\example_en.exe" $bak = "D:\localize\example_en.orig.exe" if (-not (Test-Path $bak)) { Copy-Item $src $bak -Force Get-FileHash $src -Algorithm SHA256 | Select-Object Hash, Path } else { Write-Host "Backup already exists." }逻辑说明：脚本先判断备份文件是否已经存在，不存在才复制原文件并计算 SHA256 哈希，避免重复覆盖导致备份失效。Copy-Item -Force用于强制创建新备份文件，但外面套了判断，所以第二次执行不会把已有备份盖掉。Get-FileHash -Algorithm SHA256是对原文件生成哈希值，后面汉化完可以拿修改后的文件再做一次，两条哈希不一致是正常的，但如果备份文件哈希也和最初不一致，说明备份本身被污染了。参数说明：-Algorithm SHA256可以用MD5替代，但 SHA256 冲突概率更低；Test-Path $bak是判断备份路径是否存在，若存在会输出提示，不会覆盖。
备份做完，打开 Restorator 2009，菜单文件 → 打开，选中目标 exe。加载后左侧资源树会列出字符串表、对话框、菜单、版本信息、图标等资源类型。大文件加载会慢一些，几十 MB 的程序也能打开，耐心等几秒。如果弹出「无法识别的文件格式」或资源树一片空白，八成是文件加了壳，常见加壳如 UPX，需先脱壳再汉化，这个问题后面会细说。
3.2 改字符串和对话框：双击编辑与可视化调整
改字符串表是最常规的操作。双击左侧资源树的某个 String Table 块，右侧表格出现一行行英文原文。鼠标双击值列，直接输入中文，回车确定，继续下一行。改完一个块，右侧表格底部会有个状态显示已修改行数，方便核对有没有漏改。字符串里的转义符\n和\t保留原样，翻译文本按语义填进去。长度一般不用太担心，字符串不像按钮那样受空间限制，但个别程序会在运行时按固定长度截断，翻译时看一眼原句长度作参照，中文能短则短。
改对话框时，双击左侧资源树的某个 Dialog 节点，右侧会显示一个可视化窗体，控件可以直接点击选中。选中按钮后，右侧属性面板里找到 Caption 或 Text 字段，改成中文。注意，控件下方那个 ID 字段不要动，程序靠它定位控件。改完中文后，按 Ctrl+S 保存前先在可视化界面里扫一眼，看有没有按钮文字溢出、文本被截断。窗口尺寸本身不够时，可以拖窗口边框放大，但放大后要看其他控件是否跟着错位，这种情况需要逐控件调整。
菜单和版本信息的操作逻辑类似：菜单树节点展开后是顶层菜单和子菜单，双击每一项的标题文字直接改；版本信息树节点展开后是键值对表格，双击值列改。菜单的&快捷键符放在中文括号里，版本信息里的公司名、产品名按需翻译，文件名这类不要动。
3.3 保存的三种姿势：覆盖原文件、另存 PE、导出 .res
汉化完成后，保存方式直接影响后续交付方式。三种方式对比如下：
| 保存方式 | 操作 | 适用场景 | 副作用 |
|---|---|---|---|
| 直接保存 | 文件 → 保存 | 拿到的是單文件绿色 exe，改完就交付 | 原文件被覆盖，必须提前备份 |
| 另存为新 exe | 文件 → 另存为 | 想保留英文原版，或需要对比验证 | 新文件数字签名会失效 |
| 导出 .res | 文件 → 导出 | 需要把资源合并进工程重新编译 | 导出的是资源段，不是完整程序 |
直接保存是最常见做法，但保存前务必确认目标程序没有在运行中。文件被占用时 Restorator 会保存失败，不要强行操作。另存为新 exe 适合交付场景，拿新文件给测试同事验证，英文原版留存在本机。导出 .res 完整导出当前资源数据，后续可用对应编译器的资源编译器重新链接，但这不是常规汉化交付路径，一般用于二次开发。
保存后验证是汉化的收尾动作。把新文件放到一个干净目录运行，先看版本信息里改了没有，再看主界面菜单是否完整、对话框按钮是否溢出，最后点开几个有弹窗的功能。我一般会在验证阶段打开系统的进程管理器，确认程序没有报错退出。如果程序加载即崩溃，第一时间恢复备份文件，不要试图在原文件上反复改。
4. 保存与代码页：格式选择、编码坑与多语言资源
汉化到一半保存，结果打开一看全是乱码，这是新手最容易踩的坑。乱码问题的根源往往不在翻译本身，而在保存时的代码页选择。Restorator 2009 会把资源文本在内部转换成 Unicode 处理，保存时再按目标编码写回。如果编码选错，中文就变成一串问号或波浪符。这一章把格式、编码、多语言三件事讲透，能省掉你一半的返工时间。
4.1 直接改 PE 还是导出 .res 再编译
Restorator 2009 保存时，会重建 PE 文件的资源段，重新计算资源目录偏移，然后把代码段原样保留。所以直接保存到原文件是安全的，程序代码不会受影响。但有一个隐藏问题：如果原文件带数字签名，任何修改都会让签名失效。Windows 对带签名程序被篡改很敏感，轻则弹「无法验证发布者」，重则被杀软直接拦截。所以汉化前先看文件属性里有没有「数字签名」选项卡，有的话要评估交付策略。
导出 .res 再编译的场景更接近开发流程。有些软件的资源是分语言打包的，主程序加载外部语言 DLL，这种情况直接改 DLL 里的资源就行，不需要动主程序。Restorator 能打开 .res 文件继续编辑，也能导出 .res 给开发同事用对应编译器（如 Delphi 的 brcc32）重新编进工程。我的经验是：单文件工具直接改 exe，多模块软件优先改语言 DLL，带签名的文件谨慎处理，能别改就别改。
4.2 中文不乱码：代码页与资源编码
代码页设置直接影响保存时中文的编码方式。中文 Windows 系统默认代码页是 936，也就是 GBK，绝大多数国产软件和大部分英文软件汉化时选 936 都没问题。如果原文件是韩文版或俄文版，原资源保存时用的是 949 或 1251，这种文件汉化前先看一下资源属性里的语言标识，确认原代码页，再选对应编码保存。Restorator 2009 在保存对话框里会有代码页选项，默认跟随系统，手动改成 936 对中文最稳。
还有一个容易忽略的点：资源在 PE 文件里分宽字符和窄字符两种存储方式。宽字符资源固定用 UTF-16LE，窄字符资源按系统 ANSI 代码页。Restorator 打开资源时如果显示的语言对不对，可以从右侧表格的十六进制区看出端倪。中文输入时尽量用系统原生输入法，不要从网页复制中文，因为网页里的弯引号、特殊空格会被保存成非 GBK 字符，写回后显示成「锟斤拷」这类乱码。这个坑几乎全是复制文本引起的。
4.3 多语言资源：只改目标语言
多语言软件的每个资源节点下会挂多个语言副本，左侧资源树展开后能看到英文、中文、德文等分支，语言列会显示对应的地方化名称。改的时候要精确选中目标语言副本，比如简体中文是 0804 或显示为「中文(简体)」，在这个节点下双击值列编辑。很多人改完发现界面没变化，就是改错了副本，在英文副本上写了中文，程序按系统语言取资源时拿到的还是英文。
批量操作时注意两点。第一，不要用全选替换功能，全选会把所有语言的统一字符串一起换掉，其他语言也会被污染。第二，不同语言副本的字符串 ID 相同但长度不同，改中文时长度约束参考原语言，别太放飞。还有一个判断技巧：打开文件后看资源树里语言列，如果全部是「中性」且只有一份，说明原程序只含单语言资源，随便改。如果每个资源下拉都有五六种语言，动手前先定位正确分支。
5. 汉化翻车记录：5 个高频坑与排查方法
把这几年经手的汉化事故理了一遍，高频坑就五个。每一条都是先描述现象，再说原因，最后给解决办法，照着排查比一个个试要快得多。
5.1 保存后程序无法启动，或被杀软拦截
现象：保存汉化文件后，双击程序没有反应，或者直接弹窗提示文件已损坏。有的杀软会在保存后立刻隔离这个文件。
原因：最常见的两种情况并存。一是 Restorator 保存时重建资源段，原文件如果带数字签名，签名失效会触发 Windows 的安全机制，表现为无法验证发布者，严重时直接被拒载。二是某些软件带自校验，程序启动时计算自身哈希并和内置值比对，发现被修改就拒绝运行。
解决：先恢复备份文件，确认原文件能正常启动，排除是资源编辑破坏了 PE 结构。然后看文件属性里的数字签名，如果有签名，且程序强制校验签名，这个文件基本不能直接汉化，需要走资源补丁或外挂语言包的路线。自校验程序要先定位到校验逻辑，这个已经超出一个资源编辑器的能力范围，属于逆向工程范畴。能绕就绕，绕不过去就放弃。
5.2 中文显示成乱码
现象：翻译后的中文在程序界面里变成「锟斤拷」「烫烫烫」或一堆问号，但英文界面正常。
原因：保存时代码页选错，中文按错误的编码写回资源段，程序读取时解析出乱码。另一个常见原因是输入的中文里混入了非 GBK 字符，比如从网页复制的弯引号和特殊空格，保存时无法正确转换。
解决：打开原文件备份，重新走一遍翻译流程，保存时手动把代码页确认成 936。输入法输出中文后，先在编辑区检查一遍，有弯引号就替换成直引号，有全角括号就统一成中文标点。判断问题出在输入还是出在编码，可以看乱码内容的规律：全是同一字符重复，基本是编码错位；乱码里夹杂半角符号，基本是输入污染。
5.3 按钮文字溢出或控件重叠
现象：对话框里按钮上的中文超出按钮边界，文字被截断，或者按钮与按钮之间重叠压在一起。
原因：对话框控件宽度按 DLU 定义，DLU 基于英文字符平均宽度，而中文全角字符宽度大。原按钮只按英文宽度留了余量，放中文自然装不下。加上原对话框字体不是中文字体，行高变化导致控件垂直方向也错位。
解决：双击对话框资源进入可视化编辑器，把按钮控件拉宽。宽度参考值：原英文文本长度乘以二作为中文按钮的最小宽度。再把整个对话框的字体统一改成「宋体, 9」或「微软雅黑, 9」，保存后重新检查一遍重叠情况。改完一个窗口，按 F5 在工具里预览效果，能看到真实字体渲染结果后再保存。
5.4 文件被占用，无法保存
现象：Restorator 提示无法写入文件，保存操作失败，但文件确实存在且能打开。
原因：目标程序还在运行中，exe 被系统锁定；或者是一个 DLL 被其他进程加载，比如资源管理器或某个后台服务正在使用它，Windows 不允许写入正在运行的文件。
解决：先把目标程序从任务管理器结束掉，确认进程列表里没有残留。如果结束进程后还是锁定，用进程管理器看句柄，找出是哪个进程占用了文件。DLL 被资源管理器加载的话，要么重启资源管理器，要么重启电脑后不要运行任何关联程序，直接汉化。更稳妥的做法是：在文件资源管理器里把原文件复制一份到工作目录，在副本上汉化，最后再替换。这能避开多数占用冲突。
5.5 保存后图标丢失或资源树错乱
现象：汉化保存后，程序还能运行，但图标变成白色默认图标，或者菜单里部分条目消失。
原因：保存时勾选了重建资源树或者清理冗余资源的选项，工具把某些非标准资源一并清理掉了。Restorator 2009 保存对话框里有资源重建相关选项，默认是安全的，但手动勾选后会丢弃无法识别的资源块，图标和 Manifest 这类特殊资源有时会被误伤。
解决：先从备份恢复原文件，确认图标和菜单都还在，再重新汉化。保存时不要勾选任何「重建」「清理」「压缩」类选项，只做常规保存。如果原文件的图标比较特殊，汉化前先把图标资源导出到本地，汉化后如果发现图标丢失，用 Restorator 的导入功能把原图标导回来。这个操作虽然可行，但过程麻烦，能不做就不做，所以我说保存时手别痒。
6. 进阶技巧：用 Restorator 把汉化工作量减半的三个习惯
6.1 先改版本信息，给汉化包留标记
动手改字符串表之前，先把版本信息里的文件描述改成中文，并在产品名称后面加一个「(汉化版)」标记。这个习惯不是为了好看，是为了后面版本管理时能一眼认出哪个文件被汉化过。拿到一个更新版本的外文软件时，对比版本信息能快速判断哪些文件需要重新汉化，哪些不需要。版本信息的修改不涉及布局，五分钟就能完成，但这个标记能避免你以后对着几个同名文件发愁。
6.2 导出翻译清单批量处理，再用命令查漏
文件里字符串数量超过一两百个时，在 Restorator 的表格里逐行翻效率太低。我一般把资源导出成一个制表符分隔的文本清单，用 Excel 打开，英文原文放一列，中文译文放一列，批量处理好之后导回 Restorator。一次处理几百个字符串，效率比逐行编辑快得多。导出后的文本是制表符分隔格式，Excel 打开时如果中文显示乱码，用记事本打开后另存为 UTF-8 再导入 Excel。
批量翻译完，还要检查有没有漏网之鱼。用 PowerShell 扫一遍清单里的英文残留：
$lines = Get-Content "D:\localize\translation_report.txt" -Encoding Default $lines | Where-Object { $_ -match "[\x20-\x7E]{3,}" } | Select-Object -First 20逻辑说明：Get-Content按行读取导出清单，-Encoding Default在 Windows PowerShell 5.1 里表示使用系统 ANSI 编码，中文系统下对应 GBK，这样可以避免中文乱码导致误判。Where-Object配合正则[\x20-\x7E]{3,}，筛出包含连续 3 个以上 ASCII 可打印字符的行，这些多半是还没翻译的英文原文。Select-Object -First 20只取前 20 行，避免输出刷屏。参数说明：如果清单里有大量英文品牌名、文件名这类不需要翻译的内容，把{3,}改成{5,}可以过滤掉短单词，降低噪声。
6.3 保存前后强制加载验证
汉化完成并不代表交付完成。我每次保存后都会做一次强制验证：把汉化文件复制到隔离目录，双击运行，检查版本信息、主菜单、一个带对话框的窗口、一个带弹窗的流程。四个点都过了，才算这个文件真正能交付。验证时不要在原目录直接运行，避免覆盖了其他依赖文件，也避免程序写日志到工程目录影响后续比对。
从那以后，我每次拿到一个新汉化包，不管改了几个字符串，都强制走一遍「备份 → 保存 → 隔离加载」流程。这个流程看着笨，但已经帮我拦下了不下三次因为漏看一个按钮溢出就发出去的交付。希望帮到你。
本文还有配套的精品资源，点击获取
