MultiByteToWideChar не распознает некоторые корейские символы

Этот корейский текст (в кавычках) «2013-03-22 =0E?@HD=0F 05:30» не преобразуется должным образом MultiByteToWideChar в Unicode. Цитатно-печатная форма здесь предназначена только для размещения здесь этого текста, фактическое содержимое содержит байты 0xE и 0xF.

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

=0E?@HD=0F преобразуется как есть, и результирующий Unicode содержит символы ASCII 0xE и 0xF. Однако я обнаружил, что вместо этих символов там должна появиться пара корейских символов. Я всегда думал, что международные последовательности символов начинаются с байта с кодом больше 127, но недавно обнаружил, что это не так. Однако MultiByteToWideChar по-прежнему думает так же, как и я, и отказывается обрабатывать 0xE ? @ HD 0xF как пара корейских символов, отличных от ASCII, кодовой страницы 50225 (или 949). Когда я делаю то же самое на том же компьютере, используя функции .NET (например, Encoding.GetEncoding(50255).GetString), я правильно получаю результаты преобразования и корейские символы. Но MultiByteToWideChar не работает. Я пробовал разные флаги, которые вы можете установить для MultiByteToWideChar (MB_COMPOSITE и т. д.), но все равно не повезло.

Как заставить MultiByteToWideChar работать правильно? Если это имеет значение, я на WinXP SP3. Опять же, способ .NET работает нормально, и внутренне Encoding.GetString, похоже, вызывает MultiByteToWideChar.


windows winapi character-encoding multibyte-functions
person Alex    schedule 09.04.2013    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Это известная проблема. Основной причиной является непоследовательное использование SHIFT IN (0x0E) и SHIFT OUT (0x0F) в 50225. Они не используются для кодирования сдвигов.

Важно понимать, что эти байты сами по себе не являются символами. Кодовая страница 50225 — это не обычная многобайтовая кодировка, как, например. УТФ-8. UTF-8 не имеет состояния; одна и та же последовательность байтов всегда декодируется в один и тот же Unicode. Декодирование последовательности байтов в 50255 зависит от байтов, использованных ранее, в частности 0x0E и 0x0F.

Данные советы имеют большой смысл. Используйте любую разумную кодировку Unicode. (Лично я бы посоветовал UTF-8).

person MSalters    schedule 20.08.2013

arrow_upward
0
arrow_downward

Вместо использования MultiByteToWideChar я предлагаю использовать IMultiLanguage::ConvertStringToUnicode, что предложено Microsoft и правильно декодирует символы. Единственным «недостатком» является то, что для этого требуется Windows XP, где MultiByteToWideChar работает в Windows 2000. Не огромный недостаток IMO.

IMultiLanguage также имеет некоторые другие инструменты для упрощения преобразования кодировки, такие как IMultiLanguage::GetCharsetInfo или IMultiLanguage::EnumCodePages.

person Coder12345    schedule 02.09.2015