MultiByteToWideChar无法识别某些韩语字符

此韩文文本（quoted-printable）“2013-03-22 = 0E？@ HD = 0F 05:30”未正确地被MultiByteToWideChar转换为Unicode。这里引用的可打印格式仅用于放置此文本，实际内容包含0xE和0xF字节。MultiByteToWideChar无法识别某些韩语字符

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。

来源

2013-04-09 Alex

这是一个known issue。根本原因是50225中SHIFT IN（0x0E）和SHIFT OUT（0x0F）的不一致使用。它们不用作编码转换。

理解这些字节本身不是字符很重要。代码页50225不是普通的多字节编码，例如， UTF-8。 UTF-8是无状态的;相同的字节序列总是解码为相同的Unicode。 50255中的字节序列的解码取决于先前消耗的字节，特别是0x0E和0x0F。

给出的建议很有意义。使用任何理智的Unicode编码。（我个人建议UTF-8）。

来源

2013-08-20 07:41:26 MSalters

而不是使用的MultiByteToWideChar我建议使用IMultiLanguage::ConvertStringToUnicode代替，这是suggested by Microsoft并正确解码的字符。唯一的“缺点”是它需要MultiByteToWideChar在Windows 2000上工作的Windows XP。不是一个巨大的缺点IMO。

IMultiLanguage也有一些其他的工具，使编码的转换更容易，例如IMultiLanguage :: GetCharsetInfo或IMultiLanguage :: EnumCodePages。

来源

2015-09-02 13:13:08 Coder12345

MultiByteToWideChar无法识别某些韩语字符

回答

相关问题