CLion中文乱码全攻略：从源文件编码到控制台代码页的彻底排查-代码聚汇网

CLion中文乱码全攻略：从源文件编码到控制台代码页的彻底排查

弥勒鹿·2026-10-05·阅读 22 GEO检测（免费）

C/C++CLion中文乱码

|难度：普通|阅读约 30 分钟

写了这么多年C/C++项目，折腾过VS、Eclipse、Code::Blocks，最近几年主力IDE换成了CLion。说实话，CLion在其他方面都挺省心，唯一让我反复踩坑的就是中文乱码——尤其是刚把项目从Windows搬到Linux，或者从Visual Studio迁移到CMake+CLion时，printf里明明写的是"你好，世界"，跑起来却变成一串"涓�椋�"或者干脆是问号。

这个问题的尴尬之处在于，它不像编译错误那样有明确的报错定位，也不像崩溃那样引起你的重视，屏幕上乱七八糟的字符看着烦，却又不影响程序跑。但如果你处理过JNI回调、文件读写、网络传输里的中文，就会知道乱码不是小事——一旦数据到了外部系统，编码错了就真的是错了。

这篇文章没有那种"一键解决所有乱码"的神话，而是把CLion里中文输出的整条链路拆开，带你看到底是哪一层出了问题，再给出我在Windows（MSVC工具链和MinGW工具链都覆盖）和Linux上实测有效的配置方案。不管是新手还是老手，按着排查一遍基本都能定位到根因。

1. 先搞清楚CLion乱码的"罪魁祸首"：三套编码同时参与输出

很多人的第一反应是去改CLion设置里的编码，或者网上搜个chcp 65001敲一下就完事，结果当时好用，换个项目又乱了。这是没搞清楚乱码的根源导致的。

1.1 源文件里的字符，不等于编译器看到的字符

你在CLion编辑器里写的"中文"两个字，保存到硬盘上时其实是一组字节。用什么方案把这组字符变成字节，就叫"源文件编码"。

CLion默认把文件保存为UTF-8（无BOM），这是现代编辑器的通行做法。但问题在于：编译器读取你的源文件时，未必认为它保存的是UTF-8。

MSVC（Visual Studio的编译器）如果不带任何参数，会默认假设源文件使用的是系统本地代码页，也就是简体中文Windows上的GBK（代码页936）。当它用一个GBK的脑子去读一个UTF-8编码的文件时，中文就变成了一堆它认不出来的字节。

这就是我在Windows上用MSVC工具链跑CLion项目，第一眼看到的经典乱码：
涓�椋�。
这个字符序列是固定的，你把UTF-8的"中文"字节，按GBK去解释，恰好就是这个效果。

1.2 编译器输出到内存的字节，不等于终端解析的字节

就算编译器正确读取了源文件，编译出来的程序运行时，它也会把字符串常量按"执行字符集"放在内存里。MSVC默认的执行字符集同样是系统本地代码页，GCC/MinGW通常会沿用源文件编码或系统默认。

这一层决定了你的程序里那个字符串，最终的字节序列是什么。

比如你的源文件是UTF-8，编译器也认了，但执行字符集被设置成GBK，那么程序运行时往输出流里写的就是GBK字节。反过来，如果编译器强制执行字符集是UTF-8，那么写出去的就是UTF-8字节。

1.3 终端控制台的代码页，决定了最终呈现

字节从你的程序里写出来，进入终端。终端拿到这串字节以后，还要用它的"代码页"去解码，才能把字节映射成屏幕上显示的字符。

在Linux/macOS上，终端一般是UTF-8的，所以程序输出UTF-8字节没有任何问题。在Windows上，cmd和PowerShell的历史包袱就来了——传统控制台默认代码页是936（GBK，或者叫OEM代码页），你往里面输出UTF-8字节，它当然就显示成乱码。

1.4 为什么Windows是重灾区，而Linux/macOS很少遇到

因为Linux和macOS的整个生态早就统一到UTF-8了，源文件、编译器、终端都在同一个编码体系里，根本不存在"各说各话"的问题。

Windows则是：编辑器默认UTF-8，MSVC编译器默认GBK，控制台默认GBK，三方有三种默认行为。你写的同一个printf("中文")，要经过三层翻译，只要其中一层的默认假设和另外两层不一致，到你眼前的就不是"中文"那两个字了。

