VCL TDBEdit的Font->Charset属性在10.3中未达预期（原C++ Builder 6可用）

核心背景差异 #

• C++ Builder 6属于ANSI架构的VCL版本，所有组件字符串默认使用AnsiString类型，文本渲染时GDI需要依赖Font->Charset属性匹配对应的代码页，对AnsiString的字节流做解码后再显示。你之前切换Charset为238（EASTEUROPE_CHARSET）就能实现字符转换，本质是让GDI用1250代码页，而不是默认的1252代码页解释同一个字节值：0x8C在1252代码页对应Œ，在1250代码页对应Ś，所以就出现了你观察到的转换效果。
• C++ Builder 10.3属于Unicode架构的VCL版本，从RAD Studio 2009开始VCL全栈迁移到Unicode，所有组件字符串默认使用UTF-16编码的UnicodeString类型，文本渲染时GDI拿到的已经是标准Unicode码点，不需要再通过Font->Charset做代码页解码，所以修改该属性不会对显示效果产生影响，不属于TDBEdit的Bug。

该属性保留的原因 #

仅为向下兼容：如果直接移除该属性，大量基于旧版VCL开发的项目迁移时会直接出现编译错误，同时极少数对接旧式非Unicode GDI接口的场景仍可能用到该属性，所以VCL框架没有删除该属性，只是默认的组件文本渲染逻辑不再依赖它。

字节值差异原因 #

C++ Builder 6中的char为有符号类型，0x8C作为有符号char的取值为-116，当你把它打印为32位有符号整数时会触发符号扩展，所以显示为0xFFFFFF8C；10.3中你观察到的是未做符号扩展的原始字节取值，底层单字节值本质都是0x8C，不存在编码差异。

10.3版本的正确实现方式 #

不要依赖修改Font->Charset实现代码页转换，直接使用VCL提供的编码转换类处理即可，示例代码如下：

// 示例：将1252编码的字节流转为1250编码对应的显示文本
TEncoding* enc1252 = TEncoding::GetEncoding(1252);
TEncoding* enc1250 = TEncoding::GetEncoding(1250);

// 假设sourceBuf是存储1252编码数据的字节数组
UnicodeString temp = enc1252->GetString(sourceBuf);
TBytes buf1250 = enc1252->GetBytes(temp);
UnicodeString result = enc1250->GetString(buf1250);

DBEdit1->Text = result;

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