Delphi 简繁体转换函数：编码误区与词表最长匹配实践

做 Delphi 桌面项目做久了，简繁体转换这道坎迟早要迈过去。前些日子给一套面向前端内容运营的业务工具做本地化，对方负责人丢过来一句话：“界面上能不能加个繁体按钮”。我当时想当然，觉得调个系统 API 就收工了，结果在一台新系统上被 LCMapString 结结实实上了一课——函数返回 0，一个字没变。后来把整条链路从头摸了一遍，才发现 Delphi 简繁体转换函数写法这件事，难点根本不在“怎么调用”，而在“为什么这么调用会翻车”。这篇就把我踩过的坑、写过的几版函数、以及词表怎么攒，原样摊开聊一遍。

内容大致覆盖三块：一是把编码转换和字形转换这两个概念彻底分开，很多人第一步就走歪了；二是把转换函数的接口设计、数据结构选型、最长匹配算法从头写一遍，代码可以直接拿走；三是词表从哪儿来、一简对多繁怎么收敛、上线后怎么排查。适合手上有 Delphi 项目、需要做界面或文档简繁切换的开发者，也适合只是想搞清楚“简繁转换到底难在哪”的朋友。代码用 Object Pascal 写，Delphi 2009 之后和 Delphi 7 两个版本都会给到。

1. 先把两件事掰开：编码转换不是简繁转换

1.1 为什么走一趟 GBK 转 Big5 会满屏问号

我见过太多项目在这个地方栽跟头。思路听起来特别顺：简体中文在 GBK 里，繁体中文在 Big5 里，那把字符串从 936 代码页转成 950 代码页不就完了？代码也就三行，MultiByteToWideChar(936, ...)接WideCharToMultiByte(950, ...)。跑起来一看，常用词里凡是简体专用的字，全变成问号了。

原因说穿了一点不复杂。简体字和繁体字在两套编码里是两套独立的码位映射，而它们最终都要落到同一个 Unicode 空间里。可是在 Unicode 里，简体字和繁体字压根就是两个不同的码位——“发”是 U+53D1，“發”是 U+767C，谁也不是谁的另一半。简体专用的字形，在 Big5 码页里没有对应的位置，转换函数只能给你一个问号。能转过去的，往往是那些两边写法一致的字，比如“后”，转过去还是“后”，但它在繁体语境里该是“後”的时候，编码转换一点忙都帮不上。

所以这条路走不通，不是参数没调对，是方向本身就错了。编码转换解决的是“同一个字用哪套字节表示”，简繁转换解决的是“这个字该用哪种字形写法”，两件事差着十万八千里。我在项目里后来干脆把这类调用全部标注成禁用手写规则，谁再写就 review 打回。

1.2 系统 API 的历史包袱有多重

第二条路是调 Windows 自带的LCMapString。这个函数确实带过简繁转换的能力，常量也现成：LCMAP_SIMPLIFIED_CHINESE是$02000000，LCMAP_TRADITIONAL_CHINESE是$04000000。在比较老的系统上，下面这段代码是能跑通的：

function S2TByLCMap(const S: string): string; const LCMAP_TRADITIONAL_CHINESE = $04000000; var Need, Got: Integer; begin Result := ''; if S = '' then Exit; Need := LCMapStringW(LOCALE_SYSTEM_DEFAULT, LCMAP_TRADITIONAL_CHINESE, PWideChar(S), Length(S), nil, 0); if Need <= 0 then Exit(S); SetLength(Result, Need); Got := LCMapStringW(LOCALE_SYSTEM_DEFAULT, LCMAP_TRADITIONAL_CHINESE, PWideChar(S), Length(S), PWideChar(Result), Need); if Got <= 0 then Result := S else SetLength(Result, Got); end;

