有一个 2000 年的应用程序。ANSI。来源不可用。有一个 DLL 可以 Hook 它的 API。但即使 DLL 创建了它自己的 Unicode 窗口或对话框。标题将始终是文字问号(如果代码点位于 ANSI 代码页之外。)
原因是 EXE 镜像的某些内容导致了此行为。虽然我不是 100% 确定我是否曾经尝试实例化一个带有 Unicode 标题标题的窗口是公平的。虽然我知道这是可以做到的。
这适用于所有窗口。可以肯定的是，一个窗口类注册了 W 系列函数，并且窗口创建了 W 系列和那个类。我自己在显式使用 A 和 W 函数时从未遇到过问题。我觉得这是更好的风格。特别是与在预处理器宏中包装字符串文字相比。因此，无论我在哪里，我都不会设置 Visual Studio 字符集。
当通过 DLGTEMPLATEEX(或 DIALOGEX)结构创建精心制作的对话框时，对话框是 Unicode，但只有标题不是。任何设置或获取文本的尝试(包括 InternalGetWindowText)都会失败。它必须与运行时版本或“ list ”或类似的东西有关(如果是这样，我们可以解决这个问题。)
不涉及中间代码。事实上，我习惯于挂接 Windows API。无论发生什么，它都是内在的。这真的很令人沮丧，因为自定义绘制字幕是一项不可能完成的任务，而且工具窗口太多以至于无法添加字幕。我们希望为用户呈现真实世界的文本，而不是文本垃圾，即使 ANSI 代码页不匹配也是如此。
已编辑:新信息。同一套程序中的另一个应用程序不会表现出这种行为。一个使用 Windows，不受影响的是全屏视频游戏。因此，这似乎排除了(这些程序的)开发环境成为一个因素的可能性。因此，它一定是由程序本身以某种方式发起的行为。
我认识到的一件事是 IsWindowUnicode 似乎对这些程序来说并不是不可变的。一个window怎么可能是Unicode，后来就不是了。但这也可能是上下文相关的。虽然有时感觉更像是永久性的，但通常窗口会失去其 Unicode 状态。这只是我必须继续下去的唯一线索。也许有某种特殊的东亚 IME 系统在起作用。我观察到一个简单的 Edit 控件可以从 Unicode 开始，然后就不是了。 Spy++ 仍然报告带有标题栏的主 Windows 是 Unicode。
在 Remy 的回答的评论中还有更多信息。遗憾的是，他的回答似乎是死路一条。虽然是一项崇高的努力。
包括 ( http://forums.codeguru.com/showthread.php?419079-window-title-unicode-problem ) 对出现在更典型的开发项目中的相同问题的讨论。
最佳答案
您的 DLL 可能正在创建 Unicode 窗口，但如果它没有运行自己的消息循环来为这些窗口提供服务，那么它们将由应用程序现有的消息循环提供服务，这些消息循环仍在使用 Ansi API (GetMessageA( )、DispatchMessageA() 等)，因此 Unicode 数据将被转换为 Ansi，这将丢失无法转换为 Ansi 的 Unicode 字符。这与 EXE 镜像、 list 、预处理器等无关。
关于windows - 为什么 Unicode Windows 标题栏(仅)是问号(？)代码点？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19737412/