Ответ 1
Если вы хотите поддерживать различные языки для веб-контента, вы должны использовать кодировку, охватывающую весь диапазон Unicode. Для этой цели лучшим вариантом является UTF-8. UTF-8 является предпочтительным кодированием для сети; от стандарт HTML5:
Авторы рекомендуют использовать UTF-8. Контроллеры соответствия могут рекомендовать авторам использовать устаревшие кодировки. [RFC3629]
Средства разработки должны по умолчанию использовать UTF-8 для вновь созданных документов. [RFC3629]
UTF-8 и Windows-1252 являются единственными кодировками, которые должны поддерживаться браузерами, а UTF-8 и UTF-16 являются единственными кодировками, которые должны поддерживаться синтаксическими анализаторами XML. Таким образом, UTF-8 является единственным распространенным кодированием, которое требуется для поддержки.
Ниже приведен более подробный ответ на ответ Лива, чем ответ сам по себе; это описание того, почему UTF-8 является предпочтительным для UTF-16 даже для содержимого CJK.
Для символов в диапазоне ASCII UTF-8 более компактен (1 байт против 2), чем UTF-16. Для символов между диапазоном ASCII и U + 07FF (который включает латинский расширенный, кириллический, греческий, арабский и иврит), UTF-8 также использует два байта на символ, так что это стирка. Для символов вне базовой многоязычной плоскости, как UTF-8, так и UTF-16 используют 4 байта на символ, поэтому там мыть.
Единственный диапазон, в котором UTF-16 более эффективен, чем UTF-8, предназначен для символов от U + 07FF до U + FFFF, который включает в себя указательные алфавиты и CJK. Даже для большого количества текста в этом диапазоне UTF-8 становится сравнимым, потому что разметка этого текста (HTML, XML, RTF или что у вас есть) находится в диапазоне ASCII, для которого UTF-8 - половина размер UTF-16.
Например, если я выбираю случайную веб-страницу на японском языке, домашнюю страницу nhk.or.jp, она кодируется в UTF-8. Если я перекодирую его в UTF-16, он будет почти в два раза больше его первоначального размера:
$ curl -o nhk.html 'http://www.nhk.or.jp/' $ iconv -f UTF-8 -t UTF-16 nhk.html > nhk.16.html $ ls -al nhk* -rw-r--r-- 1 lambda lambda 32416 Mar 13 13:06 nhk.16.html -rw-r--r-- 1 lambda lambda 18337 Mar 13 13:04 nhk.html
UTF-8 лучше почти во всех отношениях, чем UTF-16. Оба они представляют собой кодировки с переменной шириной, и поэтому имеют сложность, которая влечет за собой. В UTF-16, однако, 4 байтовых символа довольно необычны, поэтому гораздо легче сделать допущения фиксированной ширины и все работать до тех пор, пока вы не столкнетесь с поворотным футляром, который вы не поймали. Пример этой путаницы можно увидеть в кодировке CESU-8, которую вы получаете, если вы конвертируете текст UTF-16 в UTF-8, просто кодируя каждую половину суррогатной пары в виде отдельного символа (используя 6 байт на символ, три байта для кодирования каждой половины суррогатной пары в UTF-8) вместо декодирования пары к ее кодовой точке и кодирования ее в UTF-8. Эта путаница достаточно распространена, что ошибочное кодирование фактически стандартизировано, так что можно по крайней мере сломать программы для взаимодействия.
UTF-8 намного меньше, чем UTF-16 для подавляющего большинства контента, и если вы обеспокоены размером, сжатие вашего текста всегда будет лучше, чем просто выбор другой кодировки. UTF-8 совместим с API и структурами данных, которые используют последовательность байтов с нулевым завершением для представления строк, так что ваши API и структуры данных либо не заботятся о кодировании, либо уже могут обрабатывать разные кодировки в своих строках (например, как и большинство API-интерфейсов для обработки строк C и POSIX), UTF-8 может работать отлично, без необходимости иметь совершенно новый набор API и структур данных для широких символов. В UTF-16 не указывается конкретизация, поэтому вы решаете проблемы с контентом; на самом деле существует три разных связанных кодировки: UTF-16, UTF-16BE и UTF-16LE. UTF-16 может быть либо большим, либо бесконечным, и поэтому требуется спецификация спецификации. UTF-16BE и LE - это большие и малоразмерные версии, без спецификации, поэтому вам нужно использовать внеполосный метод (например, HTTP-заголовок Content-Type), чтобы сигнализировать, какой из них вы используете, но out- из-за того, что они ошибаются или отсутствуют.
UTF-16 - это, по сути, случайность, это произошло потому, что люди думали, что 16 бит будут достаточными для кодирования всего Юникода сначала, и поэтому начали менять свое представление и API для использования широких (16-разрядных) символов. Когда они поняли, что им понадобится больше символов, они придумали схему для использования некоторых зарезервированных символов для кодирования 32-битных значений с использованием двух кодовых блоков, поэтому они могли бы использовать те же структуры данных для новой кодировки. Это привело ко всем недостаткам кодирования с переменной шириной, например UTF-8, без большинства преимуществ.