前段时间写 loghandler，需求说出来特别简单：console 里看的、调试输出里看的、实际落盘的内容，编码得一致。就这么点要求，被中文乱码折腾了好久。各种组合来回试过，才定位到元凶不是代码，而是观察工具本身：Qt Creator 底部那个长得像控制台的窗格，其实不是控制台，是 IDE 重定向、转述过的 output。

先把结论放在最前面：

  • 那个窗格的大名是"应用程序输出"（Application Output）。Qt Creator 运行程序时不给它开控制台，而是用管道接住进程的 stdout/stderr，读出字节后由 IDE 自己解码再显示。它是转述者，不是终端。
  • 所以 SetConsoleOutputCP() 对它完全无效——那是设置真控制台渲染解码的 API，而这条链路上压根没有"控制台渲染"这一环。
  • printf 的字节流会被窗格按系统本地代码页（中文 Windows 即 GBK）固定解码。源文件是 UTF-8 的话，printf 直出中文在这个窗格里必乱，怎么设置都救不回来。
  • 更迷惑的是 qDebug 走的是另一条 Unicode 通道，在窗格里永远正常。“qDebug 好的、printf 坏的"这个组合，会把你引向一连串错误归因。

以下实测基于 Qt 5 + Qt Creator（起码大版本 5 是这样）。只要 Creator 还是"管道重定向 + 自己解码"这个架构，这个坑就大概率还在；不同版本的解码细节可能变化，所以文末的验证方法比这里的结论更重要。

症状：qDebug 正常，printf 乱码

程序里两种输出混用——qDebug 做调试，printf/fprintf 是老代码或第三方库。在 Qt Creator 里一跑：qDebug 的中文正常，printf 的中文全是 涓枃娴嬭瘯。

这类乱码不用背规律，看长相查表就能反推出"输的什么码、解的什么码”。GitHub 上这份 unicode-encoding-error-table 按外观特征收录了常见错法，涓枃娴嬭瘯 这种"古文码"就是 UTF-8 字节被按 GBK 解读——3 字节的汉字被拆成 2+1 错配，长度都对不上，看起来自然乱得不像话。反过来说，看到它就知道：输出端发的是 UTF-8，解码端在用 GBK。

常规手段全部无效

接下来是标准流程：SetConsoleOutputCP(65001)、换 locale codec、四种组合来回试，printf 纹丝不动地乱着。这时候难免开始怀疑：是不是源码编码不对？要不要给编译器加 /utf-8？是不是 MinGW 的锅？

为什么全都无效？因为你改的每一项都作用于"程序 → 真控制台"这条链路，而你盯着看的屏幕根本不在这条链路上。

真相：那是重定向的输出，不是控制台

Qt Creator 启动子进程时不分配控制台窗口，而是创建一对管道接到进程的 stdout/stderr 上，读出字节流后自己决定用什么编码解码、显示在那个窗格里。这层"转述"带来三个直接后果：

  1. SetConsoleOutputCP() 改的是控制台的解码行为，窗格链路不经过控制台，自然无效。
  2. 窗格解码 printf 字节流用的编码是 IDE 自己定的（我这版固定用系统本地代码页，即 GBK）。于是 UTF-8 直出必乱、手动转成 GBK 反而正常——“我明明设了 65001 还乱，转码成 GBK 倒好了”，这种反直觉现象就是这么来的。
  3. qDebug 压根不走这条管道，详见后文机制。

背景：Windows 把字弄上屏幕，路不止一条

要看懂机制，得先知道 Windows 的输出 API 是个多轨制。这也是这次踩坑顺带捋清的一笔账：

函数通道编码语义
WriteConsoleW直写控制台缓冲区UTF-16 宽字符，零转换
printfCRT → WriteFile / WriteConsoleA字节流，代码页语义
wprintfCRT 先按 locale 把宽字符转成多字节，再走 printf 那条路进口是 UTF-16，出口还是字节
OutputDebugString触发调试事件，被调试器捕获显示根本不属于控制台体系

两套 API（A/W 双轨）是历史包袱：内核是 Unicode 的，为了兼容 DOS 时代以来的 ANSI 程序保留双轨；CRT 为了跨平台又在上面加了一层 locale 转换。于是一个简单的 print，在编码上能绕一大圈。

表里最后一个 OutputDebugString 是关键角色：它是写给调试器的消息。而 Qt Creator 恰好是以调试器身份在运行你的程序——这就是 qDebug 在窗格里永远正常的秘密。

只留一组实验数据

