Windows下最可靠的UTF-8转GBK方案是用MultiByteToWideChar(CP_UTF8, ...)转UTF-16，再用WideCharToMultiByte(936, ...)转GBK；必须避免CP_ACP、std::codecvt_utf8（已弃用）及未校验缓冲区大小等常见错误。
Windows下用MultiByteToWideChar + WideCharToMultiByte转码最可靠
直接用标准库或第三方库（如iconv）在Windows上容易出乱码，根本原因是Windows默认不把UTF-8当“本地编码”处理，std::codecvt_utf8已弃用，且std::text_encoding尚未普及。必须走Windows API双步转换：UTF-8 → UTF-16（宽字符）→ GBK。
关键点：
-
MultiByteToWideChar(CP_UTF8, ...)把UTF-8字节流安全转成wchar_t字符串，这是唯一被Windows完全支持的UTF-8输入入口 -
WideCharToMultiByte(936, ...)中936是GBK的代码页，不能写CP_ACP——后者在中文系统虽常为936，但不可靠（比如用户改过区域设置） - 两个API都需传入
NULL先试探缓冲区大小，再分配内存，否则易缓冲区溢出
别用std::wstring_convert和std::codecvt_utf8
这两个在C++17已被标记为deprecated，VS2019起默认禁用，GCC/Clang也早不推荐。即使强制启用，std::codecvt_utf8对GBK无原生支持，强行绑定std::codecvt_byname("zh-CN")在不同平台行为不一致，且无法处理BOM、非法UTF-8序列等边界情况。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 输入含中文emoji（如"?"）时崩溃或截断——
codecvt内部没做UTF-8校验 - 转出的GBK字节末尾多出0x3F（'?'）——非法字节被静默替换，但没重算长度
- Linux/macOS编译失败——
codecvt在libstdc++中早已移除
跨平台方案：用iconv时注意//IGNORE和//TRANSLIT标志
Linux/macOS下iconv是事实标准，但默认遇到无法映射字符（如UTF-8里的「?」在GBK无对应字）会返回错误。必须显式加转换标志：
-
"UTF-8//IGNORE"：跳过无法转换的字符（适合日志、路径等容错场景） -
"UTF-8//TRANSLIT"：尝试音近字替换（如「é」→「e」），但GBK不支持此特性，实际无效 - 务必检查
iconv()返回值：返回(size_t)-1且errno == EILSEQ表示遇到非法UTF-8，不是转码失败
示例关键调用：
iconv_t cd = iconv_open("GBK", "UTF-8//IGNORE");注意iconv_open参数顺序是(to, from)，反了就白忙活。
输出到文件或控制台前，确认目标环境真需要GBK
很多场景其实不需要硬转GBK：Windows终端（如Windows Terminal）默认支持UTF-8；记事本打开UTF-8文件只要带BOM就能正确识别；现代数据库（MySQL 8.0+、PostgreSQL）默认用UTF-8通信。强行转GBK反而引入风险：
- GBK无法表示Unicode私有区、补充平面字符（如大部分emoji），转完变"???"
- 同一段文本在不同GBK实现（如GB2312 vs GB18030）下结果可能不同
- 转码后若再用
strlen计算长度，会得到字节数而非字符数，后续substr等操作易越界
真正绕不开GBK的场景只剩：对接老旧Windows API（如CreateFileA）、写入必须用GBK的Excel CSV、或维护十几年前的MFC程序——这些地方才值得投入双API转换逻辑。
