Зачем использовать Unicode, если ваша программа только на английском? - PullRequest
16 голосов
/ 15 июня 2009

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

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

Если интернационализация самих программ не считается уважительной причиной, как можно оправдать все время, потраченное на перекодировку библиотек и программ для перехода на Unicode?

Ответы [ 21 ]

3 голосов
/ 29 декабря 2009

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

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

3 голосов
/ 16 июня 2009

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

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

3 голосов
/ 15 июня 2009

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

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

2 голосов
/ 17 июня 2009

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

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

1 голос
/ 17 июня 2009

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

1 голос
/ 17 июня 2009

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

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

1 голос
/ 15 июня 2009

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

1 голос
/ 15 июня 2009

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

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

0 голосов
/ 08 июня 2011

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

Во-вторых, Windows изначально является Unicode, а API-интерфейсы ANSI являются устаревшими.

Современные приложения должны использовать Unicode, где это применимо, что практически везде.

0 голосов
/ 27 августа 2009

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

...