简介：Restorator 2009 是一款面向软件本地化和汉化的专业工具，适合需要汉化 Windows 程序的个人用户、翻译人员和中小型本地化团队。它支持直接打开 EXE、DLL、RES、RC 等常见资源文件，查看并修改字符串、菜单、对话框、图标、位图等资源；还可按关键词快速定位待翻译内容，批量替换重复文本，自动识别字符编码避免乱码，并结合版本对比、实时预览、翻译导入导出等功能完成界面调整；同时支持自定义快捷键，方便高频操作。RAR 压缩包约 3MB，已有 201 人学习/下载。压缩包内为工具本体，可覆盖从分析源文件、替换界面文本、调整控件布局到保存测试并输出汉化版本的完整流程。对需要频繁进行软件中文化、统一术语、制作汉化补丁的读者来说，这款工具既能提升日常翻译效率，也能降低跨版本维护成本。
1. 为什么还在用 Restorator 2009：老牌资源编辑器对汉化场景依然能打
接手内部工具时最头疼的不是代码，而是打开 Exe 和 Dll 后发现界面全是英文。手头临时找不到原项目工程，只能直接改二进制资源，这时候就需要一个好使的汉化工具。Restorator 2009 就是那个我从一堆工具里挑出来、用了很多年仍然没被替代的资源编辑器。它能直接打开 PE 文件，把字符串、菜单、对话框、图标、位图、版本信息等资源完整拆出来，修改后再回写，整个过程不碰汇编指令和数据段。对只想把界面文字换成中文、又不想重新编译的从业者来说，这个工具比用十六进制编辑器硬改字符串要安全得多，也适合做一次性汉化、临时替换公司名或改动对话框布局。
它解决的核心问题是：如何在不改变程序逻辑的前提下，安全替换界面资源。适合刚接触汉化的新手，也适合熟手快速验证某个 DLL 里有哪些可改文本。下文从界面识别、字符串表、对话框菜单、坑位排查到发布验证，按一条完整的实操链路往下走。
2. 认清资源树结构：决定哪些资源能碰，哪些必须绕开
很多人第一次用 Restorator 2009 时，会把它当成简单的字符串替换工具，打开文件就开始搜英文。结果改完界面全乱，或者程序直接启动不了。问题往往出在没弄懂 PE 文件里的资源目录结构。Restorator 打开 exe 或 dll 后，左侧是一棵资源树，顶层是资源类型，常见的包括 Icon、Bitmap、Menu、Dialog、String Table、Version Info、GIF、AVI 等。还有一些自定义资源类型，比如 PNG、HTML、XML，这些就看具体程序把数据放在哪里。
2.1 资源树里哪些类型负责显示文字
程序界面显示的文字，绝大多数来自 String Table 和 Dialog/Menu 资源。String Table 是一个个 ID 对应的字符串块，对话框里的静态文本、按钮标题、消息框内容通常都通过字符串 ID 间接引用。Menu 资源里则是菜单项标题。Dialog 资源比较复杂，每个对话框里包含多个控件，每个控件的 Caption 或文本直接存放在控件定义里。
为什么要先分清这些类型？因为直接改 String Table 是最安全的，它只影响字符串常量，不涉及控件布局。改 Dialog/Menu 需要调整控件尺寸和字体，否则会出现文字截断、错位或换行难看。版本信息里的 CompanyName、ProductName 这类字符串也建议改，但要注意编码方式，版本信息通常使用 Unicode 或 ANSI，这里汉化时最容易翻车。图标、位图、光标这类资源属于图形资源，汉化时一般不需要动，偶尔会遇到图片上写了英文，那就需要先导出来用绘图工具处理，再导回去。
2.2 用 Restorator 找出可汉化资源
打开文件后，在左侧资源树里逐一点开 String Table 和 Dialog 节点。Restorator 2009 的界面很直观：上方是资源树，下方是内容预览和属性区域。字符串表每个条目会显示 ID、Value 和说明。对话框则直接可视化显示窗体，点中某个控件，右侧属性区会显示 Caption、ID、控件的 X/Y 坐标和宽高。
我一般先点开“String Table”目录，把所有自定义字符串扫一遍。如果程序是用标准 MFC 写的，通常会有一个或多个以数字命名的字符串块，里面的字符串 ID 从 1 开始递增，值包含菜单提示、窗口标题、按钮文字、错误信息等。识别哪些需要汉化，看 Value 列的内容是否属于界面可见文本。有些字符串内部带有%d、%s这类格式符，或者\n换行符，这些必须保留原样，否则运行时拼接字符串会出错。
2.3 准备工作：设置字体、语言与预览参数
动刀之前先把环境配置好。Restorator 2009 的菜单里，通过“Tools > Settings”打开设置窗口，建议将“Resource Language”设为中文简体或 Neutral，必要时让工具按资源声明的语言自动匹配。字体方面，预览对话框时，如果源程序使用的是英文 UI 字体，中文预览会很难看，可以在对话框属性里临时改字体为宋体或微软雅黑，先看看大效果。这里有个细节：预览用的字体和保存到文件里的字体是两回事，真正汉化时需要在 Dialog 资源属性中修改字体名和字号，否则真实运行时还是老样子。
设置好之后，建议先随便找个文本量少的界面做一次“预览修改-恢复”练习，确认工具不会自动做多余改动。对于需要汉化的项目文件，开工前把源文件复制一份到备份目录，这个习惯比任何设置都重要。Restorator 本身不会做版本控制，保存后想反悔只能靠备份。另外，如果目标程序带有数字签名，修改资源会导致签名失效，这是预期行为，后面会有专门一节讲如何处理。
3. 字符串表汉化实操：从直接编辑到批量替换脚本
字符串表是所有汉化工作的基础，因为它最安全、最容易验证。Restorator 2009 提供了两种修改方式：一是在界面里逐个双击条目直接编辑值；二是把资源导出成 RC 脚本文件，用外部脚本批量替换后再导回。前者适合几十个字符串的小程序，后者适合字符串成百上千、且替换规则重复的场景。
3.1 在字符串表编辑器里直接改值
打开 String Table 资源后，界面下方会显示一个列表，每行包含 ID 和 Value。双击 Value 列就能进入编辑状态。修改时注意不要动 ID，只改 Value。保存按钮在工具栏上是磁盘图标，也可以直接按Ctrl+S。很多人在这一步会直接把英文替换成中文，然后立刻运行程序，结果发现有些地方没变。原因往往是字符串表存在多段，例如程序有两个 String Table 资源块，Restorator 左侧树里会显示多个子节点，必须逐一检查每个子节点里有没有要改的内容。我处理过的工具里，有的字符串表会分成 0-7、8-15 等区间，漏掉一个区间就等于漏掉一部分界面文字。
修改完一段字符串后，先别急着保存整个文件。重新点开这个节点再点击其他资源，再返回字符串表，确认刚才的改动还在。Restorator 有时会在切换到其他节点时重新加载资源，如果发现改动丢失，通常是因为当前文件被标记为只读，或者程序的所有者权限限制了写入。解决办法：先把文件复制到本地目录，去掉只读属性，再用管理员身份运行 Restorator。
3.2 导出 RC 脚本做批量翻译
字符串数量多的时候，界面内逐个改效率太低。常见的做法是先把字符串表导出为 RC 格式的文本，用脚本处理后再导回。Restorator 的菜单里有“Resource > Save as…”或右键导出资源，可以选中某个 String Table 节点，把内容保存为.rc文件。导出的 RC 文件通常包含STRINGTABLE块的BEGIN/END结构，每行是一个字符串 ID 和对应的值。
下面是我常用的一个批量替换脚本，处理导出的 RC 文件。脚本按翻译映射表把英文原文替换成中文，同时保留字符串 ID 和格式符。这里用 UTF-16 读取是考虑到 RC 文件可能保存为 Unicode 编码，如果读出来乱码，把编码改成gbk或ansi重试。
import re from pathlib import Path # 翻译映射表：key 为英文原文，value 为中文译文 translation_map = { "Open File": "打开文件", "Save File": "保存文件", "File not found": "找不到文件", "Error code: %d": "错误码：%d", } def translate_rc(src_path: Path, dst_path: Path) -> int: # 优先尝试 UTF-16，失败则回退 to GBK text = "" for encoding in ("utf-16", "gbk", "ansi"): try: text = src_path.read_text(encoding=encoding) break except UnicodeDecodeError: continue if not text: raise ValueError("无法识别 RC 文件编码，请手动指定编码") count = 0 def do_replace(match): nonlocal count raw = match.group(0) # 去掉行首行尾空白后再查表 key = raw.strip().strip('"') if key in translation_map: count += 1 return raw.replace(key, translation_map[key]) return raw # 只替换引号内的字符串，避免误伤 ID 和 BEGIN/END lines = text.splitlines() output_lines = [] for line in lines: # STRINGTABLE 内容形如: 1 "Open File" if not line.startswith("//"): new_line = re.sub(r'"([^"]*)"', do_replace, line) output_lines.append(new_line) else: output_lines.append(line) # 写入时保持原编码，若原编码不可写则用 utf-16 try: dst_path.write_text("\n".join(output_lines), encoding="utf-16") except UnicodeEncodeError: dst_path.write_text("\n".join(output_lines), encoding="utf-16", errors="replace") return count if __name__ == "__main__": result = translate_rc(Path("source.rc"), Path("translated.rc")) print(f"替换完成，共处理 {result} 处字符串")这个脚本把翻译工作从“手工逐个改”变成“维护映射表”。注意正则只是匹配"之间的内容，不会动到BEGIN、END和数字 ID。映射表用严格匹配，如果英文原文在映射表中不存在，脚本会跳过，避免造成部分替换。处理完之后，在 Restorator 里把 RC 文件导回目标资源节点即可：选中字符串表子节点，右键选择“Load Resource”，再选择生成的 translated.rc。
3.3 编码选择、格式符与超长字符串的三个参数坑
第一个坑：RC 文件编码判断错误。导出时如果 Restorator 用的是 ANSI，而你用 UTF-16 读取，替换后写回就会在 .rc 文件头部产生 BOM 乱码，导回时资源会损坏。建议先打开导出的 RC 文件用十六进制查看器看一眼前两个字节，FF FE是 UTF-16 LE，EF BB BF是 UTF-8，没有 BOM 则大概率是 ANSI/GBK。脚本里做了多编码回退，但仍然建议每次导回前备份一次源资源。
第二个坑：字符串中的格式符。软件里常见的写法是"Failed to load %s"，其中%s会在运行时被文件路径替换。翻译时不能写成"加载失败%s"吗？可以，但要注意格式符顺序。有些字符串是"%1 cannot open %2"，这里的数字序号是关键，运行时消息框会按编号填入参数，如果你调换了顺序，显示出来的内容就会张冠李戴。我一般会先把所有%d/%s/%1这类占位符提取出来，翻译后原样放回去，再检查一遍落位顺序。
第三个坑：超长字符串。英文翻译成中文后，长度通常会变短，但有时同一句话需要补足语气词，长度反而增加。Restorator 在编辑字符串时，如果长度超过程序预先分配的内存缓冲区，运行时可能越界。常见表现是启动后提示“字符串过长”或程序崩溃。解决办法不是在编辑器里硬写长文本，而是精简译文，让翻译后的字符串长度控制在原字符串长度的 1.5 倍以内，尤其针对错误消息类字符串。
4. 对话框与菜单汉化：可视化编辑和坐标调整的注意点
字符串表解决的是不一定显示在窗体上的文字，而对话框和菜单是用户直接看到的核心界面。在 Restorator 2009 里，对话框是以所见即所得的编辑器呈现的，点一下窗口，整块窗体就铺在编辑区上，可以直接拖动控件位置、修改属性。这一步比字符串表复杂得多，因为涉及布局，改完字之后控件尺寸可能装不下中文。
4.1 双击控件直接修改“Caption”
打开 Dialog 资源后，左侧是控件树，中间是窗体预览，右侧是属性面板。选中某个按钮或文本框，右侧属性面板的“Caption”或“Text”字段就是显示文字。双击控件也能进入编辑状态。需要留意的是，不要随意改控件 ID，ID 是程序代码和该控件通信的钥匙，很多消息响应函数靠 ID 判断来源，改了 ID 就会导致按钮点击无响应。
对话框里有些文字不是来自 Caption，而是来自系统资源或代码运行时动态设置。比如文件选择框里的“确定”“取消”按钮来自系统公共对话框，Restorator 无法修改这些资源。遇到这类按钮还带着英文，就说明程序没有使用自定义标题，汉化方式应该是在程序资源里新建一个对话框模板替换，或者接受现状。这个边界要提前想清楚，别花时间在无效资源上。
4.2 菜单汉化与快捷键保留
菜单资源的编辑方式类似，菜单项在预览区域显示为一列，点击每个选项，右侧属性里“Caption”就是英文标题。菜单汉化最需要注意的是快捷键提示符。英文菜单里常见&File，这个&号表示 Ctrl+F 里 F 是热键，汉化时不能删掉&，否则热键丢失。中文习惯里热键符号一般放在中文字前面，比如&文件，在界面上显示为“文件(F)”，实际效果是 Alt+F 打开文件菜单。如果不想要热键，也可以保留&但放在不同中文字前，但不能有两个&。
菜单里还会出现分隔符、弹出菜单的子项，这些都需要逐个检查。一个小技巧：汉化菜单后，依次按每个菜单的快捷键测试，确认没有冲突。比如&文件(F)和&编辑(E)如果热键字母都是 F，运行时会以最前面的为准。Restorator 不会帮你检查热键冲突，只能人工看。
4.3 字体与空间调整：把“文字截断”这一关提前过掉
对话框资源里有一个全局字体设置，位于窗体节点属性中。常见英文对话框使用MS Shell Dlg8 号字体，显示中文时字高不够，字会挤在一起。改成中文界面时，我一般把字体名换成Microsoft YaHei UI或SimSun，字号根据点阵大小调到 9 或 10。修改字体后，几乎所有控件的尺寸都需要重新评估。
在 Restorator 中，控件属性里有 X、Y、Width、Height 四项坐标参数。当英文变成中文后，按钮宽度不够会出现文字省略或挤压。处理办法有两种：一是逐控件手动拉宽，保持右侧间距统一；二是利用 Restorator 的布局工具框选多个控件，然后统一调整宽度和对齐方式。注意窗体本身的高度也要适当增加，否则底部控件会被截掉。
还有个容易忽略的点：静态文本控件LTEXT设置了SS_NOPREFIX样式的话，字符串里的&不会显示为下划线快捷键，而是原样显示。汉化时如果看到按钮上出现“打开(&O)”这种字样，而实际又不想要热键，直接去掉&即可，不会影响功能。但如果是&OK这种本来用作热键的，建议保留。
5. 汉化中的常见坑与排查：从“程序崩了”到“显示乱码”
这部分我直接按踩过的坑顺序写，每一条都是真实处理过的问题，现象、原因、对策一次说清楚，省得你去翻别的博客。
5.1 保存后程序无法启动，提示“不是有效的 Win32 程序”
现象：在 Restorator 里改完资源，保存，关闭工具，双击 exe 报错“This application has failed to start because the application configuration is incorrect”或者直接说“不是有效的 Win32 应用程序”。
原因：绝大多数情况下，是因为在左侧资源树里误删了某个资源类型，或者错误地把自定义资源导出/导回，破坏了文件原有的资源目录。Restorator 2009 对部分 64 位 PE 文件资源段的写入支持有限，如果程序带有非标准资源（比如数字签名、嵌入配置文件），直接保存会破坏 PE 头部校验。
解决：先看备份，没有备份就在保存前勾选“Create backup file”选项。针对带数字签名的程序，打开前先用工具移除签名或标注签名区域忽略。用 Restorator 的“File > Backup”功能生成.bak文件。如果没生成备份，可以尝试把原 exe 和汉化后 exe 都拖进十六进制工具，对比资源段偏移，失败状态下不要继续改，找到原始文件重来。从那以后，我每次改前都先复制一份带时间戳的备份，改完不直接双击运行，而是用资源对比工具确认资源树差异。
5.2 中文显示为乱码，字符串表里没问题，运行起来全是问号
现象：在 Restorator 里看字符串、对话框文本都是正常中文，但程序运行后界面上中文变成“????” 或方块乱码。
原因：程序内部使用的是 ANSI 编码（多字节字符集），而 Restorator 2009 编辑字符串时默认以 Unicode 保存回资源。如果目标程序的字符集是 MBCS，资源表里期望的是单字节或系统本地语言编码（比如 GBK），你写入了 UTF-16 或 UTF-8 文本，运行时按本地代码页解释就成了乱码。另一个常见原因是对话框资源里字体设置为英文字体（如 Tahoma），中文显示时字体缺字，被替换成默认字体并出现方块。
解决：在 Restorator 的字符串表编辑器属性里，查看“Character Set”字段，默认通常是0，即 ANSI。保持这个值不变，输入中文时用你系统的当前代码页（简体中文就是 GBK）。如果程序是 Unicode 编译，字符集会显示1或Unicode，那种情况直接填中文没问题。判断方法：改一个简单的字符串，保存，再用十六进制工具看资源区，如果是 GBK 编码就能看到中文正常。对话框字体问题，把字体名改为“宋体”或“Microsoft YaHei UI”，并确认对话框节点属性中字符集是 ANSI_CHARSET（0）。
5.3 修改字符串后运行时界面行为异常，某些按钮不响应
现象：汉化后程序能启动，界面也变成中文，但点击某个按钮没反应，或者鼠标悬停提示文本不显示。
原因：这通常不是改文字本身造成的，而是你在编辑时意外改了控件的 ID、消息号或菜单命令 ID。Restorator 的对话框编辑器里，控件属性最上方是 ID，双击修改文本时容易误操作拖拽控件导致控件焦点变化，但 ID 不会变。如果没动 ID，那就可能是字符串里包含了\t、\n或格式化字符，你翻译时把这些转义符弄丢了，导致运行时消息处理逻辑无法正确解析。
解决：每改完一个对话框，立刻在属性面板核对 ID 与源文件一致。当然可以更省事：用导出 RC 文件的方式，把原资源和汉化后的资源都导出成 RC，然后用文本差异工具对比，只看字符串值和字体属性变化，ID 和样式位不允许有差异。另外，检查所有字符串中的\n、\t、%%等符号，尤其%在自定义格式里经常成对出现。
5.4 对话框文字重叠、按钮超出窗体边缘
现象：对话框界面改成中文后，按钮文字都挤在一起，有些按钮超过了窗体右边界，静态文本冒到控件外面。
原因：英文和中文字宽差异大，同样长度下中文通常更紧凑，但控件初始尺寸是按英文设计的。如果还把全局字体从 8 磅改为 9 磅中文字体，控件内容区域变小，就更明显了。Restorator 不会像某些现代界面工具一样自动调整布局。
解决：先把对话框字体设为中文字体，记住字号。然后按空间占用重新排布：窗体的宽度和高度稍微加 10-20 像素，静态文本控件宽度拉长，按钮整体下移。Restorator 支持多选控件后右键“Align”对齐，“Make Same Size”统一尺寸。改完之后，在预览模式里缩放窗体，看分辨率变化时控件是否超出边界。注意预览窗体的缩放比例和真实运行不一定一致，有条件的直接运行程序看实际效果。
5.5 汉化后文件字节数暴涨，程序加载变慢甚至崩溃
现象：原本几十 MB 的 exe，经过 Restorator 保存后体积变成两倍甚至三倍，启动时明显变慢。
原因：Restorator 保存资源时，为了对齐和兼容，可能重新压缩或直接存储资源，导致体积膨胀。更常见的是你从外部导入了 RC 文件或 PNG 资源，工具会将资源以非压缩方式存储，破坏了原有 PE 的资源压缩段。这个在旧工具中非常常见。
解决：保存时不要勾选“Save with compression”，这个选项默认可能关闭。如果文件已经膨胀，导出所有资源，在新建项目中重新打开原始文件，逐个手工替换资源，最后保存为同一格式。不过在 2009 版本里这功能并不好用，最稳妥的方式是只用它改文本类资源，不大量导入图片资源。体积膨胀如果在一个可接受的范围内（比如增加 20%），不影响使用，只要程序能正常运行。膨胀超过一倍就要检查是否误导入了整个资源目录。
6. 把汉化结果做“干净”：清理非标准资源与发布前验证
汉化不等于翻译完就结束，还需要把资源里补丁一样的冗余痕迹处理掉，同时验证改动是否可控。我自己习惯用两个步骤收尾：一是清理版本信息和多余的图形资源，二是做资源差异对比和冒烟测试。
版本信息里的 CompanyName、OriginalFilename、FileDescription 通常也会显示在文件属性里。汉化后顺手把公司名和个人相关字段改掉，避免泄露内部信息。Restorator 里 Version Info 节点直接双击字符串字段即可修改，注意原作者如果用了名称为“CompanyName”的段，不要新增段，只改值。图标和位图这类图形资源中如果带有英文，要么用专业画图工具处理后原样导入，要么干脆不汉化，保持原样，避免因为图像格式问题导致体积剧增或显示异常。
资源对比验证我用一个 Python 脚本，调用 pefile 库（如果没有就 pip install pefile）分别读取原始文件和汉化后文件，输出顶层资源类型的差异列表。脚本不判断内容，只看资源树结构变化。
from pefile import PE import sys def res_tree(path): pe = PE(path, fast_load=True) pe.parse_data_directories(directories=[pe.DIRECTORY_ENTRY_RESOURCE]) tree = {} if hasattr(pe, 'DIRECTORY_ENTRY_RESOURCE'): for entry in pe.DIRECTORY_ENTRY_RESOURCE.entries: tree[entry.name, entry.id] = {} # 顶层资源类型，如 RT_ICON pe.close() return tree if __name__ == "__main__": src_tree = res_tree(sys.argv[1]) dst_tree = res_tree(sys.argv[2]) print(f"原始资源类型数量: {len(src_tree)}") print(f"汉化后资源类型数量: {len(dst_tree)}") removed = [k for k in src_tree if k not in dst_tree] added = [k for k in dst_tree if k not in src_tree] if removed: print(f"移除的资源类型: {removed}") if added: print(f"新增的资源类型: {added}") if not removed and not added: print("资源类型结构一致，可以进入冒烟测试")这段脚本只检查资源类型层，更深层的字符串对比可以通过导出 RC 后再执行文本差异工具实现。我在汉化完成之后，会先用脚本对比一次，确认没有意外删除任何顶层资源，再运行原始程序和新程序，逐一打开所有菜单、对话框、消息框，确认文字不重叠、无乱码、快捷键可用。这个冒烟测试一定要在干净环境里跑，避免 DLL 缺失导致误判。从那以后，我每次汉化完都强制走一遍资源对比和冒烟测试，如果程序带更新功能或在线验证，还会先断网再测。希望帮到你。
本文还有配套的精品资源，点击获取
