简介：基于C++Builder 6编写的一份多国语言Demo源码，面向Windows桌面应用开发者，重点演示如何通过资源文件与本地化技术实现界面语言动态切换。压缩包共34个文件，以cpp源文件、dfm窗体文件、res资源文件、bpr工程文件为主，附带h头文件、ddp文件以及可直接运行的Demo.exe，整体大小仅765KB，轻量且结构完整。资源内置简体中文、繁体中文、西班牙语三种语言配置，通过读取相应ini语言文件并配合Windows API加载资源，直观呈现多语言切换的完整实现路径，同时保留独立语言包便于二次定制。借助此工程可掌握Resource Editor工具用法、资源脚本编写逻辑、资源DLL分离更新等关键技巧，适合有一定C++基础、希望掌握国际化本地化技能的开发者参考学习。已有387人浏览学习，代码量适中，便于对照分析资源脚本、语言管理和编译选项等关键环节。 前阵子接了个老项目，C++ Builder 6 写的，用户突然要求加多国语言，界面要能在中英文之间切换。这类需求放在今天的 .NET 或者前端框架里很常规，但放到 BCB6 这种古董 IDE 上，还真要动点脑筋。这篇文章就按我当时做多国语言 Demo 源码的思路整理，把关键代码、踩坑点和最终方案都摆出来，希望能帮到同样还在维护老 VCL 项目的朋友。
先说结论：C++ Builder 6 里做多国语言，本质不是“翻译文本”，而是把界面显示字符串从代码里抽离出来，做一套可替换的映射机制。语言包可以做成资源文件、ini、xml，甚至单独的资源DLL，关键看你的项目规模和维护成本。
1. 老项目做多国语言，先想明白这三件事
1.1 C++ Builder 6 的 VCL 模型决定了实现方式
C++ Builder 6 的界面模型是 VCL（Visual Component Library），所有窗体、按钮、标签都是组件，放在一个组件树里。窗体是 TForm，按钮是 TButton，标签是 TLabel，它们都继承自 TComponent。这就意味着：我们要做界面翻译，本质上就是遍历这棵组件树，把每个组件的 Caption、Text 这类显示属性替换成目标语言。
麻烦的地方在于，BCB6 时代还没有完整的 Unicode 支持，字符串类型主要是 AnsiString，内部编码跟着系统代码页走。在中文系统下编译的程序，字符串是 GBK 编码；换到英文系统，字符串按 CP1252 解析，中文几乎必乱码。所以做多国语言不能只翻译，还得处理编码转换，这两件事是绑在一起的。
我打个比方：这就好比一栋楼的每间房门牌号都焊死在墙上。要换门牌，你得先有个“房间档案表”，记录哪个房间该挂什么牌，再有一个工人能按表把新牌子挂上去。在 VCL 里，“房间档案表”就是语言包，“工人”就是遍历组件树并赋值的函数。
1.2 三条技术路线与选型依据
BCB6 下做多国语言，常见有三条路，我列了个对比表：
| 方案 | 实现原理 | 适合场景 | 工作量 |
|---|---|---|---|
| 资源字符串表 | 用 .rc 文件定义 STRINGTABLE，运行时 LoadString 加载 | 菜单、提示语等零散文本 | 小 |
| 组件属性遍历翻译 | 递归遍历窗体组件树，根据组件名匹配语言包替换显示属性 | 窗体级界面整体切换 | 中 |
| dxGetText（gettext 移植） | 在代码中用 _("text") 包裹字符串，运行时从 po/mo 文件读取翻译 | 大批量文本、多语种持续迭代 | 大，但后期省心 |
我最终选的组合是“资源表 + 组件遍历翻译”。资源表负责那些不好绑到组件上的通用提示（消息框、日志文本等），组件遍历负责可视化界面。这样代码量不算大，逻辑也直白，适合 Demo 级别的参考实现。如果你做的是大规模商业项目，再考虑 dxGetText，后面我会讲它的接入方式。
2. 语言包结构设计与加载逻辑
2.1 从 .rc 资源到语言包文件的取舍
传统 Windows 程序的做法是写一个 .rc 资源文件，在里面建字符串表：
#define IDS_MAIN_CAPTION 100 #define IDS_BTN_OK 101 #define IDS_BTN_CANCEL 102 STRINGTABLE BEGIN IDS_MAIN_CAPTION "File Manager" IDS_BTN_OK "OK" IDS_BTN_CANCEL "Cancel" END然后代码里用 LoadString 或者 VCL 的 LoadStr 取出来：
char buf[256]; LoadString(HInstance, IDS_MAIN_CAPTION, buf, sizeof(buf)); Caption = buf;这条路本身没问题，但 BCB6 自带的 brc32 资源编译器对“同一资源 ID 多语言版本”的支持不算友好，而且换语言要切换资源 HINSTANCE，一不小心就是资源串串味。我后来更推荐把语言包从资源文件里剥出来，做成独立的 ini 文件。Demo 里加载逻辑直观，你改一行翻译不用重新编译 exe。
2.2 写一个轻量翻译管理类
我设计了一个 TTranslator 类，封装语言包加载和查询。语言包文件格式很简单：
[Strings] main.caption=文件管理器 btn.ok=确定 btn.cancel=取消 menu.file=文件(&F)查询 Key 时用“组件名.属性名”的结构，比如 main.caption 表示名为 main 的窗体的 Caption 属性，btn.ok 表示名为 btn 的按钮的 Caption。
类实现大概长这样：
class TTranslator { private: TStringList* FMap; public: __fastcall TTranslator() { FMap = new TStringList; } __fastcall ~TTranslator() { delete FMap; } bool __fastcall LoadFromFile(const AnsiString& fileName) { // 使用 TIniFile 或手动解析，加载 [Strings] 段 TIniFile* ini = new TIniFile(fileName); ini->ReadSectionValues("Strings", FMap); delete ini; return FMap->Count > 0; } bool __fastcall HasKey(const AnsiString& key) { return FMap->IndexOfName(key) >= 0; } AnsiString __fastcall Get(const AnsiString& key) { return FMap->Values[key]; } };为什么用 Key 而不是直接拿英文原文做 Key？原因是同一英文在不同语境下翻译可能不同。我们以前吃过亏，一个 “Save” 在文件菜单里是“保存”，在设置对话框里可能该翻译成“存储”，用英文原文做 Key 就会互相覆盖。用组件名做 Key 虽然前期要维护一份清单，但长期稳定得多。
3. 核心实操：窗体组件树批量翻译
3.1 遍历组件树做翻译
TTranslator 有了，接下来就是“工人”——遍历组件树。C++ Builder 6 的 VCL 组件树通过 ComponentCount 和 Components[i] 访问，每个组件的 Name 属性就是我们在语言包里定义的 Key。我用一个递归函数处理窗体上的所有组件：
void __fastcall TranslateControls(TComponent* root, TTranslator* trans) { if (!root || !trans) return; AnsiString compName = root->Name; if (compName.IsEmpty()) compName = root->ClassName(); // 按组件类型赋值 if (TLabel* lbl = dynamic_cast<TLabel*>(root)) { if (trans->HasKey(compName + ".caption")) lbl->Caption = trans->Get(compName + ".caption"); } else if (TButton* btn = dynamic_cast<TButton*>(root)) { if (trans->HasKey(compName + ".caption")) btn->Caption = trans->Get(compName + ".caption"); } else if (TCheckBox* chk = dynamic_cast<TCheckBox*>(root)) { if (trans->HasKey(compName + ".caption")) chk->Caption = trans->Get(compName + ".caption"); } else if (TMenuItem* mi = dynamic_cast<TMenuItem*>(root)) { if (trans->HasKey(compName + ".caption")) mi->Caption = trans->Get(compName + ".caption"); } else if (TTabSheet* sheet = dynamic_cast<TTabSheet*>(root)) { if (trans->HasKey(compName + ".caption")) sheet->Caption = trans->Get(compName + ".caption"); } else if (TStatusBar* bar = dynamic_cast<TStatusBar*>(root)) { // 状态栏的 Panels 是集合，不在 Components 里，需要单独处理 for (int i = 0; i < bar->Panels->Count; i++) { AnsiString panelKey = compName + ".panel" + IntToStr(i); if (trans->HasKey(panelKey)) bar->Panels->Items[i]->Text = trans->Get(panelKey); } } // 递归子组件 for (int i = 0; i < root->ComponentCount; i++) TranslateControls(root->Components[i], trans); }这里有几个隐藏问题提醒你注意：
- TEdit、TMemo 这类输入控件虽然也有 Text，但那通常是用户数据，不能翻译。所以我的类型分支里刻意跳过了它们。
- TMenuItem 继承自 TComponent 而不是 TControl，所以不能放在 TControl 分支里，必须单独判断。
- 动态创建的组件如果 Name 为空，框架会自动生成类似 “Button1” 的名字，你会发现语言包里没这个 Key，翻译就会漏。所以创建动态组件时，务必要给一个有意义的 Name。
- 如果有 TStringGrid，表头单元格不会出现在 Components 数组里，需要单独写循环，比如
StringGrid1->Cells[0][0]。
3.2 切换语言后的刷新与状态保护
语言包加载完、组件翻译完，还有一步：刷新界面。试过你就知道，光改 Caption 通常不够，有些控件需要重绘才能立刻生效，比如 TabSheet 的标签页、StatusBar 的 Panel。我的处理方式是先隐藏窗体，翻译完再显示：
void __fastcall ApplyLanguage(TTranslator* trans) { // 所有已创建的窗体都要翻译，不光是当前活动窗口 for (int i = 0; i < Screen->FormCount; i++) { TForm* f = Screen->Forms[i]; f->Visible = false; TranslateControls(f, trans); f->Visible = true; } }这个 “先隐藏再显示” 是个笨但有效的办法。如果直接翻译，德语、法语里那种超长单词会把按钮撑宽，布局一顿乱跳，用户体验极差。隐藏重绘能让窗体按新文本重新计算尺寸，视觉上干净得多。
还有一个状态保护的问题：如果窗体上有用户在填写的文本框，翻译函数不能碰这些控件的 Text。所以翻译前先判断控件类型是关键，不要把整个 f->Visible 切换当成万能药。我们内部有一版就踩过坑——切语言把用户输入的账号密码清空了，那种事故很尴尬。
4. 进阶：dxGetText 与大型项目的 i18n 方案
4.1 gettext 机制在 BCB6 下的移植
如果你的项目不只两三种语言，而是将来要扩展到十几个语种，用上面那种“组件名 + 属性名”做 Key 的方式维护成本会上来。这时候可以考虑 gettext 体系。gettext 是传统 Unix/Linux 下的 i18n 标准方案，核心思想是：开发时直接在代码里写英文原文，用 _("text") 包一下，翻译者维护 po 文件（msgid 原文，msgstr 译文），程序发布时编译成 mo 文件即可。
BCB6 下的移植方案是 dxGetText，它本质上是一套 Delphi/C++ Builder 库，通过覆盖 VCL 内部的资源加载和字符串处理函数，让 _() 能直接从 mo 文件里取翻译。它的好处是：代码里不需要维护 Key 清单，写代码时英文可读性最好，翻译进度也容易统计。缺点就是接入步骤比前两个方案复杂，而且对 VCL 内部动态字符串（比如某些控件的默认提示文本）支持不彻底。
4.2 快速接入步骤与关键坑
dxGetText 的接入步骤，我当时折腾了大半天，记录如下：
- 下载 dxGetText 源码包，把 dxgettext 目录放到工程下，然后在 Project > Options > Directories/Conditionals 的 Include Path 里加上该目录。
- 在主窗体或项目源文件里引入头文件并链接库：
#include "gnugettext.hpp" #pragma link "gnugettext.lib"- 在程序初始化时调用：
setlocale(LC_ALL, ""); tp_initialize();- 代码里把所有要翻译的字符串包起来：
Label1->Caption = _("Open File");- 翻译文件 .po 的内容用 msgfmt 编译成 .mo：
msgid "Open File" msgstr "打开文件"- 把 .mo 文件放到程序运行目录下的 locale\zh_CN\LC_MESSAGES\ 之类的子目录里，dxGetText 会按当前 locale 自动加载。
这里有个大坑：BCB6 的 AnsiString 默认使用系统 ANSI 代码页，而 .po/.mo 文件里的译文通常按 UTF-8 编码。如果你直接在程序里显示中文，很可能出现“乱码接力”。我当时的处理是写了一个 UTF8 到 AnsiString 的转换工具函数，在给 Caption 赋值前先转码。代码大概长这样：
AnsiString UTF8ToAnsiStr(const AnsiString& s) { WideString ws = UTF8Decode(s); return AnsiString(ws); }注意 UTF8Decode 返回 WideString，再从 WideString 转 AnsiString 时，转换规则取决于当前系统代码页。所以最终程序运行环境的中文语言包要配合正确的区域设置，否则依然会乱。这个“编码三层转换”的问题，是 BCB6 项目里做 i18n 最耗时间的部分，没有之一。
5. 常见问题与排查技巧
5.1 中文乱码问题
乱码基本都是编码不一致造成的。语言包文件是 UTF-8、程序按 GBK 解析，就会乱；.rc 文件用 UTF-8 保存而 brc32 按 ANSI 解析，也会乱。排查思路很简单：先确认语言包文件的编码，再确认代码里取出来后的转换函数。Windows 下用记事本打开语言包另存为 ANSI 是最省事的土办法，但如果团队里有人用 macOS/Linux 编辑，还是统一用 UTF-8 加代码转码更稳。
5.2 容易漏掉的界面元素
列表里单独点名几个：TStatusBar 的 Panels、TStringGrid 的 Cells、TListView 的 Columns 的 Caption、TActionManager 里 TAction 的 Caption、还有 DBGrid 的列标题。这些元素都不是“组件”，而是组件内部的对象集合，遍历 Components 时根本不会经过它们。建议在每个窗体的翻译函数末尾，手工补一段专门处理这些集合的代码。
5.3 切换语言后窗口闪烁与布局错乱
这类问题通常出在字体上。中文和英文的默认字体渲染宽度差异很大，切换后按钮文字可能被截断。BCB6 里有个 Font.Charset 属性，如果语言包里某个语言需要不同字符集，要记得连同字体一起切换。比如中文界面用“宋体”，英文界面用“Tahoma”，可以在语言包里加一个 meta.font.name 配置，翻译时一起设置。
5.4 多语言发布前测试清单
我整理了一个发布前的自测表，照着跑一遍基本能覆盖大多数问题：
| 检查项 | 说明 |
|---|---|
| 主窗体标题 | 切换后立即生效 |
| 所有菜单项 | 含快捷键 &F 是否冲突 |
| 按钮文本 | 是否被截断，布局是否错乱 |
| 状态栏文本 | Panel 宽度是否自适应 |
| 表格列头 | StringGrid/ListView 列标题 |
| 弹出消息框 | 用资源串加载的和硬编码的是否统一 |
| 输入控件内容 | 用户数据是否被误清空 |
| 长文本语言 | 德语/俄语等超长文本是否撑破布局 |
| 右向左语言 | 阿拉伯语等是否需要 BiDiMode 支持 |
做这个 Demo 源码时，有个小细节印象很深：第一次给客户演示，日语系统上按钮全变问号，查了半天才发现 .rc 文件保存成了 ANSI 的日文代码页，但系统里没装对应字体。所以这类老项目，建议先把字体、代码页、语言包三件事统一考虑。最后再分享一个小技巧：语言包文件名用语言代码命名（zh.ini、en.ini、ja.ini），切换逻辑里写个循环，后续加语言就是加文件加翻译，不用改代码。这大概是 BCB6 老项目里最省心的扩展方式了。
本文还有配套的精品资源，点击获取
