C ++ кодирует строку в Unicode - библиотека ICU - PullRequest
Новая
       37

C ++ кодирует строку в Unicode - библиотека ICU

1 голос
/ 15 сентября 2010

Мне нужно преобразовать несколько байтов в ISO-2022-JP и ISO-2022-JP-2 (и других вариациях ISO-2022) в Unicode. Я пытаюсь использовать ICU ( текст ссылки ), но следующий код не работает. 

std::string input = "\x1B\x28\x4A" "ABC\xA6\xA7";    //the first 3 chars are escape sequence to use JIS_X201 character set in GL/GR
UErrorCode status = U_ZERO_ERROR;
UConverter *conv;
// set up the converter
conv = ucnv_open("ISO-2022-JP", &status);
if (status != U_ZERO_ERROR) return false;   //couldn't find character set

UChar * convDest = new UChar[2*input.length()]; //ucnv_toUChars will use up to 2*length

// convert to Unicode
int resultLen = (int)ucnv_toUChars(conv, convDest, 2*input.length(), input.c_str(), input.length(), &status);

Это не работает. Результат содержит '?' charcters для всего, что я положил в это выше ASCII. В статусе нет ошибок. Что я делаю не так?

Кроме того, у меня возникли проблемы при компиляции библиотеки версии 4.4, поскольку проект MSVC 9 не будет преобразован в проект MSVC 10.

Мне также известна библиотека с открытым исходным кодом libiconv. Я не мог скомпилировать это на окнах. Если у кого-нибудь есть какие-либо советы по поводу другой библиотеки, это тоже приветствуется.

Спасибо.

EDIT Последовательность побега, которую я первоначально использовал, была неправильной. Так что теперь ICU берет строку, удаляет escape-последовательность - это шаг в правильном направлении. Но результат все еще содержит «?» символы.

EDIT2 Причина, по которой я не смог перейти на проект MSVC 10, заключалась в том, что платформа x64 не была установлена ​​(она не установлена ​​по умолчанию). В качестве альтернативы я могу открыть все проекты в текстовом редакторе и удалить все упоминания о цели x64.

Ответы [ 3 ]

3 голосов
/ 16 сентября 2010

Это не похоже на кодировку ISO 2022.Предполагается, что старшие биты равны нулю.Экранирующая последовательность выглядит несколько узнаваемой, но начинается с ESC.0x1b, а не 0xb0.Понятия не имею, что на самом деле означают эти байтовые значения.

1 голос
/ 20 сентября 2010

Не удалось получить преобразование для работы для набора символов JIS_X201 в кодировке ISO-2022-JP.И я не смог сгенерировать «действительный», используя какие-либо инструменты в моем распоряжении - пробовал Java (ICU и не ICU реализация ISO2022) и C ++.

Так что я просто написал функцию для поиска кодаи преобразовать в Unicode, используя эту таблицу: wikipedia .

EDIT Когда я начал заполнять отчет об ошибке, я хотел включить RFC для ISO-2022-JP.Затем я нашел эту строку в RFC «Набор Kana JIS X 0201 не используется в сообщениях ISO-2022-JP». текст ссылки .Таким образом, похоже, что стандарт на самом деле не определяет старшие биты.ISO-2022-JP-3 будет отображать верхние биты, но в нижнюю плоскость.Поэтому мне нужно взять каждый байт и вычесть из него 0x80, передать его через ISO-2022-JP-3, взять остальные байты <128 и передать их через конвертер ISO-2022-JP для полного набора символов JIS_X201.Ну, намного проще сделать это самому. </p>

Строго говоря, я бы сказал, что это не ошибка.Хотя это огромная головная боль.

PS Весь перепутанный поток, который я пытаюсь декодировать, исходит от DICOM.См. pdf стр. 107, чтобы узнать, что они считают приемлемым.

1 голос
/ 16 сентября 2010

(Этот вопрос выглядит знакомым, снова привет.)

Незначительный, незначительный гнид: Вы хотите проверить состояние ошибки с помощью if(U_FAILURE(status)) (или наоборот, U_SUCCESS(status)).

...