问题在于，这两个标志位在较新的系统版本上官方已经不再保证了。我在三台不同版本的机器上实测，有的直接返回 0，有的原样回吐输入字符串，还有的只对部分字符生效。更麻烦的是它跟系统区域设置挂得很紧，同一份程序在不同语言环境的机器上表现不一样，测试同学报上来的问题根本复现不了。这类依赖系统内部行为、又没有稳定文档兜底的方案，放在交付项目里就是个定时炸弹，后来我把这套代码整段删掉了。

1.3 词表方案：慢一点，但每一步都看得见

排除了前两条，剩下的路就是把简体字和繁体字的对应关系做成一张表，自己查。听起来笨，但它是唯一一个你能完全掌控结果的方案：出了错，翻词表就知道哪条映射写歪了；要加业务术语，往表里补一行就生效；跨平台、跨系统版本，行为完全一致。

代价也明摆着。第一，词表要自己攒，冷启动有成本。第二，一简对多繁、一繁对多简的歧义，光靠单字表消不掉，得往上加词组层。第三，词表越大，加载和查找的开销越高，得考虑数据结构。这三点恰好构成了后面几节要解决的全部问题，所以我们先把方案定下来：单字表打底、词组表优先、最长匹配扫描。这个组合是我试过的几种里综合表现最稳的。

2. 函数接口怎么定：签名、结构、生命周期

2.1 函数签名里藏着三个决策

一个简繁转换函数，对外暴露的接口无非是function Convert(const S: string): string。但就这一行，里面有三个点必须先想清楚。

第一个是方向。简转繁和繁转简是两张完全不同的表，绝不能混用。我一开始图省事，想用一个函数加个布尔参数区分，用起来特别容易传错。后来拆成S2T和T2S两个独立入口，各自持有独立的转换器实例，语义清楚，也方便分别配置词表。第二个是字符串类型。Delphi 2009 之后string就是UnicodeString，内部是 UTF-16，处理中文天然友好，直接用。Delphi 7 则要注意string是AnsiString，默认按 GBK 编码，繁体中文字符虽然 GBK 扩展区大部分能放下，但碰上生僻字就丢，老项目里我统一用WideString来做内部处理。第三个是是否要报错。我的做法是转换失败绝不抛异常，遇到查不到的字原样输出，保证调用方拿到的永远是可用字符串。这条在批量处理文档时救过命。

2.2 字典还是排序数组：一次实测对比

查表结构其实就两个候选。TDictionary<string, string>是 Delphi 2009 之后自带的泛型哈希表，插入和查找平均 O(1)；排序数组加二分查找是 O(log n)，但内存连续、缓存友好，而且 Delphi 7 也能用。

我拿一张四千条的词表做了轮实测，文本样本是一份约十二万字的中文文档，最大词条长度 4：

TDictionary在转换阶段明显占优，因为词表查询次数是文本长度的四倍（每个位置最多试四个长度），哈希的常数优势被放大了。排序数组的加载更快，但转换慢将近一倍。考虑到实际项目里转换是高频操作、加载只有一次，我最终选了TDictionary。Delphi 7 那边没得选，只能用排序数组，实测十二万字也在一百毫秒出头，完全能接受。

这里有个容易忽略的细节：TDictionary的键比较默认区分大小写，中文词条无所谓，但词表里如果混了英文缩写（比如某些专有名词），得显式传一个忽略大小写的比较器，否则同一份文档里大小写不同的写法会被区别对待。

2.3 词库的生命周期：别在函数里读文件

新手最容易犯的错，是把词库加载写在转换函数体里。每次调用都去读一遍文件，单次转换几十毫秒变成几百毫秒，批量处理直接卡死。我接手过一个项目就是这么写的，处理一千条记录要四十多秒，把加载提到单例初始化之后降到一秒以内。

正确的做法是懒加载单例：第一次调用时初始化，之后一直复用，用锁保证多线程下只初始化一次。词库本身在加载完成后是纯只读的，多线程并发查询TDictionary是安全的，只要没人往里写。这一点必须写进注释，否则后来接手的人随手加个“热更新词表”的功能，就会踩出偶发的访问越界。

