前段时间接手维护一个跑了十几年的 Delphi 老系统客户提了个看起来特别小的需求界面上所有简体中文要能按配置一键切成繁体。我最初的判断很乐观——Windows 有现成的LCMapString调一次 API 就该完事。结果第一版跑出来“头发护理”变成“頭發護理”“干净”变成“幹淨”“回复”变成“回複”几乎每一屏都有错。那一刻我才真正意识到在 Delphi 里写简体繁体转换函数难点从来不是“怎么调 API”而是“怎么处理 API 永远处理不好的那部分”。这篇就把我这套方案完整摊开从LCMapStringW的最小可用封装到 Delphi 7 和 Delphi 2009 之后的编码差异再到一简对多繁的词库兜底最后是我上线前踩过的几个坑。适合手上有老 Delphi 项目、需要做界面本地化或者数据迁移的人看也适合只想搞清楚“简繁转换到底难在哪”的读者。1. 简繁转换在 Delphi 里真正难的三个点1.1 字级映射只是第一步词级歧义才是主要矛盾很多人对简繁转换的直觉是“一个简体字对应一个繁体字查表替换就行”。如果是繁转简这个直觉基本成立因为转换方向是收敛的發和髮在简体里都写成发幹、乾、干在简体里都写成干多对一不存在歧义。但反过来简转繁是发散的一个简体字可能对应两三个繁体字选哪个完全取决于上下文。LCMapString做的是字符级映射它没有词法分析能力所以遇到多义字只能按内部默认规则挑一个。这个默认规则在某些系统版本上甚至不一致。我实测过同一段文本在几台不同版本的系统上跑个别字的输出结果并不完全相同这就意味着你不能拿它当“标准答案”只能当“初稿”。真正的做法是把LCMapString当成字级转换的快速通道再用一张词组表去修正那些它一定会错的地方。这两步的分工必须清楚否则代码会写成四不像——既想依赖 API 又想全自己管最后两边都不讨好。1.2 老项目的字符串编码是隐藏前提Delphi 7 的string是AnsiString在中文系统上按 GBK 存Delphi 2009 之后string变成UnicodeString按 UTF-16 存。这两个世界里写“简繁转换函数”代码几乎完全不同。更麻烦的是很多老项目里混着AnsiString、WideString、UTF8String三种类型数据库里可能是 GBK接口传参可能是 UTF-8界面控件又是 ANSI 的。转换函数如果只接受一种类型调用方就得在每一处手动转转错一个地方就是满屏问号。我最后的做法是把转换核心统一收口到WideString对外暴露两个薄封装一个吃AnsiString内部按当前 ANSI 代码页解码一个吃UnicodeString。这样无论调用方在哪个编码世界里都能找到一个对应的入口而核心逻辑只有一份。1.3 转换方向决定接口设计简转繁和繁转简虽然看起来对称但工程上完全不对称。繁转简几乎不需要词表一次LCMapString调用就能得到相当干净的结果剩下的问题主要是异体字和地区用词比如“裏”和“裡”属于锦上添花。简转繁则必须有词表而且词表的质量直接决定成品能不能交付。所以我没有写一个function Convert(S: string; Direction: TConvertDir): string这种“双向合一”的接口而是拆成SimpToTrad和TradToSimp两个函数。听上去啰嗦但调用方一眼就知道自己在干什么也方便后续只给简转繁挂词表、给繁转简保持轻量。接口设计上的这点“不优雅”换来的是半年后别人接手时不用猜。2. 用 LCMapStringW 写出第一个能用的转换函数2.1 函数原型与两个关键标志位LCMapStringW的签名在 Delphi 的Windows单元里一般都有声明但为了兼容各种版本的编译器我习惯自己external声明一次避免出现“某个版本没声明”或者声明成PChar而在 2009 之后语义变化的问题function LCMapStringW(Locale: LCID; dwMapFlags: DWORD; lpSrcStr: PWideChar; cchSrc: Integer; lpDestStr: PWideChar; cchDest: Integer): Integer; stdcall; external kernel32.dll name LCMapStringW;真正决定行为的只有两个东西Locale和dwMapFlags。转换标志位的取值是固定的转换方向dwMapFlags建议传入的 Locale简体转繁体$04000000LCMAP_TRADITIONAL_CHINESE$00000404LOCALE_TRADITIONAL_CHINESE繁体转简体$02000000LCMAP_SIMPLIFIED_CHINESE$00000804LOCALE_SIMPLIFIED_CHINESE有一点容易被误解Locale参数传的是目标语言的区域标识不是源语言。做简转繁时传繁体区域做繁转简时传简体区域。虽然在实际测试中只要标志位对Locale传什么影响不大但按规范传能避免在部分老系统上出现意外行为没必要省这点事。2.2 完整代码长度探测 缓冲区分配LCMapStringW的返回值是目标缓冲区需要的字符数如果cchDest传 0它就只返回长度不做转换。标准的两段式调用是这样function SimpToTradW(const S: WideString): WideString; const LOCALE_TRAD $00000404; LCMAP_TRAD $04000000; var Need, Got: Integer; begin Result : S; if S then Exit; Need : LCMapStringW(LOCALE_TRAD, LCMAP_TRAD, PWideChar(S), Length(S), nil, 0); if Need 0 then Exit; SetLength(Result, Need); Got : LCMapStringW(LOCALE_TRAD, LCMAP_TRAD, PWideChar(S), Length(S), PWideChar(Result), Need); if Got 0 then Result : S // 失败时退回原文不要返回空串 else SetLength(Result, Got); end;这段代码有三处值得说。第一cchSrc必须传Length(S)不能传 -1。传 -1 时 API 会把源串当以#0结尾处理一旦文本里混入内嵌的#0数据库字段里很常见转换就会在那里断掉后半段原样保留表现为“部分文字没转”。第二先探测长度再分配是因为简繁转换虽然绝大多数情况是 1:1但个别字符的映射长度会变尤其是混入标点和全角字符时。硬编码一个Length(S)大小的缓冲区早晚会出问题。第三转换失败要退回原文不能返回空串——界面上一片空白比转错几个字更难排查。2.3 为什么必须走 Wide 版本而不能用 A 版本有人会想Delphi 7 里本来就是AnsiString直接调LCMapStringA不是省事吗不行原因有两个。其一LCMapStringA内部会先把 ANSI 串按系统当前 ANSI 代码页转成 Unicode转换完再转回来。如果你的程序跑在英文系统上代码页是 1252那个 GBK 的字节流会被解成一堆无意义字符转换结果完全是垃圾。这种情况在部署到海外机器或者远程桌面环境时特别容易遇到本地测一百遍都是好的。其二简繁映射的对照表本身是 Unicode 层面的数据A 版本多绕的这一圈纯属损耗没有任何收益。所以正确姿势永远是无论当前用的是AnsiString还是UnicodeString都先显式转成WideString再调LCMapStringW。如果你的目标系统是 Vista 及以上还有一个LCMapStringEx可以选择它用 locale 名字符串而不是 LCID语义更清楚LCMapStringEx(zh-TW, LCMAP_TRAD, PWideChar(S), Length(S), PWideChar(Result), Need, nil, nil, 0);不过LCMapStringEx在老系统上不存在需要GetProcAddress动态取地址。项目如果还要兼容 XP 时代的机器就老老实实用LCMapStringW它在兼容性上没毛病。3. Delphi 7 到 XE 之后的编码适配3.1 GBK 进、GBK 出的显式转换写法Delphi 7 里把AnsiString赋给WideString会触发隐式转换走的是系统默认代码页。这在纯中文环境下没问题但一旦部署环境变了就会出事而且这种 bug 极难复现。我的做法是全程显式function AnsiToWideEx(const S: AnsiString; CodePage: UINT): WideString; var Need: Integer; begin Result : ; if S then Exit; Need : MultiByteToWideChar(CodePage, 0, PAnsiChar(S), Length(S), nil, 0); if Need 0 then Exit; SetLength(Result, Need); MultiByteToWideChar(CodePage, 0, PAnsiChar(S), Length(S), PWideChar(Result), Need); end; function WideToAnsiEx(const S: WideString; CodePage: UINT): AnsiString; var Need: Integer; begin Result : ; if S then Exit; Need : WideCharToMultiByte(CodePage, 0, PWideChar(S), Length(S), nil, 0, nil, nil); if Need 0 then Exit; SetLength(Result, Need); WideCharToMultiByte(CodePage, 0, PWideChar(S), Length(S), PAnsiChar(Result), Need, nil, nil); end;调用时把代码页写死成 936GBK不要用GetACP。理由很实际数据库里存的、配置文件里写的都是 936 的字节跟着系统代码页走反而会错。写死 936 至少在出问题时是“稳定的错”好排查。如果项目里还混着 UTF-8 的数据就再包一层UTF8Encode/UTF8Decode但代码页参数依然要显式传别让它自己去猜。3.2 UnicodeString 版本里最容易忽略的长度问题Delphi 2009 之后string就是UnicodeString看起来直接传给LCMapStringW就行但有个细节Length()返回的是 UTF-16 码元数不是“字数”。对于 BMP 内的字符绝大多数汉字都在这里两者相等但如果文本里混了 emoji 或者生僻的增补平面汉字一个“字”占两个码元。LCMapStringW的cchSrc要的正是码元数所以传Length(S)是对的。真正需要注意的是反向操作如果你自己写循环去遍历“字符”按S[i]逐个取遇到代理对就会把一个字拆成两半。转换函数本身不涉及这个问题但配套的词表匹配、长度统计、截断显示这些地方都会踩。我在项目里加了一个小工具函数CharCount专门统计真实字符数遇到高位代理就跳过下一个码元所有涉及“字数限制”的地方都用它避免用户输入框按码元数截断导致半个汉字变成乱码。3.3 一次封装两种编译期分支为了让同一份源码在 Delphi 7 和 2009 上都能编译我用了条件编译把对外接口统一起来{$IFDEF UNICODE} function SimpToTrad(const S: string): string; {$ELSE} function SimpToTrad(const S: AnsiString): AnsiString; {$ENDIF}实现上Unicode 版本直接走SimpToTradWANSI 版本先AnsiToWideEx(S, 936)转完再WideToAnsiEx(Result, 936)回去。核心转换逻辑只有SimpToTradW一份两个入口都是薄壳。这样做的好处是业务代码里完全不用关心当前编译器是什么版本照常调SimpToTrad就行。等到哪天项目整体升到新版本只要把{$ELSE}分支删掉别的什么都不用动。4. 一简对多繁LCMapString 兜不住的词怎么补4.1 典型歧义字清单与错误样例先把最容易出问题的字列出来这张表我贴在工位上很久了简体可能对应的繁体判断依据发發 / 髮出发、发生 → 發头发、理发 → 髮干幹 / 乾 / 干干部、干活 → 幹干净、干燥 → 乾干涉 → 干后後 / 后后来、后台 → 後皇后、太后 → 后里裡 / 里里面、心里 → 裡公里、里程 → 里面麵 / 面面条、面粉 → 麵方面、表面 → 面只隻 / 只一只、两只 → 隻只有、只是 → 只系係 / 繫 / 系关系 → 關係联系 → 聯繫系统 → 系統制製 / 制制造、制作 → 製制度、控制 → 制复復 / 複恢复、答复 → 復复杂、重复 → 複表錶 / 表手表、钟表 → 錶表示、表格 → 表台臺 / 台台湾地区习惯用臺但现代书面语也常直接用台LCMapString对上面这些字的处理是“一刀切”每个字只会给出一个固定结果。所以你会看到“頭髮”被转成“頭發”“乾淨”被转成“幹淨”“複雜”被转成“復雜”。这些不是偶发 bug是字符级映射的固有局限只能靠词表解决。4.2 占位符保护方案先切词再转换补词表有两条路。一条是转换完整句之后再去做“错形→正形”的替换比如把结果里的“頭發”改成“頭髮”。这条路实现简单但有个致命问题你可能改错。比如“皇后”如果已经被转成“皇後”你得再改回来可“後台”又确实是“後台”仅看结果分不清哪个该改。另一条路是在转换之前动手在简体原文里先把词组识别出来替换成占位符让LCMapString碰不到它们等字级转换完成再还原。我选的是这条路因为简体原文的上下文是明确的“头发”里的“发”一定是“髮”判断依据充足。流程分三步先用最长匹配扫描原文命中的词组替换成#1 序号 #2形式的占位符同时把对应的繁体词存进一个数组然后对整个字符串跑LCMapStringW最后把占位符按序号还原成繁体词。const PH_L #1; PH_R #2; function ProtectPhrases(const S: string; Dict: TStringList; Parts: TStringList; MaxLen: Integer): string; var i, L, W: Integer; Sub: string; Hit: Boolean; begin Result : ; i : 1; L : Length(S); while i L do begin Hit : False; for W : MaxLen downto 2 do begin if i W - 1 L then Continue; Sub : Copy(S, i, W); if Dict.IndexOfName(Sub) 0 then begin Parts.Add(Dict.Values[Sub]); Result : Result PH_L IntToStr(Parts.Count - 1) PH_R; Inc(i, W); Hit : True; Break; end; end; if not Hit then begin Result : Result S[i]; Inc(i); end; end; end;MaxLen控制词表里最长词的长度循环从长到短匹配保证“一头发”不会被拆成“一头”“发”。词表用TStringList存简体繁体的形式IndexOfName查找虽然底层是线性扫描但词表通常只有几千条加上TStringList默认是排序过的Sorted : True就可以走二分性能完全够用。4.3 词表的组织方式与匹配算法取舍词表条目数量决定算法选择。一万条以内TStringList加排序二分是最省事的方案代码短、调试直观、支持热更新。超过十万条就得考虑哈希表或者前缀树了。我在实际项目里用的是TDictionarystring, string因为 Delphi 2009 之后自带查找是 O(1)而且不用维护排序状态。代价是内存占用比TStringList高一些但一万多条词也就几 MB可以接受。匹配算法上简单的最长匹配每个位置从最长词往下试在词表不大时足够。如果词表膨胀到几万条每次从MaxLen开始逐个试会有点浪费可以改成按首字建索引先用首字查出候选词长度集合再逐个试。这个优化我在第二版才加上因为第一版在长文本上确实能感觉到卡顿。还有一个容易忽略的点重叠词。比如“干巴巴”和“干巴”最长匹配会优先命中前者这是对的。但如果词表里同时有“后台”和“台面”扫描到“后”时命中“后台”跳到“台”后面的位置就不会再匹配“台面”了。这在绝大多数情况下没问题因为原文里这两个词本来也不重叠。真正需要小心的是词表里存在互相包含的条目比如“头发”和“头发丝”这时候最长优先就能正确处理。4.4 反向转换繁→简为什么简单得多繁转简是多对一LCMapString一个调用基本就到位了。我实测过一批文本“頭髮”变“头发”“乾淨”变“干净”“複雜”变“复杂”全都正确因为目标只有一个。剩下需要处理的只有两类一类是地区用词差异比如“資訊”对应“信息”、“網路”对应“网络”这属于用词替换而不是字形转换要不要做取决于业务需求另一类是异体字“裡”和“裏”在繁体里都有人用转简体都是“里”不需要判断。所以我的TradToSimp函数里没有挂词表就是纯粹的LCMapStringW调用。如果以后有客户要求“台湾用词转大陆用词”再单独加一层用词替换表和字形转换解耦各管各的。5. 词库落地的工程细节加载、去重与更新5.1 词表从哪来怎么清洗词表来源无非三条公开的字符变体数据、现成的开源词库、以及自己从业务语料里挖。前两个能覆盖大部分通用词汇第三个才是真正提升准确率的部分——因为每个行业的歧义词不一样医疗系统里“干”出现在“干燥”里的概率远高于“干部”。拿到原始数据后必须清洗。我踩过的坑是词表里混进了长度不一致的条目比如“简体繁体”这种空值加载后Values返回空串导致命中的词被替换成空原文凭空少了一段。所以加载时一定要校验左右两边都非空、长度合理、不含占位符控制字符#1、#2。这个校验我写成独立函数加载时跑一遍把异常条目记进日志而不是直接抛异常避免一个坏条目让整个功能起不来。去重也要做。同一组简繁对可能在多个来源里重复出现TDictionary的Add遇到重复键会抛异常得用AddOrSetValue后加载的覆盖先加载的这样可以用“业务词表”覆盖“通用词表”实现优先级。5.2 内存结构与加载时机词表加载时机有两种选择程序启动时一次性加载或者第一次调用转换时懒加载。我选的是懒加载因为很多用户根本不用繁体界面启动时加载几千条词纯属浪费。懒加载的实现要注意线程安全。如果两个线程同时触发第一次转换可能同时进入加载逻辑造成重复加载或者半初始化状态。我用了一个临界区加双重检查先无锁判断字典是否已初始化没初始化再进临界区进去后重新判断一次。这个模式在 Delphi 里写起来不复杂但漏掉的话在压力测试时偶发崩溃定位起来很痛苦。内存占用方面一万条词大约占 3 到 5 MB对桌面程序可以忽略。但如果你的程序是常驻服务、要开几十个实例就得考虑把词表做成只读的全局单例共享一份内存。5.3 词库热更新与版本管理词表一定会变。业务方今天说“台”要统一转成“臺”明天又说某几个界面要保持“台”这种需求改代码太重所以我做成了外部文件加载程序启动时从指定目录读词表文件找不到就用内置的默认表。文件格式用最朴素的简体繁体每行一条UTF-8 编码方便业务方自己用记事本改。加载时先读文件再叠加内置表文件里的条目优先级更高。这样既能保证“没有外部文件也能跑”又能让客户自己微调。版本管理上我在文件头加了一行注释记录版本号和更新日期程序加载时把这个信息打进日志。出现问题的时候第一件事就是确认现场用的是哪个版本的词表——这个习惯帮我省过好几次来回沟通。6. 上线前的自测清单和几类典型翻车6.1 覆盖性用例该怎么设计简繁转换的测试用例不能靠随机抽文本得按“歧义字 词”的组合来设计。我的做法是先把第 4 节那张表里每个字的两种用法各造一个短句比如“他去理发”和“事情发生了”然后把这些句子拼成一段长文本跑转换肉眼检查每个字是否落在正确的形态上。再补一类“边界用例”纯英文、纯数字、中英混排、含全角标点、含#0字符、超长单行几万字。这几类里最容易出事的是中英混排和含#0。中英混排时LCMapString对英文字母是原样保留的但如果你在保护阶段用了#1、#2做占位符而原文里恰好也有这两个控制字符就会错乱。所以保护前要先扫描一遍把原文里的#1、#2替换掉或者直接拒绝处理。含#0的问题前面提过表现为“后半段没转”。测试时专门造一条带内嵌#0的字符串跑一遍能提前发现。6.2 长度变化与缓冲区溢出绝大多数简繁字符是一对一的但混入标点、全角字符、代理对之后长度可能变。我的代码里所有分配都基于第一次调用返回的Need没有一处用Length(S)硬算就是为了防这个。还有一种情况词表还原阶段长度会变。占位符#1 数字 #2的长度可能比原来的简体词短或长还原时如果用StringReplace逐个替换性能会很差每替换一次重建一次字符串。我的做法是先扫描一遍占位符位置算出最终长度一次性SetLength后逐段拼接避免反复分配。6.3 性能与多线程调用注意LCMapStringW本身很快十万字的文本一次调用通常在毫秒级。真正的瓶颈在词表匹配尤其是长文本加长词表的情况。我做过的粗略测试是一万条词表、十万字文本第一版实现大约需要几百毫秒改成首字索引后降到几十毫秒。这个量级对界面操作是可以接受的但如果要在列表里对几百行数据逐行转换就得考虑缓存或者批量处理。多线程方面LCMapStringW是无状态的可以并发调用。但词表的懒加载和热更新需要加锁保护。我的做法是把词表做成“加载完成后只读”的结构所有读操作无锁只有重新加载时进临界区替换整个引用。这样并发转换完全不阻塞只有极少数更新时刻会有短暂停顿。还有一个实际经验不要在主线程里做大批量转换。曾经有个界面在打开时要把几千条数据一次性转成繁体显示结果窗口卡了两三秒。后来改成后台线程转换完再回主线程更新体验立刻不一样。转换函数本身没问题问题在于调用位置。这套方案在项目里跑了大半年中间修过两次词表、改过一次编码处理的边界核心逻辑基本没动过。要我说最值得强调的一点是别指望任何单一 API 能把简繁转换做干净LCMapString是个很好的字级引擎但它不是词典。把字级和词级这两层分清楚代码结构自然就清楚了后面加词、改词、换算法都不会牵一发动全身。
前段时间接手维护一个跑了十几年的 Delphi 老系统客户提了个看起来特别小的需求界面上所有简体中文要能按配置一键切成繁体。我最初的判断很乐观——Windows 有现成的LCMapString调一次 API 就该完事。结果第一版跑出来“头发护理”变成“頭發護理”“干净”变成“幹淨”“回复”变成“回複”几乎每一屏都有错。那一刻我才真正意识到在 Delphi 里写简体繁体转换函数难点从来不是“怎么调 API”而是“怎么处理 API 永远处理不好的那部分”。这篇就把我这套方案完整摊开从LCMapStringW的最小可用封装到 Delphi 7 和 Delphi 2009 之后的编码差异再到一简对多繁的词库兜底最后是我上线前踩过的几个坑。适合手上有老 Delphi 项目、需要做界面本地化或者数据迁移的人看也适合只想搞清楚“简繁转换到底难在哪”的读者。1. 简繁转换在 Delphi 里真正难的三个点1.1 字级映射只是第一步词级歧义才是主要矛盾很多人对简繁转换的直觉是“一个简体字对应一个繁体字查表替换就行”。如果是繁转简这个直觉基本成立因为转换方向是收敛的發和髮在简体里都写成发幹、乾、干在简体里都写成干多对一不存在歧义。但反过来简转繁是发散的一个简体字可能对应两三个繁体字选哪个完全取决于上下文。LCMapString做的是字符级映射它没有词法分析能力所以遇到多义字只能按内部默认规则挑一个。这个默认规则在某些系统版本上甚至不一致。我实测过同一段文本在几台不同版本的系统上跑个别字的输出结果并不完全相同这就意味着你不能拿它当“标准答案”只能当“初稿”。真正的做法是把LCMapString当成字级转换的快速通道再用一张词组表去修正那些它一定会错的地方。这两步的分工必须清楚否则代码会写成四不像——既想依赖 API 又想全自己管最后两边都不讨好。1.2 老项目的字符串编码是隐藏前提Delphi 7 的string是AnsiString在中文系统上按 GBK 存Delphi 2009 之后string变成UnicodeString按 UTF-16 存。这两个世界里写“简繁转换函数”代码几乎完全不同。更麻烦的是很多老项目里混着AnsiString、WideString、UTF8String三种类型数据库里可能是 GBK接口传参可能是 UTF-8界面控件又是 ANSI 的。转换函数如果只接受一种类型调用方就得在每一处手动转转错一个地方就是满屏问号。我最后的做法是把转换核心统一收口到WideString对外暴露两个薄封装一个吃AnsiString内部按当前 ANSI 代码页解码一个吃UnicodeString。这样无论调用方在哪个编码世界里都能找到一个对应的入口而核心逻辑只有一份。1.3 转换方向决定接口设计简转繁和繁转简虽然看起来对称但工程上完全不对称。繁转简几乎不需要词表一次LCMapString调用就能得到相当干净的结果剩下的问题主要是异体字和地区用词比如“裏”和“裡”属于锦上添花。简转繁则必须有词表而且词表的质量直接决定成品能不能交付。所以我没有写一个function Convert(S: string; Direction: TConvertDir): string这种“双向合一”的接口而是拆成SimpToTrad和TradToSimp两个函数。听上去啰嗦但调用方一眼就知道自己在干什么也方便后续只给简转繁挂词表、给繁转简保持轻量。接口设计上的这点“不优雅”换来的是半年后别人接手时不用猜。2. 用 LCMapStringW 写出第一个能用的转换函数2.1 函数原型与两个关键标志位LCMapStringW的签名在 Delphi 的Windows单元里一般都有声明但为了兼容各种版本的编译器我习惯自己external声明一次避免出现“某个版本没声明”或者声明成PChar而在 2009 之后语义变化的问题function LCMapStringW(Locale: LCID; dwMapFlags: DWORD; lpSrcStr: PWideChar; cchSrc: Integer; lpDestStr: PWideChar; cchDest: Integer): Integer; stdcall; external kernel32.dll name LCMapStringW;真正决定行为的只有两个东西Locale和dwMapFlags。转换标志位的取值是固定的转换方向dwMapFlags建议传入的 Locale简体转繁体$04000000LCMAP_TRADITIONAL_CHINESE$00000404LOCALE_TRADITIONAL_CHINESE繁体转简体$02000000LCMAP_SIMPLIFIED_CHINESE$00000804LOCALE_SIMPLIFIED_CHINESE有一点容易被误解Locale参数传的是目标语言的区域标识不是源语言。做简转繁时传繁体区域做繁转简时传简体区域。虽然在实际测试中只要标志位对Locale传什么影响不大但按规范传能避免在部分老系统上出现意外行为没必要省这点事。2.2 完整代码长度探测 缓冲区分配LCMapStringW的返回值是目标缓冲区需要的字符数如果cchDest传 0它就只返回长度不做转换。标准的两段式调用是这样function SimpToTradW(const S: WideString): WideString; const LOCALE_TRAD $00000404; LCMAP_TRAD $04000000; var Need, Got: Integer; begin Result : S; if S then Exit; Need : LCMapStringW(LOCALE_TRAD, LCMAP_TRAD, PWideChar(S), Length(S), nil, 0); if Need 0 then Exit; SetLength(Result, Need); Got : LCMapStringW(LOCALE_TRAD, LCMAP_TRAD, PWideChar(S), Length(S), PWideChar(Result), Need); if Got 0 then Result : S // 失败时退回原文不要返回空串 else SetLength(Result, Got); end;这段代码有三处值得说。第一cchSrc必须传Length(S)不能传 -1。传 -1 时 API 会把源串当以#0结尾处理一旦文本里混入内嵌的#0数据库字段里很常见转换就会在那里断掉后半段原样保留表现为“部分文字没转”。第二先探测长度再分配是因为简繁转换虽然绝大多数情况是 1:1但个别字符的映射长度会变尤其是混入标点和全角字符时。硬编码一个Length(S)大小的缓冲区早晚会出问题。第三转换失败要退回原文不能返回空串——界面上一片空白比转错几个字更难排查。2.3 为什么必须走 Wide 版本而不能用 A 版本有人会想Delphi 7 里本来就是AnsiString直接调LCMapStringA不是省事吗不行原因有两个。其一LCMapStringA内部会先把 ANSI 串按系统当前 ANSI 代码页转成 Unicode转换完再转回来。如果你的程序跑在英文系统上代码页是 1252那个 GBK 的字节流会被解成一堆无意义字符转换结果完全是垃圾。这种情况在部署到海外机器或者远程桌面环境时特别容易遇到本地测一百遍都是好的。其二简繁映射的对照表本身是 Unicode 层面的数据A 版本多绕的这一圈纯属损耗没有任何收益。所以正确姿势永远是无论当前用的是AnsiString还是UnicodeString都先显式转成WideString再调LCMapStringW。如果你的目标系统是 Vista 及以上还有一个LCMapStringEx可以选择它用 locale 名字符串而不是 LCID语义更清楚LCMapStringEx(zh-TW, LCMAP_TRAD, PWideChar(S), Length(S), PWideChar(Result), Need, nil, nil, 0);不过LCMapStringEx在老系统上不存在需要GetProcAddress动态取地址。项目如果还要兼容 XP 时代的机器就老老实实用LCMapStringW它在兼容性上没毛病。3. Delphi 7 到 XE 之后的编码适配3.1 GBK 进、GBK 出的显式转换写法Delphi 7 里把AnsiString赋给WideString会触发隐式转换走的是系统默认代码页。这在纯中文环境下没问题但一旦部署环境变了就会出事而且这种 bug 极难复现。我的做法是全程显式function AnsiToWideEx(const S: AnsiString; CodePage: UINT): WideString; var Need: Integer; begin Result : ; if S then Exit; Need : MultiByteToWideChar(CodePage, 0, PAnsiChar(S), Length(S), nil, 0); if Need 0 then Exit; SetLength(Result, Need); MultiByteToWideChar(CodePage, 0, PAnsiChar(S), Length(S), PWideChar(Result), Need); end; function WideToAnsiEx(const S: WideString; CodePage: UINT): AnsiString; var Need: Integer; begin Result : ; if S then Exit; Need : WideCharToMultiByte(CodePage, 0, PWideChar(S), Length(S), nil, 0, nil, nil); if Need 0 then Exit; SetLength(Result, Need); WideCharToMultiByte(CodePage, 0, PWideChar(S), Length(S), PAnsiChar(Result), Need, nil, nil); end;调用时把代码页写死成 936GBK不要用GetACP。理由很实际数据库里存的、配置文件里写的都是 936 的字节跟着系统代码页走反而会错。写死 936 至少在出问题时是“稳定的错”好排查。如果项目里还混着 UTF-8 的数据就再包一层UTF8Encode/UTF8Decode但代码页参数依然要显式传别让它自己去猜。3.2 UnicodeString 版本里最容易忽略的长度问题Delphi 2009 之后string就是UnicodeString看起来直接传给LCMapStringW就行但有个细节Length()返回的是 UTF-16 码元数不是“字数”。对于 BMP 内的字符绝大多数汉字都在这里两者相等但如果文本里混了 emoji 或者生僻的增补平面汉字一个“字”占两个码元。LCMapStringW的cchSrc要的正是码元数所以传Length(S)是对的。真正需要注意的是反向操作如果你自己写循环去遍历“字符”按S[i]逐个取遇到代理对就会把一个字拆成两半。转换函数本身不涉及这个问题但配套的词表匹配、长度统计、截断显示这些地方都会踩。我在项目里加了一个小工具函数CharCount专门统计真实字符数遇到高位代理就跳过下一个码元所有涉及“字数限制”的地方都用它避免用户输入框按码元数截断导致半个汉字变成乱码。3.3 一次封装两种编译期分支为了让同一份源码在 Delphi 7 和 2009 上都能编译我用了条件编译把对外接口统一起来{$IFDEF UNICODE} function SimpToTrad(const S: string): string; {$ELSE} function SimpToTrad(const S: AnsiString): AnsiString; {$ENDIF}实现上Unicode 版本直接走SimpToTradWANSI 版本先AnsiToWideEx(S, 936)转完再WideToAnsiEx(Result, 936)回去。核心转换逻辑只有SimpToTradW一份两个入口都是薄壳。这样做的好处是业务代码里完全不用关心当前编译器是什么版本照常调SimpToTrad就行。等到哪天项目整体升到新版本只要把{$ELSE}分支删掉别的什么都不用动。4. 一简对多繁LCMapString 兜不住的词怎么补4.1 典型歧义字清单与错误样例先把最容易出问题的字列出来这张表我贴在工位上很久了简体可能对应的繁体判断依据发發 / 髮出发、发生 → 發头发、理发 → 髮干幹 / 乾 / 干干部、干活 → 幹干净、干燥 → 乾干涉 → 干后後 / 后后来、后台 → 後皇后、太后 → 后里裡 / 里里面、心里 → 裡公里、里程 → 里面麵 / 面面条、面粉 → 麵方面、表面 → 面只隻 / 只一只、两只 → 隻只有、只是 → 只系係 / 繫 / 系关系 → 關係联系 → 聯繫系统 → 系統制製 / 制制造、制作 → 製制度、控制 → 制复復 / 複恢复、答复 → 復复杂、重复 → 複表錶 / 表手表、钟表 → 錶表示、表格 → 表台臺 / 台台湾地区习惯用臺但现代书面语也常直接用台LCMapString对上面这些字的处理是“一刀切”每个字只会给出一个固定结果。所以你会看到“頭髮”被转成“頭發”“乾淨”被转成“幹淨”“複雜”被转成“復雜”。这些不是偶发 bug是字符级映射的固有局限只能靠词表解决。4.2 占位符保护方案先切词再转换补词表有两条路。一条是转换完整句之后再去做“错形→正形”的替换比如把结果里的“頭發”改成“頭髮”。这条路实现简单但有个致命问题你可能改错。比如“皇后”如果已经被转成“皇後”你得再改回来可“後台”又确实是“後台”仅看结果分不清哪个该改。另一条路是在转换之前动手在简体原文里先把词组识别出来替换成占位符让LCMapString碰不到它们等字级转换完成再还原。我选的是这条路因为简体原文的上下文是明确的“头发”里的“发”一定是“髮”判断依据充足。流程分三步先用最长匹配扫描原文命中的词组替换成#1 序号 #2形式的占位符同时把对应的繁体词存进一个数组然后对整个字符串跑LCMapStringW最后把占位符按序号还原成繁体词。const PH_L #1; PH_R #2; function ProtectPhrases(const S: string; Dict: TStringList; Parts: TStringList; MaxLen: Integer): string; var i, L, W: Integer; Sub: string; Hit: Boolean; begin Result : ; i : 1; L : Length(S); while i L do begin Hit : False; for W : MaxLen downto 2 do begin if i W - 1 L then Continue; Sub : Copy(S, i, W); if Dict.IndexOfName(Sub) 0 then begin Parts.Add(Dict.Values[Sub]); Result : Result PH_L IntToStr(Parts.Count - 1) PH_R; Inc(i, W); Hit : True; Break; end; end; if not Hit then begin Result : Result S[i]; Inc(i); end; end; end;MaxLen控制词表里最长词的长度循环从长到短匹配保证“一头发”不会被拆成“一头”“发”。词表用TStringList存简体繁体的形式IndexOfName查找虽然底层是线性扫描但词表通常只有几千条加上TStringList默认是排序过的Sorted : True就可以走二分性能完全够用。4.3 词表的组织方式与匹配算法取舍词表条目数量决定算法选择。一万条以内TStringList加排序二分是最省事的方案代码短、调试直观、支持热更新。超过十万条就得考虑哈希表或者前缀树了。我在实际项目里用的是TDictionarystring, string因为 Delphi 2009 之后自带查找是 O(1)而且不用维护排序状态。代价是内存占用比TStringList高一些但一万多条词也就几 MB可以接受。匹配算法上简单的最长匹配每个位置从最长词往下试在词表不大时足够。如果词表膨胀到几万条每次从MaxLen开始逐个试会有点浪费可以改成按首字建索引先用首字查出候选词长度集合再逐个试。这个优化我在第二版才加上因为第一版在长文本上确实能感觉到卡顿。还有一个容易忽略的点重叠词。比如“干巴巴”和“干巴”最长匹配会优先命中前者这是对的。但如果词表里同时有“后台”和“台面”扫描到“后”时命中“后台”跳到“台”后面的位置就不会再匹配“台面”了。这在绝大多数情况下没问题因为原文里这两个词本来也不重叠。真正需要小心的是词表里存在互相包含的条目比如“头发”和“头发丝”这时候最长优先就能正确处理。4.4 反向转换繁→简为什么简单得多繁转简是多对一LCMapString一个调用基本就到位了。我实测过一批文本“頭髮”变“头发”“乾淨”变“干净”“複雜”变“复杂”全都正确因为目标只有一个。剩下需要处理的只有两类一类是地区用词差异比如“資訊”对应“信息”、“網路”对应“网络”这属于用词替换而不是字形转换要不要做取决于业务需求另一类是异体字“裡”和“裏”在繁体里都有人用转简体都是“里”不需要判断。所以我的TradToSimp函数里没有挂词表就是纯粹的LCMapStringW调用。如果以后有客户要求“台湾用词转大陆用词”再单独加一层用词替换表和字形转换解耦各管各的。5. 词库落地的工程细节加载、去重与更新5.1 词表从哪来怎么清洗词表来源无非三条公开的字符变体数据、现成的开源词库、以及自己从业务语料里挖。前两个能覆盖大部分通用词汇第三个才是真正提升准确率的部分——因为每个行业的歧义词不一样医疗系统里“干”出现在“干燥”里的概率远高于“干部”。拿到原始数据后必须清洗。我踩过的坑是词表里混进了长度不一致的条目比如“简体繁体”这种空值加载后Values返回空串导致命中的词被替换成空原文凭空少了一段。所以加载时一定要校验左右两边都非空、长度合理、不含占位符控制字符#1、#2。这个校验我写成独立函数加载时跑一遍把异常条目记进日志而不是直接抛异常避免一个坏条目让整个功能起不来。去重也要做。同一组简繁对可能在多个来源里重复出现TDictionary的Add遇到重复键会抛异常得用AddOrSetValue后加载的覆盖先加载的这样可以用“业务词表”覆盖“通用词表”实现优先级。5.2 内存结构与加载时机词表加载时机有两种选择程序启动时一次性加载或者第一次调用转换时懒加载。我选的是懒加载因为很多用户根本不用繁体界面启动时加载几千条词纯属浪费。懒加载的实现要注意线程安全。如果两个线程同时触发第一次转换可能同时进入加载逻辑造成重复加载或者半初始化状态。我用了一个临界区加双重检查先无锁判断字典是否已初始化没初始化再进临界区进去后重新判断一次。这个模式在 Delphi 里写起来不复杂但漏掉的话在压力测试时偶发崩溃定位起来很痛苦。内存占用方面一万条词大约占 3 到 5 MB对桌面程序可以忽略。但如果你的程序是常驻服务、要开几十个实例就得考虑把词表做成只读的全局单例共享一份内存。5.3 词库热更新与版本管理词表一定会变。业务方今天说“台”要统一转成“臺”明天又说某几个界面要保持“台”这种需求改代码太重所以我做成了外部文件加载程序启动时从指定目录读词表文件找不到就用内置的默认表。文件格式用最朴素的简体繁体每行一条UTF-8 编码方便业务方自己用记事本改。加载时先读文件再叠加内置表文件里的条目优先级更高。这样既能保证“没有外部文件也能跑”又能让客户自己微调。版本管理上我在文件头加了一行注释记录版本号和更新日期程序加载时把这个信息打进日志。出现问题的时候第一件事就是确认现场用的是哪个版本的词表——这个习惯帮我省过好几次来回沟通。6. 上线前的自测清单和几类典型翻车6.1 覆盖性用例该怎么设计简繁转换的测试用例不能靠随机抽文本得按“歧义字 词”的组合来设计。我的做法是先把第 4 节那张表里每个字的两种用法各造一个短句比如“他去理发”和“事情发生了”然后把这些句子拼成一段长文本跑转换肉眼检查每个字是否落在正确的形态上。再补一类“边界用例”纯英文、纯数字、中英混排、含全角标点、含#0字符、超长单行几万字。这几类里最容易出事的是中英混排和含#0。中英混排时LCMapString对英文字母是原样保留的但如果你在保护阶段用了#1、#2做占位符而原文里恰好也有这两个控制字符就会错乱。所以保护前要先扫描一遍把原文里的#1、#2替换掉或者直接拒绝处理。含#0的问题前面提过表现为“后半段没转”。测试时专门造一条带内嵌#0的字符串跑一遍能提前发现。6.2 长度变化与缓冲区溢出绝大多数简繁字符是一对一的但混入标点、全角字符、代理对之后长度可能变。我的代码里所有分配都基于第一次调用返回的Need没有一处用Length(S)硬算就是为了防这个。还有一种情况词表还原阶段长度会变。占位符#1 数字 #2的长度可能比原来的简体词短或长还原时如果用StringReplace逐个替换性能会很差每替换一次重建一次字符串。我的做法是先扫描一遍占位符位置算出最终长度一次性SetLength后逐段拼接避免反复分配。6.3 性能与多线程调用注意LCMapStringW本身很快十万字的文本一次调用通常在毫秒级。真正的瓶颈在词表匹配尤其是长文本加长词表的情况。我做过的粗略测试是一万条词表、十万字文本第一版实现大约需要几百毫秒改成首字索引后降到几十毫秒。这个量级对界面操作是可以接受的但如果要在列表里对几百行数据逐行转换就得考虑缓存或者批量处理。多线程方面LCMapStringW是无状态的可以并发调用。但词表的懒加载和热更新需要加锁保护。我的做法是把词表做成“加载完成后只读”的结构所有读操作无锁只有重新加载时进临界区替换整个引用。这样并发转换完全不阻塞只有极少数更新时刻会有短暂停顿。还有一个实际经验不要在主线程里做大批量转换。曾经有个界面在打开时要把几千条数据一次性转成繁体显示结果窗口卡了两三秒。后来改成后台线程转换完再回主线程更新体验立刻不一样。转换函数本身没问题问题在于调用位置。这套方案在项目里跑了大半年中间修过两次词表、改过一次编码处理的边界核心逻辑基本没动过。要我说最值得强调的一点是别指望任何单一 API 能把简繁转换做干净LCMapString是个很好的字级引擎但它不是词典。把字级和词级这两层分清楚代码结构自然就清楚了后面加词、改词、换算法都不会牵一发动全身。
