Существует ли существенная разница между UTF-8 и UTF-16

Я вызываю веб-сервис, который возвращает мне ответ xml с кодировкой UTF-8. Я проверил это в java с помощью метода getAllHeaders().

Теперь, в моем java-коде, я беру этот ответ, а затем выполняю некоторую обработку. И позже передайте его другой службе.

Теперь я немного искал googled и узнал, что по умолчанию кодировка в Java для строк - UTF-16.

В моем ответе xml один из элементов имел символ É. Теперь это было ввернуто в запрос последующей обработки, который я делаю для другой службы.

Вместо отправки É, он отправил некоторые вещи. Теперь я хотел бы знать, будет ли действительно большая разница в двух этих кодировках? И если бы я хотел знать, что будет конвертировать из UTF-8 в UTF-16, то как я могу это сделать?

Спасибо

Ответы

Ответ 1

Оба UTF-8 и UTF-16 являются кодировками переменной длины. Однако в UTF-8 символ может занимать минимум 8 бит, тогда как в UTF-16 длина символа начинается с 16 бит.

Основные профили UTF-8:

  • Основные символы ASCII, такие как цифры, латинские символы без акценты и т.д. занимают один байт, который идентичен US-ASCII представление. Таким образом, все строки US-ASCII становятся действительными UTF-8, который обеспечивает достойную обратную совместимость во многих случаях.
  • Нет нулевых байтов, что позволяет использовать строки с нулевым завершением, это вводит большую обратную совместимость.

Основные UTF-8 минусы:

  • Многие общие символы имеют разную длину, что замедляет индексирование и ужасно исчисляем длину строки.

Основные профили UTF-16:

  • Наиболее разумные персонажи, такие как латинский, кириллический, китайский, японский может быть представлено 2 байтами. Если действительно экзотические персонажи это означает, что 16-битное подмножество UTF-16 может использоваться как кодирование с фиксированной длиной, которое ускоряет индексирование.

Основные UTF-16 минусы:

  • Множество нулевых байтов в строках US-ASCII, что означает, что нет нулевые строки и много потерянной памяти.

В общем, UTF-16 обычно лучше для представления в памяти, в то время как UTF-8 чрезвычайно хорош для текстовых файлов и сетевого протокола

Ответ 2

Есть две вещи:

  • кодировка, в которой вы обмениваетесь данными;
  • внутреннее строковое представление Java.

Вы не должны быть заняты второй точкой;) Дело в том, чтобы использовать соответствующие методы для преобразования из ваших данных (массивы байтов) в String (char массивы в конечном счете) и для преобразования формы String к вашим данным.

Самые основные классы, о которых вы можете подумать, CharsetDecoder и CharsetEncoder. Но есть много других. String.getBytes(), все Reader и Writer являются всего лишь двумя возможными способами. И есть все статические методы Character.

Если вы видите тарабарщину в какой-то момент, это означает, что вы не смогли декодировать или кодировать исходные данные байта в строки Java. Но опять же, факт, что строки Java используют UTF-16, здесь не уместен.

В частности, вы должны знать, что при создании Reader или Writer необходимо указать кодировку; если вы этого не сделаете, будет использоваться кодировка JVM по умолчанию, и она может быть или не быть UTF-8.

Ответ 3

Этот веб-сайт предоставляет UTF TO UTF Conversion

http://www.fileformat.info/convert/text/utf2utf.htm

UTF-32, возможно, является наиболее удобочитаемым для всех кодировок в кодировке Unicode, потому что его шестизначное шестнадцатеричное представление представляет собой просто скалярное значение Unicode без префикса "U +" и с нулевым числом до восьми цифр, а UTF- 32 делает модель программирования несколько более простой, увеличенный средний размер хранилища имеет реальные недостатки, делая полный переход на UTF-32 менее убедительным.

ОДНАКО

UTF-32 аналогичен старой кодировке UCS-4 и остается фиксированной. Почему это может оставаться фиксированной шириной? Поскольку UTF-16 теперь является форматом, который может кодировать наименьшее количество символов, он устанавливает лимит для всех форматов. Было определено, что 1,112,064 - это общее количество кодовых точек, которые когда-либо будут определяться либо Unicode, либо ISO 10646. Поскольку Unicode теперь определяется только от 0 до 10FFFF, UTF-32 звучит немного как бессмысленная кодировка сейчас, поскольку она 32-битная, но используется только около 21 бит, что делает это очень расточительным.