Почему кто-то использует кодировку, отличную от UTF-8?

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

Ответ 1

В Википедии перечислены преимущества и недостатки UTF-8 по сравнению с другими кодировками:

http://en.wikipedia.org/wiki/UTF-8#Advantages_and_disadvantages

Наиболее важными недостатками являются ИМХО, что UTF-8 может значительно использовать больше пространства, особенно на азиатских языках, таких как китайский, японский или хинди, и что не все кодовые точки имеют одинаковый размер, что делает измерения более сложными, и многие строковые операции, такие как поиск, неэффективны.

Ответ 2

Ну, некоторые делают это, потому что их инструменты являются архаичными или ошибочными. Некоторые делают это, потому что они не видят необходимости поддерживать что-либо кроме ASCII. Некоторые делают это, потому что они не знают ничего лучше.

Это обычные оправдания за использование Unicode.

Что касается не использования UTF-8, в частности, существуют разные причины. Некоторые системы, такие как Windows ¹ (и вытекающие из этого,.NET) и Java, пришли в то время, когда Unicode был строгим 16-битным кодом. Таким образом, действительно существовала только одна кодировка: UCS-2, код кодирования непосредственно указывает на 16-разрядные слова.

Позднее Unicode был расширен до 21 бит, потому что 65536 кодовых пунктов было недостаточно. Это вызвало появление кодировок, таких как UTF-32 и UTF-16. Для систем, ранее работающих с UCS-2, переход на UTF-16 был самым простым и разумным выбором. Windows сделала этот переход в Ye Olde Days Windows 2000.

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

¹ NT.

Ответ 3

В UTF-8 кодовые точки между 0800 и FFFF занимают три байта в UTF-8, но только два в UTF-16. Подробнее см. сравнение по Википедии, но в основном, если текст сильно использует коды в этом диапазоне (скажем, если это китайский), файлы UTF-8 будет больше, чем файлы UTF-16 с тем же содержимым.

Ответ 4

UTF-8 очень эффективен при кодировании простого текста на английском языке (такой же, как ASCII). Если ваша пользовательская база, скорее всего, будет в основном, скажем, китайской, вам будет намного лучше использовать UTF-16.

Для получения дополнительной информации см. Абсолютный минимум Каждый разработчик программного обеспечения Абсолютно, положительно должен знать о юникоде и наборах символов.

Ответ 5

Иногда они ограничены из-за исторических/неподдерживаемых причин (я разрабатываю в Windows с помощью Zend Studio на share Samba в Linux-боксе: и что-то в этом миксе означает, что я продолжаю возвращаться к Cp1512 вместо UTF8).

Иногда вам не нужно использовать UTF-8 (например, при хранении хеша md5 в базе данных: вам нужен только шестнадцатеричный диапазон 0-9 AF: зачем делать это поле UTF-8, которое будет выполняться при меньше байтового дополнительного хранилища вместо обычного ASCII).

Иногда это просто лень, изучая функции UTF-8 для определенного языка.

Ответ 6

Потому что они не знают лучше. Единственная действительная критика для utf-8 заключается в том, что кодировки для обычных азиатских языков негабарит из других кодировок. UTF-8 превосходит, потому что

Совместим с ASCII. Наиболее известные и проверенные струнные операции не нуждаются в адаптации.
Это Юникод. Все, что не является Юникодом, не должно рассматриваться даже в этот день и возраст. Если у вас есть важные данные в кодировке X, потратьте две минуты на Google и напишите функцию преобразования. Даже если вам нужно взаимодействовать с непристойным устаревшим приложением Z, вы можете управлять своими сообщениями через трубу, чтобы ваша логика оставалась в 21 веке.
UTF-16 также не является фиксированной длиной, и если предположить, что он похож на многие, это вызовет только ужасные ошибки.
Кроме того, Unicode очень сложный и почти наверняка, чем любой алгоритм фиксированного размера, адаптированный из ASCII, даст плохие результаты даже в UTF-32.

Скажите, что у вас есть эта строка UTF-16.

[0][1][2][F|3] [4] [5]

И вы хотите вставить символ с кодом 8 между [3] и [4] вы бы вставляли (5,8)

Если вы не проверяете символы вне BMP (как в UTF-8, так как вы не можете знать, сколько у вас двухкратных символов), вы получаете:

[0][1][2][F|8][3][4][5]

Два новых символа мусора. Так много для вашей кодировки с фиксированным размером. Вы можете, конечно, вообще запретить такие символы, но тогда, когда ваш код взаимодействует с реальным миром, вы можете обнаружить, что ваша программа сохраняет профиль для этого пользователя, который живет в rm -Rf/in.profile вместо [Classical Chinese Proverb].profile.

Или просто сердитый пользователь, который не может написать свою диссертацию о классических китайских притчах с вашим программным обеспечением.

