JSON中u4F60u597D显示乱码，主因是解析器未解码Unicode转义或输出环境不支持UTF-8：nlohmann/json v3.2.0+默认解码，jsoncpp早期版本可能未解码，rapidjson需启用kParseValidateEncodingFlag；解码后若仍乱码，多因终端/控制台编码不匹配UTF-8。
JSON字符串里u4F60u597D显示成乱码？先确认解析器是否自动处理
标准C++不内置JSON解析，你用的第三方库（如nlohmann/json、rapidjson、jsoncpp）是否默认解码uXXXX转义，直接决定后续要不要手动干预。nlohmann/json从v3.2.0起默认完整支持Unicode转义解码，读入std::string或std::u8string时已转为UTF-8字节序列；而早期jsoncpp（Json::Value）若用asString()可能返回未解码的原始转义串（比如"\u4f60\u597d"而非"你好"）。
- 检查你的库版本和文档，搜索“unicode escape”、“UTF-16 surrogate pair support”关键词
- 打印原始字符串字节（用
for (auto b : s) printf("%02x ", (unsigned char)b);）验证是否已是UTF-8编码（如4f60对应你的UTF-8是e4 bd a0，不是4f60） - 若看到
u4f60原样存在，说明解析阶段没触发解码——不是编码问题，是解析器配置或版本问题
nlohmann/json中std::string字段含u转义但输出仍是uxxxx？检查字符串类型和IO流设置
即使nlohmann/json正确解码了u4f60为UTF-8字节，控制台或文件输出仍显示乱码，大概率是std::cout没正确处理UTF-8，或终端/IDE编码不匹配。nlohmann/json本身不负责输出渲染，它只保证json["key"].get<:string>()</:string>返回的是合法UTF-8字节流。
- Windows下CMD默认GBK，
std::cout直接输出UTF-8会乱码；需调用SetConsoleOutputCP(CP_UTF8)并确保字体支持Unicode - Linux/macOS终端一般默认UTF-8，但若用
std::wcout搭配std::wstring反而会出错——nlohmann/json的std::string是UTF-8，不是UTF-16/UCS-2 - 写入文件时，别加BOM；用文本编辑器（如VS Code）打开时确认编码选的是UTF-8 without BOM
rapidjson读取后调用GetString()返回的char*里u没变中文？启用kParseValidateEncodingFlag
rapidjson默认不校验输入编码，若JSON源本身是UTF-8但含u转义，且你没开启验证标志，它可能跳过转义处理。必须显式启用kParseValidateEncodingFlag，否则GetString()返回的指针指向未解码的原始JSON文本片段。
#include "rapidjson/document.h" rapidjson::Document doc; // 关键：必须传入这个flag doc.Parse<rapidjson::kParseValidateEncodingFlag>(json_cstr); // 此时 doc["key"].GetString() 才返回解码后的UTF-8字符串
- 漏掉
kParseValidateEncodingFlag是rapidjson最常被踩的Unicode坑 - 若JSON源是UTF-16（如Windows记事本另存为UTF-16 LE），还需配合
rapidjson::UTF16编码类，但绝大多数Web API返回UTF-8 + u转义，用UTF-8+validate flag即可 - 不要对
GetString()结果再调用std::wstring_convert<:codecvt_utf8>></:codecvt_utf8>——这是过度转换，易引入错误
自己实现u转义解码？除非万不得已，否则别碰
手动解析u4f60需要处理UTF-16代理对（surrogate pair，如ud83dude00），还要考虑大小写（U4F60非法，但有些宽松解析器接受）、非BMP字符边界。nlohmann/json和rapidjson都已覆盖全部Unicode标准场景，自己写容易漏掉边缘case。
立即学习“C++免费学习笔记（深入）”；
- 仅当嵌入式环境无第三方库、且确定JSON只含BMP内字符（u0000–uffff）时，才考虑简单正则替换
- 示例（不推荐生产使用）：
std::regex_replace(s, std::regex(R"(\u([0-9a-fA-F]{4}))"), [](auto& m) { return utf8_from_utf16_codepoint(std::stoi(m[1], 0, 16)); }); - 真正难的是ud83dude00这类4字节UTF-16代理对，对应单个emoji，需合并高低位再转UTF-8——这正是成熟库已解决的问题
Unicode转义解析不是字符编码转换，而是JSON语法层面的字面量解释步骤；搞不清这点，就容易在“该库解码了但显示乱码”和“该库根本没解码”之间反复横跳。
