Насколько распространен UTF-8?

Насколько широко распространено использование UTF-8 для текста, отличного от английского, на WWW или в противном случае? Меня интересуют как статистические данные, так и ситуация в конкретных странах.

Я знаю, что ISO-8859-1 (или 15) прочно укоренился в Германии - но как насчет языков, где вам все равно нужно использовать многобайтовые кодировки, например, в Японии или Китае? Я знаю, что несколько лет назад Япония по-прежнему использовала различные кодировки JIS почти исключительно.

Учитывая эти наблюдения, было бы даже правдой, что UTF-8 является наиболее распространенной многобайтовой кодировкой? Или было бы правильнее сказать, что он в основном используется только в новых приложениях, специально предназначенных для международного рынка и/или для работы с многоязычными текстами? В настоящее время приемлемо иметь приложение, которое ТОЛЬКО использует UTF-8 в своем выпуске, или каждый национальный рынок ожидает, что выходные файлы будут отличаться от старой кодировки, чтобы использоваться другими приложениями.

Edit: Я не спрашиваю, полезен ли UTF-8 или как он работает. Я все это знаю. Я спрашиваю, действительно ли он широко применяется и заменяет старые кодировки.

ОТВЕТЫ

Ответ 2

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

Итак, я бы поставил БОЛЬШОЕ голосование за использование UTF-8 всюду и все время!:-) Я предполагаю, что в сервис-ориентированном мире и в средах .NET и Java это действительно не проблема или потенциальная проблема.

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

Марк

Ответ 3

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

Хорошей новостью является то, что если вы исходите из ситуации в Германии, где у вас в основном есть 8859-1/15 и ASCII, дополнительно принимая 8859-1 и конвертируя ее в UTF-8, в основном нулевая стоимость. Легко обнаружить: использование 8859-1-кодированных ö или ü недопустимо, например, UTF-8, даже не попадая в легко обнаруживаемые недопустимые пары. Использование символов 128-159 вряд ли будет действительным 8859-1. В нескольких байтах вашего первого старшего байта вы, как правило, можете получить очень и очень хорошее представление о том, какая кодировка используется. И как только вы знаете кодировку, будь то по спецификации или угадыванию, вам не нужна таблица трансляции для преобразования 8859-1 в Unicode - U + 0080 до U + 00FF точно такие же, как 0x80-0xFF в 8859-1.

Ответ 4

В настоящее время приемлемо иметь приложение, которое ТОЛЬКО использует UTF-8 в своем или каждый национальный рынок ожидать, что выходные файлы будут различные устаревшие кодировки, чтобы могут использоваться другими приложениями.

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

Mac OS X широко использует UTF-8, и это кодировка по умолчанию для файлов пользователей, и это имеет место и в большинстве (всех?) основных дистрибутивов Linux. Но в Windows... есть Windows-1252 (близкий, но не такой же, как ISO-8859-1) по-прежнему кодировка по умолчанию для многих языков? По крайней мере, в Windows XP это было, но я не уверен, что это изменилось? В любом случае, пока значительное число (в основном Windows) пользователей имеют файлы на своих компьютерах, закодированные в Windows-1252 (или что-то близкое к этому), поддержка UTF-8 приведет только к печали и путанице для многих.

Информация о конкретной стране: в Финляндии ISO-8859-1 (или 15) также все еще прочно укоренилась. Например, финские каналы IRC используют, afaik, по-прежнему в основном Latin-1. (Это означает, что ребята из Linux с UTF-8 как системные по умолчанию с использованием текстовых клиентов (например, irssi) должны выполнить некоторые обходные методы/настройки настройки.)

Ответ 5

Я часто посещаю сайты Runet. Многие из них по-прежнему используют Windows-1251 кодировку. Также это кодировка по умолчанию в Yandex Mail и Mail.ru(две крупнейшие службы электронной почты в странах СНГ). Он также устанавливается как кодировка содержимого по умолчанию в браузере Opera (второй после Firefox по популярности в регионе), когда вы загружаете его с русского IP-адреса. Однако я не совсем уверен в других браузерах.

Причина этого довольно проста: UTF-8 требует двух байтов для кодирования кириллических букв. Для кодирования без юникода требуется только 1 байт (в отличие от большинства восточных алфавитов кириллицы довольно малы). Они также имеют фиксированную длину и легко обрабатываются старыми инструментами ASCII.

Ответ 6

Пользователи символов CJK подвержены ошибкам UTF-8, естественно, потому что их символы становятся 3 байтами вместо двух. Очевидно, что в Китае предпочтение отдается их собственному 2-байтовому кодированию GBK, а не UTF-16.

Изменить в ответ на этот комментарий @Joshua:

И получается, что для большинства веб-страниц страницы будут меньше в UTF-8, так как символы HTML и javascript теперь кодируются в один байт.

Ответ:

