此韩语文本（quoted-printable）“2013-03-22 = 0E？@ HD = 0F 05:30”未被MultiByteToWideChar正确转换为Unicode。这里引用的可打印表单只是用于放置此文本，实际内容包含0xE和0xF字节。
MultiByteToWideChar(50225, 0, bs.pData, bs.nSize, pData + nSize, nConvertedLen);
= 0E？@ HD = 0F按原样转换，生成的Unicode包含0xE和0xF ASCII字符。但是，我发现有几个韩国字符应该出现在那里而不是这些字符。我一直认为国际字符序列以一个代码大于127的字节开头，但最近发现它不是真的。但是，MultiByteToWideChar仍然以我的方式思考并拒绝对待0xE？ @ H D 0xF作为50225（或949）代码页的几个非ASCII韩语字符。当我使用.NET函数（如Encoding.GetEncoding（50255）.GetString）在同一台计算机上执行相同操作时，我得到正确的转换结果，并且有韩语字符。但MultiByteToWideChar不起作用。我尝试了为MultiByteToWideChar（MB_COMPOSITE等）设置的不同标志，但仍然没有运气。
如何让MultiByteToWideChar正常工作？如果重要，我在WinXP SP3上。再一次，.NET方式工作正常，内部Encoding.GetString似乎调用MultiByteToWideChar。
答案 0 :(得分：3)
这是known issue。根本原因是在50225中使用SHIFT IN（0x0E）和SHIFT OUT（0x0F）不一致。它们不用作编码 shift 。
了解这些字节本身不是字符非常重要。代码页50225不是普通的多字节编码，例如， UTF-8。 UTF-8是无国籍的;相同的字节序列始终解码为相同的Unicode。 50255中字节序列的解码取决于先前消耗的字节，特别是0x0E和0x0F。
给出的建议很有意义。使用任何理智的Unicode编码。 （就个人而言，我建议使用UTF-8）。
答案 1 :(得分：0)
我建议使用IMultiLanguage::ConvertStringToUnicode代替suggested by Microsoft，而不是使用 MultiByteToWideChar ，而是正确解码字符。唯一的“缺点”是它需要Windows XP，其中MultiByteToWideChar可以在Windows 2000上运行。这不是一个巨大的下行IMO。
IMultiLanguage 还有一些其他工具可以简化编码转换，例如 IMultiLanguage :: GetCharsetInfo 或 IMultiLanguage :: EnumCodePages 。