先讲个我最近碰到的真实情况。一个跑了很久的老模块，突然在客户那边导出的文件列表全是“???”和乱码。一开始我以为是数据库字段出了问题，排查了半天，最后发现是新服务器的默认字符集从GBK变成了UTF-8，而代码里还在用老一套“手工拼文件名”的方式处理路径。这种问题，你应该也遇到过：VS里printf输出中文变成一团乱码；Windows上正常运行的代码丢到Linux就满屏问号；别人用压缩包发来的文件解压以后文件名全是火星文。绕来绕去，最后都会发现根子只有两个——字符编码没搞明白，STL用得不熟。
今天这篇我就把这两个看似不相关的东西放在一起讲。一方面，C++标准库里其实已经躺着一堆处理字符串、字符编码、文件路径的现成工具，很多人没深入研究；另一方面，字符编码根本不是玄学，它是一套非常明确的规则，懂了规则再配合STL的工具，你就完全不需要为了“中文能不能正常输出”去手写一堆循环加位运算的转码轮子。这篇文章适合谁？适合STL容器基本能上手、但一碰到中文就头大的C++开发者，也适合维护跨平台项目、被编码问题反复折磨的工程团队。
1. 乱码不是玄学：先搞懂你程序里到底存的是什么字节
1.1 字符集和编码方案是两个完全不同的东西
很多刚接触编码问题的开发者，会把“字符集”和“编码”混为一谈。其实它们是两层概念。
字符集定义的是“哪个字符对应哪个数字编号”，比如Unicode字符集里，“中”字的编号是U+4E2D。编码方案定义的是“编号对应的数字要如何在内存里存成字节序列”，同样是“中”字：
- UTF-8编码下，U+4E2D被写成3个字节：
0xE4 0xB8 0xAD - GBK编码下，“中”字被写成2个字节：
0xD6 0xD0
如果发送方用UTF-8把这3个字节发出去，接收方却用GBK去解码，那么0xE4 0xB8 0xAD会被强行解释成两个半字符，显示的就不是“中”，而是别的怪字。这就是乱码产生的根本原因，也是100%的乱码现象的根源：编码和解码规则不匹配。
我习惯把这件事类比成寄快递：字符集是快递单上的物品编号，编码方案是打包规则。你在北京按北京的打包规则（UTF-8）打了包，快递到了广州，广州的仓库却按另一套规则（GBK）拆包，里面的东西当然对不上。
1.2 为什么UTF-8成了跨平台的事实标准
既然乱码是规则不匹配，那最简单的方法就是统一一套规则。现实中，UTF-8几乎成了C/C++、Linux/macOS、Web领域的默认选择，不是因为它“不用转码”，而是因为这几个优点太实用了：
- 完全兼容ASCII：所有英文字母、数字、常见标点在UTF-8里都是单字节，跟历史上所有ASCII协议、文件格式完全兼容。
- 字节序无关：UTF-8不需要BOM，不存在大端小端的问题。写出去就是字节流，读回来就能解。
- 汉字编码规则清晰：常用汉字在UTF-8里固定占用3个字节，边界有明确的二进制前缀，不会出现“半个汉字”的分裂歧义。
- 跨平台友好：Linux和macOS的默认编码就是UTF-8，Windows的应用层也在持续向UTF-8靠拢。
明白这一点，你就知道大部分跨平台工程的正确方向不是研究“怎么从GBK转UTF-8更高效”，而是“怎么让整个项目从一开始就统一在UTF-8上”。
1.3 经典乱码特征速查
乱码本身也有规律可循，看特征基本能反推原因，我整理了一个速查表：
| 乱码特征 | 成因 | 典型场景 |
|---|---|---|
| 锟斤拷 | GBK字节流被误当成UTF-8解码，再转回GBK时产生了替换字符 | 文件编码混乱、数据库连接字符集不一致 |
| 烫烫烫 | VS调试器对未初始化栈内存的填充标记 | 定义了字符串数组但没赋初值 |
| 锘? | UTF-8文件带BOM（EF BB BF），被按GBK解码 | Windows记事本保存的UTF-8文件在Linux/老工具里打开 |
| 一串问号 | 终端字体缺失或代码页不支持对应字符 | 控制台输出的字符集与代码页不匹配 |
这里要稍微解释一下BOM。BOM是Unicode编码方案在文件开头写的几个特殊字节，用来告诉解码方“本文件是大端还是小端、是UTF-8还是UTF-16”。UTF-8的BOM是EF BB BF，但UTF-8本身是字节序无关的，所以很多Linux工具根本不认这个BOM。Windows记事本又有个“坏习惯”：保存UTF-8文件时默认会带上BOM，于是同一个文件在Windows里正常，放到Linux上开头就多出一个“锘?”字符。这个问题我们在后面写文件读写代码时要专门处理。
2. C++字符串的“进化史”：char、wchar_t、char8_t，以及std::string的真实身份
2.1 char其实是字节，不是字符
很多C++初学者有个根深蒂固的误解：char就是用来存字符的。严格来说，C++里的char只保证占1个字节，它是一个“字节类型”，而不是“字符类型”。当你在char变量里放0xE4时，它并不关心这个字节是“中”字的开头，还是字母“a”，它只知道这是一个8位二进制数。
std::string继承了同样的特点，它本质上是一个“字节容器”。你说“我把中文字符存到了std::string里”，更准确的说法是“我把中文按某种编码后的字节序列存到了std::string里”。这样做有好处也有坏处：
- 好处是灵活，字节流可以在不同编码方案之间随意搬运，
std::string本身不关心内容是什么。 - 坏处是没有编码标记，你得自己在外面维护“这个字符串是UTF-8还是GBK”的约定。一旦约定被破坏，乱码就会出现。
理解这一点后，再看“用std::string处理中文”的问题，思路会清晰很多：你处理的其实是字节，具体按什么规则解释这些字节，是你自己的事，std::string不管。
2.2 wchar_t并不是万灵药，它也有“跨平台陷阱”
很多被乱码折磨过的人，会想到用宽字符wchar_t来解决问题，觉得宽字符能装下所有字符就不会乱。这个思路方向对了一半，但实际用起来更坑。wchar_t的标准定义只是“足够容纳实现所支持的最大字符集的宽字符类型”，但它的宽度在不同平台并不一致：
- 在Windows上，
wchar_t是2字节，是UTF-16编码。 - 在Linux和macOS上，
wchar_t是4字节，通常是UCS-4/UTF-32编码。
这样一来，跨平台代码里如果用std::wstring作为通用字符串类型，在Windows上存的是UTF-16字节，到Linux上按UTF-32解，必然出问题。所以我的建议很明确：跨平台代码内部不要用wchar_t作为通用字符串容器。但在Windows开发中，系统API的很多字符串参数（文件名、路径、注册表键值）都是UTF-16，必须用wchar_t来对接，这时就需要做窄宽字符转换。
2.3 C++11和C++20带来的Unicode支持和char8_t
C++11引入了带编码前缀的字符串字面量：
u8"字符串"：要求编译器按UTF-8编码存储。u"字符串"：按UTF-16编码存储，对应char16_t。U"字符串"：按UTF-32编码存储，对应char32_t。
这在当时已经解决了部分问题，但有个历史遗留——u8字符串字面量的类型被定义成const char[]，也就是说，它虽然要求内容必须按UTF-8编码，但类型上还是普通char，一些编码转换函数接收char*时也不会区分编码，埋了不少隐患。
C++20引入了char8_t类型，并把u8字符串字面量的类型改成了const char8_t[]，彻底和普通char区分开。这个改动对类型安全是好事，但代价是大量现有代码需要迁移，比如原来写std::string s = u8"中文";会直接报错，需要写std::string s = reinterpret_cast<const char*>(u8"中文");或者先转成std::u8string再处理。所以如果你的项目还在用C++17，要保持清醒：u8字符串字面量回到std::string时是隐式的、很方便，但一旦升到C++20就要准备一批兼容代码了。
2.4 STL容器在这件事里的真实角色
搞清楚了字符串类型的来龙去脉，再回来看STL，视角会不一样。处理编码问题时，STL的容器和算法更多是扮演“字节搬运工”和“文本处理流水线”的角色。std::string是字节容器，std::wstring是宽字节容器，std::vector<uint8_t>也常被用来存原始二进制。真正和编码转换相关的工作，主要落在标准库的std::wstring_convert、std::codecvt、std::filesystem::path这些组件上。后面我会逐个细说。
这里稍微提醒一下：std::string_view（C++17）在处理文件内容、解析文本时非常好用，它不拥有内存，只是视图，可以避免大量不必要的字符串拷贝。解析文本时先用string_view切出片段，需要长期保留时再拷贝成std::string，这是实践中非常高效的习惯。
3. 五个高频乱码现场与完整排查链路：从printf到解压包
3.1 场景一：VS里printf/printf输出中文变成问号或乱码
这个是我被问得最多的问题。先在Visual Studio里写一段：
#include <cstdio> int main() { printf("中文输出测试\n"); return 0; }运行时控制台输出一团乱码或者问号。这个问题的链路比看上去长，它涉及三处编码是否一致：
- 源码文件本身的编码：如果你的
.cpp文件是GBK保存的，那么“中文输出测试”这6个字在文件里占用12个字节（每字2字节）。 - 编译器如何解释字面量：MSVC编译时有一个“执行字符集”的概念，默认情况下它会根据系统区域设置（比如中文Windows用GBK/代码页936）来解释
char字符串字面量。如果你的源码是UTF-8但编译器按GBK解释，字面量就会被拆错。 - 控制台的代码页：默认Windows控制台代码页是936（GBK），你往控制台输出字节时，控制台会按GBK去解码显示。如果你输出的是UTF-8字节，显示自然错。
排查的时候，我建议按这个顺序确认：
- 第一步：确认源码文件编码。在VS右下角能看到当前文档编码，如果不是UTF-8，建议“另存为”→选择“UTF-8 with signature”或“UTF-8 without signature”。
- 第二步：给编译器加
/utf-8编译选项。这个选项会同时把源字符集和执行字符集都改成UTF-8，一劳永逸。在项目属性 → C/C++ → 命令行 → 附加选项里加上即可。 - 第三步：在程序里设置控制台代码页为UTF-8。Windows下可以用
SetConsoleOutputCP(CP_UTF8)：
#include <cstdio> #ifdef _WIN32 #include <windows.h> #endif int main() { #ifdef _WIN32 SetConsoleOutputCP(CP_UTF8); #endif printf("中文输出测试\n"); return 0; }三步做完，基本能彻底解决VS控制台中文乱码。记住这个思路：源码编码、编译器执行字符集、输出端解码，三处对齐就永远不乱。
3.2 场景二：用std::ifstream读取GBK文本文件后输出乱码
很多项目里会读取老系统导出的文本文件，这些文件大概率是GBK编码的。用std::ifstream读出来后直接拼接字符串、打印日志，出现乱码几乎是一定的。
原因还是那句话：std::ifstream读取到的是文件里的原始字节，它不会做转码。GBK文件读进来是0xD6 0xD0，你如果把这个字节流直接当UTF-8输出，解码端就会看到两个无效序列。
正确的处理方式是：先把字节读进std::string，然后判断文件是GBK还是UTF-8，再做编码转换。判断方法最常用的是看BOM，UTF-8带BOM时开头三个字节是EF BB BF。如果没有BOM，可以结合内容特征判断，比如看是否包含0x80~0xFF的高位字节，这种文件多半是GBK或其它本地编码。
这里放一段用标准库做GBK转UTF-8的代码（Windows下借助系统API，Linux/Unix平台可以配合iconv实现，标准库本身不直接支持GBK，但转换思路一致）：
#include <fstream> #include <sstream> #include <string> #ifdef _WIN32 #include <windows.h> std::string gbk_to_utf8(const std::string& gbkStr) { if (gbkStr.empty()) return {}; const int len = MultiByteToWideChar(CP_ACP, 0, gbkStr.c_str(), -1, nullptr, 0); std::wstring wstr(len, L'\0'); MultiByteToWideChar(CP_ACP, 0, gbkStr.c_str(), -1, wstr.data(), len); const int utf8Len = WideCharToMultiByte(CP_UTF8, 0, wstr.c_str(), -1, nullptr, 0, nullptr, nullptr); std::string utf8Str(utf8Len, '\0'); WideCharToMultiByte(CP_UTF8, 0, wstr.c_str(), -1, utf8Str.data(), utf8Len, nullptr, nullptr); return utf8Str; } #endif int main() { std::ifstream fin("old_report.txt", std::ios::binary); std::ostringstream oss; oss << fin.rdbuf(); std::string rawData = oss.str(); // 假设文件是GBK，实际代码里应先做编码探测 #ifdef _WIN32 std::string utf8Data = gbk_to_utf8(rawData); #else std::string utf8Data = rawData; // Linux下通常应使用iconv转换 #endif return 0; }这段代码的重点是告诉你：文件读进来只是第一步，转码才是关键。写日志、入数据库之前都要保证字符串统一成UTF-8。
3.3 场景三：Linux下解压Windows发来的压缩包，文件名全是乱码
这个场景很多运维和开发都遇到过：Windows上用WinRAR或2345压缩的文件，文件名是GBK编码，传到Linux上解压，归档工具默认按UTF-8解码文件名，于是所有文件名都变成乱码。
命令行层面最简单的方法是：
# 安装unar，它默认会尝试多种编码 unar xxx.zip # 或者用convmv将已解压的乱码文件改名 convmv -f GBK -t UTF-8 --notest file_name这个问题对C++开发者尤其重要，因为如果你的程序要处理用户上传的zip包，就必须考虑文件名编码。很多第三方解压库返回的是原始字节文件名，你需要自己判断编码并转码。我一般建议在服务端统一按UTF-8处理所有文件名，收到压缩包后，先读取原始文件名，检测到非UTF-8就转成UTF-8再落盘，避免进入业务层之后再乱。
3.4 场景四：嵌入式环境的Keil工程和串口终端乱码
嵌入式开发里，乱码通常出现在两个地方：一是Keil打开代码文件时中文注释乱码，二是串口工具（比如minicom）收到的中文信息乱码。
第一个问题的原因非常简单：代码文件本身是GBK编码，Keil编辑器默认按UTF-8打开，于是注释全乱了。解决方法是在Keil的Editor配置里把Encoding设置成匹配文件的实际编码，或者干脆把源码统一转成UTF-8并调整Keil的默认编码。
第二个问题要稍微绕一点。串口工具本质上是字节透传，minicom显示的字符取决于终端模拟器的解码规则。设备端如果通过串口发送的是GBK编码的中文，而minicom端按UTF-8解码，那必然会乱。这种情况不是“数据丢了”，而是“解释方式不一致”。在C++程序里接收串口数据是同样道理，收到的是一串字节，要自己决定按什么编码去解释。项目里如果设备输出固定编码，就要在采集端做对应转换，不要指望接收端自动猜。
3.5 场景五：VSCode里源码显示乱码，以及中文路径导致的代码跳转问题
VSCode默认以UTF-8解码文件，如果你的源码是GBK，刚打开时就会显示乱码。这时可以在右下角状态栏点击当前文件编码，选择“通过编码重新打开”，或者选择“通过编码保存”，把文件统一保存成UTF-8。
还有一个经常和编码一起出现的小毛病：项目放在中文路径下，C/C++插件有时候加载不了compile_commands.json或者c_cpp_properties.json，导致函数、变量全部无法跳转。这其实属于工具链对非ASCII路径支持不好的问题。排查时先看输出面板有没有报路径错误，如果有，优先把工程移动到纯英文路径下，能省很多莫名其妙的麻烦。这也算是一个“编码”问题，不过是文件系统路径层的编码问题。
4. 别急着造轮子：标准库里对付编码问题的现成工具
4.1 容器选择：先决定你的“内部存储编码”
处理编码问题，第一步永远是定策略：你的程序内部统一用哪种编码。我的推荐是UTF-8。因为UTF-8兼容范围最广，Linux下的系统调用、大部分第三方库、现代Web协议都以它为标准。既然内部统一UTF-8，那容器选择就非常清晰：
| 容器 | 用途 | 备注 |
|---|---|---|
std::string | 内部存储和处理UTF-8字节流 | 最常用，可直接进行大部分文本处理 |
std::wstring | 对接Windows API等需要UTF-16的场景 | 临时转换用，不建议作为通用存储 |
std::u16string | 特定协议或格式要求UTF-16时使用 | C++11标准类型 |
std::vector<uint8_t> | 处理原始二进制数据、编码探测缓冲区 | 防止误按字符串处理 |
4.2 std::wstring_convert 和 std::codecvt：编码转换的主力
C++标准库虽然没有把GBK转换直接封装好，但对UTF-8和UTF-16之间互相转换是支持的。std::wstring_convert配合std::codecvt_utf8或std::codecvt_utf8_utf16是最经典的组合：
#include <string> #include <locale> #include <codecvt> std::string wstring_to_utf8(const std::wstring& wstr) { std::wstring_convert<std::codecvt_utf8<wchar_t>> conv; return conv.to_bytes(wstr); } std::wstring utf8_to_wstring(const std::string& str) { std::wstring_convert<std::codecvt_utf8<wchar_t>> conv; return conv.from_bytes(str); }这段代码在Windows和Linux上都能跑，前提是wchar_t能容纳目标字符。Windows上wchar_t是UTF-16，所以用codecvt_utf8<wchar_t>转换中文没问题；在Linux上wchar_t是UCS-4，也能正常转换。
不过有两点务必要知道：
std::wstring_convert在C++17标准中被标记为deprecated（不推荐使用），因为它的接口设计和异常安全性有一些问题。但现实是C++20标准没有提供直接替代品，所以很多实际项目依然在用。我的建议是：不要因为deprecated就彻底拒绝它，合理使用能快速解决问题，但要有意识地控制使用范围。- 转换时如果遇到非法字节流，
from_bytes会抛出std::range_error异常。实际项目里要加try-catch，不要让一个坏文件直接挂掉整个服务。
4.3 std::filesystem::path：处理文件名编码的隐藏解法
很多开发者不知道std::filesystem::path其实是处理编码问题的利器。它有一个非常重要的特性：在不同平台上，path内部使用的字符类型不同。
- 在Windows上，
path内部存的是wchar_t（UTF-16），因为Windows API层就要求UTF-16。 - 在POSIX系统（Linux、macOS）上，
path内部存的是char字节序列。
由于这个差异，直接cout << path.string()在Windows上要小心，而在Linux上基本没问题。但path提供了一个跨平台一致的u8string()方法，它返回UTF-8编码的字符串，适合跨平台交换。
举个例子，遍历一个目录并把文件名统一打印成UTF-8：
#include <filesystem> #include <iostream> namespace fs = std::filesystem; int main() { const fs::path root = fs::current_path(); for (const auto& entry : fs::directory_iterator(root)) { const std::string name = entry.path().filename().u8string(); std::cout << name << "\n"; } return 0; }这段代码在Windows和Linux上行为一致。u8string()在C++17中返回std::string，在C++20中返回std::u8string，后者需要用reinterpret_cast<const char*>才能传给普通std::string，升级到C++20时要注意这个细节。用std::filesystem之后，很多手工拼接路径、手工转码的轮子真的都可以扔掉了。
4.4 哪些“轮子”该造，哪些不该造
讨论“告别重复造轮子”，有一点需要说透：不是所有轮子都不该造。标准库能覆盖的，优先用标准库；专门领域的基础库能覆盖的，优先用第三方成熟库。我见过不少团队遇到乱码问题，第一反应是写一个ConvertAnsiToUtf8函数，然后这个函数被复制到各个模块，有的实现了BOM跳过，有的没实现，有的对非法字符直接丢弃，有的返回空字符串——这种“很多个人造的轮子”反而成了新的乱码来源。
我个人的判断标准是这样的：
| 场景 | 推荐做法 |
|---|---|
| 常见编码转换（UTF-8/16、ANSI） | 标准库std::wstring_convert+ Win32 API/iconv |
| 编码探测（判断文件是UTF-8还是GBK） | 优先用第三方库（如uchardet）或简单规则封装 |
| 字符串trim、split、大小写转换 | std::string方法配合std::string_view、算法函数 |
| 路径拼接、目录遍历 | std::filesystem::path |
| 业务相关的特殊解析逻辑 | 自己写，但尽量收敛在一个模块里，别到处都是 |
“不该造的轮子”不是说你不能用STL，而是别把STL已经解决的问题重新发明一遍。比如std::string的拼接、查找、替换方法足够丰富，很多人却还在写char*循环拼接；std::transform能做到的大小写转换，很多人非要自己写函数。
5. 一个完整的跨平台示例：收集目录文件名并统一转成UTF-8
前面讲了不少理论，下面给一个能直接编译运行的完整示例。这个示例的目标是：扫描当前目录下的所有文件，把文件名统一按UTF-8输出到一个文本文件里。整个过程用了std::filesystem、std::wstring_convert、std::ofstream，没有手写任何转码轮子。
#include <filesystem> #include <fstream> #include <iostream> #include <string> #include <locale> #include <codecvt> #ifdef _WIN32 #include <windows.h> #endif namespace fs = std::filesystem; // 简单的UTF-8与宽字符互转工具，集中管理 std::string to_utf8(const std::wstring& wstr) { std::wstring_convert<std::codecvt_utf8<wchar_t>> conv; return conv.to_bytes(wstr); } std::wstring from_utf8(const std::string& str) { std::wstring_convert<std::codecvt_utf8<wchar_t>> conv; return conv.from_bytes(str); } int main() { #ifdef _WIN32 SetConsoleOutputCP(CP_UTF8); #endif const fs::path root = fs::current_path(); std::ofstream logFile("file_list_utf8.txt", std::ios::binary | std::ios::trunc); if (!logFile.is_open()) { std::cerr << "Failed to create output file." << std::endl; return 1; } // 遍历目录 try { for (const auto& entry : fs::directory_iterator(root)) { const fs::path filename = entry.path().filename(); #ifdef _WIN32 // Windows上path内部是UTF-16，转成UTF-8再写入 const std::string utf8Name = to_utf8(filename.wstring()); #else // Linux上path内部是char字节，按UTF-8处理通常没问题 const std::string utf8Name = filename.u8string(); #endif logFile << utf8Name << "\n"; } } catch (const fs::filesystem_error& e) { std::cerr << "Filesystem error: " << e.what() << std::endl; return 1; } logFile.close(); std::cout << "Done. Open file_list_utf8.txt for results." << std::endl; return 0; }编译方式：
- Windows + MSVC：在项目属性里加
/std:c++17和/utf-8，直接编译。 - Linux + GCC：
g++ -std=c++17 main.cpp -o list_files，GCC 8之前的版本可能需要加-lstdc++fs链接标准库的filesystem实现。
这段代码有几个细节值得强调：
- 输出文件用
std::ios::binary打开，避免在Windows上把\n自动转成\r\n，这样可以保证生成的文件在跨平台查看时行为一致。 std::filesystem::directory_iterator在遍历过程中如果遇到权限不足、文件被占用等情况，会抛出fs::filesystem_error，所以外面包了try-catch。- Windows分支用
filename.wstring()转UTF-16，再统一转成UTF-8；Linux分支直接filename.u8string()，保证了目标文件内容始终是UTF-8。
如果你需要处理超大目录，可以考虑用recursive_directory_iterator加过滤条件，或者在循环里用entry.path().extension()筛选特定后缀，这都属于很自然的扩展。
6. 收尾：三条实操经验和两个少有人提的小技巧
6.1 三条经验原则
第一个经验：团队项目里固定“UTF-8无BOM”作为统一编码。一个项目里一旦出现GBK、UTF-8带BOM、UTF-8无BOM混着来的文件，编译警告和乱码问题就会没完没了。建议在仓库根目录放.editorconfig文件，明确charset = utf-8，并且在CI脚本里加一个检查步骤，发现非UTF-8文件直接报错。
第二个经验：编译选项尽量在构建系统里统一配置，不要靠每个开发者的IDE手工设置。CMake项目里可以针对MSVC加/utf-8，针对GCC/Clang加-finput-charset=UTF-8 -fexec-charset=UTF-8，把编码一致性锁死在构建层。
第三个经验：写跨平台代码时永远不要依赖wchar_t的宽度。在Windows上它就是2字节UTF-16，在Linux上就是4字节UCS-4，你把std::wstring序列化到文件或者网络传输，到了另一个平台就是一堆无法理解的字节。跨平台传输统一用UTF-8的std::string，只在触及系统API时临时转成宽字符。
6.2 两个小技巧
第一个技巧：快速判断一个文本文件是不是UTF-8。打开文件的二进制前几个字节，如果是EF BB BF，那基本可以确定是UTF-8带BOM；如果不带BOM，可以做一个简单推断——按UTF-8的规则逐字节验证整个文件是否合法，如果完全合法，大概率是UTF-8；如果解到一半就出现非法序列，则多半是GBK或其它本地编码。这个规则能覆盖工作中80%的编码判断需求。
第二个技巧：在MSVC的老项目里，如果不想立刻改构建系统，可以在源码顶部加一句#pragma execution_character_set("utf-8")，让编译器把char字符串字面量按UTF-8生成。这个办法方便，但它是MSVC扩展，而且对源码文件本身的编码识别帮助有限，不能当成长期方案，只能当救急手段。
最后再分享一点个人体会。我踩过几次编码坑之后，再遇到乱码问题，已经不太焦虑了——先问“这个字节是从哪来的”，再问“它要被谁解码”，最后问“中间有没有人绕过编码转换”。三句话问完，问题基本就定位了。这也是我这次写这篇长文的原因：编码不是玄学，规则就几条，STL里能用的工具就那几样，花一个下午吃透，后面能少熬好几个通宵。
