Почему Unicode использования, если Ваша программа является английской только?

При использовании Unicode он оставляет дверь открытой для интернационализации, если требования когда-либо изменятся, и вам потребуется использовать текст на других языках, кроме английского.

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

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

Unicode похож на cooties . Как только он «заражает» одну область, его обычно трудно сдержать, учитывая взаимосвязанность зависимостей. Рано или поздно вам, вероятно, придется подключить библиотеку, совместимую с Unicode, и, таким образом, вы будете использовать wchar_t или тому подобное. Вместо маршалинга между типами символов хорошо иметь единообразные строки повсюду.

Таким образом, приятно быть последовательными. В противном случае вы получите что-то похожее на Windows API, у которого есть версия «A» и версия «W» для большинства API, поскольку они изначально не согласовывались. (А в некоторых случаях Microsoft вообще отказалась от создания версий «A» .)

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

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

Интернационализация - это гораздо больше, чем просто текст на разных языках. Бьюсь об заклад, это ниша будущего в IT-мире. Черт возьми, это уже есть. Уже много сказано, просто подумал, что добавлю мелочь. Даже если ваши клиенты сейчас довольны английским, это может измениться в будущем. И чем дольше вы ждете, тем сложнее будет преобразовать вашу базу кода. У них даже сегодня могут быть проблемы, например, с именами файлов или другими типами данных, которые вы сохраняете / загружаете в своем приложении.

Только представьте, что клиент хочет использовать имена вроде Schrödingers Cat для файлов, которые он сохранил с помощью вашего программного обеспечения. Или представьте себе локализованную версию Windows с переводом Мои документы , в котором используются символы, отличные от ASCII. Это была бы интернационализация, которая, хотя вы вообще не поддерживаете интернационализацию, повлияла на ваше программное обеспечение.

Кроме того, всегда хорошо иметь возможность поддерживать интернационализацию позже.

