c++oding="utf-8" ?>
std::wstring_convert不能直接用于utf-8转gbk，因其在c++17中被弃用，且依赖的std::codecvt系列在主流标准库中不支持gbk，跨平台行为不可靠；推荐windows用winapi（multibytetowidechar+widechartomultibyte），linux/macos用iconv。
UTF-8 转 GBK 为什么不能直接用 std::wstring_convert
因为 std::wstring_convert 在 C++17 中已被弃用，且它依赖的 std::codecvt_utf8 和 std::codecvt_utf8_utf16 在多数标准库实现（如 libstdc++、MSVC 新版本）中不支持 GBK（即 std::codecvt_byname("zh-CN") 不可靠或根本不可用）。强行启用会触发编译警告甚至链接失败，比如：undefined reference to std::codecvt_byname<char16_t char mbstate_t>::do_out</char16_t>。
实操建议：
- 别碰
std::codecvt系列——它设计僵硬、locale 绑定脆弱、跨平台行为不一致 - Windows 下优先用系统 API
MultiByteToWideChar+WideCharToMultiByte，绕过 C++ 标准库编码设施 - Linux/macOS 下用
iconv库（POSIX 标准），稳定支持 UTF-8 ↔ GBK（实际是GB18030，兼容 GBK） - 若需纯 C++ 无外部依赖，可引入轻量级转换表（如
utf8cpp+ 自定义 GBK 映射），但仅适用于有限字符集
Windows 上用 WinAPI 实现 UTF-8 → GBK（推荐）
WinAPI 的 MultiByteToWideChar 和 WideCharToMultiByte 是最稳妥路径：UTF-8 先转为 wchar_t（UTF-16），再转为 GBK（CP936）。注意 Windows 中 GBK 即 CP936，不是严格意义上的 GBK，但日常完全等价。
关键点：
-
MultiByteToWideChar(CP_UTF8, ...)输入必须是合法 UTF-8，否则返回 0；可用IsValidUTF8预检（或用UTF8-CPP库验证） -
WideCharToMultiByte(CP936, ...)对无法映射的 Unicode 字符（如某些 emoji 或生僻汉字）默认替换为?，可通过传入WC_NO_BEST_FIT_CHARS改为失败返回 - 两次调用都需先用
0作为lpMultiByteStr/lpWideCharStr参数获取缓冲区大小，避免栈溢出
简例：
// UTF8str 是 const char*，len 是字节数 int wlen = MultiByteToWideChar(CP_UTF8, 0, UTF8str, len, nullptr, 0); if (wlen == 0) return false; std::vector<wchar_t> wbuf(wlen); MultiByteToWideChar(CP_UTF8, 0, UTF8str, len, wbuf.data(), wlen); <p>int gbklen = WideCharToMultiByte(CP936, 0, wbuf.data(), wlen, nullptr, 0, nullptr, nullptr); if (gbklen == 0) return false; std::vector<char> gbkbuf(gbklen); WideCharToMultiByte(CP936, 0, wbuf.data(), wlen, gbkbuf.data(), gbklen, nullptr, nullptr); </char></p></wchar_t>
Linux/macOS 用 iconv 实现 UTF-8 ↔ GBK
iconv 是 POSIX 标准接口，几乎所有 Linux 发行版和 macOS 自带，支持 "UTF-8" ↔ "GBK" 或更准确的 "GB18030"（后者是 GBK 超集，能覆盖全部 Unicode 字符）。
常见坑：
-
iconv_open("GBK", "UTF-8")在部分旧系统（如 CentOS 6）可能不识别"GBK"，改用"GB2312"（子集）或"GB18030"更稳妥 -
iconv输入/输出缓冲区必须可写，且需手动管理inbytesleft/outbytesleft，循环调用直到转换完成 - 遇到非法序列时默认中止，可设
//IGNORE后缀忽略（如"GBK//IGNORE"），但会丢失字符 - 不要假设
iconv返回值是目标长度——它返回的是成功转换的源字节数，目标长度需自己累计
简例（错误处理省略）：
iconv_t cd = iconv_open("GB18030", "UTF-8");
char *in = const_cast<char>(utf8_cstr);
size_t inleft = utf8_len;
std::vector<char> outbuf(4096);
char *out = outbuf.data();
size_t outleft = outbuf.size();
<p>while (inleft > 0 && iconv(cd, &in, &inleft, &out, &outleft) == (size_t)-1) {
if (errno == E2BIG) { /<em> 扩容重试 </em>/ }
}
iconv_close(cd);
</p></char></char>
跨平台封装要注意的边界情况
真正难的不是单次转换，而是统一处理不同平台下的语义差异：
- Windows 的
CP936和 Linux 的GB18030并不完全等价：前者缺少量扩展汉字，后者支持全部 Unicode；若数据需双向互通，建议全程用GB18030（Windows 也支持CP54936） - 空字符串、含嵌入
\0的字符串、超长字符串（>64KB）在各 API 中行为不同，务必单独测试 - 多线程下
iconv_t句柄非共享，每个线程应独立iconv_open；WinAPI 函数本身是线程安全的 - 不要把转换结果当
std::string直接printf("%s")输出到终端——终端编码可能不是 GBK，会显示乱码
最易被忽略的一点：GBK 是双字节编码，但并非所有两字节组合都是合法字符。转换后若出现孤立字节（如单个 0xA1），说明原始 UTF-8 有损坏或 API 调用参数错位，必须校验输入合法性而非依赖转换函数兜底。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
