如何修改Delphi生成的.exe中STRINGTABLE条目编号？解决Sisulizer翻译错位问题

问题概述 #

我们使用Sisulizer翻译Delphi应用已有多年，一直依赖STRINGTABLE条目编号作为翻译匹配的键值。近期出现异常：未更新Delphi（10.3）及Sisulizer（4.0 Build 374）版本，但编译生成的.exe中STRINGTABLE的资源ID发生了变化，导致Sisulizer写入错误文本，翻译后的应用完全无法使用。即使编译旧代码，编号依然不匹配（示例：对应德语文本现位于编号3870.61907处）。

核心疑问：Delphi自动创建的STRINGTABLE条目编号原本由IDE自行管理，无法手动修改，是否存在编译器设置或其他因素会影响该编号的分配？

可能影响STRINGTABLE编号的关键因素及排查步骤 #

1. 编译器与链接器配置变更 #

• 检查项目选项（Project Options）中的资源编译器设置：确认是否启用了Use custom resource compiler，或修改了资源编译参数。部分自定义参数可能干扰Delphi自动分配资源ID的逻辑。
• 查看链接器选项：检查Linker标签下的Resource file是否被修改，是否引入了额外的外部.res文件，这类文件可能与自动生成的STRINGTABLE发生资源ID冲突，导致编号偏移。

2. 依赖组件的隐性更新 #

即使未升级Delphi，项目引用的VCL组件、第三方控件可能被悄悄更新（比如通过自动更新工具或手动替换了组件文件）。组件内部新增或调整的资源条目会改变Delphi自动分配资源ID的顺序，最终影响STRINGTABLE的编号。建议：

• 对比当前项目引用的组件版本与之前正常编译时的版本；
• 尝试移除第三方组件后编译测试，看编号是否恢复正常。

3. 系统资源编译器（rc.exe）版本变化 #

Windows 10的系统更新可能替换了系统自带的rc.exe（资源编译器），不同版本的rc.exe对资源ID的分配规则可能存在差异。可以通过以下步骤验证：

• 在命令行中执行rc /?查看当前版本；
• 尝试使用Delphi安装目录下自带的rc.exe路径（通常在bin文件夹内）替换系统版本，重新编译项目。

4. Delphi项目缓存或配置损坏 #

Delphi的本地缓存文件（如.dproj.local、.identcache、.res临时文件）损坏可能导致资源ID分配逻辑异常。处理方式：

• 删除项目目录下的缓存文件，重新加载项目并编译；
• 尝试创建新的空白项目，逐步迁移旧代码，排查是否为原项目配置问题。

5. Sisulizer项目缓存干扰 #

虽然Sisulizer版本未变，但项目的缓存文件可能损坏，导致读取的资源ID与实际exe中的不匹配。建议：

• 清理Sisulizer项目的缓存数据，重新导入当前编译的exe资源，对比编号是否一致；
• 创建新的Sisulizer测试项目，导入exe资源验证编号是否正常。

内容的提问来源于stack exchange，提问作者Bruno