Многие языки (Java [и, следовательно, большинство языковых реализаций на основе JVM], C # [и, следовательно, большинство реализаций языков на основе .NET], Objective C, Python 3, ...) поддерживают Unicode. строки по своему предпочтению или даже (почти) исключительно (вы должны изо всех сил стараться работать со «строками» байтов, а не символов Unicode).

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

Если вам не нужно переходить на юникод, не делайте этого. Я основываю это на том факте, что вы думали, что вам нужно изменить код, не связанный с компонентом, который вам уже нужно изменить, чтобы все это работало с Unicode. Если вы можете сделать компонент / функцию, над которой вы работаете, «готовой к Unicode», не распространяя отток кода на множество других компонентов (особенно на другие компоненты без хорошего тестового покрытия), тогда сделайте это готовым для Unicode. Но не перебивайте всю кодовую базу без бизнес-необходимости.

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

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

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

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

Предположим, ваша программа позволяет мне указывать мое имя в ней, в форме, диалоговом окне и т. Д., И мое имя не может быть записано с помощью символов ascii ... Даже если ваша программа на английском языке данные могут быть на другом языке ...

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

Чтобы прояснить, что я пытаюсь заставить вас сказать, что они не примут эту аргументацию, но это разумно.

Всегда лучше перестраховаться, чем сожалеть, IMO.

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

Расширенные научные, технические и математические правила набора символов.

Где еще можно сказать ⟦∀c∣c∈Unicode⟧ и тому подобное.

Это действительно хороший вопрос. Единственная причина, по которой я могу думать, что это не имеет ничего общего с I18n или неанглийским текстом, заключается в том, что Unicode особенно подходит для того, что можно было бы назвать набором символов концентратора. Если вы думаете о своей системе как о концентраторе с его внешними зависимостями как о лучах, вы хотите изолировать преобразования кодировки символов на лучах, чтобы ваша система концентратора работала согласованно с выбранной вами кодировкой. Что делает Unicode идеальным набором символов для концентратора вашей системы, так это то, что он признает существование других наборов символов, он определяет эквивалентность между своими собственными символами и символами в этих внешних наборах символов, и вот s непрерывный процесс, в котором он расширяется, чтобы идти в ногу с инновациями и эволюцией внешних наборов символов. Существуют всевозможные странные кодировки: даже когда документация заверяет вас, что внешняя система или библиотека использует простой ASCII, часто оказывается, что это какой-то вариант, такой как IBM775 или HPRoman8, а приятная вещь в Unicode заключается в том, что независимо от того, что кодирование брошено на вас, есть большая вероятность, что на unicode.org есть таблица, которая точно определяет, как преобразовать эти данные в Unicode и вернуться обратно без потери информации. Опять же, эквиваленты az довольно хорошо определены в каждом наборе символов, поэтому, если ваши данные действительно ограничены стандартным английским алфавитом, ASCII может работать так же хорошо, как и набор символов концентратора.

Решение о кодировании - это решение о двух вещах: какой набор символов разрешен и как эти символы представлены. Юникод позволяет использовать практически любой символ, когда-либо изобретенный, но у вас могут быть свои причины не хотеть или не нуждаться в таком широком выборе. Вы можете по-прежнему ограничивать имена пользователей, например, комбинациями z и подчеркивания, возможно, потому, что вам нужно поместить их во внешнюю систему LDAP, чей собственный набор символов ограничен, возможно, потому что вам нужно распечатать их, используя шрифт, который не покрывают весь Unicode, возможно, потому, что он закрывает проблемы безопасности, возникающие при использовании похожих символов. Если вы используете что-то вроде ASCII или ISO8859-1, уровень хранения / передачи реализует множество этих ограничений; с Unicode уровень хранения не t ограничивать что-либо, поэтому вам, возможно, придется реализовать свои собственные правила на уровне приложения. Это больше работы - больше программирования, больше тестирования, больше возможных состояний системы. Компромисс за эту дополнительную работу - большая гибкость, правила на уровне приложения изменить легче, чем системные кодировки.

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

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

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

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

1 причина только: Политика меняется, и когда они меняются, они сломают ваш существующий код. Период.

Проектирование для зла, и у вас есть шанс не взломать свой код так скоро. В этом случае используйте Юникод. Случилось со мной на бразильской специфической системе, унаследованной от фондового рынка.

Символы вне 7-битного диапазона ASCII также полезны и на английском языке. Кто-нибудь, использующий ваше программное обеспечение, даже должен написать знак €? Или £? Как насчет того, чтобы отличить "резюме" от "резюме"? Вы говорите, что его используют ученые всего мира, у которых могут быть имена типа "Йорг" или "Гурмундсдоттир". В научной среде полезно говорить о длинах волн типа λ, единицах типа Å или углах как Θ, даже на английском языке.

Некоторые из этих символов, такие как "ö", "£" и "€", могут быть доступны в 8-битных кодировках типа ISO-8859-1 или Windows-1252, так что может показаться, что вы можете просто использовать эти кодировки и покончить с этим. Проблема в том, что есть символы вне этих диапазонов, которые многие используют очень часто, и поэтому много существующих данных закодировано в UTF-8. Если ваше программное обеспечение не понимает, что при импорте данных оно может интерпретировать символ "£" в UTF-8 как последовательность из 2-х символов Windows-1252 и выдать его как "£". Если подобная ошибка останется незамеченной достаточно долго, вы можете начать серьезно искажать данные, так как многократные проходы неправильной интерпретации все больше и больше изменяют ваши данные до тех пор, пока они не станут невосстановимыми.

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

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

Если вы не работаете с Юникодом, то я бы порекомендовал убедиться, что все данные, принимаемые системой, являются 7-битными чистыми (то есть, нет символов за пределами 7-битного диапазона US-ASCII). Это поможет избежать проблем с несовместимостью 8-.битовые унаследованные кодировки, такие как семейство ISO-8859 и UTF-8.