Кодировки GB. + и другие восточноазиатские кодировки являются кодировками переменной длины. Байты со значениями до 0x7F отображаются в основном в ASCII (с небольшими вариациями). Некоторые байты с высоким набором бит представляют собой байты с байтами последовательностей от 2 до 4 байтов, а другие являются незаконными. Также как UTF-8.

Поскольку "символы HTML и javascript" также являются символами ASCII, они ВСЕГДА были 1 байт, как в этих кодировках, так и в UTF-8.

Ответ 7

Вот некоторые статистические данные, которые я смог найти:

  • Эта страница показывает статистику использования кодировок символов на "верхних сайтах".
  • Эта страница является еще одним примером.

Обе эти страницы, похоже, страдают от значительных проблем:

  • Неясно, насколько репрезентативны их выборки, особенно для стран, не говорящих по-английски.
  • Неясно, какие методологии использовались для сбора статистики. Они подсчитывают страницы или количество обращений к страницам? Как насчет загружаемого/загруженного контента.

Более важно то, что статистика предназначена только для контента, доступного в Интернете. Более широкая статистика (например, для кодирования документов на жестких дисках пользователя) не представляется доступной. (Это меня не удивляет, учитывая, насколько сложным/дорогостоящим было бы проведение исследований, необходимых во многих странах.)

Короче говоря, ваш вопрос не несет объективной ответственности. Возможно, вы сможете найти какие-то исследования о том, как "приемлемое" приложение только для UTF-8 может быть в определенных странах, но я не смог его найти.

Для меня отмена заключается в том, что было бы неплохо написать ваши приложения для агностики кодирования символов и позволить пользователю решить, какую кодировку символов использовать для хранения документов. Это относительно легко сделать на современных языках, таких как Java и С#.

Ответ 8

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

Это делает его отличным выбором в качестве формата обмена, но поскольку символы кодируются для разных байтов (от одного до четырех байтов на символ), работать с ними не всегда очень приятно. Поэтому, как правило, чистнее резервировать UTF-8 для обмена данными и использовать преобразование в точках входа и выхода.

Для системного внутреннего хранилища (включая файлы на диске и базы данных), вероятно, более чистым является использование собственного UTF-16, UTF-16 с некоторым другим сжатием или некоторой 8-разрядной кодировкой "ANSI" . Последнее, конечно, ограничивает вас определенной кодовой страницей, и вы можете пострадать, если работаете с многоязычным текстом. Для обработки данных локально вам, вероятно, понадобится кодировка "ANSI" или собственный UTF-16. Обработка символов становится гораздо более простой проблемой.

Поэтому я бы предположил, что UTF-8 популярен извне, но реже внутри. Внутренне UTF-8 кажется кошмаром для работы, кроме статических текстовых блоков.

Некоторые СУБД, похоже, все время сохраняют текстовые капли как UTF-8. Это дает преимущество сжатия (при хранении UTF-16), не пытаясь разработать еще одну схему сжатия. Поскольку преобразование в/из UTF-8 настолько распространено, вероятно, они используют системные библиотеки, которые, как известно, работают эффективно и надежно.

Самые большие проблемы с схемами "ANSI" связаны с одним небольшим набором символов и требуют обработки многобайтовых последовательностей символов для языков с большими алфавитами.

Ответ 9

В то время как он специально не затрагивает вопрос - UTF-8 является единственной кодировкой символов, обязательной для реализации во всех протоколах IETF-треков.

http://www.ietf.org/rfc/rfc2277.txt

Ответ 10

Вам может быть интересен этот вопрос. Я пытался создать CW для поддержки Unicode на разных языках.

Ответ 11

Меня интересуют как статистические данных и ситуации в конкретных страны.

В W3Techs мы имеем все эти данные, но, возможно, нелегко найти:

Например, вы получаете распределение кодировки символов на японских сайтах, сначала выбрав язык: Языки контентa > Японский, а затем выберите Сегментация > Кодировки символов. Это приведет вас к этому отчету: Распределение кодировок символов среди сайтов, использующих японский язык. Вы видите: японские сайты используют 49% SHIFT-JIS и 38% UTF-8. Вы можете сделать то же самое на домен верхнего уровня, скажем все .jp-сайты.

Ответ 12

Как Java, так и С# используют UTF-16 внутренне и могут легко перевести на другие кодировки; они довольно хорошо укоренились в корпоративном мире.

Я бы сказал, что принимать только UTF в качестве входных данных не так уж и важно в наши дни; Действуй.

Ответ 13

Меня интересуют как статистические данных и ситуации в конкретных страны.

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

Если вы создаете приложение, для которого все ваши конкуренты выводятся, например, ISO-8859-1 (или для большинства последних 10 лет), я думаю, что все ваши (потенциальные) клиенты ожидали бы, что вы откроете такие файлы без особых хлопот.

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