Почему не все, что мы делаем в Юникоде?

Question

Учитывая, что Unicode существует уже 18 лет , почему все еще существуют приложения, которые не поддерживают Unicode? Даже мой опыт работы с некоторыми операционными системами и Unicode был болезненным, если не сказать больше. Как отметил Джоэл Спольски в 2003 году, это не так сложно. Так в чем же дело? Почему мы не можем собрать это вместе?

Answer 1

Начните с нескольких вопросов

Как часто ...

• вам нужно написать приложение, которое имеет дело с чем-то, кроме ascii?
• вам нужно написать мультиязычное приложение?
• Вы пишете приложение, в котором имеет для нескольких языков по сравнению с его первой версией?
• Вы слышали, что Unicode используется для представления не-ascii символов?
• Вы читали, что Unicode - это кодировка? Этот Юникод является кодировкой?
• Вы видите людей, которые путают UTF-8-кодированные строки и данные Unicode?

Знаете ли вы разницу между сопоставлением и кодировкой?

Где вы впервые услышали о Unicode?

• В школе? ( действительно )
• на работе?
• в модном блоге?

Вы когда-нибудь за 1039 * юных дней испытывали перемещение исходных файлов из системы в локали A в систему в локали B, редактировали опечатку в системе B, сохраняли файлы, отказываясь от всех -Каждый комментарий и ... в конечном итоге тратить много времени, пытаясь понять, что случилось? (Ваш редактор перепутал вещи? Компилятор? Система? ...?)

Вы в конечном итоге решили, что никогда больше вы прокомментируете свой код, используя не-ascii символы?

Посмотрите, что делается в другом месте

Python

Я упоминал на SO, что я люблю Python? Нет? Ну, я люблю Python.

Но до Python3.0 его поддержка Unicode отстой. И были все те новички-программисты, которые в то время едва знали, как написать цикл, получая UnicodeDecodeError и UnicodeEncodeError из ниоткуда при попытке работать с не-ascii символами. Ну, в основном они получили травму жизни от монстра Unicode, и я знаю очень много очень эффективных / опытных кодеров Python, которые до сих пор боятся идеи иметь дело с данными Unicode.

А в Python3 существует четкое разделение между Unicode и bytestrings, но ... посмотрим, насколько сложно переносить приложение из Python 2.x в Python 3.x, если вы ранее не заботились о разделение / если вы не действительно понимаете, что такое Юникод.

Базы данных, PHP

Знаете ли вы популярный коммерческий сайт, который хранит свой международный текст как Unicode?

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

Одна из ключевых проблем заключается в том, как сортировать текстовые данные, если вы сохраняете их как кодовые точки Unicode. Здесь идет Unicode collations , которые определяют порядок сортировки по кодовым точкам Unicode. Но надлежащая поддержка сопоставлений в базах данных отсутствует / находится в активной разработке. (Вероятно, есть и много проблем с производительностью. - IANADBA) Кроме того, пока нет общепринятого стандарта для сопоставлений: для некоторых языков люди не согласны с тем, как следует сортировать слова / буквы / группы слов.

Вы слышали о нормализации Unicode ? (По сути, вам следует преобразовать данные Unicode в каноническое представление перед их сохранением) Конечно, это важно для хранения базы данных или локальных сравнений. Но PHP, например, обеспечивает поддержку нормализации только с версии 5.2.4, вышедшей в августе 2007 года.

На самом деле, PHP еще не полностью поддерживает Unicode. Придется подождать PHP6, чтобы везде были доступны Unicode-совместимые функции.

Итак, почему не все, что мы делаем в Юникоде?

1. Некоторым людям не нужен Юникод.
2. Некоторым людям все равно.
3. Некоторые люди не понимают, что они будут позже нуждаться в поддержке Unicode.
4. Некоторые люди не понимают Unicode.
5. Для некоторых других Unicode чем-то похож на доступность для веб-приложений: вы начинаете без, и добавите поддержку для него позже
6. Многим популярным библиотекам / языкам / приложениям не хватает надлежащей, полной поддержки Unicode, не говоря уже о проблемах сопоставления и нормализации. И пока все элементы в вашем стеке разработки полностью не поддерживают Unicode, вы не можете написать чистое приложение Unicode.

Интернет явно помогает распространять тренд Юникода. И это хорошо. Инициативы, такие как внесение изменений в Python3, помогают информировать людей об этой проблеме. Но нам придется терпеливо подождать, чтобы увидеть Unicode везде, и новые программисты инстинктивно используют Unicode вместо Strings, где это важно.

Что касается анекдота, поскольку FedEx, по-видимому, не поддерживает международные адреса, все студенты Google Summer of Code '09 попросили Google предоставить только ascii имя и адрес для доставки. Если вы думаете, что большинство бизнес-игроков понимают, что стоит за поддержкой Unicode, вы просто ошибаетесь. FedEx не понимает, а их клиенты на самом деле не заботятся. Тем не менее.

Answer 2

• Многие разработчики продуктов не считают, что их приложения используются в Азии или других регионах, где требуется Unicode.
• Преобразование существующих приложений в Unicode стоит дорого и, как правило, обусловлено возможностями продаж.
• У многих компаний есть продукты, поддерживаемые в устаревших системах, и переход на Unicode означает совершенно новую платформу разработки.
• Вы будете удивлены, как много разработчиков не понимают всех последствий Unicode в многоязычной среде. Это не просто случай использования широких строк.