注意：这里说的乱码和"编译时生成的代码运行没问题"不是一回事。只要源文件能编译通过，程序大概率能运行，只是输出到屏幕的字节没人能识别。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 第一步排查：CLion里源文件到底是什么编码

既然源文件编码是第一层，那就先把它搞清楚、搞统一。

2.1 查看当前文件的真实编码状态

CLion右下角状态栏会显示当前文件的编码格式，比如UTF-8或GBK。光标悬停上去，能看到文件的实际编码。如果显示的是带BOM的UTF-8，会写成UTF-8 BOM。

但注意，右下角显示的其实是CLion正在用的编码。如果文件本身是GBK保存的，CLion检测到后会以GBK解码，同样显示一个编码名。想要100%确认字节真相，可以用xxd或Notepad++的十六进制模式看一眼文件头。

一个快速判断技巧：

文件开头有EF BB BF三个字节，是UTF-8带BOM。
没有任何BOM，文件里中文能正常显示，那大概率是UTF-8无BOM或GBK。
用file命令或者vs code右下角，都能辅助确认。

2.2 一次性把整个项目的编码统一成UTF-8

CLion里改编码最正规的做法是：

Settings/Preferences -> Editor -> File Encodings

把这三项都设成UTF-8：

Global Encoding（新建文件的默认编码）
Project Encoding（当前项目编码）
Default encoding for properties files（配置文件编码）

改完以后，CLion弹窗问你是否要把现有文件转成新编码，选转换。这一步会重写每个文件的内容，如果之前是GBK保存的，转换后中文会以UTF-8字节重新存储。

如果你有一大堆历史文件，也可以在CLion界面右下角点击编码区域，手动为每个文件单独转换。更暴力的方式是在命令行用iconv批量搞定：

bash复制iconv -f GBK -t UTF-8 src.c > src_utf8.c

不过这么做有一定风险，如果文件里混着两种编码的内容，转换后会直接把某些字符"转没了"变成?，所以批量转换前最好把项目复制一份存档。

2.3 关于BOM的取舍：要不要带BOM？

这是CLion用户特别容易忽略的一个细节。

保存UTF-8文件时，可以带BOM（Byte Order Mark），也可以不带。BOM的作用是告诉编译器"我是UTF-8，别猜了"。

MSVC遇到带BOM的UTF-8源文件时，能自动识别并正确解析。但如果源文件是UTF-8无BOM，MSVC就按本地代码页去猜，在简体中文系统上猜成GBK，于是乱码。

所以你面临的选择是：

方案	优点	缺点
UTF-8带BOM	MSVC能自动识别，且Windows记事本兼容	某些工具链（比如部分GCC版本、链接器脚本）对BOM敏感，早期版本的GCC可能报错
UTF-8无BOM + /utf-8编译选项	跨平台一致性最好，GCC/MinGW和MSVC都兼容	必须在工程里显式声明编译选项，否则MSVC还是按GBK读
全部转成GBK	老Windows控制台天生支持	跨平台项目到了Linux上就乱，不推荐

我个人现在的习惯是：纯Windows + MSVC的项目，保存为UTF-8带BOM；任何可能跨平台的项目，保存为UTF-8无BOM并在CMake里统一加编译选项。

3. 第二步拦截：让编译器和运行时认可你的编码

源文件编码这个源头理顺之后，就该轮到编译器这层了。

3.1 MSVC工具链的做法：/utf-8 编译选项

MSVC从Visual Studio 2015 Update 2开始提供了/utf-8选项，它等价于同时指定/source-charset:utf-8和/execution-charset:utf-8。

这意味着：

编译器按UTF-8去读源文件（解决源文件解析乱码）
程序运行时，字符串常量在内存里以UTF-8字节存在（解决执行字符集乱码）

在CMake项目里，最稳妥的写法是：

cmake复制if(MSVC)
    add_compile_options(/utf-8)
endif()

在CLion的新版CMake版本中，也可以用add_compile_definitions或者target_compile_options精确控制：

cmake复制target_compile_options(your_target PRIVATE /utf-8)

