Я действительно не вижу проблемы здесь. Это действует последовательность байт в ISO 2022:
Escape-последовательности для обозначения набора символов принимают форму ESC Я [я ...] F, где есть один или более промежуточный I байтов из диапазона 0x20-0x2F и конечного байта F из диапазона 0x40-0x7F. (Диапазон 0x30-0x3F зарезервирован для частного использования F байт.) Байт I определяет тип набора символов и рабочий набор, к которому он предназначен, а байт F идентифицирует набор символов сам.
...
Код: ESC $) F
Hex: 1B 24 29 F
Abbr: G1DM4
Имя: G1 Назначенный многобайтовая 94-набор F
Эффект: выбирает 94n- набор символов, который будет использоваться для G1.
В Р является 0x43 (С), эта последовательность байт указывает декодер, чтобы переключиться на ISO-2022-KR:
Кодировка символов с использованием ISO/IEC 2022 механизм включают в себя:
. ..
ISO-2022-KR. Кодировка для корейского языка.
ESC $) C, чтобы перейти к KS X 1001-1992, ранее названный KS C 5601-1987 (2 байта на символ) [обозначается G1,]
В этом случае, вы должны указать в качестве iso-2022-kr charset в MIME Content-Type или RFC2047 -кодированный заголовок. Но декодер ISO 2022 по-прежнему должен иметь возможность переключать кодировки динамически при декодировании, поэтому для данных необходимо включить интуитивную последовательность переключения в корейскую кодировку.
Есть ли способ конвертировать без префикса?
Не с IMultiLanguage2 и WideCharToMultiByte(), no.Они не имеют понятия, как вы собираетесь использовать их выход, поэтому имеет смысл, почему они включают начальную последовательность переключения в корейскую кодировку - поэтому декодер, не имеющий доступа к информации о кодировке из MIME (или другого источника), все равно будет знать, какая кодировка для использовать первоначально.
Когда вы помещаете данные в сообщение MIME, вам придется вручную отключить последовательность переключателей набора символов, когда вы установите кодировку MIME на iso-2022-kr. Если вы не хотите разбить его вручную, вам придется найти (или написать) кодер Unicode, который не выводит эту начальную последовательность переключения.
В чем проблема? Если это то, что API возвращает, то это то, что ваша строка ввода Unicode действительно конвертируется в ISO-2022 Korean. Вы должны указать 'charset = iso-2022-kr' в заголовке MIME' Content-Type'. –
Проблема в том, что префикс не нужен. Если я использую Outlook (IConverterSession) для создания MIME-файла, значение заголовка MIME (To) точно совпадает с моим минусом префикса 4 байта. Как Outlook, так и мой код указывают «iso-2022-kr» в значении заголовка. Я могу удалить префикс (список возможных префиксов можно найти, например, по адресу http://www.opensource.apple.com/source/ICU/ICU-491.11.3/icuSources/common/ucnv_ct.c), но я бы предпочел, чтобы IMultiLanguage выполнял эту работу. –
Независимо от того, требуется ли это * или нет, он по-прежнему * действителен * по ISO 2022. Если Outlook не может правильно его обработать, Outlook нарушен. –