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

Question

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

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

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

Answer 1

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

Что делать, если я хочу сохранить имя клиента, в котором используются неанглийские символы? Или название места в другой стране?

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

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

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

Если вы используете UTF-8 для вашего текста в Юникоде, вы даже получаете возможность читать простые строки ASCII, что должно сэкономить вам некоторые головные боли.

Answer 2

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

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

Всегда лучше быть в безопасности, чем сожалеть, ИМО.

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Где еще вы можете сказать ⟦∀c|c∈Unicode⟧ и подобные технические вещи.

Answer 8

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

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

Answer 9

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

Answer 10

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

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

Answer 11

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

Answer 12

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

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

Answer 13

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

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

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

Answer 14

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

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

Answer 15

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

Answer 16

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

Answer 17

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

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

Answer 18

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

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

Design for evil, и у вас есть шанс не нарушать ваш код так скоро. В этом случае используйте Unicode. Случилось со мной в бразильской специфической системе на фондовом рынке.

Answer 19

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

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

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

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

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

Answer 20

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

Во-вторых, Windows, является естественным Unicode, и ANSI API являются наследием.

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

Answer 21

Я бы сказал, что это отношение выражало наивность, но я не смог бы описать наивность в ASCII-only.

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

Даже без старомодного стиля сотрудничества Нью-Йорка, как бы бедная женщина называла Зоэ, если ее работодатели использовали такую ​​систему?

Увы, она даже не будет искать другую работу, поскольку обновление ее резюме было бы невозможным, и ей пришлось бы возобновить вместо этого. Как она объяснит это своей невесте?