为了搞清楚，我把 ConsoleOutputCP × locale codec 的四种组合、qDebug / printf / 手动转码几种输出姿势，在两种终端里各跑了一遍矩阵。完整数据不贴了——那是给当时的我看的，不是给读者的。两边各自一句话规律：真 cmd 里，输出字节的编码跟 ConsoleOutputCP 一致才正常（qDebug 的字节编码由 locale codec 决定，所以它也得跟上，唯一全对的组合是双 UTF-8）；窗格里，跟任何设置都无关，printf 只有 GBK 字节才正常，qDebug 永远正常。

全部数据里只留最有说服力的一组。同一个程序，同一次运行逻辑（CP65001 + locale=GBK）：

输出内容Qt Creator 窗格真 cmd
printf 直出 UTF-8乱码正常
qDebug正常乱码

完全相反。拿窗格当证据，你会得出"65001 没用，qDebug 可靠、printf 不可靠"；拿真 cmd 当证据，结论恰好反过来。两边都没说谎，只是它们根本是两个不同的显示设备。

（顺带一提：窗格里 qDebug 和 printf 的输出顺序是乱的——一个走调试通道、一个走 stdout 管道，两边缓冲互不同步。所以那里连输出顺序都不能当真。）

机制：qDebug 为什么在两边表现不同

Qt 5 的默认消息处理器在 Windows 上有两条出口，它先判断 stderr 是不是真控制台。

真 cmd 里，stderr 就是控制台，走字节流路径，前后共两次编解码：

QString("中文测试")
  → QTextCodec::codecForLocale() 编码为字节流
    （locale=GBK 出 GBK 字节；locale=UTF-8 出 UTF-8 字节）
  → 写入 stderr
  → 控制台按 ConsoleOutputCP 解码显示

编码一次、解码一次，两次用的编码必须一致，否则乱码。

Qt Creator 里，stderr 是管道不是控制台，qDebug 改走宽字符路径，全程无编解码：

QString("中文测试")
  → 保持 UTF-16
  → OutputDebugStringW()（宽字符 API，不出字节流）
  → Qt Creator 以调试器身份接住
  → 按 Unicode 直接渲染

没有字节环节，所以永远正确、不受任何编码设置影响。

printf 没有这种待遇：它在两边都是原始字节流，区别只在最后由谁解码——真 cmd 用 ConsoleOutputCP（可以设置），窗格用 Creator 自己的固定解码（我这版是 GBK）。同一份字节，两个解码器，两种命运。

避坑指南

  1. 排查编码问题的第一动作：换到真终端验证。 直接在 cmd / Windows Terminal 里运行 exe；或者勾上 Qt Creator 项目运行设置里的 “Run in terminal”，让程序在外部真终端里跑。窗格里的显示不能作为编码问题的证据。
  2. 真终端里的正确姿势（Qt 5 实测唯一全对的组合）：
SetConsoleOutputCP(65001);                                        // 终端按 UTF-8 解码
QTextCodec::setCodecForLocale(QTextCodec::codecForName("UTF-8")); // qDebug 编码成 UTF-8 字节

源文件保持 UTF-8 即可。Qt 6 已把 QTextCodec 挪进 Qt5Compat 且默认行为不同，不在此文讨论范围。 3. 在 Qt Creator 窗格里，两个方向都别信：qDebug 中文正常是 Unicode 通道的功劳，不代表你的编码配置对了；printf 中文乱码是窗格解码所致，不代表你的程序错了。 4. 别为 IDE 的显示问题改业务代码。为了迁就一个假终端把输出手动转成 GBK，会把真终端里的正确性换掉，本末倒置。真要看 printf 输出，去真终端看。 5. 学会识别假控制台：只要输出是"被别的程序接住再转述"的（IDE 输出窗、日志面板、CI 日志页），ConsoleOutputCP、控制台字体、终端属性统统不适用，解码规则由转述者自定。想程序化判断，看 GetConsoleMode 对该句柄是否成功。

写在最后

回到开头的 loghandler。最后它能写对，靠的不是把每种输出通道都调整一遍，而是先想明白了每个通道各自是谁、在哪一步做解码——想明白这一层，“console、debug、实际输出编码不一致"就从一个玄学问题变成了一张可以逐段核对的链路图。

这次实验本来是研究编码，结果最大的干扰项是测量工具——在 Qt Creator 里观察输出，观察工具本身就改变了输出的路径，堪称编码版的观察者效应。所以排查乱码时，第一个要回答的问题不是"我的编码哪里错了”，而是"我盯着的那块屏幕，是谁画的"。想清楚这一点，一半的坑还没踩就已经绕过去了。