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

Ответ 1

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

Как часто...

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

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

Где вы впервые узнали о Unicode?

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

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

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

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

Python

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

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

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

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

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

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

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

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

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

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

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

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

Для анекдота, потому что FedEx, по-видимому, не поддерживает международные адреса,

Ответ 2

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

Нижняя строка - стоимость.

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

• Требуется сознательное усилие, практически без видимой выгоды.
• Многие программисты боятся этого или не понимают этого.
• Управление ДЕЙСТВИТЕЛЬНО не понимает и не заботится об этом, по крайней мере, пока клиент не кричит об этом.
• Команда тестирования не тестирует соответствие Unicode.
• "Мы не локализуем пользовательский интерфейс, поэтому не говорящие на английском языке не будут использовать его в любом случае".

Ответ 10

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

Однако было бы наивно думать, что роль Юникода - это только вопрос экзотических языков из Евразии и других частей мира. Богатая кодировка текста имеет много смысла, чтобы довести даже до "простого" английского текста. Посмотрите в какую-нибудь книгу.

Ответ 11

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

Вторая причина частично в том, что это вызывает первый выпуск, Unicode - это не научная ракета, но это дает вам массу проблем, с которыми вам никогда не приходилось иметь дело в ASCII. С ASCII вы имели четкие отношения one byte == one glyph, могли бы обращаться к N-му символу строки простым str[N], могли просто хранить все символы всего набора в памяти и так далее. С Unicode вы больше не можете этого делать, вам приходится иметь дело с разными способами кодирования Unicode (UTF-8, UTF-16,...), байтов байтов, ошибок декодирования, множеством шрифтов, которые имеют только подмножество символов которые вам понадобятся для полной поддержки Unicode, больше глифов, которые вы хотите сохранить в памяти в данный момент времени и так далее.

ASCII можно понять, просто просмотрев таблицу ASCII без какой-либо дополнительной документации, с Unicode, которая просто больше не имеет места.

Ответ 12

Из-за инерции, вызванной С++. У него была (есть) ужасная поддержка юникода и перетащили разработчиков.

Ответ 13

Дополнительные накладные расходы.

Ответ 14

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

Ответ 15

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

Хорошо, что с моей точки зрения. Я думаю, если вы ожидаете, что код будет использовать std::wstring hw(L"hello world"), вам нужно объяснить, как все работает, чтобы печатать wstring вам нужно wcout: std::wcout << hw << std::endl; (я думаю), (но endl кажется прекрасным..)... Мне кажется, что больше работы для меня - конечно, если бы я писал международное приложение, мне пришлось бы инвестировать в его выяснение, но до тех пор я этого не делаю (как я подозреваю большинство разработчиков).

Я думаю, это вернулось к деньгам, время - деньги.

Ответ 16

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

edit: Другими словами, Unicode - это то, о чем вы должны думать, и мышление - это не то, что большинство людей интересует, даже программисты.

Ответ 17

Мне лично не нравится, как некоторые форматы unicode разбивают его так, что вы больше не можете делать string [3], чтобы получить третий символ. Конечно, это может быть абстрагировано, но представьте, насколько медленнее будет большой проект со строками, например GCC, если бы он должен был поперек строки, чтобы выяснить n-й символ. Единственный вариант - кэширование, где "полезные" позиции есть и даже тогда они замедляются, а в некоторых форматах теперь вы получаете хорошие 5 байт на символ. Для меня это просто смешно.