Итог - стоимость.

Answer 3

Широко распространенная доступность инструментов разработки для работы с Unicode может быть более недавним событием, чем вы думаете. Еще несколько лет назад работа с Unicode была болезненной задачей преобразования между символьными форматами и работы с неполными или ошибочными реализациями. Вы говорите, что это не так сложно, и по мере совершенствования инструментов это становится все более правдоподобным, но есть много способов запутаться, если детали не будут скрыты от вас хорошими языками и библиотеками. Черт, просто вырезание и вставка символов Юникода может быть сомнительным предложением несколько лет назад. Обучение разработчиков также заняло некоторое время, и вы все еще видите, что люди совершают массу действительно элементарных ошибок.

Стандарт Unicode весит, вероятно, десять фунтов. Даже просто обзор этого должен был бы обсудить тонкие различия между символами, глифами, кодовыми точками и т. Д. Теперь подумайте об ASCII. Это 128 символов. Я могу объяснить все это кому-то, кто знает двоичный файл, примерно за 5 минут.

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

Answer 4

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

ИМО, это функция коллективной привычки, а не сознательного выбора.

Answer 5

Одним из важных факторов является поддержка языка программирования, большинство из которых использует набор символов, который умещается в 8 бит (например, ASCII) в качестве значения по умолчанию для строк. Класс String в Java использует UTF-16, и есть другие, которые поддерживают варианты Unicode, но многие языки выбирают простоту. Пространство настолько тривиально в наши дни, что кодировщикам, которые цепляются за «эффективные для пространства» строки, нужно дать пощечину. Большинство людей просто не работают на встроенных устройствах, и даже такие устройства, как сотовые телефоны (большая волна вычислений ближайшего будущего) могут легко обрабатывать 16-битные наборы символов.

Другим фактором является то, что многие программы написаны только для запуска на английском языке, и разработчики (1) не планируют (или даже не знают, как) локализовать свой код для нескольких языков, и (2) они часто этого не делают. даже думать об обработке ввода в не-римских языках. Английский является доминирующим естественным языком, на котором говорят программисты (по крайней мере, для общения друг с другом) и в значительной степени распространяющийся на производимое нами программное обеспечение. Тем не менее, апатия и / или невежество, безусловно, не могут длиться вечно ... Учитывая тот факт, что мобильный рынок в Азии полностью затмевает большую часть остального мира, программистам придется иметь дело с Unicode довольно скоро, будь они нравится тебе или нет.

Не смотря на то, что оно того стоит, я не думаю, что сложность стандарта Unicode не так уж важна для программистов, а скорее для тех, кто должен реализовать языковую поддержку. При программировании на языке, где тяжелая работа уже выполнена, есть еще меньше причин не использовать под рукой инструменты. C'est la vie, старые привычки тяжело умирают.

Answer 6

Лень, невежество.

Answer 7

Поскольку UTF-16 стал популярным до UTF-8, а UTF-16 - свинья для работы. ИМХО

Answer 8

Все операционные системы до недавнего времени были построены на предположении, что символ является байтом. Его API были созданы так, инструменты были созданы так, языки были созданы так.

Да, было бы намного лучше, если бы все, что я написал, было уже ... эээ ... UTF-8? UTF-16? UTF-7? UTF-32? Э-э-э ... ммм ... Кажется, что бы вы ни выбрали, вы кого-то раздражаете. И на самом деле это правда.

Если вы выберете UTF-16, то все ваши данные, как и в целом для всего западного мира, перестанут беспрепятственно читаться, поскольку вы потеряете совместимость с ASCII. Добавьте к этому, байт перестает быть символом, который серьезно нарушает предположения, на которых основано современное программное обеспечение. Кроме того, некоторые страны не принимают UTF-16. Теперь, если вы выберете ЛЮБУЮ кодировку переменной длины, вы нарушите некоторые базовые условия большого количества программного обеспечения, например, нет необходимости проходить строку, чтобы найти n-й символ, и возможность прочитать строку из любой ее точки.

А потом UTF-32 ... ну, это четыре байта. Какой был средний размер жесткого диска или памяти, но 10 лет назад? UTF-32 был слишком большой!

Таким образом, единственное решение - изменить все - программное обеспечение, утилиты, операционные системы, языки, инструменты - в то же время, чтобы быть в курсе i18n. Что ж. Удачи с «одновременно».

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

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

Answer 9

Поскольку для 99% приложений поддержка Юникода не является флажком в матрице сравнения продуктов клиента.

Добавить к уравнению:

1. Требуется сознательное усилие почти без видимой пользы.
2. Многие программисты этого боятся или не понимают.
3. Менеджмент ДЕЙСТВИТЕЛЬНО не понимает этого или не заботится об этом, по крайней мере, пока клиент не кричит об этом.
4. Команда тестирования не проверяет соответствие Юникоду.
5. «Мы не локализовали пользовательский интерфейс, поэтому не говорящие по-английски его бы не использовали».

Answer 10

Традиция и отношение. К сожалению, ASCII и компьютеры являются синонимами для многих людей.

Однако было бы наивно думать, что роль Юникода - это только вопрос экзотических языков Евразии и других частей света. Кодировка расширенного текста имеет много смысла, чтобы привести даже к «простому» английскому тексту. Иногда заглядывайте в книгу.