Windows ANSI版WM_CHAR为何未输出UTF-8序列？实验存疑

文档描述与实验现象 #

• 根据2023年1月MSDN文档，Windows 1903及以上版本中，使用ANSI版RegisterClass时，将进程代码页设为UTF-8，可让WM_CHAR消息返回UTF-8字符序列。
• 但在Win10 21H2环境下，基于Charles Petzold《Programming Windows 5th-ed》的Keyview2A.exe v1.8实验出现不符预期的结果：
  • 非UTF-8ACP模式：输入中文“电”（U+7535，GBK编码B5 E7），能正常收到代码页936的ANSI序列；
  • UTF-8ACP模式：仅收到0x3F（问号）；
  • 测试俄文、希腊文等SBCS字符后，总结出实际执行逻辑：IME生成Unicode值，Windows检查目标HWND的HKL，通过GetLocaleInfo获取关联ANSI代码页，调用WideCharToMultiByte转换为MBCS序列；单字节字符发送一个WM_CHAR，双字节字符则发送两个wParam为0x3F的WM_CHAR。

问题本质解析 #

这种情况既非操作错误，也不是文档误导，而是UTF-8ACP模式的生效存在易被忽略的限制：

1. 代码页与HKL的绑定逻辑：Windows没有为UTF-8单独分配输入区域设置（HKL），即使进程代码页设为UTF-8，系统仍会根据窗口HKL关联的系统语言ANSI代码页执行转换。当转换多字节UTF-8字符时，原ANSI代码页无法识别，直接返回0x3F。
2. ANSI消息机制的局限性：ANSI版WM_CHAR的wParam是单字节值，无法承载UTF-8的变长字节序列。系统在处理多字节UTF-8字符时，无法正确拆分并传递完整字节流，最终只能返回替代字符0x3F。
3. 文档描述的适用范围：MSDN文档中“WM_CHAR提供UTF-8字符序列”的描述，仅适用于ASCII范围内的单字节字符，多字节UTF-8字符无法通过ANSI窗口的WM_CHAR机制正确传递——这是ANSI窗口体系基于固定长度代码页设计的固有缺陷。

可行解决方案 #

• 优先改用Unicode版窗口过程（RegisterClassW），直接处理Unicode字符后自行转换为UTF-8，从根源上规避ANSI代码页的限制；
• 若需保留ANSI窗口，可监听WM_IME_CHAR消息直接获取Unicode字符，再手动调用WideCharToMultiByte(CP_UTF8,...)转换为UTF-8序列，绕过系统的代码页转换逻辑。

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