Delphi 扩展ASCII字符显示为？（问号）

我有一个带有一堆标志（静态图像）的表单，每个标志下面都有一个勾选框。用户选择勾选框以允许他们使用特定语言。在设计时，我已经为每种语言设置了相应的本地化复选框标题，在本例中为“西班牙文”（西班牙语）

对于几乎每种语言，它在运行时都会显示得很好，但对于一些语言，它会更改为“Espa？ol”。具体来说，当我选择立陶宛语并使用：

// Note: 1063 = ((SUBLANG_DEFAULT shl 10) or LANG_LITHUANIAN)
SetThreadLocale(1063);

奇怪的是，如果我只是在表单的OnShow处理程序中用下面的行重新应用标题，那么它就会正确地显示为“Español”

通过检查运行时标题中是否包含“？”字符，然后重新应用标题，可以稍微改进上述代码。应用程序的其余部分完美地显示立陶宛语（在运行时设置标签）

请注意，“ñ”是扩展的ASCII码241。这个问题影响了其他几个扩展字符，例如“弗朗西斯”中的“231”（字符231）。有趣的是一些扩展ASCII字符显示正确，例如“¾”（字符190）

这是IDE中的一个bug（使用Delphi7）还是传统ASCII（即非UNICODE）字符的一个事实？是否有更好的方法在运行时检测不兼容的设计时扩展ASCII字符（可能基于区域设置）

---

我执行的所有搜索都没有解释为什么字符会显示为“？”。我假设这是因为当前Windows代码页中必须缺少请求的字符，但我找不到任何引用明确说明发生这种情况时显示的内容（如果无法使用UNICODE，也没有说明如何克服此问题）.

字符是指由于目标代码页不包含所需字符而导致从一个代码页到另一个代码页的转换失败时发生的情况。这是针对ANSI Win32 API编程的必然结果。不能用所有语言表示所有字符

唯一现实的方法是使用Unicode。从Delphi 7开始，您有两个主要选项：

坚持使用Delphi7并使用TNT Unicode组件

升级到Delphi的现代版本，该版本本机支持Unicode

---

你说，注意“ñ”是扩展的ASCII码241。嗯，那不是真的。具体来说，您使用的是Windows ANSI代码页。“ñ”存在于某些代码页中，但并非所有代码页中，并且很可能在不同的代码页之间具有不同的数值。扩展ASCII在这里不是一个有用的术语。没错，我的术语有点马虎。我指的是当前代码页中128-255的ASCII字符。我知道代码241（0xF1）依赖于代码页，只是想知道如何在运行时最好地检测失败字符…为什么您准备在这里接受失败？把这件事做好并不难。为什么要使用基于ANSI代码页的无望的残废方法？这是一个非常可怕的方法。你是指在UNICODE可用时使用ANSI代码页吗？如果是这样，我同意你的看法。我们将很快升级，目前使用某种短期修复方法。所有基于NT的平台都支持Unicode。除非您以Windows98为目标，否则没有理由不使用Unicode。现在是2016年，你早该忘记ANSI代码页了。好的，谢谢David。从Delphi XE升级是有可能的，但除了UNICODE问题之外，Delphi 7简直太棒了，很难放弃！TNT组件看起来很有趣，以前从未听说过。我假设从Delphi 2009起不再需要这些组件，并且（在Delphi 7中）您可以根据需要选择使用std VCL组件或TNT等效组件？现在，您已经安装了TNT Unicode组件并试用了TTntCheckBox，这相当于非Unicode VCL TCheckBox控件。很好，谢谢大卫。

tbLangSpanish.Caption := 'Español';  // Strange, it now corrects itself!