Насколько распространенный UTF-8 действительно?

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

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

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

Марк

И Java, и C # внутренне используют UTF-16 и могут легко преобразовываться в другие кодировки; они довольно прочно закрепились в мире предприятий.

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

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

Хорошие новости: , если вы приехали из Германии, где у вас в основном 8859-1 / 15 и ASCII, дополнительно принять 8859-1 и преобразовать его в UTF-8 практически не требует затрат. Это легко обнаружить: использование ö или ü в кодировке 8859-1 является недопустимым UTF-8, например, даже не входя в легко обнаруживаемые недопустимые пары. Использование символов 128-159 маловероятно 8859-1. В пределах нескольких байтов от вашего первого старшего байта вы обычно можете иметь очень и очень хорошее представление о том, какая кодировка используется. И как только вы узнаете кодировку, будь то спецификация или предположение, вы не будете

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

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

Или же, если вы обнаружите, что переоцениваете объем работы вы можете сделать это за день, тогда вам, возможно, придется переоценить это во время ретроспективы. Количество продуктивного времени в день, которое команда решает учитывать при планировании своей мощности для спринта, называется фокусным фактором .

Хенрик Книберг говорит следующее:

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

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

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

• Завершите спринт в пятницу утром. Проведите обзор и ретроспективу вашего спринта утром, а оставшуюся часть дня позвольте команде поработать над чем-нибудь другим, чтобы очистить голову. Начнем с планирования спринта в понедельник.
• Мы ввели понятие «лабораторные дни». Это целые дни, когда команду отвлекают от проекта, и они проводят день, работая над улучшением своих технических навыков путем совместных исследований и сотрудничества по конкретным техническим темам. данные и ситуация в конкретных стран.

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

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

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

Приемлемо ли в наше время иметь приложение, которое использует ТОЛЬКО 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), необходимо выполнить некоторые обходные пути / настройки.)

Пользователи символов 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 - единственная кодировка символов, обязательная для реализации во всех протоколах отслеживания IETF.

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

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" связаны с одним небольшим набором символов и нуждаются в обрабатывать последовательности многобайтовых символов для языков с большими алфавитами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You might be interested in this question. I've been trying to build a CW about the support for unicode in various languages.

Вот некоторые статистические данные, которые мне удалось найти:

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

Обе эти страницы, похоже, страдают от существенных проблем:

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

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

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

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

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

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

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

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

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