var GS2T: TZhConverter = nil; GLock: TObject = nil; function ToTraditional(const S: string): string; begin if GS2T = nil then begin TMonitor.Enter(GLock); try if GS2T = nil then begin GS2T := TZhConverter.Create; GS2T.LoadFromFile(ExtractFilePath(ParamStr(0)) + 'dict_s2t.txt'); end; finally TMonitor.Exit(GLock); end; end; Result := GS2T.Convert(S); end;

GLock在单元初始化段创建，finalization段释放，顺序别搞反。这个小模式我在好几个项目里复用，稳得很。

3. 核心实现：最长匹配怎么落地

3.1 单字替换为什么撑不住

先看单字表能把你带到哪儿。词表里写“发 → 發”，那“头发”就变成“頭發”，错了，应该是“頭髮”。词表里写“后 → 後”，“皇后”就变成“皇後”，也错了。词表里写“里 → 裡”，“公里”变成“公裡”，照样错。

这些错误没法靠改单字映射修掉，因为冲突是结构性的：一个简体字在不同词里对应不同繁体字，单字层面根本无从判断。唯一的出路是把上下文纳进来，也就是词组优先。词表里既有单字条目也有词组条目，扫描时优先匹配最长的词，匹配不上再退到单字。这就是最长匹配，规则简单，但对词表质量极度敏感。

我把“头发/頭發”这类错误整理成了一份回归用例，每次改词表就跑一遍。这份用例现在有三百多条，覆盖了所有我遇到过的易错组合，是整个方案里最有价值的资产，比代码本身还重要。

3.2 主转换函数的完整写法

下面是 Delphi 2009 之后可以直接编译的版本。核心逻辑就是一句话：从当前位置开始，从最长键长往下试，试到就替换并跳过相应长度，试不到就原样输出一个字符。

