Windows控制台输出是否使用区域代码页而非GetConsoleOutputCP返回的编码

结论 #

Windows控制台本身的输出逻辑确实采用GetConsoleOutputCP()返回的代码页，你遇到的字符显示异常问题，根源是C标准库的I/O函数的转码逻辑和控制台代码页不匹配，和控制台本身的配置无关。

核心原因 #

Windows平台上存在两套独立的字符编码配置体系：

• 第一套是控制台窗口的系统级配置：由GetConsoleCP/SetConsoleCP控制输入代码页，GetConsoleOutputCP/SetConsoleOutputCP控制输出代码页。这套配置仅在调用Windows原生控制台API（如WriteConsoleA）时直接生效，不会主动和C运行时配置同步。
• 第二套是C运行时（CRT）的区域编码配置：由setlocale函数设置，所有C标准库提供的I/O函数（printf/putchar/fwrite等）都会遵循这套配置。默认情况下printf会把你传入的字节当做setlocale指定编码的字符处理，先转成Unicode，再转成控制台输出代码页对应的字节传给控制台显示。

你调用setlocale(LC_ALL, "")时，CRT的区域编码被设置为系统默认的ANSI代码页1251，你传入的175、224是866编码下的西里尔字符，被CRT误判为1251编码的字符转码后输出，自然就显示为错误的字符。

解决方法 #

你可以根据需求选择任意一种方案修复显示问题：

• 直接调用Windows原生控制台输出APIWriteConsoleA输出你拿到的866编码字节，跳过CRT的转码逻辑，就会按照GetConsoleOutputCP返回的866代码页正常显示。
• 显式设置CRT的区域编码和控制台输出代码页一致，调用setlocale(LC_ALL, ".866")即可，CRT会正确识别你传入的866编码字符，输出正常。
• 全程使用宽字符版本的标准I/O函数（wprintf/getwchar等），宽字符会直接用Unicode传递给控制台，不需要考虑多字节代码页匹配问题。

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