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

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

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

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

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