简介Restorator 2007 Build 1747 汉化版是一款面向 Windows 程序资源修改与界面本地化的轻量工具适合汉化爱好者、软件维护人员以及需要调整可执行文件资源的使用者。它采用类似文件管理器的操作界面支持拖拽编辑可对菜单、对话框、字符串、图标、位图、光标等资源进行查看、修改与替换也能导出为 RC/RES 资源文件有效解决手工修改程序资源繁琐且容易出错的问题。压缩包共 3 个文件包含两个 exe 程序文件和一个 html 说明文档整体仅 3.74MB其中 exe 分别为主程序与更新程序html 可作安装使用参考。目前已有 288 人学习或浏览该下载页。工具内置编辑窗口修改后可直接拖拽覆盖原资源并回存文件配合汉化版本与更新组件可快速完成界面汉化、样式调整与资源备份提升日常资源编辑效率。1. Restorator 2007 汉化版老工具凭什么还能撑起软件汉化和资源定制Restorator 2007 是一款老牌的 Windows 资源查看与编辑工具标题里的 “Bulid 1747” 其实是 Build 1747 的笔误这个版本号在当年是相当稳定的一个号。它做的事情很直接把 exe、dll、ocx 里的图标、对话框、菜单、字符串表、版本信息、RCDATA 资源全部在一棵资源树里摊开让你像操作文件夹一样拖出来、改掉、再塞回去。汉化版则是把英文界面语言资源替换成了中文降低了上手门槛。今天还在找这个版本的人多半不是图新鲜而是手里真有一批老软件要汉化、要改图标、要换版本号或者要处理那些新版工具已经不愿意兼容的 PE 文件。适合软件汉化从业者、装机维护人员、做软件二包和定制分发的人。它解决的是“别让我重新写一遍资源”的问题——资源就在那里你只需要一个趁手的编辑器把它打开。2. 先把汉化版跑起来安装部署、兼容性设置与资源结构2.1 汉化版与官方版的差别先认准版本再谈其他Restorator 2007 的汉化版通常是绿色包形态解压后就是一个主程序 Restorator.exe 加几个语言资源文件不需要安装向导。官方版和汉化版的底层 PE 结构完全一致汉化只是把字符串资源和对话框资源替换成中文程序行为没有变化。所以你在网上见到的所谓“汉化版”本质上就是一份被替换了 UI 语言的便携版配置文件也往往被预先写好了。拿到手先做两件事。第一确认版本号打开程序后看“帮助 → 关于”里面的 Build 号应该是 1747如果不是那可能是其他 Build 的汉化包某些功能菜单布局会有细微差异。第二确认它是不是真的能独立运行把整个目录拷到一个不带中文和空格的路径下比如C:\Restorator\双击主程序看能否起来。有些汉化版把语言文件放在相对路径下一旦路径里有空格或者中文资源加载就会出问题表现为菜单一半中文一半英文。老版本工具常见的问题是它依赖的 VC 运行库在新系统里不再预装。Restorator 2007 是 VS2005 时代的产品依赖msvcr80.dll和msvcp80.dll这一层。绿色版有的会把这两个 dll 直接放在同目录有的则依赖系统运行库。如果启动报“内存位置访问无效”或者弹乱码错误框先去系统里查这两个 dll 是否存在再决定是装运行库还是补文件。2.2 在 Win10 / Win11 上把它跑稳注册表兼容模式与运行库检查我一般不会去右键属性里点兼容性选项卡因为那只能对当前用户生效一次而且容易在重装系统后忘记。更可复现的做法是直接把兼容模式写进注册表。下面的命令把 Restorator.exe 设置为以 Windows XP SP3 兼容模式运行适用大多数 Win10 和 Win11 环境reg.exe ADD HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers /v C:\Restorator\Restorator.exe /t REG_SZ /d WINXPSP3 /f参数说明/v指定要设置的程序完整路径注意这里要用分号开头的完整路径/d WINXPSP3是兼容模式代号实际值还可以填WIN7、WINXPSP2等/f表示强制覆盖已有键。执行后不需要重启直接双击主程序。如果兼容模式设置了还是启动即退多半是运行库缺失。检查 Restorator 同目录和系统目录里的关键 dllGet-ChildItem C:\Restorator -Filter *.dll | Select-Object Name Get-ChildItem C:\Windows\System32 -Include msvcr80.dll,msvcp80.dll -ErrorAction SilentlyContinue注意System32里查的是 32 位版本的运行库因为 Restorator 2007 本身是 32 位程序。如果在 System32 里没找到去C:\Windows\SysWOW64里再看一次。缺的话直接把运行库文件复制到 Restorator 同目录是最省事的做法这样不污染系统换机器也方便。老工具跑新系统这种事玄学问题少缺 dll 的问题多。2.3 认识资源树的层级图标、字符串和对话框分别藏在哪Restorator 打开一个 exe 后左侧是资源树顶层先看到“图标”、“对话框”、“菜单”、“字符串表”、“版本信息”、“RCDATA” 这些分组。注意不同编译器出来的文件资源分组名可能略有差异比如 Delphi 程序的资源往往集中在 RCDATA 里而 VC 程序会更常规地分散在 Icon / String Table / Version 这几个组里。在动手改之前先把几个关键资源的性质和用途弄清。图标组里通常不是一个文件而是从 16x16 到 256x256 的多个尺寸分栏Restorator 会以图标组的形式展示每个尺寸可以单独替换。字符串表是按 ID 分块存储的字符串可能分布在多个块搜索时不要只盯一块。版本信息是一段固定结构的资源里面是 FileVersion、ProductName 这些键值对直接双击右侧窗口就能改。RCDATA 是万能的杂货箱很多程序的配置、皮肤、脚本都塞在里面需要时按十六进制或原始数据类型查看。表格列出最常用的三类资源与对应场景资源类型在资源树中的位置常用编辑场景图标图标 / Icon替换软件 exe 图标、dll 图标字符串表字符串表 / String Table汉化界面文案、修改提示消息版本信息版本 / Version改版本号、产品名、版权信息对话框对话框 / Dialog汉化窗口布局、调整控件默认文本对话框是 Restorator 相对 Resource Hacker 的优势区它能可视化预览对话框布局改完能直接看到控件位置和文字这一点在汉化软件时非常省事不用靠脑补坐标。3. 用 Restorator 改资源和汉化软件从打开文件到保存回滚的标准流程3.1 替换 exe/dll 图标尺寸匹配与实操顺序替换图标是刚接触 Restorator 的人最先做的事也是翻车率最高的事。问题通常出在“我只做了一个 ico但资源树里要的是好几种尺寸”。Restorator 的图标组要求各尺寸尽量齐全否则空白处会被默认图标顶替甚至出现资源管理器里图标显示为空白的情况。标准流程是先用 Restorator 打开目标 exe在图标组里右键导出全部图标逐个查看原资源用了哪些尺寸。然后拿源代码或设计稿生成对应尺寸的 ico再在 Restorator 里逐项替换。不要偷懒只替换 256x256 那个大尺寸因为带 .exe 资源管理器默认显示的是小尺寸图标组里的第一个。替换前最好在本地检查 ico 到底带了几个尺寸不要等替换完才发现缺 16px。下面的 PowerShell 函数可以快速读出一个 ico 文件内包含的所有尺寸function Get-IcoSize { param([string]$Path) $fs [System.IO.File]::OpenRead($Path) try { $br New-Object System.IO.BinaryReader($fs) $br.BaseStream.Seek(2, [System.IO.SeekOrigin]::Begin) | Out-Null $count $br.ReadUInt16() for ($i 0; $i -lt $count; $i) { $w $br.ReadByte() $h $br.ReadByte() if ($w -eq 0) { $w 256 } if ($h -eq 0) { $h 256 } $bpp $br.ReadUInt16() Write-Output ({0}x{1} {2}bpp -f $w, $h, $bpp) $br.BaseStream.Seek(12, [System.IO.SeekOrigin]::Current) | Out-Null } $br.Close() } finally { $fs.Close() } }调用方法Get-IcoSize -Path C:\icon\app.ico。这段代码的逻辑是ico 文件头第 2、3 字节是图片数量第 4 字节开始每个目录项 16 字节其中第 1 字节是宽、第 2 字节是高0 表示 256紧接着的两个字节是颜色位数。跳过 12 字节的剩余目录项就能连续读到所有尺寸。参数说明里最容易搞错的是那个Seek(12, ...)它不是跳整个文件而是跳过每个目录项的后 12 字节——目录项总长 16已经读了前 4 字节剩下 12 字节不需要解析。替换完图标后不要直接点保存先点“保存到一个新文件”验证一次确认目标程序还能正常启动再覆盖原文件。这一步是后悔药也是血泪经验。3.2 修改字符串表和版本信息编码命中率与 ID 边界字符串表里存的是程序运行时显示的文字也是汉化工作的主战场。Restorator 2007 的字符串表编辑器是网格化界面左边是资源 ID右边是对应文本。修改时直接双击文本即可但要注意三个坑第一字符串表通常按 ID 分多块每块有各自的起始 ID 范围你搜文案时要选“整个字符串表”范围不要只看当前块第二字符串有长度限制改成超长文案可能导致程序运行时报资源加载错误务必保证替换后长度不超过原字符串表的整体块大小第三中文内容要确认编码老程序大多采用 ANSIGBK内码导入文本时没有做正确编码转换的话保存后就是乱码。版本信息相对简单它是键值对结构常见的 FileVersion、ProductVersion、CompanyName、ProductName 都能直接改。注意一个细节有些程序的版本号同时出现在“版本信息”和“文件属性”两个位置文件属性里的版本号其实是编译器打包写进 PE 可选头里的Restorator 里也能改但很多汉化版对这部分覆盖不完整导致“关于对话框里改了资源管理器属性里还是老版本号”。这时候我一般会先用 Restorator 的“查找替换”直接扫整个文件把所有旧版本号一并替换。查找替换支持在多个资源类型之间跨组搜索对版本号、公司名这类重复出现的文本特别有效比逐个点开改更快。3.3 汉化一个软件的最小流程从导出、翻译到回导验证汉化第三方面程序是 Restorator 2007 最典型的用途也是最容易让人打退堂鼓的场景。很多人拿到的软件文字不是集中在字符串表里而是分散在对话框、菜单和 RCDATA 中。完整的汉化工作不应该只改字符串表还要同步处理这三处否则会出现“菜单是中文的按钮还是英文”的半吊子汉化状态。我习惯的最简流程分五步。第一步打开目标 exe把所有能看到的文本资源过一遍确认哪些是 UI 文案哪些是版权信息、日志输出等不应动的部分。第二步把字符串表和对话框里的文案导出成文本做成翻译对照表。第三步在对照表里逐条翻译注意大小写、占位符和换行符。第四步回导到 Restorator保存为新文件。第五步用一个新的进程打开修改后的 exe确认程序能正常启动且文案显示正确。手工逐条翻译又慢又容易漏我一般会把翻译对照表存成 CSV方便随时核对和管理。一个简单的字典格式ResourceID,Original,Translated IDS_APP_NAME,Setup Wizard,安装向导 IDS_BTN_OK,OK,确定 IDS_BTN_CANCEL,Cancel,取消 IDS_LOADING,Loading...,正在加载...注意第三行的 ID 是程序内部标识不要随便改改了就找不着资源了。第四列的 Translated 是你要替换成的目标文案。对 Restorator 来说它并不直接支持导入 CSV 做自动替换但这份 CSV 可以作为“人工替换时的核对清单”左边原文本在 Restorator 里按下相同字符串搜索右边填目标文本。把核对工作从记忆里解放出来。CSV 文件用 UTF-8 保存时要留意 Excel 打开是否有 BOM 头没有 BOM 时中文列可能在 Excel 里变成乱码不影响脚本读取但影响人工核对效率。4. 批量场景与联动用 Restorator 2007 处理多文件任务的思路4.1 批量处理的起点先做备份再做名单最后才动手Restorator 2007 同一时刻可以打开多个文件以标签页形式切换所以处理同一批软件的图标或版本信息时可以批量打开逐个保存。但批量场景最考验的其实不是编辑器而是操作纪律。不要开着编辑器直接对原始目录里的文件动手这是翻车现场的高发原因。我一般会先写一个批处理做全量备份把目标目录下所有 exe 和 dll 复制到 backup 目录保留原始文件名和修改时间万一改坏了可以直接回滚。下面这个脚本可以放在和 Restorator 同级的目录里运行echo off set SRCDIRD:\samples set BAKDIRD:\samples\backup if not exist %BAKDIR% mkdir %BAKDIR% for %%i in (%SRCDIR%\*.exe %SRCDIR%\*.dll) do ( copy /y %%i %BAKDIR%\%%~nxi nul echo backed up %%~nxi ) echo All done.参数说明里三个点值得记牢%%i是 for 循环的当前文件变量在批处理里必须写两个百分号命令行里才写一个%%~nxi表示展开为文件名加扩展名不含路径copy /y是覆盖已存在的备份而不提示。这个脚本不会递归处理子目录如果你的目标文件分散在多层目录需要把for换成for /r %SRCDIR% %%i in (*.exe *.dll)或者在执行前手动dir /s确认文件清单。备份做完后用 Restorator 批量打开文件挨个检查资源树里有没有异常资源比如图标组缺失、字符串表为空这类问题在批量替换图标时最常见。处理顺序应该是先在一两个文件上试通整个流程再对剩余文件批量处理而不是上来就对几十个文件动手。4.2 翻译对照表驱动验证用脚本核对遗漏不靠肉眼批量汉化除了改资源还涉及进度管理和质量核对。我见过最尴尬的情况是汉化完十几个 dll 之后发现有一个文件漏了一处字符串而那个字符串的 ID 和其他文件完全一致但因为当时人手替换时看漏了最终导致线上反馈“有的界面是中文有的是英文”。这种问题适合用脚本辅助核对。可以把翻译对照表 CSV 作为输入扫描 Restorator 导出的每个文件的资源文本统计哪些预期资源还没被替换。下面这个 Python 脚本生成一份“替换核对清单”输出每个文件中仍未处理的原文 ID让漏网之鱼无处可藏import csv import os dict_path dict.csv export_dir export missing {} with open(dict_path, r, encodingutf-8-sig) as f: rows list(csv.DictReader(f)) for item in os.listdir(export_dir): path os.path.join(export_dir, item) content open(path, r, encodingutf-8, errorsignore).read() need_ids [row[ResourceID] for row in rows if row[Translated]].append([]) if False else [] for row in rows: # 导出的资源内容里应当包含原文如果原文还在说明没替换成功 if row[Original] in content and row[Translated] not in content: need_ids.append(row[ResourceID]) if need_ids: missing[item] need_ids for file, ids in missing.items(): print(f{file}: {, .join(ids)})这段代码的逻辑不复杂把所有用 Restorator 导出的文本资源读进来逐条比对翻译对照表里的原文和目标译文是否同时存在。如果原文存在而译文不存在说明这个 ID 在当前文件里还没被替换。参数说明里有两个关键点encodingutf-8-sig是为了吃下 Excel 导出的带 BOM 的 CSVerrorsignore是防止老程序导出的文本里混入非 UTF-8 字节导致整个文件读取中断。需要明确的是这个脚本只是核对辅助不直接调用 Restorator所以它不会因为工具本身的问题产生误报。4.3 与 Resource Hacker、VS 资源文件的边界分工Restorator 2007 不是万能的工程上常需要和其他工具配合。Resource Hacker 的优势在于它也是老牌工具且对命令行脚本支持更好适合做单纯的资源替换Restorator 的优势在于可视化编辑对话框和跨资源类型查找替换适合做人工密集的汉化工作。两者可以同时打开同一个文件做不同事但不要在同一个文件上交叉保存那会破坏对方的资源结构。另外如果公司内部有 Visual Studio.rc文件里的资源定义和 Restorator 里的资源树是同一套体系。常见的做法是从 Restorator 里导出资源为.res格式或者直接导出对话框模板文本供开发参考。但反过来用 Restorator 修改过的 exe 再生成的.res不一定能和原始.rc完全等价因为它会丢失一些编译器专属的元数据。所以定制的原则是能改资源的场景优先改资源不要试图用 Restorator 去还原完整的工程源码结构。5. 避坑Restorator 2007 汉化版高频翻车现场与排查5.1 启动即闪退缺运行时库不是汉化包的锅现象双击 Restorator.exe 后没有任何界面进程闪一下就没了甚至安全软件弹窗提示“已阻止程序运行”。原因多数情况是系统缺少 VC 2005 系列的运行库文件或者是主程序被安全软件拦截。汉化版本身不背这个锅因为汉化只改资源段不涉及程序入口逻辑。少数情况是汉化版的主程序被二次加壳某些安全组件误判。解决先把 Restorator 目录放到杀软白名单里。然后检查同目录下有没有msvcr80.dll,msvcp80.dll和mfc80.dll没有的话复制一份到同目录再启动。如果还不行换一个版本的汉化包有时是打包者压缩了运行库导致文件损坏。5.2 保存后文件损坏临时文件路径和原文件占用现象在 Restorator 里改了资源后点保存程序提示“保存失败”重试后原文件打不开或启动时报资源损坏。原因Restorator 2007 保存时是在原文件同级目录写临时文件再覆盖如果原文件所在目录没有写权限或者文件被其他进程锁定比如杀软正在扫描、文件还在被运行学习进程使用临时文件写不进去原文件容易被截断。另外如果磁盘空间不足也会静默写坏。解决把待修改文件提前复制到本地磁盘非系统盘目录不要直接在 U 盘或网络共享目录里改。修改前一定做好备份保存失败时不要反复点保存先关闭文件检查磁盘空间把目标文件从杀软排除列表里加进去重新打开再操作。5.3 中文换成乱码编码格式没对齐现象修改保存后程序界面里的中文变成“锟斤拷”或“鎴戞槸”这类字符或者对话框里中文显示为问号。原因Restorator 2007 的字符串表编辑器默认按系统 ANSI 代码页处理文本。在中文 Windows 上 ANSI 是 GBK如果你从 UTF-8 来源的翻译稿里复制文本直接粘贴进去保存时就会把 UTF-8 字节按 GBK 解释产生乱码。解决导入文本前先把翻译稿另存为 ANSIGBK编码格式。在 Restorator 的字符串表编辑框里粘贴前注意观察右下角是否显示“ANSI”字样。如果显示的是 Unicode 或 UTF-8点选项里把代码页切回 ANSI。对话框资源里的静态文本同理。RCDATA 里嵌入的资源文本另当别论要看目标程序实际读取的是哪种编码。5.4 编辑后数字签名失效哈希变了就是变了现象对某个正式发布的 exe 改了版本信息后右键属性里显示“此文件包含的数字签名无效”。原因数字签名是对整个文件内容做的哈希签名任何资源替换都会改变文件内容签名自然失效。这不算 Restorator 的 bug是签名机制本身的特性。部分程序的启动检查逻辑会校验签名签名失效后可能导致程序拒绝启动。解决不要对已签名的正式文件直接改资源。正确做法是先从原始版本取得未签名源文件或者与厂商协调要么就接受“修改后签名失效”这一结果只用于内部测试。如果确实需要保留签名完整性只能做文件资源级修改后重新签名你手里得有对应的代码签名证书才能走这个流程。5.5 打不开部分 64 位程序的资源这是工具边界现象用 Restorator 2007 打开某些 64 位 exe左侧资源树能显示但展开图标或对话框时程序卡死或者提示“资源读取失败”。原因Restorator 2007 的 PE 解析器对 64 位资源的支持不完整尤其是某些编译器生成的新版资源格式和 .NET 程序嵌入资源它只能看到壳进不了解析层。这不是因为你下载的汉化版有问题原版也这样。解决确认目标程序是否 .NET 程序。是的话用其他工具生成 exe 的 .res 再反向合并或者直接用.NET程序的本地化机制做资源替换。不是 .NET 但确实打不开的换 Resource Hacker 或更新版本的工具处理。老工具不是万能的边界要认。6. 进阶技巧用资源 Hash 验证你的每一次修改改资源最怕的不是改错而是不知道改完的成品到底跟原版差了多少。在批量定制场景里我们需要一个客观的验证手段来回答“这次修改到底动了哪些资源”。Restorator 2007 本身不带 diff 功能但我们可以用文件哈希配合资源导出来做修改前后对照。最直接的做法是在打开文件前先计算一次 MD5保存后再算一次两次不一致说明文件已经变化。但 MD5 一致只能证明“没改过”没法定性“改了什么”。更讲究一点的方法是用 Restorator 的“导出资源”功能把修改前后的资源分别导出到两个目录然后对整个目录做递归哈希比对这样能精确定位到具体是字符串、图标还是版本信息发生了变化。下面这个 PowerShell 脚本可以一次递归计算一个目录下所有文件的哈希适合导出前后各跑一次function Get-DirHash { param([string]$Path) Get-ChildItem $Path -Recurse -File | ForEach-Object { $hash (Get-FileHash $_.FullName -Algorithm MD5).Hash $relative $_.FullName.Replace($Path, ) Write-Output ({0}t{1} -f $hash, $relative) } } Get-DirHash -Path D:\export_before Get-DirHash -Path D:\export_after用法是把修改前用 Restorator 导出的资源放在D:\export_before修改后导出到D:\export_after再用比对工具或直接把两个输出文件做 diff就能看到哪些资源文件变了。参数说明Replace($Path, )是把绝对路径里的目标目录去掉只留相对路径这样两边导出的文件名顺序也一致。Get-FileHash默认是 SHA256我习惯改成 MD5对小资源文件比对更快现场也没有碰撞安全性的顾虑。我自己会在批量改资源时把这条哈希验证流程固定成习惯备份 → 导出原始资源 → 修改 → 保存 → 导出新资源 → 哈希比对。等所有这些验证通过后才把文件交付出去。就算是最不起眼的版本号修改也走一遍这条流程因为它能防住“以为自己改了、实际保存没生效”的那种白忙活。Restorator 2007 这个老伙计虽然界面过时但只要摸清了它的脾气依然是汉化和资源定制场景里最趁手的黑匣子小心态工具。希望这些流程和避坑记录能帮到你。本文还有配套的精品资源点击获取