我正在使用IMultilanguage2 :: ConvertStringFromUnicode从UTF-16转换。对于某些语言（日语，中文，韩语），我得到一个转义序列（例如0x1B, 0x24, 0x29, 0x43代码页50225（ISO-2022韩语））。 WideCharToMultiByte表现出相同的行为。
我正在构建MIME消息，因此编码在标头本身中指定，并且转义前缀按原样显示。
有没有一种方法可以在没有前缀的情况下进行转换？
谢谢！
答案 0 :(得分：2)
我真的没有看到这里的问题。这是ISO 2022中的有效字节序列：
指定字符集的转义序列采用 ESC I [ I ... ] F 的形式，其中有一个或多个来自0x20-0x2F范围的中间 I 字节，以及来自0x40-0x7F范围的最终 F 字节。 （范围0x30-0x3F保留用于专用 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编码标头中的字符集。但是ISO 2022解码器仍然必须能够在解码时动态切换字符集，因此数据包含朝向字符集的初始切换序列是有效的。
有没有一种方法可以在没有前缀的情况下进行转换？
不在IMultiLanguage2和WideCharToMultiByte()，没有。他们不知道你将如何使用他们的输出，所以它们为什么包含一个初始切换序列到韩国字符集是有道理的 - 所以无法访问MIME（或其他来源）的字符集信息的解码器仍然知道什么字符集到最初使用。
将数据放入MIME邮件时，在将MIME邮箱设置为iso-2022-kr时，必须手动删除字符集切换顺序。如果您不想手动剥离它，则必须找到（或写入）不输出该初始切换顺序的Unicode编码器。
答案 1 :(得分：1)
那是一只红鲱鱼 - 结果表明转义序列 是必要的。问题在于我的代码使用Trim（）Delphi函数修剪名称和地址，该函数修剪小于或等于空格（0x20）的所有字符;包括转义字符（0x1B）。
切换到我自己的修剪功能，只删除修复问题的空格。