Какие проблемы побуждают людей использовать специфичные для Японии кодировки, а не Unicode?

24

На работе я сталкиваюсь с множеством японских текстовых файлов в Shift-JIS и других кодировках. Это вызывает много проблем mojibake (нечитаемый символ) для всех пользователей компьютера. Unicode предназначался для решения такого рода проблем путем определения единого набора символов для всех языков, и сериализация UTF-8 рекомендуется для использования в Интернете. Так почему же не все переходят с японских кодировок на UTF-8? Какие проблемы или недостатки UTF-8 сдерживают людей?

РЕДАКТИРОВАТЬ: W3C перечисляет некоторые известные проблемы с Unicode , это тоже может быть причиной?

legacy unicode character-encoding Николас Рауль
источник
На самом деле все больше и больше популярных сайтов есть в UTF-8, один пример - ニ コ ニ コ コ и は て て
Кен Ли
8
Почему не все переходят с ISO-8851-1 на UTF-8?
ysdx
1
Он упоминается мимоходом здесь , что SHIFT-JIS -> UTF-8 преобразования не без потерь, которая была бы одной из основных причин для продолжения использования Shift-JIS , где это уже используется. Я обнаружил, что этот очевидный факт не удивителен, поэтому я надеялся, что один из приведенных здесь ответов может стать более подробным или, по крайней мере, предоставить источник для заявления, но ни один из них не делает.
Кайл Стрэнд
@KyleStrand см support.microsoft.com/en-us/help/170559/...
Людвиг Schulze
@LudwigSchulze Спасибо. Все еще не много деталей, но, по крайней мере, официальный источник ...
Кайл Стрэнд,

Ответы:

28

Одним словом: наследие.

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

Есть много западных компаний, которые все еще используют ASCII или latin-1 по тем же причинам, только никто не замечает, потому что это никогда не вызывает проблемы.

deceze
источник
8
Японская индустрия программного обеспечения ... медленнее, чем грязь в использовании нового программного обеспечения / стандартов.
Марк Хосанг
2
Слова @Mark Truer никогда не были сказаны! (Я работаю в / с японскими ИТ ... -_- ;;)
deceze
5
Да, но у западных компаний есть оправдание тому, что наше устаревшее программное обеспечение полно жестко закодированных предположений, что 1 байт = 1 символ, что делает переход на UTF-8 более сложным, чем для азиатов, которые давно должны были писать код, очищенный от MBCS.
Ден04
@MarkHosang Я подтверждаю, что ваше утверждение на 100% верно (я работаю в японской компании в Токио)
Хасан Тарек
9

Вот причины, которые, как я помню, были приведены для того, чтобы не делать UTF-8 или другое представление Unicode кодировкой символов по умолчанию для языка сценариев Ruby, который в основном разработан в Японии:

  • Причина 1: объединение Хань . Наборы символов (не уверен, что «алфавиты» здесь будут правильными), используемые Китай, Корея и Япония, все связаны, произошли из общей истории, не уверены в деталях. Консорциум Unicode решил использовать только одну кодовую точку Unicode для кодирования всех вариантов (китайский, японский и корейский) одного и того же символа, даже если их внешний вид отличается на всех 3 языках. Их аргументация заключается в том, что внешний вид должен определяться шрифтом, используемым для отображения текста.

Очевидно, что эти рассуждения воспринимаются японскими пользователями настолько же нелепо, насколько это было бы доказательством для английских читателей, что, поскольку латинский алфавит разработан на основе греческого алфавита, достаточно иметь только одну кодовую точку для греческой альфы ». α и латинский «a», и пусть внешний вид определяется используемым шрифтом. (То же самое для "β" = "b", "γ" = "g" и т. Д.)

(Обратите внимание, что я бы не смог включить греческие символы здесь в stackexchange, если бы это было так.)

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

Могло быть дано больше причин, которые я больше не помню.

Людвиг Шульце
источник
Похоже, что начиная с 2.0 Ruby принял UTF-8 по умолчанию. Но объединение Хана, кажется, действительно важная морщина (и довольно спорная проблема ) в мире Юникода, которая, очевидно, не получает достаточного внимания, так как я никогда не слышал об этом раньше.
Кайл Стрэнд
А вот статья в Википедии по вопросу объединения Хань: en.wikipedia.org/wiki/Han_unification Это действительно кажется правильным вопросом, отличный ответ! Кроме того, потеря даты была бы хорошей причиной.
Спбник
8

Ответ deceze имеет очень сильный элемент правды, но есть еще одна причина, по которой Shift-JIS и другие все еще используются: UTF-8 ужасно неэффективен для некоторых языков, в основном в наборе CJK. Shift-JIS, IIRC, является двухбайтовой кодировкой шириной, тогда как UTF-8 обычно является 3-байтовой, а иногда даже 4-байтовой в своих кодировках с CJK и другими.

ПРОСТО МОЕ правильное мнение
источник
7
Хотя это правда, всегда есть альтернатива UTF-16, которая может быть столь же эффективной, как Shift-JIS. Я также утверждаю, что головная боль при работе с различными кодировками намного превышает небольшое увеличение в наши дни. Иными словами, я никогда не слышал аргумент эффективности для Shift-JIS по любому прежнему использовать его. ;-)
deceze
5
Я слышал, что вопрос эффективности использовался как оправдание лени и инерции.
Просто мое правильное мнение
1
UTF-16 делает базовые символы ASCII [значительного числа которых, например, в HTML) вдвое больше. Насколько я понимаю, это фактически делает UTF-16 еще хуже, чем UTF-8 для японских веб-страниц.
Random832
2
@ ПРОСТО Мое правильное МНЕНИЕ: попробуйте "Просмотр источника" или эквивалентный. Предполагая, что весь фактический текст написан на японском языке, вероятно, будет много ключевых слов и тому подобного, которые были получены из английского языка и представлены в ASCII.
Дэвид Торнли
4
Для меня это звучит как причина, которую мы находим потом . Я уверен, что эффективность практически не имеет ничего общего со статус-кво. Для меня это просто инерция и наследие. На самом деле я также думаю, что это связано с тем фактом, что большая часть кода, созданного японскими программистами, предназначена для других японцев, поэтому они даже не чувствуют необходимости использовать что-то вроде Unicode.
Жюльен Геро
2

Подсчитайте размер строки / использование памяти среди основных причин.

В UTF-8 восточноазиатским языкам часто требуется 3 или более байтов для своих символов. В среднем им требуется на 50% больше памяти, чем при использовании UTF-16 - последний из которых уже менее эффективен, чем собственное кодирование.

Другой основной причиной было бы наследство, как указывает децезе.

Дени де Бернарди
источник
2

Наследие и размер хранилища, как говорили другие, но есть еще одна вещь: персонажи катакана.

Для представления символов катаканы в Shift-JIS требуется всего один байт, поэтому японский текст, включая катакану, занимает менее 2 байтов на символ (1,5 для микса 50/50), что делает Shift-JIS несколько более эффективным, чем UTF-16 (2 байта). / char) и гораздо более эффективный, чем UTF-8 (3 байта / char).

Дешевое хранение должно было сделать эту проблему намного меньше, но, очевидно, нет.

azheglov
источник