Почему кто-либо использует кодирование кроме UTF-8? [закрытый]

Question

Почему кто-либо использует кодирование кроме UTF-8? [закрытый]

Вы можете следовать приведенному ниже коду, который работает для меня:

 var     loopStop = false;
YOUR_ARRAY.forEach(function loop(){
    if(loopStop){ return; }
    if(condition){ loopStop = true; }
});

36

encoding unicode utf-8

задан Welbog 29 July 2009 в 13:01

16 ответов

Другие вопросы по тегам:

encoding unicode utf-8

Похожие вопросы:

score 26 · Answer 1

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

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

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

score 0 · Answer 2

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

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

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

score 0 · Answer 3

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

score 0 · Answer 4

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

0

ответ дан 27 November 2019 в 05:33

score 5 · Answer 5

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

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

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

score 0 · Answer 6

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

score 4 · Answer 7

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

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

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

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

score 9 · Answer 8

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

score 8 · Answer 9

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

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

score 12 · Answer 10

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

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

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

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

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

¹ NT.

score 3 · Answer 11

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

score 3 · Answer 12

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 отходит от унификации из-за таких жалоб.

score 5 · Answer 13

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

Примеры:

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

score 5 · Answer 14

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

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

Допустим, у вас есть строка UTF-16.

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

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

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

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

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

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

score 2 · Answer 15

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

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

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

score 1 · Answer 16

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

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

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