Почему все не, мы делаем в Unicode?

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

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

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

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

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

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

Дополнительные накладные расходы, требования к пространству.

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

Потому что UTF-16 стал популярным раньше, чем UTF-8, а UTF-16 - это скучно. ИМХО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would say there are mainly two reason. First one is simply that the Unicode support of your tools just isn't up to snuff. C++ still doesn't have Unicode support and won't get it until the next standard revision, which will take maybe a year or two to be finished and then another five or ten years to be in widespread use. Many other languages aren't much better and even if you finally have Unicode support, it might still be a more cumbersome to use then plain ASCII strings.

The second reason is in part what it causing the first issue, Unicode is hard, its not rocket science, but it gives you a ton of problems that you never had to deal with in ASCII. With ASCII you had a clear one byte == one glyph relationships, could address the Nth character of a string by a simple str[N], could just store all characters of the whole set in memory and so on. With Unicode you no longer can do that, you have to deal with different ways Unicode is encoded (UTF-8, UTF-16, ...), byte order marks, decoding errors, lots of fonts that have only a subset of characters which you would need for full Unicode support, more glyphs then you want to store in memory at a given time and so on.

ASCII could be understand by just looking at an ASCII table without any further documentation, with Unicode that is simply no longer the case.