Windows平台解析Big5编码最稳妥方式是调用MultiByteToWideChar(950,0,...)，因其无需额外依赖且准确；不可用CP_UTF8或CP_ACP强行读取，否则因编码不兼容导致乱码或非法字符。
直接用 MultiByteToWideChar + CP_BIG5 解析 Big5 编码，是 Windows 平台最稳妥、无需额外依赖的方式。
为什么不能直接当 UTF-8 或 GBK 处理
Big5 是固定双字节编码，但和 GBK/GB2312 不兼容：同一字节序列在 Big5 和 GBK 下可能解出完全不同的字，甚至非法字符。常见错误是把 Big5 文件用 CP_UTF8 或 CP_ACP（即 GBK）强行读取，结果出现乱码或 ? 占位符。
- Big5 的有效字节范围是
0x81–0xFE（高位）+0x40–0x7E或0xA1–0xFE（低位），而 GBK 的高位是0x81–0xFE、低位是0x40–0xFE（但排除0x7F），两者重叠区域极少 - Windows 系统里没有原生的
CP_BIG5宏定义（老版本 SDK 可能缺失），需手动定义为950 - Linux/macOS 下无
MultiByteToWideChar，必须换用iconv或opencc，但那是另一套路径
Windows 下解析 Big5 字符串为宽字符
核心就是调用 MultiByteToWideChar，指定代码页 950。注意它只做编码转换，不涉及简繁体语义映射——Big5 字符串转成 wchar_t 后，仍是繁体字形，只是变成 Unicode 码点。
- 先调用一次获取目标缓冲区长度：
MultiByteToWideChar(950, 0, pszBig5, -1, NULL, 0) - 分配
wchar_t缓冲区（长度单位是wchar_t个数，不是字节） - 再调用第二次完成转换：
MultiByteToWideChar(950, 0, pszBig5, -1, wszOut, nLen) - 如果返回值为 0，说明输入含非法 Big5 序列，可检查
GetLastError()是否为ERROR_NO_UNICODE_TRANSLATION
从 Big5 文件读取并解析的典型流程
文件操作本身不关心编码，关键在读入后的解码时机。不要用 fgets + CP_ACP，而应二进制读取后显式解码。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 用
fopen(..., "rb")打开文件，避免文本模式自动换行转换干扰字节流 - 用
fread读入原始字节到char*缓冲区，确保末尾补\0（MultiByteToWideChar需要 null-terminated 输入） - 确认缓冲区内容确实是 Big5 编码——比如开头几个字节符合 Big5 范围（如
0xA4 0x40是「丂」），否则后续全错 - 转换完成后，
wchar_t*可安全用于std::wstring、Win32 API（如SetWindowTextW）等宽字符接口
跨平台方案的现实约束
如果项目必须支持 Linux/macOS，MultiByteToWideChar 不可用，此时得切到 iconv：
- Linux 下：用
iconv_open("UTF-32LE", "BIG5")，注意目标编码选UTF-32LE才能对齐wchar_t（多数系统sizeof(wchar_t) == 4） - macOS 下：
iconv默认不支持BIG5，需安装libiconv并链接-liconv，且调用前确认iconv -l | grep -i big5输出存在 - 更轻量的选择是封装
opencc，但它只处理 Unicode 文本，不解决 Big5 → Unicode 解码问题——你得先用iconv或其他方式把 Big5 转成 UTF-8，再喂给opencc
真正容易被忽略的是：Big5 编码本身不带 BOM，也没有任何元信息标识自己是 Big5；判断编码类型只能靠统计分析或业务约定。一旦误判，整个解析链就崩了。
