Однако, я начинаю новый проект и хочу использовать Unicode (потому что это то, что должен делать ответственный программист, не так ли?). Для этого нам нужно будет начать конвертировать все библиотеки, которые мы вписали в Unicode. Это небольшая задача.
Если интернационализация самих программ не считается веской причиной, как бы оправдать все время, затрачиваемое на перекодировку библиотек и программ, чтобы перейти к Unicode?
Это, очевидно, зависит от того, что на самом деле делает ваше приложение, но только потому, что у вас есть только английская версия, это не означает, что интернационализация не является проблемой.
Что делать, если я хочу сохранить имя клиента, в котором используются неанглийские символы? Или название места в другой стране?
В качестве дополнительного бонуса (поскольку вы говорите, что вы нацеливаетесь на ученых) заключается в том, что в Unicode поддерживаются всевозможные научные символы и нотации.
В конечном счете, мне гораздо легче быть последовательным. Unicode ведет себя одинаково независимо от того, на чей компьютер вы запускаете приложение. Не-Юникод означает, что по умолчанию используется какой-либо языковой набор символов или кодовая страница, и поэтому текст, который отлично выглядит на вашем компьютере, может быть заполнен символами мусора на чужом.
Кроме того, вам, вероятно, не нужно переводить все ваши библиотеки в Unicode за один раз. Записывайте обертки по мере необходимости для преобразования между Unicode и любой кодировкой, которую вы используете в противном случае.
Если вы используете UTF-8 для текста в Юникоде, вы даже получаете возможность читать простые строки ASCII, что должно сэкономить вам некоторые головные боли при конвертации.
Говорят, что они всегда будут на английском языке, но вы признаете, что у вас есть клиенты по всему миру. Приходит клиент и говорит, что интернационализация - это разрыватель сделок, действительно ли они откажутся от них?
Чтобы прояснить то, что я пытаюсь заставить вас сказать, что они не будут принимать это рассуждение, но это звучит.
Всегда лучше быть в безопасности, чем жалеть, ИМО.
Расширенные правила набора научных, технических и математических символов.
Где еще вы можете сказать ⟦∀c|c∈Unicode⟧ и подобные технические материалы.
Символы за пределами 7-битного диапазона ASCII также полезны и на английском языке. Кто-нибудь, кто использует ваше программное обеспечение, даже должен написать знак €? Или? Как насчет отличия "резюме" от "резюме"? Вы говорите, что он используется учеными всего мира, у которых могут быть такие имена, как "Йорг" или "Гудмундсдоттир". В научной обстановке полезно говорить о таких длинах волн, как λ, единицы, такие как Å, или углы как Θ, даже на английском языке.
Некоторые из этих символов, такие как "ö", "£" и "€", могут быть доступны в 8-битных кодировках, таких как ISO-8859-1 или Windows-1252, поэтому может показаться, что вы можете просто использовать эти кодирования и сделать с ним. Проблема в том, что за пределами этих диапазонов есть символы, которые многие используют очень часто, поэтому в UTF-8 закодировано множество существующих данных. Если ваше программное обеспечение не понимает, что при импорте данных он может интерпретировать символ "£" в UTF-8 как последовательность из двух символов Windows-1252 и отображать его как "Â". Если эта ошибка не обнаруживается достаточно долго, вы можете начать серьезно искажать свои данные, так как многократные пропуски неверного толкования изменяют ваши данные все больше и больше, пока они не станут невосстановимыми.
И хорошо подумать об этих проблемах на ранней стадии разработки вашей программы. Поскольку строки имеют тенденцию быть очень низкоуровневой концепцией, пронизанной по всей вашей программе, с множеством предположений о том, как они работают в неявном виде, как они используются, может быть очень сложно и дорого добавить поддержку Unicode в программу позже, если вы даже не задумывались над этим вопросом.
Моя рекомендация состоит в том, чтобы всегда использовать типы и библиотеки типов Unicode, где это возможно, и убедиться, что все ваши тесты (будь то единица, интеграция, регрессия или любые другие типы тестов), которые имеют дело со строками, пытаются передать некоторый Unicode строками через вашу систему, чтобы они работали и проходили через невредимые.
Если вы не обрабатываете Unicode, я бы рекомендовал, чтобы все данные, принятые системой, были 7-битными (т.е. нет символов за пределами 7-разрядного диапазона US-ASCII). Это поможет избежать проблем с несовместимостью между 8-битными устаревшими кодировками, такими как семейство ISO-8859 и UTF-8.
Предположим, ваша программа позволяет мне поместить мое имя в нее, в форму, диалог, что угодно, и мое имя не может быть написано с помощью символов ascii... Несмотря на то, что ваша программа находится на английском языке, данные могут быть на другом языке...
Не имеет значения, что ваше программное обеспечение не переведено, если ваши пользователи используют международные символы, тогда вам нужно поддерживать unicode, чтобы иметь возможность делать правильную капитализацию, сортировку и т.д.
Хорошо для одного, ваши пользователи могут знать и понимать английский, но у них все еще могут быть "локальные" имена. Если вы разрешаете своим пользователям делать какие-либо входные данные для вашего приложения, они могут захотеть использовать символы, которые не являются частью ascii. Если вы не поддерживаете юникод, у вас не будет возможности разрешить эти имена. Вы вынуждаете своих пользователей принимать более простое имя только потому, что приложение недостаточно интеллектуально для обработки специальных символов.
Другое дело, даже если стандарт сейчас заключается в том, что приложение будет выпущено только на английском языке, вы также блокируете возможность интернационализации с помощью ASCII, добавляя к работе, которая должна быть выполнена, когда политика компании решает, что переводы - это хорошо. Политика компании хороша, но также, как известно, изменилась.
Если вам нет необходимости в переключении на unicode, не делайте этого. Я основываю это на том факте, что вам показалось, что вам нужно будет изменить код, не имеющий отношения к компоненту, который вам нужно изменить, чтобы все это работало с Unicode. Если вы можете создать компонент/функцию, которую вы работаете над "Unicode ready", не распространяя отторжку кода на множество других компонентов (особенно других компонентов без хорошего покрытия теста), тогда вперед и сделайте его готовым к юникоду. Но не переваривайте всю свою кодовую базу без необходимости в бизнесе.
Если потребность в бизнесе возникает позже, тогда обратитесь к нему. В противном случае вам это не понадобится.
Люди в этой теме могут предполагать сценарии, когда они становятся бизнес-требованиями. Запускайте эти сценарии менеджерами продуктов, прежде чем рассматривать их сценарии, заслуживающие внимания. Убедитесь, что они знают стоимость обращения к ним, когда вы спрашиваете.
Компания, над которой я работаю **, как политика **, выпустит только программное обеспечение на английском языке, хотя у нас есть клиенты по всему миру.
Только одна причина: изменения политики, и когда они меняются, они нарушают существующий код. Период.
Дизайн для зла, и у вас есть шанс не нарушать ваш код так скоро. В этом случае используйте Unicode. Случилось со мной в бразильской специфической системе на фондовом рынке.
Я бы сказал, что это отношение выражало наивность, но я не смог бы описать наивность только в ASCII.
ASCII по-прежнему работает для некоторых компьютерных кодов, но не подходит для фасада между машиной и пользователем.
Даже без старомодного стиля сотрудничества в Нью-Йорке, как бы бедная женщина называла Зоэ, если ее работодатели использовали такую систему?
Увы, она даже не стала бы искать другую работу, поскольку обновление ее резюме было бы невозможным, и ей пришлось бы возобновить работу. Как она объяснит это своей невесте?
Многие языки (Java [и, следовательно, большинство языковых реализаций на основе JVM], С# [и, следовательно, большинство .NET-языковых реализаций], Objective C, Python 3,...) поддерживают строки Unicode по предпочтению или даже (почти ) исключительно (вам нужно уйти с вашего пути, чтобы работать со строками "байтов", а не с символами Юникода).
Если компания, на которой вы работаете навсегда, намерена использовать любой из этих языков и платформ, поэтому было бы весьма целесообразно начать планирование стратегии поддержки Unicode; пилотный проект, в частности, может быть плохой идеей.
Это действительно хороший вопрос. Единственная причина, по которой я могу думать об этом, не имеет ничего общего с I18n или неанглийским текстом, так это то, что Unicode особенно подходит для того, что можно назвать набором символов хаба. Если вы считаете, что ваша система как концентратор со своими внешними зависимостями в качестве спиц, вы хотите изолировать преобразования кодировки символов на спицах, чтобы ваша хаб-система работала последовательно с выбранной вами кодировкой. Что делает Unicode идеальным набором символов для концентратора вашей системы, так это то, что он признает существование других наборов символов, он определяет эквивалентность между его собственными символами и символами в этих наборах внешних символов, и существует постоянный процесс, когда он расширяется, чтобы поддерживать с инновациями и эволюцией внешних наборов символов. Там есть всевозможные странные кодировки: даже когда документация гарантирует вам, что внешняя система или библиотека использует простой ASCII, часто оказывается такой вариант, как IBM775 или HPRoman8, и приятная вещь о Unicode заключается в том, что независимо от того, что на вас бросается кодировка, есть хорошая вероятность, что есть таблица на unicode.org, которая точно определяет, как конвертировать эти данные в Юникод и обратно, без потери информации. Опять же, эквиваленты a-z довольно хорошо определены в каждом наборе символов, поэтому, если ваши данные действительно ограничены стандартным английским алфавитом, ASCII может делать так же, как набор символов-концентраторов.
Решение о кодировании - это решение по двум вещам: какой набор символов разрешен и как эти символы представлены. Unicode позволяет использовать практически любой персонаж, когда-либо изобретенный, но у вас могут быть свои причины не хотеть и не нуждаться в таком широком выборе. Вы можете по-прежнему ограничивать имена пользователей, например, комбинациями az и подчеркивания, возможно, потому, что вы должны поместить их во внешнюю систему LDAP, чей собственный набор символов ограничен, возможно, потому, что вам нужно распечатать их, используя шрифт, который не охватывают все Unicode, возможно, потому, что он закрывает проблемы безопасности, открытые внешними персонажами. Если вы используете что-то вроде ASCII или ISO8859-1, уровень хранения/передачи реализует многие из этих ограничений; с Unicode уровень хранения не ограничивает ничего, поэтому вам, возможно, придется реализовать свои собственные правила на уровне приложения. Это больше работы - больше программирования, больше тестирования, более возможных состояний системы. Компромисс для этой дополнительной работы более гибкий, правила на уровне приложений легче изменить, чем системные кодировки.
Причиной использования юникода является уважение правильных абстракций в вашем дизайне.
Просто привыкно относиться к понятию текст. Это не сложно. Нет причин создавать сломанный дизайн, даже если ваши пользователи являются английскими.
Просто подумайте о клиенте, который хочет использовать такие имена, как Schrödingers Cat, для файлов, которые он сохранил с помощью вашего программного обеспечения. Или представьте себе некоторые локализованные Windows с переводом My Documents, в котором используются символы, отличные от ASCII. Это будет интернационализация, которая, несмотря на то, что вы вообще не поддерживаете интернационализацию, оказывает влияние на ваше программное обеспечение.
Кроме того, возможность поддержки интернационализации позже - это всегда хорошо.
Юникод похож на cooties. Как только он "заражает" одну область, обычно трудно содержать ее, учитывая взаимосвязь зависимостей. Рано или поздно вам, вероятно, придется привязать библиотеку, совместимую с юникодом, и, следовательно, будет использовать wchar_t или тому подобное. Вместо того, чтобы маршировать между типами символов, приятно иметь последовательные строки.
Таким образом, приятно быть последовательным. В противном случае вы получите что-то похожее на Windows API с версией "A" и "W" для большинства API-интерфейсов, поскольку они несовместимы для начала. (И в некоторых случаях Microsoft отказалась от создания версий "A" в целом.)
Интернационализация - это нечто большее, чем просто текст на разных языках. Я держу пари, что это ниша будущего в IT-мире. Черт, это уже есть. Многое уже было сказано, просто подумал, что я добавлю небольшую вещь. Несмотря на то, что ваши клиенты сейчас довольны английским, это может измениться в будущем. И чем дольше вы ждете, тем сложнее будет конвертировать вашу базу кода. У них может быть даже сегодня проблемы с, например, имена файлов или другие типы данных, которые вы сохраняете/загружаете в своем приложении.
Вы не сказали, на каком языке вы используете. На некоторых языках переход от ASCII к Unicode может быть довольно простым, тогда как в других (которые не поддерживают Unicode) это может быть довольно сложно.
Тем не менее, может быть, в вашей ситуации вы не должны поддерживать Unicode: вы не можете придумать вескую причину, почему вы должны, и есть некоторые причины (т.е. ваши затраты на изменение существующих библиотек), которые утверждают. Я имею в виду, возможно, "идеально" вы должны, но на практике может быть какая-то другая, более важная или более неотложная вещь, на которую нужно потратить свое время и силы в данный момент.
Если программа принимает текстовый ввод от пользователя, она должна использовать unicode; вы никогда не знаете, какой язык пользователь будет использовать.
При использовании Unicode он оставляет дверь открытой для интернационализации, если требования когда-либо меняются, и вы должны использовать текст на других языках, чем английский.
Кроме того, в вашем новом проекте вы всегда можете просто писать обертки для библиотек, которые внутренне конвертируют между ASCII и Unicode и наоборот.
У вашего потенциального клиента уже может быть приложение не-Юникод на другом языке, отличном от английского, и вы не сможете запускать свою программу, не перепутывая язык юникода Windows взад и вперед, что будет большой болью.
Потому что Интернет в подавляющем большинстве использует Unicode. Веб-страницы используют unicode. Текстовые файлы, включая ваши документы клиента, и данные в их буферах обмена, - это Юникод.
Во-вторых, Windows, является естественным Unicode, и ANSI API являются наследием.
Современные приложения должны использовать Unicode, где это применимо, что почти везде.