简介这套为Delphi 5量身打造的TntUnicodeControls 2.1.11组件集面向需要处理中文、日文等非ASCII字符的桌面应用开发者用于弥补早期Delphi版本在Unicode支持上的不足。压缩包内共177个文件约743KB以pas源码、dcu编译单元、dpk/dof工程配置及res/dcr资源文件为主同时包含少量示例与说明文档便于直接编译安装并接入现有VCL项目。控件库提供TntEdit、TntButton等原生控件的Unicode增强版以及TntWideString等扩展类型与转换函数能显著简化多语言界面的开发。目前已有253人学习使用适合希望低成本实现全球化软件的中高级Delphi开发者既能获得完整源码用于学习内部实现又能在实际项目中快速集成提升跨语言文本的处理体验。1. TntUnicodeControls 是给谁的后悔药Delphi 2007 之前的 Unicode 难题接手某公司老系统时我见过最经典的一幕Delphi 7 写的进销存客户要录入俄语客户名。程序跑起来TEdit 里打一个俄文字母屏幕上直接一个问号。更诡异的是明明数据库字段能存 Unicode界面上却怎么都敲不进去。这种问题在 Delphi 2009 之前几乎是死结因为原生 VCL 的 string 是 AnsiString控件内部走的是 ANSI 字符集的消息通道。TntUnicodeControls_2_1_11 就是当年最主流的解法一套带 Tnt 前缀的控件在同一个 VCL 框架里把按钮、编辑框、列表框、自定义绘制全部换成 WideString 版本让 Delphi 5 到 2007 的项目能正儿八经地处理和显示 Unicode。本文就按一个维护老项目的人最关心的路径来讲它怎么工作、怎么装、控件怎么换、哪些参数必须调、以及实际踩过的坑。2. 先拆开 Tnt 控件的底细TntControl 基类与 TntString 的配合逻辑2.1 Tnt 控件不是新控件是 VCL 的 Unicode 版影子TntUnicodeControls 最核心的设计思路不是重新发明一套界面库而是给标准 VCL 控件做“替身”。也就是说它把 TButton 变成 TntButton把 TEdit 变成 TntEdit但控件名、属性名、事件名都尽量保持和原来的 VCL 控件一致。这样就带来一个好处老项目里Button1.Caption : 确定这种代码只要把控件类换掉连属性赋值都不用改。坏处也在这里如果你只是换了控件类而没有同步改掉底层字符串处理逻辑数据还是会从 AnsiString 的缺口漏出去。我一般会把 Tnt 控件看作“VCL 控件壳 WideString 内核”。每个 Tnt 控件内部会重写关键的消息分发方法例如从 WM_SETTEXT 里取 WideChar 缓冲区而不是直接取 PChar。这个再封装层就是它能解决乱码的根本原因。实际使用时你在 Form 上放一个 TntEdit它看起来和 TEdit 没什么两样但属性检查器里Text的返回类型已经是 WideString这决定了后续所有赋值和比较操作都要按 Unicode 规则走。2.2 TntControl 到底改了什么从 TControl 到消息转发要理解它改了什么得先看一条常见的调用链。标准 TEdit 在显示文字时会走SendMessage(Handle, WM_SETTEXT, 0, LPARAM(PChar(S)))这里PChar(S)在 Delphi 2007 之前实际上是一个指向 ANSI 字节序列的指针。系统拿到这个指针后按照当前线程的代码页去解释。当代码页是 GBK而字符串里混了俄文或罗马尼亚文必然出现乱码。Tnt 控件把这条链路拆开它先用自己的TntControl.SetTextW方法调用SendMessageW(Handle, WM_SETTEXT, 0, LPARAM(PWideChar(WideString)))同时把内部FText保存为一个WideString。这是一个很关键的差异——老的 VCL 控件用TCaption stringTnt 控件用TntCaption WideString。所以在编译时你就会看到差异给 TntEdit.Text 赋一个AnsiString编译器会自动做隐式转换但这个转换不是无害的——如果 AnsiString 里的字节并不是当前代码页的有效字符转换后就是一堆 UFFFD 替换符。这属于后面要讲的参数坑。2.3 为什么要用 TntString 而不是 string字符长度与内存布局Tnt 控件自带一个重要的类型叫TntString它在跑在 Windows 上时等价于WideString。用WideString而不是UnicodeString的原因很务实Delphi 2007 之前的编译期 RTL 还不支持新的 UnicodeString 快速引用计数而 WideString 直接走系统 OLE 的 BSTR 分配兼容性和内存管理都交给系统做不容易爆引用计数。这里有一个新手特别容易看走眼的地方Length(TntString)返回的到底是字符数还是字节数你会发现它返回的是 WideChar 个数而不是 Byte。比如处理一个包含中文和 emoji 的字符串一个 emoji 在 WideString 里是两个 WideCharLength会多算一个。这不是 Tnt 控件的问题而是所有 UTF-16 存储的共同特点。我在处理输入法文本时习惯用一个辅助函数把代理对合并统计避免按Length截断字符串时把一个 emoji 劈成两半。下面这个函数可以放在公共单元里function TntStringCharacterCount(const S: WideString): Integer; var i: Integer; begin Result : 0; i : 1; while i Length(S) do begin Inc(Result); if (Ord(S[i]) $D800) and (Ord(S[i]) $DBFF) then Inc(i); { 跳过低代理项 } Inc(i); end; end;这个函数里判断$D800到$DBFF是 UTF-16 的高代理区如果当前位置是高代理说明下一个 WideChar 是低代理必须合并当成一个字符。你把它用在 TntEdit 的字符数统计、或者在 TntMemo 里按显示行截断时能少踩一半的 Unicode 坑。参数说明S是要统计的 TntString 对象返回整数。调用方不要直接用Length(Text)作为输入法最大长度校验否则用户打一个表情符号就会莫名其妙被截断。3. 在 Delphi 7 里装好 TntUnicodeControls_2_1_11安装顺序与最小可跑工程3.1 拿到压缩包后先看目录packages、source 和 installerTntUnicodeControls_2_1_11 解压后常见的目录结构是这样packages里放了分版本的分组文件比如 D7、D2005、D2006 各自对应的.dpksource里是控件源码和运行时包源码如果有bin目录可能是预编译的.dcu和.bpl。我强烈建议你不要直接去点某个自动安装脚本而是在 Delphi 里手动添加source到 Library 路径再打开packages下对应当前 IDE 版本的主包文件。为什么一定要手动因为 2.1.11 这个版本要兼容从 Delphi 5 到 Delphi 2007 的多个 IDE不同版本对包命名和资源文件格式要求不一样。自动安装脚本通常假定你的安装路径是默认的C:\Delphi一旦你换了盘符或者把源码放在带中文的目录下包能编译出 DCU但 IDE 注册组件时往往找不到资源。我见过有人卡在“编译通过但没有控件”上大半天最后发现是源码路径里有中文IDE 在读取.res文件时用了 ANSI 路径解析直接崩了。这里给你一个检查清单第一解压路径不要有中文和空格第二确认 Delphi 的 Library 路径已经指向source目录第三在packages目录里找到类似TntUnicode_D7.dpk的文件这个才是 Delphi 7 对应的项目。如果你用的是 Delphi 6找TntUnicode_D6.dpk。不要拿 D7 包硬装到 D6 里编译器会因为找不到Windows.pas里的某个新 API 报错。3.2 用 IDE 编译安装 DCP 包的两种路线路线一是在 IDE 里操作先打开 D7 的包文件在项目管理器里找到Runtime Packages下的那个包右键选择Compile编译通过后再右键Install。这个方式能直观地看到 IDE 提示“已安装”并且组件面板会多出一个 Tnt 页。路线二是用命令行编译适合需要把编译过程写进批处理、方便同事的团队。我常用这样一段命令dcc32 -B -Q -DDELPHI7 -IE:\TntUnicodeControls\source -UE:\TntUnicodeControls\source -EE:\TntUnicodeControls\dcu TntUnicode_D7.dpk这段命令里-B表示重新构建-Q是安静模式-DDELPHI7是条件编译用的符号-I和-U都指向 source 目录-E指定 DCU 输出目录。编译成功后再执行一次 IDE 内的Install或者用regsvr32其实 Delphi 的包不是 COM 组件不需要 regsvr32。命令行编译只生成.dcu和.bpl真正把组件注册进 IDE 还是得在 IDE 里 Install 那个.bpl。所以我一般只把命令行当作“编译检查”最终安装还是靠 IDE 菜单。如果你发现 IDE 提示“无法找到 TntControl.dcu”先别怀疑控件包坏了去检查Tool Options Library里的路径有没有把source加进去。加了还报错就检查是不是有多个版本的 DCU 残留在 IDE 的Lib默认目录把旧的删干净再编译一次。这个坑在 2.1.11 上尤其明显因为网上流传的很多精简版压缩包里混了不同版本的 DCU。3.3 建一个最小工程验证 TntEdit 的 Unicode 输入装好以后我建议不要直接改造大项目先建一个只有 Form 和两个控件的工程验证环境是否健康。放一个TntEdit和一个TntButton然后在按钮的OnClick里把一个俄文常量赋给Edit1.Text再弹出来。下面是完整步骤procedure TForm1.TntButton1Click(Sender: TObject); var S: WideString; begin S : Привет, мир; { 俄文“你好世界” } TntEdit1.Text : S; ShowMessage(TntEdit1.Text); end;注意这里ShowMessage在 Delphi 7 里接收的是string所以TntEdit1.Text这个WideString会隐式转回AnsiString。如果俄文字符在系统代码页里没有对应关系弹窗里照样显示问号。这不代表 TntEdit 有问题而是ShowMessage本身是 ANSI 的。正确的验证方式是再放一个TntMemo把文字赋值给它同时用GetWindowTextW检查窗口文本function GetTntTextW(Handle: HWND): WideString; var Len: Integer; begin Len : GetWindowTextLengthW(Handle); SetLength(Result, Len); GetWindowTextW(Handle, PWideChar(Result), Len 1); end;这段代码通过GetWindowTextLengthW拿到系统缓冲区里的字符数再用GetWindowTextW取出来放到WideString里。如果这个函数返回的字符串和刚才输入的俄文完全一致说明 Tnt 控件内部确实走的是 Unicode 通道。参数说明Handle是目标窗口句柄也就是 TntEdit1.Handle返回值是宽字符字符串。你用这个函数去检查 TntEdit、TntMemo、TntComboBox 的文本都能拿到真实内容。这也是后面排查“控件明明显示正常但数据库读出来乱码”时的标准工具。4. 把现有代码换成 Tnt 控件常用替换清单与 5 个必调参数4.1 控件映射表从 TEdit 到 TntEdit从 TCheckBox 到 TntCheckBoxTnt 控件覆盖了 VCL 常用控件的大部分但并不是全部。我整理过一张自己的替换表按风险高低排序。最安全的是和文本直接相关的TEdit - TntEdit、TMemo - TntMemo、TListBox - TntListBox、TComboBox - TntComboBox、TLabel - TntLabel、TCheckBox - TntCheckBox、TRadioButton - TntRadioButton、TButton - TntButton。这些控件的Caption或Text直接变成WideString替换后处理中文、日文、韩文都没问题。中等风险的是带项列表的TTreeView - TntTreeView、TListView - TntListView、TToolBar - TntToolBar、TStatusBar - TntStatusBar它们不光文本要改节点数据和OwnerDraw回调里也可能涉及字符串长度。比较隐蔽的是那些不带文本但通过 Windows API 拿文本的控件比如TDateTimePicker和TMonthCalendar。Tnt 控件库其实也有对应的TntDateTimePicker但很多人会忽略因为它们的Text属性并不是直接暴露的。你如果继续用标准TDateTimePicker在中文系统上它能正常显示日期但如果你要自定义格式为“yyyy年MM月dd日 dddd”然后配合FormatSettings里的 Unicode 符号就可能出现错位。我的建议是先替换 Form、Panel、DataModule 里直接和用户输入相关的控件跑通一轮回归再处理网格和树。项目里如果用了DBGrid先别急着替换——Tnt 控件库里没有TntDBGrid常见的做法是继续用标准 DBGrid但要靠TntDataSet不对Tnt 库里没有数据集控件所以要解决数据库里读出来的WideString显示问题要么把 DBGrid 的列字段类型设为ftWideString要么自己写一个 自定义呈现器 。这段路走得通但和 Tnt 本身无关别把时间浪费在找“TntDBGrid”上。4.2 替换后必须检查的 5 个参数Caption、Font.Charset、ImeMode、MaxLength、CharCase这 5 个参数是我每次做替换时逐个过一遍的。第一个是Caption和Text的类型你可以用鼠标点中控件在对象检查器里看属性类型是否标成TntCaption或WideString确认真正的替换生效。第二个是Font.Charset默认是DEFAULT_CHARSET但如果你原来手工给控件设置过GB2312_CHARSET替换成 Tnt 后反而要把它改回DEFAULT_CHARSET。原因是 Tnt 控件内部用WideString绘制字体选择交给 Windows 字体链接机制强制指定 ANSI 字符集会让系统错误地选回宋体以外的低版本字体。第三个是ImeMode这个属性在标准 VCL 里存在但经常不生效Tnt 控件通过ImmSetContext实现了真的输入法切换。如果你的输入框要输入中文把ImeMode设为imChinese要输入英文设为imEnglish。不设的话输入法可能一直停在全角状态。第四个是MaxLength这个参数在 AnsiString 时代是按字节数限制的在 Tnt 控件里却是按字符数限制。假设你原来设MaxLength : 10用户输入 5 个汉字加 5 个英文字符在旧代码里算 15 个字节会被拦掉在 Tnt 控件里算 10 个字符正好放行。这算是一个行为改善但如果你依赖这个参数强行限制数据库字段长度就要小心数据库字段如果是VARCHAR(20)而你的每个汉字按 UTF-8 存 3 字节界面上放行的 10 个字符可能让数据库报超长。第五个是CharCase标准 TEdit 的CharCase会把输入内容直接按大小写转换但 Tnt 版对这个参数的处理粒度不同——它在WM_CHAR阶段处理对非拉丁字符不会误伤但对某些欧洲字符比如ß和ı转换结果取决于 Windows 版本。我的建议是把有明确要求的输入框手动处理OnChange而不是依赖CharCase毕竟它的转换规则在 Unicode 里并不完整。4.3 替换遗留的 AnsiString 赋值WideString 转换的坑代码里最常见的问题是var S: string; S : TntEdit1.Text;。这个赋值会触发隐式转换把 TntEdit1.Text 的 WideString 按当前线程代码页转换成 AnsiString。如果字符串里只有 ASCII 和中文在中文系统上没问题一旦有俄文、阿拉伯文或扩展拉丁字符转换结果就是 ? 或空白。你必须在整个调用链上把变量类型改成WideString或TntString。下面是需要改的类型对照var OldCaption: string; { 旧代码 } NewCaption: WideString; { 替换后 } begin OldCaption : TntButton1.Caption; { 可能静默丢失字符 } NewCaption : TntButton1.Caption; { 完整保留 } end;string和WideString在赋值操作上编译器不会警告所以这是隐藏得最深的坑。我用一个土办法避免在每个单元顶部给string起个别名AnsiString然后让编译器类型检查在不确定的地方报错其实更可靠的是用WideString显式声明所有界面相关变量。另外如果你调用了 Windows API比如SendMessage(Handle, WM_GETTEXT, ...)这里的缓冲区要按WideChar申请并且用SendMessageW。Tnt 控件虽然封装了绝大多数场景但如果你直接操作Handle就会绕开封装必须自己注意。5. 必踩的坑Tnt 控件在中文系统下的乱码、资源泄漏与安装顺序5.1 安装后 IDE 报错或控件面板不显示现象、原因、解决现象按照 3.2 的步骤编译通过也点了 Install但组件面板上找不到 “Tnt” 页或者在打开窗体时 IDE 弹“Class TntButton not found”。原因基本是两个一是 IDE 的包格式和源码里requires的运行时包不一致二是存在另一个同名包在更早的搜索路径里被加载导致 IDE 组件注册表冲突。解决方法是先清掉旧包在 IDE 的Component Install Packages里把Tnt Unicode Controls前一项“Remove”然后关闭 IDE删除$(DELPHI)\Lib下面所有Tnt*.dcu、Tnt*.bpl、Tnt*.res文件重启 IDE 再重新编译安装。我碰到过最奇葩的一次是TntExtCtrls的.bpl版本号和控件源码头部的TNT_UNICODE_VERSION不匹配IDE 加载了高版本的 BPL 又遇到低版本 DCU结果面板上有一半控件是灰的。清理重装能解决 90% 的安装问题。5.2 TntEdit 能输入但显示方框字体 Charset 没设对现象TntEdit 能接受中文输入字也存进去了但显示成一个个方框。原因不是输入链路而是字体渲染链路的字符集选择。Windows 的 EditBox 内部会根据font.charset选择字形如果 Charset 是DEFAULT_CHARSET且字体名是“宋体”实际上能显示中文。但如果你继承了一个字体设置比如从 Form 上传下来的MS Sans Serif这个字体本身不含中文字形系统会降级到 System 字体结果就是方框。解决方法是给每个 TntEdit 单独指定Font.Name : 宋体或者更好的无衬线字体Microsoft YaHei并且确保Font.Charset : DEFAULT_CHARSET。注意在 Delphi 7 里“宋体”这个名字是 ANSI 字面量但它在所有中文 Windows 上都能被正确转换如果你写微软雅黑在非中文系统上可能找不到。我一般写成Font.Name : Microsoft YaHei因为这是英文字体名各语言系统都认。5.3 和第三方皮肤控件一起用按钮字全变黑块现象项目里用了某种皮肤控件把 TButton 替换为 TntButton 后皮肤控件无法识别 TntButton按钮上的文字变成黑块或消失。原因皮肤控件内部通过遍历控件类名来判断要渲染哪一种控件只认TButton不认TntButton。解决要么在皮肤控件的映射表里手动增加 TntButton 的分类要么给 TntButton 写成派生类让它在运行时伪装类名实际操作中更直接的办法是不替换按钮类只替换 TEdit/TMemo/Label 这类文本显示控件。按钮上的文字大多是短文本多半是中文在 GBK 下也能正常显示真正需要 Tnt 的是输入框和复杂字符区。如果你非得所有控件都换那就顺着皮肤控件的扩展接口把 TntButton 的绘制函数注册进去。这个方向比较折腾我做过一次以后再遇到皮肤项目我就明确建议“只换文本输入类控件”。5.4 切换输入法时程序卡顿处理 WM_IME_NOTIFY 的正确姿势现象在 TntEdit 里切换输入法程序偶尔卡死一两秒甚至崩溃。原因Tnt 控件为了支持输入法上下文会处理WM_IME_NOTIFY和WM_IME_SETCONTEXT但如果你在这些消息里访问了 VCL 控件属性而输入法进程是从系统消息循环里来的可能触发重入。解决在 Tnt 控件的OnImeNotify事件如果有或者重写的WndProc里不要做任何界面刷新操作只做状态保存。我一般在工程里加一个标志位等消息队列空闲再处理。下面这段示意代码放在 TntEdit 的派生类里procedure TMyTntEdit.WndProc(var Message: TMessage); begin if Message.Msg WM_IME_NOTIFY then begin FLastImeNotify : Message.WParam; // 只是存值不刷新界面 Exit; // 跳过默认处理避免 VCL 内部触发重入 end; inherited WndProc(Message); end;这段代码最关键的是Exit它阻止了默认分支中对某些输入法上下文函数的调用从而避免卡顿。代价是你可能会丢掉一些输入法提示的默认行为比如候选窗口的显示位置。不过 2.1.11 的控件库自带一套输入法上下文管理你直接继承 TntEdit 而不重写 WndProc通常也不会卡。只有在集成第三方输入法比如某些老式中文输入法时这种重入问题才会冒出来。我自己的经验是如果项目只在公司内部用可以这么干如果是通用软件还是得保证输入法提示完整那就不要 Exit而是把调用是非重入函数。6. 进阶用 Tnt 控件做输入法自绘和跨版本迁移的边界6.1 自绘 TntButton 的 OnPaint 里如何正确画文字如果你要在 Tnt 控件上做自绘就别再用Canvas.TextOut配合string了那样画出来的还是 ANSI 转码后的文本。正确做法是用DrawTextW直接传PWideChar。下面这段代码可以在 TntButton 的派生类里画出自定义外观procedure TMyTntButton.PaintText(ACanvas: TCanvas); var R: TRect; T: WideString; begin R : ClientRect; T : Caption; // Caption 已经是 TntCaption InflateRect(R, -4, -4); DrawTextW(ACanvas.Handle, PWideChar(T), Length(T), R, DT_CENTER or DT_VCENTER or DT_SINGLELINE or DT_END_ELLIPSIS); end;注意这里DrawTextW的Length(T)是字符数传入-1也可以但显式传入字符数可以避免在字符串中间出现嵌入#0时截断。比较坑的是Canvas.Font的句柄要和 Tnt 控件的字体同步否则画出来的字体比显示的字体小一圈。你可以先ACanvas.Font : Self.Font再画确保一致。6.2 从 Tnt 控件迁移到 Delphi 2009 原生 Unicode 的验证方法如果你的团队终于决定升级到 Delphi 2009 及以上版本Tnt 控件就可以退休了因为原生 VCL 已经全面支持 Unicode。迁移时最值得做的事情不是简单地把TntEdit改成TEdit而是验证所有WideString和UnicodeString混用点。我会写一段小脚本遍历整个工程的所有窗体读取每个控件的Text、Caption、Items用IsTextUnicode检查结果里是否包含无效字符。更省事的方法是编译一个 Debug 版程序然后把所有输入控件“全选、复制、粘贴”到记事本看有没有问号。操作很简单在运行界面上按 CtrlA 然后 CtrlC粘贴出来的字符串如果完整基本说明 Tnt 控件到原生的迁移没漏。迁移后记得删掉Tnt*单元引用不然编译器会把旧 DCU 也带进来导致一次编译两种 CRT甚至内存越界。我自己当年迁移一个 20 万行代码的项目最后漏了一个TntSystem.pas的引用结果在关闭窗体时偶发访问冲突查了半天才发现是这个引用让 RTL 里有两套Move函数。经验就是全局搜索Tnt把所有uses里的Tnt*清干净再重新编译两轮。希望帮到你。本文还有配套的精品资源点击获取
简介这套为Delphi 5量身打造的TntUnicodeControls 2.1.11组件集面向需要处理中文、日文等非ASCII字符的桌面应用开发者用于弥补早期Delphi版本在Unicode支持上的不足。压缩包内共177个文件约743KB以pas源码、dcu编译单元、dpk/dof工程配置及res/dcr资源文件为主同时包含少量示例与说明文档便于直接编译安装并接入现有VCL项目。控件库提供TntEdit、TntButton等原生控件的Unicode增强版以及TntWideString等扩展类型与转换函数能显著简化多语言界面的开发。目前已有253人学习使用适合希望低成本实现全球化软件的中高级Delphi开发者既能获得完整源码用于学习内部实现又能在实际项目中快速集成提升跨语言文本的处理体验。1. TntUnicodeControls 是给谁的后悔药Delphi 2007 之前的 Unicode 难题接手某公司老系统时我见过最经典的一幕Delphi 7 写的进销存客户要录入俄语客户名。程序跑起来TEdit 里打一个俄文字母屏幕上直接一个问号。更诡异的是明明数据库字段能存 Unicode界面上却怎么都敲不进去。这种问题在 Delphi 2009 之前几乎是死结因为原生 VCL 的 string 是 AnsiString控件内部走的是 ANSI 字符集的消息通道。TntUnicodeControls_2_1_11 就是当年最主流的解法一套带 Tnt 前缀的控件在同一个 VCL 框架里把按钮、编辑框、列表框、自定义绘制全部换成 WideString 版本让 Delphi 5 到 2007 的项目能正儿八经地处理和显示 Unicode。本文就按一个维护老项目的人最关心的路径来讲它怎么工作、怎么装、控件怎么换、哪些参数必须调、以及实际踩过的坑。2. 先拆开 Tnt 控件的底细TntControl 基类与 TntString 的配合逻辑2.1 Tnt 控件不是新控件是 VCL 的 Unicode 版影子TntUnicodeControls 最核心的设计思路不是重新发明一套界面库而是给标准 VCL 控件做“替身”。也就是说它把 TButton 变成 TntButton把 TEdit 变成 TntEdit但控件名、属性名、事件名都尽量保持和原来的 VCL 控件一致。这样就带来一个好处老项目里Button1.Caption : 确定这种代码只要把控件类换掉连属性赋值都不用改。坏处也在这里如果你只是换了控件类而没有同步改掉底层字符串处理逻辑数据还是会从 AnsiString 的缺口漏出去。我一般会把 Tnt 控件看作“VCL 控件壳 WideString 内核”。每个 Tnt 控件内部会重写关键的消息分发方法例如从 WM_SETTEXT 里取 WideChar 缓冲区而不是直接取 PChar。这个再封装层就是它能解决乱码的根本原因。实际使用时你在 Form 上放一个 TntEdit它看起来和 TEdit 没什么两样但属性检查器里Text的返回类型已经是 WideString这决定了后续所有赋值和比较操作都要按 Unicode 规则走。2.2 TntControl 到底改了什么从 TControl 到消息转发要理解它改了什么得先看一条常见的调用链。标准 TEdit 在显示文字时会走SendMessage(Handle, WM_SETTEXT, 0, LPARAM(PChar(S)))这里PChar(S)在 Delphi 2007 之前实际上是一个指向 ANSI 字节序列的指针。系统拿到这个指针后按照当前线程的代码页去解释。当代码页是 GBK而字符串里混了俄文或罗马尼亚文必然出现乱码。Tnt 控件把这条链路拆开它先用自己的TntControl.SetTextW方法调用SendMessageW(Handle, WM_SETTEXT, 0, LPARAM(PWideChar(WideString)))同时把内部FText保存为一个WideString。这是一个很关键的差异——老的 VCL 控件用TCaption stringTnt 控件用TntCaption WideString。所以在编译时你就会看到差异给 TntEdit.Text 赋一个AnsiString编译器会自动做隐式转换但这个转换不是无害的——如果 AnsiString 里的字节并不是当前代码页的有效字符转换后就是一堆 UFFFD 替换符。这属于后面要讲的参数坑。2.3 为什么要用 TntString 而不是 string字符长度与内存布局Tnt 控件自带一个重要的类型叫TntString它在跑在 Windows 上时等价于WideString。用WideString而不是UnicodeString的原因很务实Delphi 2007 之前的编译期 RTL 还不支持新的 UnicodeString 快速引用计数而 WideString 直接走系统 OLE 的 BSTR 分配兼容性和内存管理都交给系统做不容易爆引用计数。这里有一个新手特别容易看走眼的地方Length(TntString)返回的到底是字符数还是字节数你会发现它返回的是 WideChar 个数而不是 Byte。比如处理一个包含中文和 emoji 的字符串一个 emoji 在 WideString 里是两个 WideCharLength会多算一个。这不是 Tnt 控件的问题而是所有 UTF-16 存储的共同特点。我在处理输入法文本时习惯用一个辅助函数把代理对合并统计避免按Length截断字符串时把一个 emoji 劈成两半。下面这个函数可以放在公共单元里function TntStringCharacterCount(const S: WideString): Integer; var i: Integer; begin Result : 0; i : 1; while i Length(S) do begin Inc(Result); if (Ord(S[i]) $D800) and (Ord(S[i]) $DBFF) then Inc(i); { 跳过低代理项 } Inc(i); end; end;这个函数里判断$D800到$DBFF是 UTF-16 的高代理区如果当前位置是高代理说明下一个 WideChar 是低代理必须合并当成一个字符。你把它用在 TntEdit 的字符数统计、或者在 TntMemo 里按显示行截断时能少踩一半的 Unicode 坑。参数说明S是要统计的 TntString 对象返回整数。调用方不要直接用Length(Text)作为输入法最大长度校验否则用户打一个表情符号就会莫名其妙被截断。3. 在 Delphi 7 里装好 TntUnicodeControls_2_1_11安装顺序与最小可跑工程3.1 拿到压缩包后先看目录packages、source 和 installerTntUnicodeControls_2_1_11 解压后常见的目录结构是这样packages里放了分版本的分组文件比如 D7、D2005、D2006 各自对应的.dpksource里是控件源码和运行时包源码如果有bin目录可能是预编译的.dcu和.bpl。我强烈建议你不要直接去点某个自动安装脚本而是在 Delphi 里手动添加source到 Library 路径再打开packages下对应当前 IDE 版本的主包文件。为什么一定要手动因为 2.1.11 这个版本要兼容从 Delphi 5 到 Delphi 2007 的多个 IDE不同版本对包命名和资源文件格式要求不一样。自动安装脚本通常假定你的安装路径是默认的C:\Delphi一旦你换了盘符或者把源码放在带中文的目录下包能编译出 DCU但 IDE 注册组件时往往找不到资源。我见过有人卡在“编译通过但没有控件”上大半天最后发现是源码路径里有中文IDE 在读取.res文件时用了 ANSI 路径解析直接崩了。这里给你一个检查清单第一解压路径不要有中文和空格第二确认 Delphi 的 Library 路径已经指向source目录第三在packages目录里找到类似TntUnicode_D7.dpk的文件这个才是 Delphi 7 对应的项目。如果你用的是 Delphi 6找TntUnicode_D6.dpk。不要拿 D7 包硬装到 D6 里编译器会因为找不到Windows.pas里的某个新 API 报错。3.2 用 IDE 编译安装 DCP 包的两种路线路线一是在 IDE 里操作先打开 D7 的包文件在项目管理器里找到Runtime Packages下的那个包右键选择Compile编译通过后再右键Install。这个方式能直观地看到 IDE 提示“已安装”并且组件面板会多出一个 Tnt 页。路线二是用命令行编译适合需要把编译过程写进批处理、方便同事的团队。我常用这样一段命令dcc32 -B -Q -DDELPHI7 -IE:\TntUnicodeControls\source -UE:\TntUnicodeControls\source -EE:\TntUnicodeControls\dcu TntUnicode_D7.dpk这段命令里-B表示重新构建-Q是安静模式-DDELPHI7是条件编译用的符号-I和-U都指向 source 目录-E指定 DCU 输出目录。编译成功后再执行一次 IDE 内的Install或者用regsvr32其实 Delphi 的包不是 COM 组件不需要 regsvr32。命令行编译只生成.dcu和.bpl真正把组件注册进 IDE 还是得在 IDE 里 Install 那个.bpl。所以我一般只把命令行当作“编译检查”最终安装还是靠 IDE 菜单。如果你发现 IDE 提示“无法找到 TntControl.dcu”先别怀疑控件包坏了去检查Tool Options Library里的路径有没有把source加进去。加了还报错就检查是不是有多个版本的 DCU 残留在 IDE 的Lib默认目录把旧的删干净再编译一次。这个坑在 2.1.11 上尤其明显因为网上流传的很多精简版压缩包里混了不同版本的 DCU。3.3 建一个最小工程验证 TntEdit 的 Unicode 输入装好以后我建议不要直接改造大项目先建一个只有 Form 和两个控件的工程验证环境是否健康。放一个TntEdit和一个TntButton然后在按钮的OnClick里把一个俄文常量赋给Edit1.Text再弹出来。下面是完整步骤procedure TForm1.TntButton1Click(Sender: TObject); var S: WideString; begin S : Привет, мир; { 俄文“你好世界” } TntEdit1.Text : S; ShowMessage(TntEdit1.Text); end;注意这里ShowMessage在 Delphi 7 里接收的是string所以TntEdit1.Text这个WideString会隐式转回AnsiString。如果俄文字符在系统代码页里没有对应关系弹窗里照样显示问号。这不代表 TntEdit 有问题而是ShowMessage本身是 ANSI 的。正确的验证方式是再放一个TntMemo把文字赋值给它同时用GetWindowTextW检查窗口文本function GetTntTextW(Handle: HWND): WideString; var Len: Integer; begin Len : GetWindowTextLengthW(Handle); SetLength(Result, Len); GetWindowTextW(Handle, PWideChar(Result), Len 1); end;这段代码通过GetWindowTextLengthW拿到系统缓冲区里的字符数再用GetWindowTextW取出来放到WideString里。如果这个函数返回的字符串和刚才输入的俄文完全一致说明 Tnt 控件内部确实走的是 Unicode 通道。参数说明Handle是目标窗口句柄也就是 TntEdit1.Handle返回值是宽字符字符串。你用这个函数去检查 TntEdit、TntMemo、TntComboBox 的文本都能拿到真实内容。这也是后面排查“控件明明显示正常但数据库读出来乱码”时的标准工具。4. 把现有代码换成 Tnt 控件常用替换清单与 5 个必调参数4.1 控件映射表从 TEdit 到 TntEdit从 TCheckBox 到 TntCheckBoxTnt 控件覆盖了 VCL 常用控件的大部分但并不是全部。我整理过一张自己的替换表按风险高低排序。最安全的是和文本直接相关的TEdit - TntEdit、TMemo - TntMemo、TListBox - TntListBox、TComboBox - TntComboBox、TLabel - TntLabel、TCheckBox - TntCheckBox、TRadioButton - TntRadioButton、TButton - TntButton。这些控件的Caption或Text直接变成WideString替换后处理中文、日文、韩文都没问题。中等风险的是带项列表的TTreeView - TntTreeView、TListView - TntListView、TToolBar - TntToolBar、TStatusBar - TntStatusBar它们不光文本要改节点数据和OwnerDraw回调里也可能涉及字符串长度。比较隐蔽的是那些不带文本但通过 Windows API 拿文本的控件比如TDateTimePicker和TMonthCalendar。Tnt 控件库其实也有对应的TntDateTimePicker但很多人会忽略因为它们的Text属性并不是直接暴露的。你如果继续用标准TDateTimePicker在中文系统上它能正常显示日期但如果你要自定义格式为“yyyy年MM月dd日 dddd”然后配合FormatSettings里的 Unicode 符号就可能出现错位。我的建议是先替换 Form、Panel、DataModule 里直接和用户输入相关的控件跑通一轮回归再处理网格和树。项目里如果用了DBGrid先别急着替换——Tnt 控件库里没有TntDBGrid常见的做法是继续用标准 DBGrid但要靠TntDataSet不对Tnt 库里没有数据集控件所以要解决数据库里读出来的WideString显示问题要么把 DBGrid 的列字段类型设为ftWideString要么自己写一个 自定义呈现器 。这段路走得通但和 Tnt 本身无关别把时间浪费在找“TntDBGrid”上。4.2 替换后必须检查的 5 个参数Caption、Font.Charset、ImeMode、MaxLength、CharCase这 5 个参数是我每次做替换时逐个过一遍的。第一个是Caption和Text的类型你可以用鼠标点中控件在对象检查器里看属性类型是否标成TntCaption或WideString确认真正的替换生效。第二个是Font.Charset默认是DEFAULT_CHARSET但如果你原来手工给控件设置过GB2312_CHARSET替换成 Tnt 后反而要把它改回DEFAULT_CHARSET。原因是 Tnt 控件内部用WideString绘制字体选择交给 Windows 字体链接机制强制指定 ANSI 字符集会让系统错误地选回宋体以外的低版本字体。第三个是ImeMode这个属性在标准 VCL 里存在但经常不生效Tnt 控件通过ImmSetContext实现了真的输入法切换。如果你的输入框要输入中文把ImeMode设为imChinese要输入英文设为imEnglish。不设的话输入法可能一直停在全角状态。第四个是MaxLength这个参数在 AnsiString 时代是按字节数限制的在 Tnt 控件里却是按字符数限制。假设你原来设MaxLength : 10用户输入 5 个汉字加 5 个英文字符在旧代码里算 15 个字节会被拦掉在 Tnt 控件里算 10 个字符正好放行。这算是一个行为改善但如果你依赖这个参数强行限制数据库字段长度就要小心数据库字段如果是VARCHAR(20)而你的每个汉字按 UTF-8 存 3 字节界面上放行的 10 个字符可能让数据库报超长。第五个是CharCase标准 TEdit 的CharCase会把输入内容直接按大小写转换但 Tnt 版对这个参数的处理粒度不同——它在WM_CHAR阶段处理对非拉丁字符不会误伤但对某些欧洲字符比如ß和ı转换结果取决于 Windows 版本。我的建议是把有明确要求的输入框手动处理OnChange而不是依赖CharCase毕竟它的转换规则在 Unicode 里并不完整。4.3 替换遗留的 AnsiString 赋值WideString 转换的坑代码里最常见的问题是var S: string; S : TntEdit1.Text;。这个赋值会触发隐式转换把 TntEdit1.Text 的 WideString 按当前线程代码页转换成 AnsiString。如果字符串里只有 ASCII 和中文在中文系统上没问题一旦有俄文、阿拉伯文或扩展拉丁字符转换结果就是 ? 或空白。你必须在整个调用链上把变量类型改成WideString或TntString。下面是需要改的类型对照var OldCaption: string; { 旧代码 } NewCaption: WideString; { 替换后 } begin OldCaption : TntButton1.Caption; { 可能静默丢失字符 } NewCaption : TntButton1.Caption; { 完整保留 } end;string和WideString在赋值操作上编译器不会警告所以这是隐藏得最深的坑。我用一个土办法避免在每个单元顶部给string起个别名AnsiString然后让编译器类型检查在不确定的地方报错其实更可靠的是用WideString显式声明所有界面相关变量。另外如果你调用了 Windows API比如SendMessage(Handle, WM_GETTEXT, ...)这里的缓冲区要按WideChar申请并且用SendMessageW。Tnt 控件虽然封装了绝大多数场景但如果你直接操作Handle就会绕开封装必须自己注意。5. 必踩的坑Tnt 控件在中文系统下的乱码、资源泄漏与安装顺序5.1 安装后 IDE 报错或控件面板不显示现象、原因、解决现象按照 3.2 的步骤编译通过也点了 Install但组件面板上找不到 “Tnt” 页或者在打开窗体时 IDE 弹“Class TntButton not found”。原因基本是两个一是 IDE 的包格式和源码里requires的运行时包不一致二是存在另一个同名包在更早的搜索路径里被加载导致 IDE 组件注册表冲突。解决方法是先清掉旧包在 IDE 的Component Install Packages里把Tnt Unicode Controls前一项“Remove”然后关闭 IDE删除$(DELPHI)\Lib下面所有Tnt*.dcu、Tnt*.bpl、Tnt*.res文件重启 IDE 再重新编译安装。我碰到过最奇葩的一次是TntExtCtrls的.bpl版本号和控件源码头部的TNT_UNICODE_VERSION不匹配IDE 加载了高版本的 BPL 又遇到低版本 DCU结果面板上有一半控件是灰的。清理重装能解决 90% 的安装问题。5.2 TntEdit 能输入但显示方框字体 Charset 没设对现象TntEdit 能接受中文输入字也存进去了但显示成一个个方框。原因不是输入链路而是字体渲染链路的字符集选择。Windows 的 EditBox 内部会根据font.charset选择字形如果 Charset 是DEFAULT_CHARSET且字体名是“宋体”实际上能显示中文。但如果你继承了一个字体设置比如从 Form 上传下来的MS Sans Serif这个字体本身不含中文字形系统会降级到 System 字体结果就是方框。解决方法是给每个 TntEdit 单独指定Font.Name : 宋体或者更好的无衬线字体Microsoft YaHei并且确保Font.Charset : DEFAULT_CHARSET。注意在 Delphi 7 里“宋体”这个名字是 ANSI 字面量但它在所有中文 Windows 上都能被正确转换如果你写微软雅黑在非中文系统上可能找不到。我一般写成Font.Name : Microsoft YaHei因为这是英文字体名各语言系统都认。5.3 和第三方皮肤控件一起用按钮字全变黑块现象项目里用了某种皮肤控件把 TButton 替换为 TntButton 后皮肤控件无法识别 TntButton按钮上的文字变成黑块或消失。原因皮肤控件内部通过遍历控件类名来判断要渲染哪一种控件只认TButton不认TntButton。解决要么在皮肤控件的映射表里手动增加 TntButton 的分类要么给 TntButton 写成派生类让它在运行时伪装类名实际操作中更直接的办法是不替换按钮类只替换 TEdit/TMemo/Label 这类文本显示控件。按钮上的文字大多是短文本多半是中文在 GBK 下也能正常显示真正需要 Tnt 的是输入框和复杂字符区。如果你非得所有控件都换那就顺着皮肤控件的扩展接口把 TntButton 的绘制函数注册进去。这个方向比较折腾我做过一次以后再遇到皮肤项目我就明确建议“只换文本输入类控件”。5.4 切换输入法时程序卡顿处理 WM_IME_NOTIFY 的正确姿势现象在 TntEdit 里切换输入法程序偶尔卡死一两秒甚至崩溃。原因Tnt 控件为了支持输入法上下文会处理WM_IME_NOTIFY和WM_IME_SETCONTEXT但如果你在这些消息里访问了 VCL 控件属性而输入法进程是从系统消息循环里来的可能触发重入。解决在 Tnt 控件的OnImeNotify事件如果有或者重写的WndProc里不要做任何界面刷新操作只做状态保存。我一般在工程里加一个标志位等消息队列空闲再处理。下面这段示意代码放在 TntEdit 的派生类里procedure TMyTntEdit.WndProc(var Message: TMessage); begin if Message.Msg WM_IME_NOTIFY then begin FLastImeNotify : Message.WParam; // 只是存值不刷新界面 Exit; // 跳过默认处理避免 VCL 内部触发重入 end; inherited WndProc(Message); end;这段代码最关键的是Exit它阻止了默认分支中对某些输入法上下文函数的调用从而避免卡顿。代价是你可能会丢掉一些输入法提示的默认行为比如候选窗口的显示位置。不过 2.1.11 的控件库自带一套输入法上下文管理你直接继承 TntEdit 而不重写 WndProc通常也不会卡。只有在集成第三方输入法比如某些老式中文输入法时这种重入问题才会冒出来。我自己的经验是如果项目只在公司内部用可以这么干如果是通用软件还是得保证输入法提示完整那就不要 Exit而是把调用是非重入函数。6. 进阶用 Tnt 控件做输入法自绘和跨版本迁移的边界6.1 自绘 TntButton 的 OnPaint 里如何正确画文字如果你要在 Tnt 控件上做自绘就别再用Canvas.TextOut配合string了那样画出来的还是 ANSI 转码后的文本。正确做法是用DrawTextW直接传PWideChar。下面这段代码可以在 TntButton 的派生类里画出自定义外观procedure TMyTntButton.PaintText(ACanvas: TCanvas); var R: TRect; T: WideString; begin R : ClientRect; T : Caption; // Caption 已经是 TntCaption InflateRect(R, -4, -4); DrawTextW(ACanvas.Handle, PWideChar(T), Length(T), R, DT_CENTER or DT_VCENTER or DT_SINGLELINE or DT_END_ELLIPSIS); end;注意这里DrawTextW的Length(T)是字符数传入-1也可以但显式传入字符数可以避免在字符串中间出现嵌入#0时截断。比较坑的是Canvas.Font的句柄要和 Tnt 控件的字体同步否则画出来的字体比显示的字体小一圈。你可以先ACanvas.Font : Self.Font再画确保一致。6.2 从 Tnt 控件迁移到 Delphi 2009 原生 Unicode 的验证方法如果你的团队终于决定升级到 Delphi 2009 及以上版本Tnt 控件就可以退休了因为原生 VCL 已经全面支持 Unicode。迁移时最值得做的事情不是简单地把TntEdit改成TEdit而是验证所有WideString和UnicodeString混用点。我会写一段小脚本遍历整个工程的所有窗体读取每个控件的Text、Caption、Items用IsTextUnicode检查结果里是否包含无效字符。更省事的方法是编译一个 Debug 版程序然后把所有输入控件“全选、复制、粘贴”到记事本看有没有问号。操作很简单在运行界面上按 CtrlA 然后 CtrlC粘贴出来的字符串如果完整基本说明 Tnt 控件到原生的迁移没漏。迁移后记得删掉Tnt*单元引用不然编译器会把旧 DCU 也带进来导致一次编译两种 CRT甚至内存越界。我自己当年迁移一个 20 万行代码的项目最后漏了一个TntSystem.pas的引用结果在关闭窗体时偶发访问冲突查了半天才发现是这个引用让 RTL 里有两套Move函数。经验就是全局搜索Tnt把所有uses里的Tnt*清干净再重新编译两轮。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
