std::text_encoding在C++23中仅为无功能的枚举类型，仅提供utf_8等静态常量用于标注编码意图，不验证、不转换、不处理BOM，零开销也零功能；实际编码转换需依赖iconv、Windows API或第三方库如utf8cpp。
std::text_encoding 在 C++23 中只是个空壳，不提供任何编码转换能力，别指望它能帮你转 UTF-8 和 GBK。
std::text_encoding 只是枚举，不是编解码器
它定义了几个静态常量（如 std::text_encoding::utf_8），仅用于标记“这个字符串*声称*是 UTF-8 编码”，但标准库根本不检查、不验证、不转换。它不读文件，不调用 iconv，也不处理 BOM。
- 常见错误现象：
std::text_encoding::utf_8被当成“自动转码开关”，结果传给std::ofstream或std::string_view完全没效果 - 使用场景：目前几乎只有配合未来可能的文本协议元数据（比如网络 API 声明 payload 编码）或自定义 I/O 类型做类型标注，纯属占位符
- 性能 / 兼容性影响：零开销，也零功能；GCC 13/Clang 16 实现里它就是个 enum class，连头文件都不带实现逻辑
真正要转编码，得靠第三方或平台 API
标准库至今没提供 std::encode 或 std::decode —— 这不是遗漏，是委员会明确推迟到“未来 TS”。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- Windows 下常用
MultiByteToWideChar+WideCharToMultiByte，注意CP_UTF8和CP_ACP的区别 - Linux/macOS 常用
iconv()：先iconv_open("UTF-8", "GBK")，再循环iconv()，最后iconv_close() - 跨平台推荐
utf8cpp（轻量，只处理 UTF-8 ↔ UTF-32）或icu（完整，但庞大）；std::codecvt已被 C++17 废弃，别碰 - 参数差异：比如
iconv的const char**输入指针是 in/out 参数，容易因未更新指针导致死循环或越界
std::text_encoding 与 std::filesystem::path 的关系？没有
有人以为 std::filesystem::path 会根据 std::text_encoding 自动解码路径字符串，实际完全无关。path 内部存储的是 char 或 wchar_t 序列，操作系统怎么解释，它就怎么传——Windows 用 UTF-16，Linux 用原始字节。
立即学习“C++免费学习笔记（深入）”；
- 常见错误现象：用
std::string构造含中文路径的std::filesystem::path，在 Linux 下正常，在 Windows 下乱码，误以为是 encoding 标记问题 - 根本原因：Windows API 要求路径为
wchar_t*，而std::filesystem::path的std::string构造函数只是逐字节复制，没做任何编码映射 - 正确做法：Windows 上直接用
std::wstring构造 path，或用std::filesystem::u8path()（C++20，接受 UTF-8 编码的std::string）
std::text_encoding 现在唯一的实用价值，是让你在写模板时多一个类型安全的标签；真要干活，它连个字节都不帮你动。别在它身上浪费调试时间——该查 iconv 手册就查，该看 Windows 文档就看。