Ответ 7

Потому что за пределами англоязычного мира люди используют различные кодировки, которые предшествовали Unicode и рассчитаны на соответствующие языки на протяжении десятилетий. Эти кодировки, специфичные для языка, были укоренились повсюду и в значительной степени являются стандартом. Если вы хотите иметь какую-либо надежду на взаимодействие с устаревшими системами, вы должны их использовать, поэтому все системы должны поддерживать их и обычно использовать их по умолчанию, даже если они уже поддерживают UTF-8. Могут быть даже несколько устаревших кодировок, традиционно используемых для разных целей.

Примеры:

ISO-8859-1 в Западной Европе - фактически устаревший там, так как вам нужно ISO-8859-15 для знака Euro.
ISO-2022-JP в Японии для электронных писем, Shift JIS для веб-сайтов
Big5 в Тайване
GB2312 в Китае

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

Ответ 8

Одна из законных причин - когда вам нужно иметь дело с устаревшими документами, программным обеспечением или оборудованием, которые не совместимы с Unicode.

Другой законной причиной является то, что вам нужно использовать язык программирования/библиотеки, которые не поддерживают UTF8/Unicode... или вообще.

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

И, конечно, есть такие причины, как близорукость, невежество, лень... и сроки.

Ответ 9

Также стоит помнить, что в некоторых случаях (где требуется нелатинский набор символов) UTF-8 может на самом деле раздуваться больше, чем 16-битная кодировка Unicode. В этих случаях лучшим выбором будет ucs-2 или utf-16.

Ответ 10

http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/02/cjk-unicode-angst-in-japan-and.html содержит хорошие сводки + ссылки о трудностях, которые японские пользователи имеют с Unicode.

http://www.hastingsresearch.com/net/04-unicode-limitations.shtml

Очевидно, что Unicode отходит от унификации из-за таких жалоб.

Ответ 11

Причины использования 8-разрядных наборов символов/кодировок, отличных от Unicode, - это все совместимость какого-либо типа и/или инерция. В этом отношении наиболее частыми причинами использования UTF-8 являются совместимость со стандартами, такими как XML, которые определяют или предпочитают UTF-8.

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

При преобразовании устаревшего кода, который использовался 8-битовыми кодировками, отличными от Unicode, использование UTF-16 может быть инструментом для обеспечения того, чтобы весь код был преобразован, поскольку несоответствия могут быть обнаружены как ошибки типа компиляции. Многие языки, среды выполнения и библиотеки, такие как Javascript, JVM,.NET, ICU используют 16-битные строки и UTF-16, хотя протоколы хранения и Интернета обычно являются 8-разрядными.

Ответ 12

Связанный с объектом при использовании MySQL, как если бы он был недостаточно сложным, вы получаете возможность выбрать, какой тип сортировки UTF-8 вы хотите использовать. Итак, что бы вы использовали?

UTF-8 general ci или UTF-8 unicode ci?

(Я предпочитаю использовать вариант UTF-8, который используется для подключения к базе данных)

Ответ 13

Представьте, что все файлы, которые следует учитывать, приведены в GB2312 (стандарт континентальной Европы). Тогда вы можете выбрать GB18030 как кодировку Unicode. Они совместимы так же, как и все ASCII - UTF-8. Это полезно в материковой части Китая!

Вы можете решить еще быстрее, когда узнаете, что оба упомянутых стандарта GB требуются в вашем IT-продукте по закону (насколько я слышал), если вы хотите отправиться в Китай (материк).

Еще одна проблема заключается в том, что GB2312, а также GB18030 также совместимы с ASCII.

Это алгоритмически не очень надежный. - Если у вас нет политических причин или какого-либо наследия GB2312, нет смысла использовать его. Но если да, то здесь вы получили свой ответ.

Ответ 14

Поскольку вы иногда хотите легко работать с кодовыми точками - тогда вы выберете f.e. UCS-2 или UCS-4.

Ответ 15

Unicode, безусловно, является хорошим местом для работы в большинстве случаев, но разработчик должен быть знаком со многими различными типами кодировки символов. Конечно, ASCII может использоваться, если набор символов ограничен.

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

Статья Джоэля о обязательном знании для кодировки символов хороша и стоит прочитать.

Ответ 16

Многие API требуют других кодировок Unicode - в основном UTF-16. Например, Java,.NET, Win32.

Ответ 17

На моем предыдущем работодателе мы использовали iso-8859-1 для некоторых наших страниц ASP, чтобы соответствовать сортировке нашего SQL Server, который, как вы можете предположить, не был Unicode. Я хотел изменить сортировку, но менеджер сказал, чтобы дождаться, пока мы обновим наш SQL Server, чтобы сделать это. Само собой разумеется, этого никогда не было - я не был с ними чуть больше года, поэтому я не знаю, наконец ли это сделали.