这条命令只影响编译，不影响链接，所以放在add_compile_options还是target_compile_options都可以。只要保证所有源文件在编译时带上这个flag，MSVC就会乖乖把源文件当UTF-8处理。

3.2 MinGW/GCC工具链的做法与差异

MinGW用的是GCC，GCC在源文件编码的默认处理上比MSVC宽松不少。GCC默认源字符集是UTF-8，所以在Linux和Windows上，它一般不会把UTF-8读成GBK。

但是，执行字符集这一层要注意。GCC默认执行字符集是"实现定义"，MinGW版GCC在Windows下通常还是按UTF-8/Latin1之类处理，这会带来一个结果：程序输出的字符串常量是UTF-8字节，而Windows控制台默认按GBK解码，照样乱码。

为了强制统一，我习惯在CMake里同时给GCC也加上显式参数：

cmake复制if(NOT MSVC)
    add_compile_options(-finput-charset=UTF-8 -fexec-charset=UTF-8)
endif()

这样不管用的是MinGW还是Linux上的GCC，从源文件读取到最终生成的字符，都明确是UTF-8，避免编译器自作主张。

3.3 在CMakeLists.txt里写入统一配置模板

直接看一个我常用的模板片段：

cmake复制# 统一UTF-8构建
if(MSVC)
    # 让MSVC把源文件按UTF-8读取，并且生成UTF-8字符串字面量
    add_compile_options(/utf-8)
    # 如果装了Windows版UTF-8支持，也可以加下面的宏
    # add_compile_definitions(/D_UNICODE /DUNICODE)
else()
    # GCC/Clang旧版本可能默认不是严格UTF-8编译
    add_compile_options(-finput-charset=UTF-8 -fexec-charset=UTF-8)
endif()

这还不算完。MSVC在某些项目里，即使加了这个选项，编译器仍可能对带source file编码的糟糕注释文件有抱怨。如果你的项目里有历史遗留的GBK注释文件，建议先把文件编码批量转成UTF-8（见第2节），再谈编译选项，否则会出现"部分中文注释被编译器当成非法字符"的警告。

注意：不要误以为只要改了源文件编码就万事大吉。程序运行时往控制台输出的字节，取决于编译器生成的目标代码，而不是源文件的保存格式。所以第2节和第3节必须配合。

4. 最后一公里：Windows控制台代码页与CLion内置终端

把源文件和编译器都统一到UTF-8之后，如果你在Linux/macOS，到这里基本问题就解决了。但在Windows上，还有最后一道关卡：控制台。

4.1 理解代码页机制：chcp 65001和chcp 936

Windows控制台有一套独立的字符集系统——代码页。你可以把它理解成控制台用来把字节翻译成字符的对照表：

chcp 936：GBK（中文系统老版本cmd的默认值）
chcp 65001：UTF-8

如果你在cmd里执行：

bash复制chcp

看到936，那就意味着控制台准备用GBK来解释你程序输出的一切字节。你的程序输出的是UTF-8字节，自然是乱码。

临时切换的办法：

bash复制chcp 65001

然后你当前控制台的代码页就变成UTF-8，这时候再运行程序，UTF-8输出就能正常显示了。

但这里有个坑——chcp 65001只是在当前这个shell进程里生效，你新开一个cmd/PowerShell窗口，又回到936了。而且老版本的Windows上，chcp 65001之后某些控制台命令（尤其是一些有TUI的工具）会出现奇怪的显示错位。

4.2 为CLion内置终端持久化UTF-8

CLion的Run窗口和内置终端走的是JetBrains自带的Console + Windows的ConPTY方案，和传统cmd不是一回事。新版本的CLion（2022.2+）在Windows上已经能较好处理UTF-8输出。

如果你在CLion的Run窗口里输出还是乱码，第一反应不应该是在Windows设置里找开关，而是先确认CLion本身是否以UTF-8模式运行程序。

可以看两处：

Settings -> Editor -> File Encodings，把"Console"相关的编码（有时显示在General -> Console）也设为UTF-8。

Settings -> Build, Execution, Deployment -> Build Tools -> CMake，确认.cmake文件编码统一。

另外，CLion在Windows上调用程序时，默认通过系统控制台还是模拟控制台，其实你可以简单验证：在Run/Debug Configuration里，把执行方式设成Use Console或Use external console后跑一次，看看是不是只有其中一种乱码。如果外部命令行乱、Run窗口不乱，那就是典型控制台代码页问题；如果Run窗口也乱，多半是程序输出字节本身不是UTF-8，要回头查第3节的编译选项。

