Есть ли причина не использовать UTF-8, 16 и т. д. для всего?

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

Кроме того, как насчет программ для Windows, оболочки Linux и тому подобного - можете ли вы безопасно использовать там UTF-8?


person Joe Phillips    schedule 15.01.2011    source источник
comment
Для существующих протоколов, которые не поддерживают UTF-8, это хорошая причина не использовать UTF-8 :) Лично мне нравится поддерживать только кодировку UTF-8, поскольку она позволяет использовать символы Unicode, позволяя моей жизни вращаться вокруг символов ASCII. пробел (открывая содержимое UTF-16 в тупом редакторе, у меня глаза кровоточат).   -  person    schedule 15.01.2011
comment
@pst: Потому что это так красиво выглядит?   -  person dan04    schedule 15.01.2011


Ответы (3)


Если доступна UTF-32, предпочтите ее другим версиям для обработки.

Если ваша платформа изначально поддерживает Unicode UTF-32/UCS-4, то «сжатые» версии UTF-8 и UTF-16 могут работать медленнее, поскольку они используют разное количество байтов для каждого символа (последовательности символов), что делает невозможным выполнять прямой поиск в строке по индексу, в то время как UTF-32 использует 32-битные «плоские» значения для каждого символа, что значительно ускоряет некоторые строковые операции.

Конечно, если вы программируете в очень ограниченной среде, такой как, например, встроенные системы, и можете быть уверены, что вокруг будут только символы ASCII или ISO 8859-x, всегда, вы можете выбрать эти кодировки. для эффективности и скорости. Но в целом придерживайтесь форматов преобразования Unicode.

person foo    schedule 15.01.2011
comment
UTF-32 занимает в 4 раза больше места, чем ASCII (или UTF-8 при кодировании символов ASCII) для тех же данных. Это определенно может иметь значение. Кроме того, в отличие от устаревших наборов символов, таких как ISO-8859-* (и в отличие от UTF-8), у вас есть проблемы с порядком следования байтов с UTF-32 и UTF-16. - person dkarp; 15.01.2011
comment
@dkarp: вот почему я написал для обработки в первом предложении. Для хранения вы можете рассмотреть форматы хранения или сжатие, в зависимости от среды, скорости компонентов, частоты доступа к строкам и других факторов. Оптимизация редко проводится только по одному фактору. -- Но главный фактор, как я уже писал, это поддержка платформы. Windows, например, использовала UTF-16 для внутреннего использования, когда я последний раз смотрел, поэтому лучше использовать UTF-16, оставив оптимизацию операций со строками поставщику платформы/библиотеки. - person foo; 17.01.2011
comment
@foo Извините, но я не куплюсь на это. Если вы не хотите вводить данные в кодировке UTF-32 и не хотите выводить данные в кодировке UTF-32, а также не хотите хранить в памяти раздутые строки UTF-32, в чем выигрыш? UTF-32 — это даже не один символ/графема на 32 бита, это одна кодовая точка на 32 бита. Сочетание символов, каноническая эквивалентность, радость. Причина, по которой очень немногие платформы и приложения используют UTF- 32 -- преимущества, как правило, не перевешивают затраты. - person dkarp; 17.01.2011
comment
@dkarp: Вы правы в отношении разницы между кодовыми точками и символами; тем не менее, проблемы с различной длиной прогона сохраняются, включая аспекты скорости кэша/доступа. Итак, есть аргументы за и против. Вы также можете назвать UTF-16 раздутым с точки зрения кодировки UTF-8/8-Bit; тем не менее, многие производители платформ решили пойти с ним, вероятно, видя здесь лучший баланс компромиссов - Java делает это сейчас, Windows делает это сейчас, Mac OS делает, Qt и, возможно, еще несколько используют UTF-16. (Очевидно, принимая во внимание необходимость обработки порядка байтов). - person foo; 17.01.2011
comment
@dkarp: Но я видел Python в Linux с использованием UTF-32, и, как сообщается, раздувание незначительно, см. cmlenz.net/archives/2008/07/the-truth-about-unicode-in-python . Несколько других платформ *ix также предпочитают UTF-32. Итак, я возвращаюсь к тому, что писал ранее: используйте то, что предоставляет/предпочитает ваша платформа, при условии, что это представление Unicode. Вы не хотите писать Unicode самостоятельно. - person foo; 17.01.2011

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

UTF-8 хорошо работает почти со всеми современными программами, даже в Windows.

person Marc-François    schedule 15.01.2011
comment
Что ж, вы можете писать программное обеспечение на основе UTF-8 в Windows (я это сделал), но вам следует избегать таких функций, как fopen, которые принимают строку ANSI :-( - person dan04; 15.01.2011
comment
Какая? фопен? На каком языке? Говорил ли я, что невозможно написать программное обеспечение для Windows, основанное на UTF-8? Я не понимаю вашей точки зрения. Или, может быть, кто-то удалил свой комментарий. - person Marc-François; 15.01.2011

Хорошо известно, что utf-8 лучше всего подходит для хранения файлов и сетевого транспорта. Но люди спорят, лучше ли utf-16/32 для обработки. Одним из основных аргументов является то, что utf-16 по-прежнему имеет переменную длину, и даже utf-32 по-прежнему не является одной кодовой точкой на символ, так чем же они лучше, чем utf-8? Мое мнение, что utf-16 - очень хороший компромисс.

Во-первых, символы вне BMP, которым нужны двойные кодовые точки в utf-16, используются крайне редко. Китайские иероглифы (а также некоторые другие азиатские иероглифы) в этом диапазоне практически мертвы. Обычные люди вообще не будут их использовать, разве что специалисты используют их для оцифровки древних книг. Таким образом, utf-32 большую часть времени будет пустой тратой времени. Не беспокойтесь слишком об этих символах, так как они не испортят ваше программное обеспечение, если вы не обращались с ними должным образом, если ваше программное обеспечение не предназначено для этих особых пользователей.

Во-вторых, часто нам нужно, чтобы выделение строковой памяти было связано с количеством символов. например столбец строки базы данных для 10 символов (при условии, что мы храним строку Unicode в нормализованной форме), что будет 20 байтов для utf-16. В большинстве случаев он будет работать именно так, за исключением крайних случаев, он будет содержать только 5-8 символов. Но для utf-8 общая длина одного символа в байтах составляет 1-3 байта для западных языков и 3-5 для азиатских языков. Это означает, что нам нужно 10-50 байт даже для обычных случаев. Больше данных, больше обработки.

person Dudu    schedule 14.11.2011
comment
Я не согласен с Не слишком беспокойтесь об этих символах, так как они не испортят ваше программное обеспечение, если вы не обращались с ними должным образом. Сказать, что Моя программа использует/поддерживает UTF-16, когда вы имеете в виду, что Моя программа использует/поддерживает подмножество UTF-16, является либо неискренним, либо откровенной ложью. Ошибки — это одно; намеренное отсутствие поддержки всей UTF-16 не является ошибкой. - person Kevin; 27.07.2017