https://diankao.github.io/tags/%E7%BC%96%E7%A0%81/Recent content in 编码 on 我的博客Hugozh-cnMon, 17 Aug 2026 17:48:32 +0800https://diankao.github.io/posts/qtcreator-fake-console-encoding-trap/Mon, 17 Aug 2026 17:48:32 +0800https://diankao.github.io/posts/qtcreator-fake-console-encoding-trap/<p>前段时间写 loghandler，需求说出来特别简单：console 里看的、调试输出里看的、实际落盘的内容，编码得一致。就这么点要求，被中文乱码折腾了好久。各种组合来回试过，才定位到元凶不是代码，而是观察工具本身：<strong>Qt Creator 底部那个长得像控制台的窗格，其实不是控制台，是 IDE 重定向、转述过的 output</strong>。</p> <p>先把结论放在最前面：</p> <ul> <li>那个窗格的大名是&quot;应用程序输出&quot;（Application Output）。Qt Creator 运行程序时不给它开控制台，而是用管道接住进程的 stdout/stderr，读出字节后<strong>由 IDE 自己解码</strong>再显示。它是转述者，不是终端。</li> <li>所以 <code>SetConsoleOutputCP()</code> 对它<strong>完全无效</strong>——那是设置真控制台渲染解码的 API，而这条链路上压根没有&quot;控制台渲染&quot;这一环。</li> <li>printf 的字节流会被窗格按系统本地代码页（中文 Windows 即 GBK）固定解码。源文件是 UTF-8 的话，printf 直出中文在这个窗格里<strong>必乱</strong>，怎么设置都救不回来。</li> <li>更迷惑的是 qDebug 走的是另一条 Unicode 通道，在窗格里<strong>永远正常</strong>。&ldquo;qDebug 好的、printf 坏的&quot;这个组合，会把你引向一连串错误归因。</li> </ul> <p>以下实测基于 Qt 5 + Qt Creator（起码大版本 5 是这样）。只要 Creator 还是&quot;管道重定向 + 自己解码&quot;这个架构，这个坑就大概率还在；不同版本的解码细节可能变化，所以文末的验证方法比这里的结论更重要。</p> <h2 id="症状qdebug-正常printf-乱码">症状：qDebug 正常，printf 乱码</h2> <p>程序里两种输出混用——qDebug 做调试，printf/fprintf 是老代码或第三方库。在 Qt Creator 里一跑：qDebug 的中文正常，printf 的中文全是 <code>涓枃娴嬭瘯</code>。</p> <p>这类乱码不用背规律，看长相查表就能反推出&quot;输的什么码、解的什么码&rdquo;。GitHub 上这份 <a href="https://github.com/justjavac/unicode-encoding-error-table">unicode-encoding-error-table</a> 按外观特征收录了常见错法，<code>涓枃娴嬭瘯</code> 这种&quot;古文码&quot;就是 UTF-8 字节被按 GBK 解读——3 字节的汉字被拆成 2+1 错配，长度都对不上，看起来自然乱得不像话。反过来说，看到它就知道：输出端发的是 UTF-8，解码端在用 GBK。</p>