4.3 运行程序本身主动切换到UTF-8输出模式

与其每次在外部环境里切换代码页，不如让程序自己"入乡随俗"。

在Windows上，可以通过Win32 API直接设置控制台代码页：

cpp复制#ifdef _WIN32
#include <windows.h>
#endif

int main() {
#ifdef _WIN32
    SetConsoleOutputCP(CP_UTF8);
    SetConsoleCP(CP_UTF8);
#endif
    printf("中文测试\n");
    return 0;
}

SetConsoleOutputCP(CP_UTF8)告诉控制台，接下来的字节请按UTF-8解析。这段代码只要在程序入口跑一次就行。

如果你的项目使用C++的iostream而不是printf，那还要注意一下locale的问题。不要以为设置控制台代码页后，std::cout << "中文"就一定正常。中间如果有人调用了setlocale(LC_ALL, "zh-CN")这类行为，字符串可能被转成其他编码。

我踩过一次坑：程序里用了std::wcout输出宽字符，结果控制台上显示成一个一个?。原因在于wcout的locale没有正确设置。解决方案是初始化时：

cpp复制std::locale::global(std::locale(".UTF-8")); // Windows在VS2015+支持
// 或者
std::wcout.imbue(std::locale(".UTF-8"));

说回CLion。在CLion的Run窗口里跑程序，只要CLion自身解码正常，上面的SetConsoleOutputCP(CP_UTF8)其实影响不大，因为JetBrains的终端模拟器就是用UTF-8解码的。但如果你把程序拖到传统cmd、PowerShell或者桌面环境下的Windows Terminal里运行，这段代码就很有用了。

5. 乱码现场还原：一个从乱到不乱的真实案例

光讲理论不够，我挑一个实际环境完整走一遍排查链路。

5.1 初始状态：Windows + MSVC + CLion，最简单的printf

环境是：

Windows 11 简体中文
CLion 2023.2
MSVC工具链
CMake项目

源文件：

cpp复制#include <cstdio>

int main() {
    const char* msg = "中文测试";
    printf("%s\n", msg);
    return 0;
}

CLion的Run窗口输出结果：

code复制涓\uㄣ��娴嬭瘯

（不同控制台可能渲染略有差异，但"涓"开头的乱码很有辨识度）

5.2 逐步调整后的对比

第一步：只把源文件转成GBK

把CLion右下角编码改成GBK，重新转换文件。此时源文件在内存里按GBK解码显示正常，但CLion可能提示要不要转成UTF-8。如果保持GBK保存，重新构建运行：

CLion Run窗口：仍然乱码，因为CLion的运行控制台默认按UTF-8解码。
传统cmd：正常。因为源文件是GBK，MSVC按GBK读，输出GBK字节，控制台也按GBK解码，三层全齐。

这印证了：只要三层编码一致，就不会乱码。但不是我们想要的现代方案。

第二步：源文件UTF-8 + 编译选项/utf-8

源文件不转，保持UTF-8，在CMakeLists里加上：

cmake复制if(MSVC)
    add_compile_options(/utf-8)
endif()

重新构建运行：

CLion Run窗口：正常显示"中文测试"。
传统cmd（代码页936）：仍乱码或显示问号，因为程序输出的是UTF-8字节，cmd默认按GBK解码。

第三步：在代码里加SetConsoleOutputCP(CP_UTF8)

在main函数开头加上：

cpp复制#ifdef _WIN32
    SetConsoleOutputCP(CP_UTF8);
#endif

重新构建，这次CLion Run窗口和Windows Terminal、新cmd窗口里都正常。

从这三步对照可以看到，乱码问题的解法不是单一的，而是每一层都有对应动作，具体取决于你最终在哪运行。

5.3 特殊场景：JNI/动态库里的中文输出

顺手说说热搜里提到的"在CLion中配置JNI环境"。

JNI场景下，Java端字符串是UTF-16，而你通过JNI调用C/C++函数时，如果这个native函数用printf往标准输出打中文，或者在返回给Java的字符串里带中文，编码链路会多一个环节：

