Windows下GBK↔UTF-8应通过CP_ACP/CP_UTF8经UTF-16中转，Linux/macOS用iconv；禁用已弃用的std::codecvt；std::ifstream不处理编码，需手动转换。
Windows 下用 MultiByteToWideChar 和 WideCharToMultiByte 转 GBK ↔ UTF-8
Windows API 是最稳妥的本地方案，不依赖第三方库，且能精确控制编码行为。关键在于两次中转：GBK ↔ UTF-16（wchar_t）↔ UTF-8。
常见错误是直接用 CP_UTF8 当作源码页去读 GBK 文件，结果乱码——CP_UTF8 只能用于 UTF-8 编码/解码，不能“解释” GBK 字节流。
- 从 GBK 转 UTF-8：先用
MultiByteToWideChar(CP_ACP, ...)把 GBK 字节转成wchar_t字符串（注意：CP_ACP在简体中文 Windows 上默认为 GBK），再用WideCharToMultiByte(CP_UTF8, ...)转出 UTF-8 字节 - 从 UTF-8 转 GBK：顺序反过来，先
MultiByteToWideChar(CP_UTF8, ...)解码 UTF-8 到wchar_t，再WideCharToMultiByte(CP_ACP, ...)编码为 GBK - 务必检查返回值：若函数返回 0，调用
GetLastError()查具体错误；常见如缓冲区太小（返回所需字节数）、输入非法序列（如截断的 UTF-8） -
CP_ACP不可硬编码为 936，它依赖系统 locale；但若明确只处理 GBK，可用936替代CP_ACP提高可移植性
Linux/macOS 下用 iconv 处理 UTF-8 ↔ GBK
POSIX 系统没有内置宽字符编码转换 API，iconv 是事实标准。它轻量、稳定，且支持大量编码，但需注意初始化和内存管理。
容易踩的坑是忽略 iconv 的“状态保持”特性：一次调用可能无法处理完全部输入，尤其遇到多字节边界时；反复调用前必须重置转换描述符或新建一个。
立即学习“C++免费学习笔记（深入）”；
- 初始化：
iconv_t cd = iconv_open("GBK", "UTF-8")或iconv_open("UTF-8", "GBK")；失败返回(iconv_t)-1 - 转换时用指针地址的地址（
&inbuf,&outbuf），因为iconv会移动指针位置 - 输出缓冲区必须留足空间：UTF-8 中文通常 3 字节，GBK 是 2 字节，但转换方向不同，长度变化不固定；建议按输入长度 × 2 预分配
- 转换完成后必须调用
iconv_close(cd)，否则资源泄漏；多次复用时别忘了iconv_reset(cd)
跨平台 C++11 以上用 std::codecvt_utf8？别用了
std::codecvt_utf8 和相关 facet 在 C++17 中已被标记为 deprecated，GCC/Clang 新版本默认禁用，MSVC 也仅提供有限兼容。它不仅接口晦涩，还强制绑定 std::wstring，而 wstring 在 Windows 和 Linux 下语义完全不同（UTF-16 vs UTF-32），根本做不到真正跨平台。
试图用它桥接 GBK 几乎必然失败：标准库没提供 GBK 的 codecvt 实现，自己写要重载虚函数、管理 state、处理不完整序列——复杂度远超收益。
- 不要尝试特化
std::codecvt_byname<char32_t, char, std::mbstate_t>去模拟 GBK - 不要依赖
std::wifstream的imbue+codecvt读 GBK 文件——在 Linux 下大概率读成空或乱码 - 替代思路：Windows 用 WinAPI，Linux/macOS 用
iconv，封装一层薄胶水函数即可，比啃标准库废弃设施省心得多
读文件时编码搞错，std::ifstream 本身不负责解码
std::ifstream 只做字节读取，所谓“按某种编码打开”是误解。它没有编码参数，所有文本解释都发生在你调用 getline() 或 >> 后的内存操作阶段。
典型翻车场景：用 std::ifstream 读 GBK 文件，然后直接拿 std::string 给 UTF-8 接口（如 JSON 解析器、网络发送）用——字节没变，但语义已错。
- 正确流程：先用上述任一方法（WinAPI / iconv）把原始字节转为目标编码字符串，再交给业务逻辑
- 如果文件头有 BOM（如 UTF-8 BOM
\xEF\xBB\xBF），可用来自动判断编码，但 GBK 没 BOM，不能靠这个区分 - 避免用
std::string存“带编码含义”的数据；更安全的做法是定义struct text { std::string data; encoding_t enc; }，强制编码意识显式化
最麻烦的从来不是怎么转，而是哪一步该转、哪一步不该转。比如日志输出、配置解析、网络收发，每个环节的编码契约是否一致，比单次转换函数选型重要得多。一个 GBK 字符串被误当 UTF-8 传进 ICU 库，可能直接触发断言崩溃——这种问题不会报“编码错误”，只会报“illegal argument”。