function TZhConverter.Convert(const S: string): string; var Sb: TStringBuilder; I, L, K, MaxLen: Integer; Key, Val: string; Hit: Boolean; begin if S = '' then Exit(''); Sb := TStringBuilder.Create(Length(S) + 16); try I := 1; L := Length(S); while I <= L do begin { 代理对保护：遇到高位代理整体拷贝两个码元 } if (S[I] >= #$D800) and (S[I] <= #$DBFF) and (I < L) then begin Sb.Append(S[I]); Sb.Append(S[I + 1]); Inc(I, 2); Continue; end; MaxLen := FMaxKeyLen; if (L - I + 1) < MaxLen then MaxLen := L - I + 1; Hit := False; for K := MaxLen downto 1 do begin Key := Copy(S, I, K); if FDict.TryGetValue(Key, Val) then begin Sb.Append(Val); Inc(I, K); Hit := True; Break; end; end; if not Hit then begin Sb.Append(S[I]); Inc(I); end; end; Result := Sb.ToString; finally Sb.Free; end; end;

几个细节值得单独拎出来说。TStringBuilder一定要给个预估容量，直接Create空的话，长文本会触发多次扩容，实测风格差异能到百分之三十。代理对保护那段看着多余，但如果输入里混了表情符号或者生僻的扩展区汉字，不做这个判断就会把一个字符劈成两半，输出乱码。FMaxKeyLen是加载词表时统计出来的最大键长，别写死，业务词表随时可能加长词。最后那个Hit标志比用K的残留值判断可靠得多，我第一版就是拿K < 1判断的，结果for循环变量在循环结束后行为依赖编译器实现，踩了个隐蔽的坑。

3.3 词库加载与自检

加载这块，格式我定的是最朴素的制表符分隔文本，一行一条，#开头是注释。选它是因为运维同学能直接用记事本改，不用培训。

procedure TZhConverter.LoadFromFile(const AFileName: string); var Lines: TStringList; I, P: Integer; Line, K, V: string; begin Lines := TStringList.Create; try Lines.LoadFromFile(AFileName, TEncoding.UTF8); FDict.Clear; FMaxKeyLen := 1; for I := 0 to Lines.Count - 1 do begin Line := Trim(Lines[I]); if (Line = '') or (Line[1] = '#') then Continue; P := Pos(#9, Line); if P = 0 then Continue; K := Trim(Copy(Line, 1, P - 1)); V := Trim(Copy(Line, P + 1, MaxInt)); if (K = '') or (V = '') then Continue; FDict.AddOrSetValue(K, V); if Length(K) > FMaxKeyLen then FMaxKeyLen := Length(K); end; finally Lines.Free; end; end;

加载完一定要做一次自检，检查三件事：词条总数是否在合理区间、最大键长是否超出预期、有没有键或值为空。我在一个项目里就遇到过词表文件被编辑器改成了 GBK 编码，加载进来全是乱码，转换结果惨不忍睹，但程序不报任何错。后来加了一条规则：加载后如果词条数少于预期下限，直接抛异常，让问题在启动阶段暴露，而不是在用户面前。

4. 词表从哪儿来、怎么攒、怎么维护

4.1 用官方变体字段起底

从零手写词表是不现实的。我的起点是 Unicode 标准附带的汉字数据库，里面有两个字段正好对得上：kTraditionalVariant给出某个字的繁体变体，kSimplifiedVariant反过来给简体变体。数据是纯文本，一行一个码位，格式固定，写个几十行的解析脚本就能抽出第一版。

处理思路很直接：把码位转成字符，一个简体字对多个繁体变体的情况，拆成多条记录。抽完之后大概能拿到三千多条单字映射，覆盖了日常用字的绝大部分。但这批数据里噪音不少，有些变体是古籍异体字，现代出版根本不用；有些是地区差异，港澳台各有各的写法。所以抽出来只是第一步，后面必须过一遍人工筛选，把业务场景用不到的清掉。

我做筛选的办法是拿一份几十万字的真实业务语料跑一遍，统计每个词条在语料里的命中次数，低于阈值的一律砍掉。这一步很粗暴，但效果极好，词表从三千多条压到两千出头，体积小了，误判也少了。

4.2 一简对多繁的收敛策略

最折磨人的就是一简对多繁。举几个典型的：

策略很清楚：单字表选一个出现频率最高的作为默认值，剩下的靠词组表纠偏。默认值的选择原则是“宁可错得少”——统计语料里哪个变体出现最多就选哪个。“发”选“發”因为“发送、发布、发现”远多于“头发”；“面”选“面”因为“方面、全面、面对”远多于“面条”。

词组表不用一上来就穷举。我的做法是先上线，收集转换错误的反馈，一条一条往词组表里补。三个月下来补了两百多条，覆盖了百分之九十以上的问题。剩下那些极低频的，错就错了，收益成本不成比例。

反向的繁转简同样有歧义。“著”在繁体里既是“著作”的“著”，也是“着急”的“著”，转简体后要区分成“著”和“着”。这类词在词表里必须成对处理，光靠单字永远解决不了。

4.3 分层维护：公共词表和业务词表分开

词表千万别做成一个大文件。我在项目里拆成两层：一层是公共词表，跟具体业务无关，通用性强，升级时整体替换；另一层是业务词表，装产品名、功能名、内部术语，由业务方维护。加载时先读公共词表，再读业务词表覆盖，顺序不能反。

这么拆的好处很实际。公共词表可以跟着组件一起发布，业务词表可以单独热更新，两边互不影响。曾经有客户临时要求把产品名从简体改成特定的繁体写法，运维同学自己改一个文件、重启程序就完事了，不用研发介入。

业务词表还有个特殊用途：可以放“禁止转换”的条目。比如某些注册了商标的英文缩写，或者内部约定保留的简体字，在业务词表里写成键值相同的一行，就能把它锁死。这个用法我一开始没想到，是后来业务方提的需求，加上之后省了很多扯皮。

5. 踩坑记录与排查速查

5.1 高频错误案例对照

跑了大半年，错误基本集中在几个地方，整理成表，遇到问题先对照排查。

这张表我贴在工位上，新同事接手先看一遍，能省掉一半的沟通成本。

5.2 性能压测和缓存要不要做

简单说结论：一般场景不需要缓存，做了反而增加复杂度和出错概率。

我做过压测，十二万字文档，四千条词表，单线程转换耗时四十毫秒左右。加上二级缓存（对重复出现的词做结果缓存）能降到三十毫秒，提升百分之二十五，但引入了缓存一致性问题——热更新词表时缓存必须整体清空，忘了清就会出现新旧混用。这点收益不值得这点风险，我最终没上。

真正值得优化的是两处。一是TStringBuilder的预分配容量，按输入长度乘一点二给，能省下多次扩容。二是避免在循环里反复调用Copy生成临时字符串，我这版每轮最多生成四次小字符串，代价可接受，但如果把最大键长放到 8，次数翻倍，耗时明显上升。所以词表里超过六个字的条目我一般会考虑合并或删掉，长词带来的收益远不如开销。

如果确实有超长文本要处理，比如整本手册，建议按段落切分，一段一次调用，边转换边输出，别一次性吞进去。这样内存占用平稳，用户也能看到进度。

6. 老版本 Delphi 的兼容处理

6.1 Delphi 7 上的字符串陷阱

老项目还在 Delphi 7 上跑，这时候string是AnsiString，默认 GBK。繁体中文字符在 GBK 扩展区大部分能放下，但一些生僻字和港台特有写法会丢。我的处理办法是内部统一用WideString，只在出入口做转换。

数据结构那边没有泛型，用不了TDictionary。替代方案是自己维护两个动态数组，一个存键一个存值，按WideString排序，查找走二分。实测十二万字在一百二十毫秒左右，可以接受。

function TZhConverter7.FindKey(const Key: WideString): Integer; var Lo, Hi, Mid, Cmp: Integer; begin Result := -1; Lo := 0; Hi := FCount - 1; while Lo <= Hi do begin Mid := (Lo + Hi) shr 1; Cmp := CompareStr(FKeys[Mid], Key); if Cmp = 0 then begin Result := Mid; Exit; end else if Cmp < 0 then Lo := Mid + 1 else Hi := Mid - 1; end; end;

注意CompareStr对WideString是按码位比较的，跟排序时用的顺序必须完全一致，否则二分查找会漏。我第一版排序用的是CompareText，查找用CompareStr，结果一半的词查不到，排查了大半天。这种低级错误在老代码里特别常见，改的时候一定要两头对齐。

6.2 词库打包：外挂还是内嵌

外挂文件的好处是能热更新、能现场改，缺点是容易丢、容易被改坏、多一层文件路径问题。内嵌资源的好处是单文件分发、不怕丢，缺点是每次改词表都要重新编译。

我的默认选择是内嵌为主、外挂为辅：公共词表编译进资源，业务词表外挂。这样产品发出去是个干净的单文件，业务方要改术语也能自己动手。

内嵌的做法是把词表文本做成.res资源文件，运行时用TResourceStream读出来再喂给加载函数，走的是同一套解析逻辑，不用维护两份代码。资源脚本的写法各个 Delphi 版本略有差异，这里就不展开了，核心是让加载函数接受流而不只是文件名，接口稍微改一下就行。

部署时还有一个坑：外挂词表放在程序目录下，用ExtractFilePath(ParamStr(0))拼路径，这在大多数情况下没问题，但如果程序被装到受保护目录（比如某些系统的程序文件夹），写入会失败。所以词表只读不写，任何运行时的修改都落到用户数据目录，这条在安装包里就要定好，别等上线后才发现。

最后分享一个我在实际项目里养成的习惯：转换函数上线前，拿一份包含两千个常用词的测试文本跑一遍，人工抽查前两百个结果，重点看“发”“后”“里”“干”“面”这几个高频歧义字。这一步大概花二十分钟，能拦下八成以上的词表问题，比事后被用户投诉划算得多。工具就在手边，关键是愿不愿意在交付前多花这二十分钟。