native代码里的字符串字面量，仍然受源文件编码+编译选项影响。
如果通过NewStringUTF把const char*转成jstring，这个接口要求的是Modified UTF-8字节。而你在Windows上用/utf-8编译后，字符串常量确实是UTF-8字节，基本符合这个接口要求。
但如果native代码里的字符串在源文件里是GBK，编译器又按GBK读，那么NewStringUTF拿到的字节其实不是标准UTF-8，Java端拿到后就会乱。

在这种场景里，我的建议和纯控制台程序不太一样：JNI层不要依赖控制台代码页，直接保证源文件编译出的字节是UTF-8即可。因为Java虚拟机拿到字节后会按UTF-8解析，它不看你Windows控制台是936还是65001。所以，/utf-8编译选项在这里是关键，SetConsoleOutputCP反而用处不大。

6. 我的最终推荐配置与日常维护建议

解决一次乱码不难，难的是以后每个项目都不再乱码。所以最后给出我的标准化配置和日常注意点。

6.1 不同平台的推荐配置清单

环境	源文件编码	编译选项	终端设置	代码里额外动作
Windows + MSVC	UTF-8（建议带BOM，或配合/utf-8）	`add_compile_options(/utf-8)`	CLion内置Run窗口即可；外部cmd需要chcp 65001或Win11新版终端	可选设置`SetConsoleOutputCP(CP_UTF8)`
Windows + MinGW	UTF-8无BOM	`-finput-charset=UTF-8 -fexec-charset=UTF-8`	同上	可选设置`SetConsoleOutputCP(CP_UTF8)`
Linux/macOS + GCC/Clang	UTF-8无BOM	一般不需要，若遇旧工具链加上面GCC选项	CLion默认	一般不需要
跨平台项目	UTF-8无BOM	按编译器条件分别加选项	各平台用各平台方式	在Windows环境下设置代码页

这张表是原则性的。注意"带BOM"只用于纯Windows小项目，跨平台项目一旦带BOM，某些Linux下的编译器或脚本可能不认，反而出幺蛾子。

6.2 遇到新项目时，先做哪三步

不管项目是从哪来的，我拿到手会按这个顺序排查：

看源文件编码：CLion右下角如果显示不是UTF-8，先批量转成UTF-8。
看CMakeLists里有没有UTF-8编译选项：没有就在开头加上if(MSVC)和else分支的两行。
跑一次看Run窗口：还乱码就检查CLion的File Encodings设置里的Console编码；如果输出到外部cmd乱、Run窗口正常，说明程序字节没问题，是外部终端代码页问题。

这套顺序覆盖了90%的CLion中文乱码场景。剩下10%是那些"字符串从某个外部库/文件读进来"的情况，那就要单独调试数据来源了。

6.3 一些容易忽略的小坑

最后列几个我实际踩过、也算CLion用户高频遇到的坑：

CLion本身的日志和CMake输出乱码：CMake构建过程中，MSVC的cl.exe输出可能是本地代码页。如果你在CLion的Build窗口看到乱码，但运行时不乱，不用太在意，因为Build信息不参与程序逻辑。
Windows系统设置里的"Beta版：使用Unicode UTF-8提供全球语言支持"：这个勾选后，系统区域会变成UTF-8，很多老软件中文显示会出问题，也不建议轻易开。它对CLion本身的乱码没有本质帮助，反而可能让你用GBK编码的老文件全部显示错乱。
UTF-8 BOM的文件经过Git提交到Linux服务器：如果文件带了BOM，Linux上的GCC某些版本会报"stray '\357' in program"之类的错误，这就是BOM被当成了普通字符。解决方式是统一用无BOM的UTF-8，主要靠自定义puttyxx，也就是在编辑器层面把BOM去掉。

还有一个经验和大家分享：我在维护一个老项目时，遇到中文乱码，排查到最后发现不是编译器和终端的问题，而是那个项目的源文件在多次迁移中，有一部分文件是GBK、有一部分是UTF-8，CLion检测编码时又只认了其中一部分。后来我干脆用脚本把所有文件统一转成UTF-8无BOM，并在项目里强制固定编码策略，乱码问题才算彻底根治。编码这种东西，滞后成本远高于一次性统一成本，尽早规范总是省心的。