CLion 跑个printf(你好)控制台直接吐出一堆火星文这事估计每个从 Visual Studio 或者老工程迁过来的同学都撞见过。更气人的是网上搜出来的改法五花八门今天改个编码明天又乱了尤其 Windows 平台CLion 内置终端、MinGW 工具链、系统代码页三者只要有一个不对付中文输出就能给你表演各种花式乱码。我前前后后踩过不少坑也把源码编码、编译器参数、控制台代码页这条链路彻底捋了一遍这篇就按“先懂原理、再给方案、最后给可复现的配置”的顺序把我实测有用的方法完整写出来。适合被 CLion 中文乱码折磨的 C/C 初学者也适合团队里被 Windows 老工程编码问题困住的同学。1. 乱码从哪来先搞明白编码链条很多教程直接甩一句“改成 UTF-8 就好了”但真正上手改完还是乱因为乱码从来不是单一环节的问题。搞清楚下面这条链你就知道该动哪里。1.1 源码编码、编译器编码、控制台代码页的三角关系一段中文从你敲进编辑器到显示在屏幕要经过三个环节第一环是源码文件在磁盘上的字节序列。CLion 默认情况下新建文件保存为 UTF-8无 BOM但如果你用旧版 Windows 记事本编辑过或者从老项目里拷来的源文件很可能是 GBK/ANSI 保存的。文件本身是什么编码决定了里面中文对应的字节是什么。第二环是编译器怎么解释这些字节。MSVC 编译器在 Windows 中文系统上默认按活动代码页 ACP通常是 936也就是 GBK来解析源码里的字符串字面量。GCC/Clang 在 Windows 下也有一套默认规则。如果源码是 UTF-8 字节编译器却按 GBK 去读字符串在编译产物里就已经是错误的字节序列了。第三环是运行时的控制台怎么显示。你用printf输出的字节最后会交给终端终端再按自己的代码页通常同样是 936去解码。终端图标下的 CMD 默认代码页是 GBK而 CLion 集成终端、Windows Terminal 的代码页又是可以动态切换的。这三环只要有两环不一致结果就是乱码。举个生活化例子你用中文短信发送端把“你好”编码成 GBK 字节对方手机却按 UTF-8 解码出来的就是乱码如果编码、传输、解码三者统一哪怕中间是奇怪的编码结果也是对的。所以解决问题的思路很简单让源码编码、编译器执行字符集、控制台代码页三者统一优先统一成 UTF-8。1.2 看一眼乱码形态就能预判是哪一环出错乱码其实分好几种先别急着改配置观察一下输出是什么样能帮你少走弯路。输出一串问号????????说明字符在编译阶段或运行阶段已经被替换成了无法识别的占位符。常见于编译器按 ASCII 丢弃高位字节或源码字符集和执行字符集配置冲突。输出空心方块、实心方块口口口内容其实已经传到终端了但终端当前字体或代码页里没有对应字形。这种情况和编译无关纯粹是显示层的问题。输出一堆“类中文”胡言乱语比如浣犲ソ这是典型的 UTF-8 字节被 GBK 解码或者反过来 GBK 字节被 UTF-8 解码。你可以理解为发送端和接收端使用了不同字典来翻译同一串二进制。有些字符正常、有些字符乱可能是文件里混用了多种编码比如注释是 UTF-8、字符串是 GBK也可能是个别特殊符号全角引号、破折号在转换时丢码。我把这些形态和原因记成了自查表后面第 5 节会给出完整速查。现在先记住输出的是问号就优先查编译选项和源码编码输出的是方块就优先查终端字体和代码页输出的是胡言乱语就查“编译产物编码”与“终端代码页”是否配对。2. 主方案让源码、编译器、控制台三方都统一成 UTF-8我最推荐的方案不是继续用 GBK而是把整条链路都迁到 UTF-8。Windows 10/11 现代版本对 UTF-8 的支持已经比 XP/7 时代好太多CLion 生态也默认 UTF-8长远看最省心。下面按“改代码、改工程、改系统”三个级别给出方案从最轻量到最彻底你可以按需选择。2.1 方案 A编辑器用 UTF-8编译器追加 UTF-8 参数控制台切 65001这是对现有工程改动最小、效果最直接的组合拳分三步。第一步确认 CLion 的编码设置。打开 Settings → Editor → File Encodings把 Global Encoding、Project Encoding、Properties Files 都设成 UTF-8。CLion 新建的源文件默认就是 UTF-8但旧文件不一定所以还要检查文件右下角的编码显示把 GBK 文件转成 UTF-8转换的具体操作和坑在 4.1 节单独讲。第二步给编译器追加 UTF-8 参数。我用 CMake 时会在 CMakeLists.txt 里按工具链分开写if(MSVC) add_compile_options($$COMPILE_LANGUAGE:C,CXX:/utf-8) else() add_compile_options(-finput-charsetUTF-8 -fexec-charsetUTF-8) endif()/utf-8是 MSVC 的参数告诉编译器源码按 UTF-8 读、执行字符集也用 UTF-8 写。GCC/Clang 用-finput-charsetUTF-8和-fexec-charsetUTF-8配对前者指定源文件编码后者指定写入可执行文件的字符串字面量编码。注意修改之后必须重载 CMake 工程CLion 顶部会提示 Reload CMake Project别忽略。第三步让控制台代码页切到 65001。两种做法一种是临时在运行前手动执行chcp 65001另一种是写死在代码里#ifdef _WIN32 #include windows.h #endif int main() { #ifdef _WIN32 SetConsoleOutputCP(CP_UTF8); SetConsoleCP(CP_UTF8); #endif printf(你好CLion 中文测试\n); return 0; }SetConsoleOutputCP(CP_UTF8)会把当前进程的输出代码页设置成 UTF-8在 CLion 的 Run 窗口和外部 CMD 里实测都有效。注意这种方式只影响你的程序不影响系统全局属于“按需切换”。如果你不想在代码里写 Windows 专用逻辑也可以在 CLion 的运行配置里加一个chcp 65001的 Before Launch 外部工具但代码内设置其实更省事也方便团队统一。这套组合拳的优势是只改项目不碰系统风险低、回滚容易。缺点是每次都依赖编译参数和运行时设置如果哪天代码里忘了写SetConsoleOutputCP或者换了别的编译器忘了加 CMake 参数乱码会卷土重来。2.2 方案 B不换 UTF-8让旧工程保持 GBK 代码页 936不是所有项目都适合立刻迁到 UTF-8。比如你在维护一个十年前的老项目源码里到处都是 GBK 编码的中文注释用第三方库也是 GBK 约定的接口这时候硬迁 UTF-8 可能引发大量编译警告和字符串错乱。这种场景下你可以让 CLion 和编译器“迁就”文件本身。具体做法是把 CLion 的 Project Encoding 改成 System DefaultWindows 中文系统下就是 GBK/936源文件保持 ANSI 保存编译器不要加-fexec-charsetUTF-8终端代码页保持默认的 936。也就是说源码按 GBK 存、运行时按 GBK 输出三方统一到 GBK一样能显示中文。这里有一个我实际踩过的坑CLion 某些弹窗会提示把工程编码转成 UTF-8如果点了 Convert编辑器里看起来一切正常但编译器还是按 GBK 读 UTF-8 文件字符串就乱了。老项目的编码转换一定要分批做、做一次验证一次不要一个Convert All梭哈。如果你不想动老工程方案 B 是零修改最快的应急方式。但它的缺点也很明显后续新增第三方库、接入现代构建工具时 GBK 会越来越别扭比如 Python 脚本读源码、Git 差异比较、CI 日志收集这些环节都可能出问题。所以我的建议是老项目可以用 GBK 临时过渡新项目一律走方案 A 的 UTF-8 链路。2.3 方案 C开启 Windows 系统级 UTF-8 Beta 选项慎用Windows 提供了一键把所有非 Unicode 程序的编码默认值切到 UTF-8 的开关路径是控制面板 → 区域 → 更改系统区域设置 → 勾选“Beta使用 Unicode UTF-8 提供全球语言支持”→ 重启。勾选之后系统的 ACP 和 OEM 代码页都会被改成 65001CLion 控制台默认代码页也会变成 UTF-8很多乱码问题会直接消失。但这里我必须泼一盆冷水。这个选项是“Beta”在真实环境里影响范围极大。老旧的 GBK 原生程序可能显示乱码个别驱动安装程序可能读取配置文件异常甚至某些注册表导入、快捷方式执行都会出莫名其妙的问题。我自己在一台主力工作机上开过一个月后来因为某个专业软件的中文资源文件乱掉又关掉了。所以我的结论是这个方案适合你有一台专门做开发实验的机器或者你能接受偶尔遇到老软件乱码的情况否则不建议在主力机上开启。对团队办公环境更不要轻易下发这个策略。2.4 方案 D注册表微调了解原理不建议日常使用和系统 Beta 选项类似手动改注册表也能改变系统代码页。位置在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage相关键包括ACP、OEMCP、MACCP默认值是936你可以改成65001后重启。这相当于手动执行了 Beta 选项做的事而且还能精确控制哪些代码页切换。但从实际经验看这个操作的风险和方案 C 一样而且更容易改出问题比如某些版本 Windows 对ACP65001的支持并不完整会出现资源管理器右键菜单中文丢失、部分官方安装程序拒绝运行等情况。我只在虚拟机里做过验证用于理解原理生产机强烈不建议这么改。真要改系统级优先用方案 C 的官方开关别碰注册表。3. 完整实操在 CLion 里一步步配置并验证下面我把解决方案 A 从头到尾的操作步骤展开包含我在真实项目里的配置过程和验证结果。这个过程可以当成一份 checklist 直接抄。3.1 修改 CLion 的文件编码与新建文件默认编码进入 Settings → Editor → File Encodings把 Global Encoding、Project Encoding、Default encoding for properties files 全部改成 UTF-8。同时建议在 Settings → Editor → File Encodings 下方的“Create UTF-8 files”相关选项里确认新文件默认就是 UTF-8。若你的团队里有 Visual Studio 开发者可以选 UTF-8 with BOM因为 VS 对无 BOM 的 UTF-8 源文件解析比较挑加 BOM 更保险如果团队全是 CLion/GCC 流无 BOM 就行省得 BOM 在某些构建脚本里捣乱。改完编码后打开一个旧文件留意 CLion 右下角的编码小图标。如果显示为 GBK并且文件内容里有中文CLion 会弹一个 Reload / Convert 的提示框。这里千万注意如果只是想看选 Reload按文件当前编码重新加载显示如果想永久转成 UTF-8选 Convert。但转换前先备份或提交 Git因为这个操作会改变文件所有中文字符的底层字节Git diff 会非常壮观。我习惯是先提交一次“迁移前状态”再集中转换然后逐个文件 diff 确认没有意外改动。3.2 配置 CMakeLists 与编译器编码参数在 CMakeLists.txt 中追加前面给过的编码块最好放在定义工程名之后、添加可执行文件之前cmake_minimum_required(VERSION 3.20) project(EncodingDemo LANGUAGES C CXX) if(MSVC) add_compile_options($$COMPILE_LANGUAGE:C,CXX:/utf-8) else() add_compile_options(-finput-charsetUTF-8 -fexec-charsetUTF-8) endif() add_executable(EncodingDemo main.cpp)这里我用$$COMPILE_LANGUAGE:C,CXX:/utf-8这种生成器表达式是为了防止/utf-8在 Ninja 多语言混编时被误传给其他语言编译器算是个经验细节。如果你的工程是纯 C直接写add_compile_options(/utf-8)也行。改完之后CLion 顶部会出现 CMake 工程重载提示点 Reload。如果你用的是 CLion 自带的 MinGW 工具链上面else()分支的-finput-charsetUTF-8 -fexec-charsetUTF-8会生效。如果是 MSVC 工具链走/utf-8分支。这套写法在 Windows 上用 CLion 我实测过很多次能覆盖大多数情况。3.3 控制台输出与内置终端代码页设置CLion 的 Run 窗口默认由 IDE 渲染它本质上也是一个终端模拟器代码页跟随进程启动时的控制台。如果你只改了代码里的SetConsoleOutputCP(CP_UTF8)在 Run 窗口通常能正常显示但某些 CLion 新版本切换了新的终端渲染器后内嵌 Run 面板对代码页的感知会有延迟此时更稳妥的做法是让程序跑在外部控制台。在 Settings → Build, Execution, Deployment → Console 里把“Run 终端”从内置改成外部 CMD或者直接在运行配置里勾选“Run in external terminal”。外部 CMD 窗口对chcp 65001的响应更符合 Windows 原生行为少很多花边问题。如果你希望每次运行都自动切换代码页又不想在代码里写 Windows 头文件还有个偏方在 CMakeLists 里加一句set(CMAKE_CXX_STANDARD? 不相关。正确做法是在 CLion 的 Settings → Tools → Terminal 里把 shell 启动参数改成类似cmd.exe /k chcp 65001这样每次打开终端窗口都会先切代码页。但注意这个设置只影响终端窗口不影响 Run 窗口所以还是建议优先用代码内SetConsoleOutputCP 必要时外部控制台这套组合。另外早期版本的 Windows 控制台在 65001 代码页下有过光标错位、换行不正常的毛病Windows 10 2020 之后的版本基本解决了如果你还在用老系统出现光标问题不要慌那不是项目编码问题。3.4 一个典型场景的完整排查演示我专门搭了一个测试工程来演示源码内容很简单#include cstdio int main() { printf(你好中文乱码测试\n); printf(Café 中文 English 混合\n); return 0; }文件保存为 UTF-8 无 BOM。工具链用 MinGW GCC控制台默认代码页 936。这时候不修改任何编码参数直接编译运行输出就是典型的 UTF-8 字节被 GBK 解码的乱码形态。然后我按上面的三步依次改动每次记录结果。改动步骤控制台输出表现初始状态UTF-8 源码 无编译参数 936 代码页乱码显示为“浣犲ソ”一类错位字符添加-fexec-charsetUTF-8编译参数乱码形态变化变成少量问号和方块说明编译器写入可执行文件的字符集变了代码内追加SetConsoleOutputCP(CP_UTF8)中文正常显示混合内容也正常取消编译参数只保留SetConsoleOutputCP(CP_UTF8)字符串又乱因为编译阶段字节已经被错误转换运行阶段再切代码页无济于事这个实验最有价值的结论是编译和显示是两回事只修一个环节往往治标不治本。真正有效的必须同时满足两个条件——编译器把源码当成 UTF-8 读进来并写出正确的字节序列终端把字节序列按 UTF-8 解码。如果你看到某个教程只让改注册表代码页、只让改编辑区编码却完全没提编译器参数那大概率是没说全。4. 那些容易被忽略的周边坑主方案都做了乱码却还是没有彻底消失大概率是碰到了下面的周边问题。每个都困扰过我和团队里的同事单独拿出来说说。4.1 旧工程 GBK 文件和 UTF-8 文件混在一起CLion 一个工程里很可能同时存在 GBK 和 UTF-8 源码。比如某个模块是同事用 Visual Studio 老版本写的另一些文件是后来用 CLion 新建的。这时候整个工程只有一个 Project Encoding 配置改哪个都会有文件“不适合”。我的处理方法是先统计源文件编码分布然后分批迁移。迁移单文件可以这样操作先把文件另存为 UTF-8CLion 右下角编码图标 → Convert 到 UTF-8再对比 Git diff 确认只有中文字符涉及的行变化没有意外内容被改动。批量迁移可以用命令行工具比如在 Git Bash 里执行for f in $(find src -name *.cpp -o -name *.h); do iconv -f GBK -t UTF-8 $f $f.tmp mv $f.tmp $f done这里假设源文件原编码是 GBK。如果文件混着 GB18030 扩展区位生僻字iconv的-f GBK可能会失败换成GB18030更保险。批量转换有风险转完用编译器和测试用例各跑一遍重点检查中文相关的日志输出、字符串比较、正则表达式匹配。千万不要干到一半又反悔转回去来回转换是编码丢字的最大来源。4.2 控制台字体与字形问题导致的“假乱码”有时候程序输出的中文在 Git Bash 或 IDE 里看着是几个方框但复制出来却是正常中文这就是字体或字形渲染的问题不是编码问题。Windows 自带的传统控制台字体是点阵字体微軟雅黑也不一定能被 old conhost 正确 fallback。尤其在 CLion 内置 Run 窗口里字体渲染走 IDE 的字体配置如果你设置的 Font 不支持 CJK 字形中文就会变成豆腐块。解决办法在 CLion 的 Settings → Editor → Color Scheme → Console Font 里把字体改成NSimSun或者Microsoft YaHei Mono这两种在 Windows 下对中文支持都比较好。如果你跑外部 CMD右键窗口标题栏 → 属性 → 字体选一个 TrueType 字体比如“新宋体”或“Consolas 中文回退”。新版 Windows Terminal 则直接在设置界面里选字体Cascadia Mono对中文不太友好可以配一个Noto Sans Mono CJK SC作为回退字体。这个坑不属于编码但很多人到最后一步被它拦住白白折腾半天。4.3 和 VSCode、Visual Studio、Tomcat 乱码的共性与差异搜热词经常看到“VSCode 中文显示乱码”“Visual Studio 中文输出乱码”这些和 CLion 乱码的本质是一样的都是源编码、编译器编码、终端解码三者不统一。VSCode 里中文显示乱多数是编辑器拿 UTF-8 打开了一个 GBK 文件点右下角编码选“Reopen with Encoding”即可别乱点“Save with Encoding”Visual Studio 2022 中 C 项目的中文输出乱码可以用/utf-8编译选项加上项目属性里的“备用字符集”来治原理和 CLion 方案 A 相同。至于 Tomcat 8 的中文乱码更多是请求参数和响应编码的问题跟控制台代码页关系不大属于另一个维度的事。遇到乱码先冷静判断是编辑器显示乱、编译时刻乱、运行窗口乱还是网络传输过程中乱把链路拆开定位比盲目改全局设置有效得多。4.4 重启之后乱码又复现有人按照方案 A 全改好了重启电脑再打开 CLion 跑程序又乱了大喊“白折腾”。其实有个常见细节被忽略chcp 65001是本次进程内有效CLion 每次启动 Run 窗口时代码页继承的是系统默认值。如果你依赖手动在终端敲chcp或者注册表没改重启后自然回到 936。解决方案是在代码里加上SetConsoleOutputCP(CP_UTF8)或者把 CLion 终端启动参数改成/k chcp 65001而不是只靠一次手动执行。同理Windows 服务、计划任务里跑的程序控制台代码页更不会继承你手动设置的 chcp必须写成启动脚本或程序内设置。这一条对自动化部署尤其要重视。5. 高频问题速查与项目长期建议顺手把我在排查乱码时最常用的对照表和长期规范整理出来节省你下次翻文档的时间。5.1 乱码问题速查表症状优先排查项推荐处理输出全是???编译参数、源码中的高位字节编译器加/utf-8或-fexec-charsetUTF-8输出是空心方块字体、终端渲染换支持 CJK 的控制台字体检查 Run 窗口字体输出是“浣犲ソ”类错位中文终端代码页 vs 编译产物编码运行时SetConsoleOutputCP(CP_UTF8)或chcp 65001有的文件正常有的乱源码文件编码不统一统一迁移到 UTF-8校准 CLion 的 File EncodingsCLion 源码显示中文正常编译后运行乱编译器执行字符集与运行环境不匹配检查 CMakeLists 里的编码编译选项重启后又乱代码页没有持久化程序内设置代码页或配置终端启动参数持久化外部 CMD 正常CLion Run 窗口乱内置终端和外部终端解码差异在 CLion Console 设置中改用外部终端这张表对我的帮助很大基本能覆盖日常工作里 95% 的中文乱码场景。你自己遇到新问题也可以顺着表格反推把“症状”和“环境”补充完整再定位。5.2 团队项目长期维护中的编码规范建议如果你不是一个人开发编码规范必须写进团队约定不然今天你改成 UTF-8明天有人用 VS 打开另存成 GBK后天 CI 日志就花了。我建议从下面几点开始立规矩。新文件一律 UTF-8。如果团队有 Windows 原生开发流统一用 UTF-8 with BOM省得 MSVC 老版本和 GCC 对无 BOM 文件的判断不一致。提交前用 Git 的core.quotepath false配置避免中文文件名在 Git 输出里被转义成八进制排查 diff 时容易看错。在 CI 脚本里统一使用 UTF-8 读取项目日志和源码文件避免在不同语言的构建步骤之间传递字节流时出现二次转码。如果确实要继续维护 GBK 老工程至少保证同一编译单元内的文件编码一致不要在一个 .cpp 里混用 GBK 和 UTF-8 字符串否则你连“这文件到底是什么编码”都说不清楚。我自己的经历是刚开始觉得改编码参数麻烦总想靠系统 Beta 开关一劳永逸后来在主力机上翻了车又退回项目内统一方案。现在我的建议非常简单——新项目直接按方案 A 配置好CMake 里那几行编码参数从一开始就写上旧项目能迁就迁不能迁就维持 GBK 完整链路绝不搞半吊子混合编码。这套思路帮我从“今天修好明天又乱”的循环里彻底跳了出来。最后再多说一句个人习惯遇到乱码我第一件事不是改设置而是先把输出内容复制到十六进制里看一眼。如果看到E4 BD A0 E5 A5 BD这种以E开头的三字节序列那就是标准 UTF-8 的“你好”问题基本在终端代码页如果看到C4 E3 BA C3这种二字节序列那就是 GBK问题可能在编译器或源码编码。判断清楚之后再动手通常一次就能命中比反复试错高效得多。希望这篇经验能让你少走我当年的弯路。