这段韩文"2013-03-22 = 0 e ?@HD=0F 05:30"不能被MultiByteToWideChar正确转换为Unicode。此处引用的可打印形式只是用于放置此文本，实际内容包含0xE和0xF字节。
MultiByteToWideChar(50225, 0, bs.pData, bs.nSize, pData + nSize, nConvertedLen);
= 0 e ?@HD=0F按原样转换，生成的Unicode包含0xE和0xF ASCII字符。然而，我发现应该出现几个韩文字符，而不是这些字符。我一直认为国际字符序列以代码大于127的字节开始，但最近发现事实并非如此。然而，MultiByteToWideChar仍然认为我所做的方式，并拒绝处理0xE ?@ dh 0xF作为50225(或949)代码页的一对非ascii韩文字符。当我在同一台计算机上使用. net函数(如Encoding.GetEncoding(50255). getstring)执行相同操作时，我得到了正确的转换结果，并且那里有韩文字符。但是MultiByteToWideChar不起作用。我尝试了不同的标志，你可以设置MultiByteToWideChar (MB_COMPOSITE等)，但仍然没有运气。
如何让MultiByteToWideChar正常工作?如果有关系的话，我用的是WinXP SP3。再一次，. net的方式工作得很好，内部编码。GetString似乎调用MultiByteToWideChar
这是一个已知问题。根本原因是50225中SHIFT IN (0x0E)和SHIFT OUT (0x0F)的使用不一致。它们不用于编码移位。
重要的是要理解这些字节本身不是字符。代码页50225不是普通的多字节编码，例如UTF-8。UTF-8是无状态的;相同的字节序列总是解码为相同的Unicode。50255中字节序列的解码取决于先前消耗的字节，特别是0x0E和0x0F。
给出的建议很有意义。使用任何统一的Unicode编码。(我个人建议使用UTF-8)。
而不是使用MultiByteToWideChar我建议使用multilanguage::ConvertStringToUnicode来代替，这是微软建议的，可以正确解码字符。唯一的"缺点"是它需要Windows XP，而MultiByteToWideChar可以在Windows 2000上工作。在我看来，这并不是一个很大的缺点。
IMultiLanguage也有一些其他的工具，使编码转换更容易，如IMultiLanguage::GetCharsetInfo或IMultiLanguage:: enumcopages 。