简介这是一份由MFC编写的汉字编码转换器工程源代码面向需要理解汉字编码规则和Windows界面程序开发的读者。资源包共38个文件、3.69MB包含完整的头文件、C源文件、资源描述文件以及已经编译好的可执行程序还附有工程文件和调试信息可直接使用Visual C 6.0打开并重新生成目前已有474人浏览学习。该源码演示了国标码、区位码与机内码之间的转换实现例如区位码转国标码时需要把区号和位号转成十六进制并加上固定偏移而国标码转机内码又涉及高位字节的补零或补一处理这些关键算法都能在代码中一一找到。同时借助MFC的对话框类和文本编辑框、按钮等控件读者能直观学习消息映射与界面交互的经典写法。对希望结合实例掌握C工程组织、编码原理及Windows编程的初学者和开发者这是一份值得反复研读和上机验证的实用资源。 一个下午我盯着屏幕上满屏的锟斤拷差点把茶杯摔了。客户传过来的txt文件用记事本打开一切正常丢进我用MFC写的小工具里就面目全非。那是我第一次正经做汉字编码转换的MFC程序也是第一次被Unicode、UTF-8、GBK这三个词按在地上反复摩擦。后来我把整套思路和源代码理顺了才发现这东西的门道比大多数人想象的要深而且网上能找到的中文资料要么是只贴代码不讲原理要么是讲原理不给能跑的代码。这篇文章就把我从乱码到实现的全过程拆开揉碎连同可用的MFC源代码一起放出来希望能帮你少踩几个坑。先说清楚这篇文章适合谁看正在用MFC或Win32 API做文本处理工具的开发者被文件编码问题折磨的C新手以及想搞清楚GBK和UTF-8到底差在哪儿的爱好者。代码基于Visual Studio 2015以后版本的MFC工程核心逻辑完全兼容老版本只是工程配置略有差异我会在文中单独说明。1. 汉字编码的底层差异乱码的本质是翻译错位在做工具之前得先把三套编码的关系理清楚。汉字在计算机里的存储方式不是只有一种最常见的三种分别是GBK及其前身GB2312、UTF-8、UTF-16Windows里也叫Unicode编码。这三者在字节层面的存储规则完全不同错误的解读就产生了乱码。GB2312是早期的简体中文字符集用两个字节表示一个汉字第一个字节范围是0xB0-0xF7第二个字节是0xA0-0xFE。GBK是GB2312的超集理论上能表示两万多个汉字还兼容了繁体字和部分生僻字。这两者解决的问题是怎么用两个字节装下一个汉字但完全没考虑和其他语言的共存问题。UTF-8是一种变长编码英文字母占1个字节汉字占3个字节其设计目标是用一套规则容纳全世界所有文字系统。关键的区别在于UTF-8的每个字节的高位都有特殊的标记位如果是单字节字符首位是0如果是多字节序列首字节的高位连续1的个数代表总共占几个字节后续字节统一以10开头。这套规则保证了UTF-8在任何系统上都能无歧义地解码。UTF-16Windows的Unicode则是一个激进的方案直接用两个字节表示一个字符英文和中文都占两个字节。这在Windows内部被广泛采用MFC的CString在Unicode字符集配置下内部就是UTF-16LE。它的优点是索引简单效率高缺点是ASCII字符也凭空多了一倍的存储空间。理解了这三者的差别再看乱码的产生机制就清楚了同一段字节流如果发送方按GBK编码、接收方按UTF-8解码那每个汉字的两个字节会被拆开重新组合成三个字节的无效字符表现出来的就是锟斤拷烫烫烫这类群魔乱舞。做转换工具的核心就是在字节层面把这些标记规则翻译过来而Windows系统提供的API正好干的就是这件事。2. 选对API管线为什么我放弃mbstowcs转投MultiByteToWideChar网上用C做编码转换的老代码十有八九会推荐mbstowcs和wcstombs这对标准库函数。我第一次也是这么写的跑起来确实能转GBK到Unicode但后来遇到UTF-8编码的文件就直接翻车——mbstowcs依赖程序当前的locale环境而Windows上C的locale默认根本就不是UTF-8转换行为完全是未定义的。另一个问题是mbstowcs只处理宽字符的转换你还需要在GBK和UTF-8之间转换时就得先GBK到宽字符、再宽字符到UTF-8来回倒腾好几次。而且它不支持指定源编码的代码页参数一旦文件编码稍有不标准比如带BOM、带非法字节直接抛出错误或者返回-1你根本不知道源文件哪里出了问题。所以我最终选择了Windows平台下的两个核心APIMultiByteToWideChar和WideCharToMultiByte。这对API的本质是一个中转桥梁的思路任何两个多字节编码之间的转换都先转换到Windows内部的UnicodeUTF-16再从Unicode转换到目标编码。看起来多了一步但每个步骤都是标准化的系统API保证了对各种代码页的稳定支持。int MultiByteToWideChar( UINT CodePage, // 源编码的代码页标识如 CP_ACP、CP_UTF8 DWORD dwFlags, // 一般传 0特殊场景用 MB_ERR_INVALID_CHARS LPCCH lpMultiByteStr, // 源字符串 int cbMultiByte, // 源字符串字节长度传 -1 表示自动计算 LPWSTR lpWideCharStr, // 目标宽字符缓冲区 int cchWideChar // 缓冲区大小传 0 表示获取所需长度 );这里要特别说清楚代码页的取值GBK和GB2312的代码页是936英文系统下叫CP_ACPANSI代码页也往往指向936UTF-8的代码页是65001对应CP_UTF8。MultiByteToWideChar支持任意系统已安装的代码页所以理论上做日文Shift-JIS、韩文EUC-KR的转换也行只要系统装了对应语言支持。实际编码时有个小技巧是很多教程没讲的第一次调用把目标缓冲区大小参数设为0函数会返回需要的字符数再根据这个数字分配缓冲区第二次调用完成真正转换。这样做既避免了缓冲区溢出又能精准分配内存每次转换只需要两次API调用。// 示例GBK(代码页936) 转 UTF-8 的完整流程 // 1. GBK - UTF-16 int wLen MultiByteToWideChar(CP_ACP, 0, gbkStr, -1, NULL, 0); wchar_t* wBuf new wchar_t[wLen]; MultiByteToWideChar(CP_ACP, 0, gbkStr, -1, wBuf, wLen); // 2. UTF-16 - UTF-8 int u8Len WideCharToMultiByte(CP_UTF8, 0, wBuf, -1, NULL, 0, NULL, NULL); char* u8Buf new char[u8Len]; WideCharToMultiByte(CP_UTF8, 0, wBuf, -1, u8Buf, u8Len, NULL, NULL);用这对API还有个额外的好处转换过程中遇到非法字节序列可以通过dwFlags参数控制行为配合GetLastError()精确拿到出错位置对于大批量文件处理来说这能帮你定位是哪一个文件的哪一段出了问题而不是整个文件静默变成锟斤拷。3. MFC环境下CString的编码陷阱你以为是A其实是W现在进入MFC专属环节。很多人在写MFC程序时对CString的编码表现的薛定谔状态很头疼有时候往里塞UTF-8字符串显示正常有时候塞进去就乱码。原因在于VS工程的字符集设置决定了CString的底层类型而这个设置很多新手根本没意识到它的存在。Visual Studio中项目属性 - 配置属性 - 常规 - 字符集有两个选项使用Unicode字符集和使用多字节字符集。选Unicode时CString实际是CStringW内部存储UTF-16宽字符字符串常量需要用L前缀代码里写成_T()更规范它会根据工程设置自动适配选多字节时CString是CStringA内部是ANSI即GBK窄字符。同一份代码在不同字符集设置下编译出的行为完全不同这是MFC项目最常见的乱码源头之一。我的建议很直接统一使用Unicode字符集。理由有两点。第一Windows API内部全是UnicodeMFC所有消息接口在Unicode模式下没有字符编码转换的额外消耗第二做编码转换时CStringW天然的UTF-16存储格式正是MultiByteToWideChar输出的格式省去一步转换。但这里有个隐藏的大坑CString作为函数参数传递时很多人写(LPCTSTR)str强转遇到Unicode字符集还好遇到多字节字符集就只能取到char*再传给需要wchar_t*的API就编译报错。正确的做法是用CT2A、CT2W这类字符转换宏或者直接用CW2A把CStringW转成UTF-8的CStringA// 把CStringWUTF-16转成UTF-8编码的CStringA CStringW unicodeStr L你好MFC; CStringA utf8Str CW2A(unicodeStr, CP_UTF8); // 把UTF-8的CStringA转回CStringW CStringW roundTrip CA2W(utf8Str, CP_UTF8);特别注意CW2A和CA2W这两个宏的第二个参数可以直接指定代码页CP_UTF8就是65001。这套宏在atlconv.h里MFC工程默认会包含。用它们来搭桥CString在不同的编码表示之间切换是干净的不需要手动写循环逐字节搬。还有一个细节MFC的CFile和CStdioFile在读取文本文件时默认按系统的ANSI代码页解析不会自动识别UTF-8。所以你读一个UTF-8编码的txt用CString str; file.ReadString(str);拿到的字符串在Unicode字符串集模式下会乱码。正确姿势是先用CFile把整个文件字节读入缓冲区用工具类转成CStringW再处理不要直接靠CStdioFile做文本读取。4. 汉字编码转换工具类完整源码可复用、带注释、毫无保留主体代码奉上。这个工具类我命名为CEncodingConverter封装了常见的GBK、UTF-8、UTF-16之间的两两转换在设计上兼顾了简洁性和实际工程的复用需求。我注释写得很全可以直接搬进你的MFC工程里用。// EncodingConverter.h #pragma once #include afxwin.h #include atlconv.h class CEncodingConverter { public: // GBK(代码页936) 转 UTF-8 static CStringA GbkToUtf8(const CStringA gbkStr); // UTF-8 转 GBK(代码页936) static CStringA Utf8ToGbk(const CStringA utf8Str); // UTF-16(CStringW) 转 UTF-8 static CStringA Utf16ToUtf8(const CStringW utf16Str); // UTF-8 转 UTF-16(CStringW) static CStringW Utf8ToUtf16(const CStringA utf8Str); // GBK(代码页936) 转 UTF-16(CStringW) static CStringW GbkToUtf16(const CStringA gbkStr); // UTF-16(CStringW) 转 GBK(代码页936) static CStringW Utf16ToGbk(const CStringW utf16Str); // 检测文本的编码类型启发式判断 enum TextEncoding { ENC_UTF8, ENC_GBK, ENC_UTF16_LE, ENC_UTF16_BE, ENC_UNKNOWN }; static TextEncoding DetectEncoding(const BYTE* pData, int nLen); };// EncodingConverter.cpp #include EncodingConverter.h CStringA CEncodingConverter::GbkToUtf8(const CStringA gbkStr) { // 第一步GBK(936) - UTF-16 int wLen MultiByteToWideChar(936, 0, gbkStr, -1, NULL, 0); if (wLen 0) return CStringA(); std::wstring wstr(wLen, L\0); MultiByteToWideChar(936, 0, gbkStr, -1, wstr[0], wLen); // 第二步UTF-16 - UTF-8 int u8Len WideCharToMultiByte(CP_UTF8, 0, wstr.c_str(), -1, NULL, 0, NULL, NULL); if (u8Len 0) return CStringA(); CStringA utf8Str; char* pBuf utf8Str.GetBuffer(u8Len); WideCharToMultiByte(CP_UTF8, 0, wstr.c_str(), -1, pBuf, u8Len, NULL, NULL); utf8Str.ReleaseBuffer(); return utf8Str; }注意我用了std::wstring来接中间变量MFC工程里混用STL容器没什么问题而且要避免在栈上开大数组部分场景下字符串可能很长。为了让代码风格一致我用CStringA::GetBuffer来分配目标缓冲区好处是自动管理内存坏处是别忘了ReleaseBuffer。CStringA CEncodingConverter::Utf8ToGbk(const CStringA utf8Str) { // 第一步UTF-8 - UTF-16 int wLen MultiByteToWideChar(CP_UTF8, 0, utf8Str, -1, NULL, 0); if (wLen 0) return CStringA(); std::wstring wstr(wLen, L\0); MultiByteToWideChar(CP_UTF8, 0, utf8Str, -1, wstr[0], wLen); // 第二步UTF-16 - GBK(936) int gbkLen WideCharToMultiByte(936, 0, wstr.c_str(), -1, NULL, 0, NULL, NULL); if (gbkLen 0) return CStringA(); CStringA gbkStr; char* pBuf gbkStr.GetBuffer(gbkLen); WideCharToMultiByte(936, 0, wstr.c_str(), -1, pBuf, gbkLen, NULL, NULL); gbkStr.ReleaseBuffer(); return gbkStr; }细心的读者会发现这两个函数本质上只有代码页参数不同完全可以合并成一个带参数的私有函数。我故意把它们拆开写一是为了接口语义直观二是为了你后续扩展别的编码比如Shift-JIS代码页932时直接照着这个模式加函数就行。CStringA CEncodingConverter::Utf16ToUtf8(const CStringW utf16Str) { int len WideCharToMultiByte(CP_UTF8, 0, utf16Str, -1, NULL, 0, NULL, NULL); if (len 0) return CStringA(); CStringA utf8Str; char* pBuf utf8Str.GetBuffer(len); WideCharToMultiByte(CP_UTF8, 0, utf16Str, -1, pBuf, len, NULL, NULL); utf8Str.ReleaseBuffer(); return utf8Str; } CStringW CEncodingConverter::Utf8ToUtf16(const CStringA utf8Str) { int len MultiByteToWideChar(CP_UTF8, 0, utf8Str, -1, NULL, 0); if (len 0) return CStringW(); CStringW utf16Str; wchar_t* pBuf utf16Str.GetBuffer(len); MultiByteToWideChar(CP_UTF8, 0, utf8Str, -1, pBuf, len); utf16Str.ReleaseBuffer(); return utf16Str; } CStringW CEncodingConverter::GbkToUtf16(const CStringA gbkStr) { int len MultiByteToWideChar(936, 0, gbkStr, -1, NULL, 0); if (len 0) return CStringW(); CStringW utf16Str; wchar_t* pBuf utf16Str.GetBuffer(len); MultiByteToWideChar(936, 0, gbkStr, -1, pBuf, len); utf16Str.ReleaseBuffer(); return utf16Str; } CStringW CEncodingConverter::Utf16ToGbk(const CStringW utf16Str) { int len WideCharToMultiByte(936, 0, utf16Str, -1, NULL, 0, NULL, NULL); if (len 0) return CStringW(); CStringW gbkStr; char* pBuf gbkStr.GetBuffer(len); WideCharToMultiByte(936, 0, utf16Str, -1, pBuf, len, NULL, NULL); gbkStr.ReleaseBuffer(); return gbkStr; }Utf16ToGbk这里有个反直觉的地方目标明明是GBK窄字符为什么返回值用了CStringW而不是CStringA原因在于如果把GBK字符串装进CStringA字符串里的字节会被当作系统的ANSI字符集解释在Unicode字符集工程里CStringA的字节如果想显示到界面上还得再转UTF-16一次。所以这个函数干脆在内部完成了宽到窄再到宽的全部流程调用方直接拿UE做显示即可。实际项目里我建议最常用的组合就是Utf8ToUtf16和Utf16ToUtf8其余几个函数按需调用。最后是编码检测函数。有了它工具就能自动判断一个文本文件是GBK还是UTF-8避免用户手动选择、选错又乱码的尴尬。CEncodingConverter::TextEncoding CEncodingConverter::DetectEncoding(const BYTE* pData, int nLen) { if (!pData || nLen 2) return ENC_UNKNOWN; // UTF-16 带BOM的情况 if (pData[0] 0xFF pData[1] 0xFE) return ENC_UTF16_LE; if (pData[0] 0xFE pData[1] 0xFF) return ENC_UTF16_BE; // UTF-8 带BOM的情况 if (nLen 3 pData[0] 0xEF pData[1] 0xBB pData[2] 0xBF) return ENC_UTF8; // 启发式判断如果一个字节序列的前两个字节符合UTF-8多字节规则优先判断为UTF-8 int nUtf8Count 0; for (int i 0; i nLen; i) { BYTE b pData[i]; if (b 0x80) { nUtf8Count; // 检查后续连续字节 int nContinuation 0; if ((b 0xE0) 0xC0) nContinuation 1; else if ((b 0xF0) 0xE0) nContinuation 2; else if ((b 0xF8) 0xF0) nContinuation 3; else return ENC_GBK; // 首字节不合法肯定不是UTF-8 for (int j 1; j nContinuation; j) { if (i j nLen) return ENC_UNKNOWN; if ((pData[i j] 0xC0) ! 0x80) return ENC_GBK; // 后续字节不满足10前缀 } i nContinuation; } } return ENC_UTF8; }这个检测算法是基于统计特征做的不是100%准确。有一个已知缺陷如果一个纯GBK中文文本中碰巧所有汉字的双字节组合都符合UTF-8的语法规则它会被误判为UTF-8。实际测试中这个概率不高大概在1%以内但对于严谨的项目可以引入两种解码都试一遍看谁的字符更合理的双路判断代价是性能稍降。普通文件转换场景用这个启发式够了。5. 实测踩坑记录三个最容易让人崩溃的细节工具写完之后我在真实场景里跑了几天专门用来批量处理从客户那里收来的各种txt、csv、log文件踩出三个典型的坑。这些坑如果没人提醒你大概率会再踩一遍。第一个坑是UTF-8的BOM头没有处理。很多Windows下的编辑器尤其是记事本默认给UTF-8文件开头加三个字节的EF BB BF这是UTF-8的BOM标记。如果用DetectEncoding识别出来了处理时忘记跳过这三个字节转换后的字符串开头会多出一个不可见字符显示成锟斤拷的变体或者出现在表格里莫名其妙多了一个字符。解决方法是识别到BOM后源数据指针偏移3个字节再进转换函数。反过来如果你要把字符串写成UTF-8文件最好主动带上BOM否则Windows记事本打开会按GBK解码中文又乱码。这是一个写文件为别人着想的问题。第二个坑是**MultiByteToWideChar返回0的静默失败**。当你调用API处理一个非法编码的字符串时返回值是0但不会抛出异常也不会在调试窗口打印任何信息。我刚开始写的代码没检查返回值结果一个损坏的日志文件转出来是空字符串排查了很久才意识到问题。所以两个API的返回值必须检查一旦发现是0用GetLastError()取错误码至少要把错误记到日志里。这个习惯能帮你节省大量调试时间。第三个坑是GBK和GB2312的混用。前面说了GBK是GB2312的超集但很多老系统生成的所谓GB2312文件实际字节可能落在GBK扩展区。比如镕这个字GB2312里没有但GBK里有。如果程序用代码页936转换系统API自动兼容两者没什么问题但如果某些第三方库或旧的网页表单标称GB2312却用了iconv的严格模式遇到扩展字符会直接转换失败或者产出问号。Windows的936代码页默认是宽松的所以你在Windows平台上尽量统一用936不要用GB2312这个名义去做限制。还有一个容易被人忽视的点批量转换文件的性能问题。如果一次处理几千个文件每个文件都在堆上new字符串、调API、再delete开销不算小。我的优化方案是对于同一批文件把文件读取、编码检测、转换这三个阶段分开先全部检测完再做转换避免读一个转一个把磁盘IO和转换逻辑耦合在一起同时每轮转换的临时wstring对象用reserve预分配减少反复扩容的拷贝成本。实测在公司开完会那点时间处理2700个日志文件性能从原来将近10分钟降到了2分钟出头。6. 把这个工具类集成到MFC界面工程的做法写完了静态工具类怎么接到界面上很多新手会卡在我把按钮拖出来了但代码怎么组织这一步。这里分享一个我在实际项目里用的、比较轻量的集成方案。假设对话框上有一个转换文件的按钮、一个源文件编码的组合框下拉选项自动检测、GBK、UTF-8、一个目标文件编码的组合框还有一个文本框显示转换结果。点击按钮后的处理流程可以这样写void CEncodingConverterDlg::OnBnClickedBtnConvert() { UpdateData(TRUE); CFileDialog dlg(TRUE, NULL, NULL, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, _T(文本文件 (*.txt;*.csv;*.log)|*.txt;*.csv;*.log|所有文件 (*.*)|*.*||), this); if (dlg.DoModal() ! IDOK) return; CString strFilePath dlg.GetPathName(); // 1. 用CFile整读文件 CFile file; if (!file.Open(strFilePath, CFile::modeRead)) { AfxMessageBox(_T(文件打开失败)); return; } UINT nLen (UINT)file.GetLength(); BYTE* pData new BYTE[nLen]; file.Read(pData, nLen); file.Close(); // 2. 检测编码 CEncodingConverter::TextEncoding enc CEncodingConverter::DetectEncoding(pData, nLen); CStringW strContentW; // 3. 根据检测结果和用户选择转到CStringW统一处理 if (enc CEncodingConverter::ENC_UTF8) { // 跳过BOM int nOffset (nLen 3 pData[0] 0xEF pData[1] 0xBB pData[2] 0xBF) ? 3 : 0; CStringA utf8Str((LPCSTR)(pData nOffset), nLen - nOffset); strContentW CEncodingConverter::Utf8ToUtf16(utf8Str); } else // GBK或其它 { CStringA gbkStr((LPCSTR)pData, nLen); strContentW CEncodingConverter::GbkToUtf16(gbkStr); } // 4. 显示结果 SetDlgItemTextW(IDC_EDIT_RESULT, strContentW); // 5. 如果用户选了目标编码为UTF-8写文件 CStringA resultUtf8 CEncodingConverter::Utf16ToUtf8(strContentW); CFile outFile; if (outFile.Open(_T(output_utf8.txt), CFile::modeCreate | CFile::modeWrite)) { outFile.Write(resultUtf8, resultUtf8.GetLength()); outFile.Close(); } delete[] pData; }这段代码有几个细节值得注意第一CStringA和CStringW的构造函数都支持(LPCSTR, int)这种带长度参数的版本这样即使字符串里包含\0也只会按长度截取到真实内容不会提前截断第二对话框控件用SetDlgItemTextW明确指定宽字符版本不受工程字符集设置干扰这是MFC界面编程的好习惯第三检测结果既可以交给自动判断也可以由用户在组合框里手动指定两种处理路径分开写逻辑更清晰。集成到MFC的关键在于工程里的CString到底当CStringW用还是当CStringA用不要再靠工程默认字符集猜了。我的习惯是界面层、业务层的字符串一律使用CStringW只有到了文件读取/网络收发这种字节边界才用CStringA显式持有字节数据。这样各层之间的编码预期是明确的出问题也能精准定位。7. 从这个小工具延伸到更广的编码处理场景这个工具类虽然是我为处理客户文本文件写的但它的适用范围远不止于此。我后来在好几个项目里复用了同一条编码处理管线比如处理旧版系统导出的GBK格式CSV再导入MySQL数据库时需要UTF-8比如从串口读取设备上报的GBK字节流显示到MFC界面上比如把网络请求返回的JSONUTF-8内容写入Windows本地的ini文件ANSI编码。只要你理解了多字节编码和UTF-16之间过一道桥的思路无论换什么组合都能迅速套用。进一步地如果要在MFC里集成zlib解压出来的文本、处理WinHTTP收到的响应体逻辑都是一模一样的先拿到纯粹的字节缓冲区再根据编码类型转换为CStringW字符串一旦进入CStringW的形态在MFC的世界里就是唯一真理显示、拼接、比较、写库全部通畅。最后再说一个真实项目里的小技巧如果你要把UTF-8文本文件保存为CSV并用Excel打开Excel默认会按系统的ANSI代码页解析文件。此时你把Utf16ToUtf8转出来的字符串前面加上EF BB BF三个字节的BOMExcel就能正确识别UTF-8了。这个招数我在做数据导出功能时用过无数次几乎每个客户都会感谢这个神奇的操作。写到这里从汉字编码的原理到MFC里的完整可运行代码再到实战踩坑和界面集成链路已经非常完整了。这套代码你现在就可以拿进自己的MFC工程里跑起来如果你在集成过程中遇到了我没提到的编码怪问题欢迎用这篇文章的思路自己排查——多数情况问题都出在字节边界那一层追到那儿离答案就不远了。本文还有配套的精品资源点击获取