Преобразование UTF-8 в UCS2 с использованием icu приводит к тарабарщине

Преобразование ICU дает вам правильные результаты, но вы не совсем знаете, что с ними делать, и успешно конвертируете их в тарабарщину. Вот то, что вы делаете неправильно, более или менее по порядку.

Один

Вы печатаете данные, отличные от Latin-1, в системе, которая (как показывают имеющиеся данные) изначально работает на Latin-1.

Это не так уж плохо, когда вы печатаете UTF-8, потому что UTF-8 разработан, чтобы не ломать вещи, которые работают с 8-битными символьными данными слишком сложно. Вы увидите тарабарщину, но, по крайней мере, вы увидите все свои данные и сможете преобразовать их обратно во что-то осмысленное.

UTF-16 (которая, кстати, заменила UCS-2 еще в 1996 году) не так хороша. Строка в кодировке UTF-16 содержит единицы кода длиной два байта. Любой из этих двух байтов вполне может быть равен нулю. (Все символы ASCII, закодированные как UTF-16, имеют нулевой байт). Пока другой байт не равен нулю, весь символ не равен NULL. Однако ваши printf, strlen и так далее не подозревают, это другой байт. Они думают, что вы кормите их латиницей-1, и они остановятся на первом нулевом байте (который они интерпретируют как символ NULL).

К счастью для вас, символ ĩ не имеет нулевого байта в кодировке UTF-16, так что на этот раз вам это сошло с рук.

Как это сделать правильно? Никогда не printf или fputs, а fwrite/std::ostream::write; никогда strcpy, всегда memcpy; никогда не strlen, но всегда держите длину под рукой в ​​отдельной переменной.

Два

Вы печатаете эти данные на экране.

Ваш экран может интерпретировать байты от (предположительно) от 0 до 31, и часто байты, которые следуют за ними, разными и интересными способами. Например, перемещение курсора, звуковой сигнал или изменение цвета текста. Вы печатаете данные UTF-16, которые могут иметь абсолютно любые байты в своей кодировке, даже если источник содержал совершенно обычные печатные символы Unicode. Так что может случиться все что угодно.

К счастью, единственный символ, который вы пытались преобразовать, не содержит вредоносных байтов в своем представлении UTF-16.

Как это сделать правильно? Если вам нужно напечатать что-то для быстрого просмотра, напечатайте шестнадцатеричные коды для всех или только непечатаемых символов.

 void print_bytes (FILE* fp, const unsigned char* s, int len,
                    bool escape_all) {
   // note: explicit length, *never* strlen!
   // note: unsigned char, you need it
   int i;
   for (i = 0; i < len; ++i, ++s)
   {
      if (escape_all || ! isprint(*s)) {
        fprintf ("\\x%02x", *s);
      } 
      else {
        fputc(*s, fp);
      }
   }
 }

Три

Вы ищете символы Latin-1, которые вы получили на своем экране, в файле info и, таким образом, интерпретируете их, как если бы они были символами Unicode, а затем берете их 16-битные коды символов (один 16-битный код на каждый символ) и интерпретируете их. как если бы они были байтами.

Не нужно много говорить об этом. Просто не делай этого. У вас есть функция, которая печатает байты в удобочитаемом шестнадцатеричном представлении. Используй это. В качестве альтернативы используйте любое количество свободно доступных программ, которые отображают или даже позволяют редактировать такое представление.

Это, конечно, не означает, что вы не должны использовать fileinfo. Делайте это правильно, что в основном означает знание вашей кодировки и того, как любая данная кодировка символа отличается (хотя иногда и похожа) на его кодовую точку Unicode.

Четыре

Этот абзац не об ошибках как таковых, а скорее об интуиции разработчика (или ее отсутствии), которая не соответствует ни одному из опубликованных вами кодов.

Несмотря на все вышеперечисленные ошибки, вам удалось получить почти хорошие данные. У вас есть 00 во всех четных местах, что может означать, что что-то не так с размером вашего целого числа в битах, и вам нужно избавиться от этих нулей. После этого у вас останется FFFE в качестве первых двух байтов, которые вы должны были распознать как спецификацию. Вы подозреваете, что у вас есть проблема с порядком байтов, но вы не пытались решить ее, изменив вариант UTF-16 (UTF-16LE против UTF-16BE).

Это то, что любой разработчик Unicode должен уметь применять почти инстинктивно.

Юникод большой и сложный, намного сложнее, чем думает большинство людей. Это только самое начало самого начала.

Предложите улучшения для этого ответа.