2

MultiByteToWideChar 无法将这个韩文文本（引用打印）“2013-03-22 =0E?@HD=0F 05:30”正确转换为 Unicode。此处引用可打印的形式只是为了将这段文字放在这里，实际内容包含0xE和0xF字节。

MultiByteToWideChar(50225, 0, bs.pData, bs.nSize, pData + nSize, nConvertedLen);

=0E?@HD=0F 按原样转换，生成的 Unicode 包含 0xE 和 0xF ASCII 字符。但是，我发现那里应该出现几个韩文字符而不是这些字符。我一直认为国际字符序列以代码大于 127 的字节开头，但最近发现它不是真的。但是， MultiByteToWideChar 仍然认为我的方式并拒绝对待 0xE ？@ HD 0xF 作为 50225（或 949）代码页的几个非 ASCII 韩语字符。当我使用 .NET 函数（如 Encoding.GetEncoding(50255).GetString）在同一台计算机上执行相同操作时，我得到正确的转换结果并且韩语字符在那里。但是 MultiByteToWideChar 不起作用。我尝试了可以​​为 MultiByteToWideChar（MB_COMPOSITE 等）设置的不同标志，但仍然没有运气。

如何让 MultiByteToWideChar 正常工作？如果重要的话，我在 WinXP SP3 上。同样，.NET 方式运行良好，并且在内部 Encoding.GetString 似乎调用了 MultiByteToWideChar。

4

2 回答 2

3

这是一个已知问题。根本原因是 50225 中SHIFT IN(0x0E) 和SHIFT OUT(0x0F) 的使用不一致。它们不用作编码移位。

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

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

于 2013-08-20T07:41:26.770 回答
0

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

IMul​​tiLanguage还有一些其他工具可以使编码转换更容易，例如IMultiLanguage::GetCharsetInfo或IMultiLanguage::EnumCodePages。

于 2015-09-02T13:13:08.913 回答