我正在使用IMultilanguage2::ConvertStringFromUnicode从UTF-16进行转换。对于某些语言(日语,中文,韩语),我得到了转义序列(例如,代码页50225的0x1B, 0x24, 0x29, 0x43
(ISO-2022韩语))。 WideCharToMultiByte表现出相同的行为。
我正在构建MIME消息,因此在 header 本身中指定了编码,并且转义前缀按原样显示。
有没有没有前缀的转换方法?
谢谢!
最佳答案
我真的没有在这里看到问题。那是ISO 2022中的有效字节序列:
用于指定字符集的转义序列采用 ESC I [...] F 的形式,其中存在一个或多个0x20–0x2F范围内的中间I字节,以及最后一个0x40–0x7F范围内的F字节。 (0x30–0x3F范围保留供 private 使用的F字节。)I字节标识字符集的类型及其要指定的工作集,而F字节标识字符集本身。
...
代号:ESC $)F
十六进制:1B 24 29 F
缩写:G1DM4
名称:G1指定多字节94组F
效果:选择用于G1的94n个字符集。
当F为0x43(C)时,此字节序列告诉解码器切换至ISO-2022-KR:
使用ISO / IEC 2022机制的字符编码包括:
...
ISO-2022-KR。朝鲜语编码。
ESC $)C 切换到KS X 1001-1992,以前称为KS C 5601-1987(每个字符2个字节)[指定为G1]
在这种情况下,您必须将iso-2022-kr
指定为MIME Content-Type
或RFC2047编码的 header 中的字符集。但是,ISO 2022解码器仍然必须能够在解码时动态切换字符集,因此对于数据而言,包含对韩国字符集的初始切换序列是有效的。
有没有没有前缀的转换方法?
不支持IMultiLanguage2
和WideCharToMultiByte()
,不可以。他们不知道您将如何使用它们的输出,因此它们为什么包括向朝鲜字符集的初始切换序列很有意义-因此无法访问MIME(或其他来源)的字符集信息的解码器仍会知道要使用什么字符集最初使用。
将数据放入MIME消息时,将MIME字符集设置为iso-2022-kr
时,必须手动剥离字符集切换序列。如果不想手动剥离它,则必须找到(或编写)不输出该初始开关序列的Unicode编码器。