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

24

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

EDIT: 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 з тих же причин, тільки ніхто не помічає, оскільки це ніколи не спричиняє проблеми.

— обман
джерело

8

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

— Марк Хосанг

2

@ Марк Truer слова не говорили більше! (Я працюю в / з японськими IT ... -_- ;;)

— декабрь

5

Правда, але західні компанії мають виправдання, що наше застаріле програмне забезпечення наповнене жорсткими припущеннями, що 1 байт = 1 символ, що робить перехід на UTF-8 складнішим, ніж для азіатців, яким давно доводилося писати код очищення MBCS.

— dan04

@MarkHosang Я підтверджую, що ваше твердження на 100% правильне (я працюю в японській компанії в Токіо)

— Хассан Тарек

9

Ці причини, які я пам'ятаю, були наведені через те, що UTF-8 або інше Unicode не було представлене за замовчуванням кодування символів для мови сценаріїв Ruby, розроблене в основному в Японії:

Причина 1: Об’єднання Хана . Набори символів (не впевнений, чи "алфавіти" тут би були правильними), що використовуються в Китаї, Кореї та Японії, пов'язані між собою, розвинулися з загальної історії, не впевнені в деталях. Консорціум Unicode вирішив витратити лише одну кодову точку Unicode для кодування всіх варіантів (китайської, японської та корейської) історичного символу, навіть якщо їх зовнішність відрізняється на всіх трьох мовах. Їх міркування полягає в тому, що зовнішній вигляд повинен визначатися шрифтом, який використовується для відображення тексту.

Мабуть, це міркування японськими користувачами сприймається настільки ж смішним, як було б стверджувати англійським читачам, що, оскільки латинський алфавіт склався з грецького алфавіту, достатньо мати лише одну точку коду для грецької альфа " α "та латинська" a ", і нехай зовнішній вигляд визначається шрифтом, який використовується. (Те саме для "β" = "b", "γ" = "g" тощо)

(Зверніть увагу, що я б не зміг включити грецькі символи сюди на stackexchange, якби це було так.)

Причина 2. Неефективні перетворення символів. Для перетворення символів з Unicode в застарілі японські кодування та назад потрібні таблиці, тобто немає простого обчислення від значення кодової точки Unicode до старого значення кодової точки і навпаки. Також є певна втрата інформації при перетворенні, оскільки не всі кодові точки в одному кодуванні мають унікальне представлення в іншому кодуванні.

Можливо, було дано більше причин, яких я вже не пам’ятаю.

— Людвіг Шульце
джерело

Здається, що з 2.0 Ruby було прийнято UTF-8 за замовчуванням. Але об'єднання Хана, здається, є дійсно важливою зморшкою (і досить суперечливою проблемою ) у світі Unicode, яка, очевидно, не приділяє достатньої уваги, оскільки я ніколи раніше про неї не чув.

— Кайл Странд

І ось стаття у Вікіпедії з питання об’єднання Хань: en.wikipedia.org/wiki/Han_unification Це дійсно видається валідним питанням, чудова відповідь! Також втрата дати буде вагомою причиною.

— spbnick

8

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

— ПРОСТО МОЯ правильна думка
джерело

7

Хоча це правда, завжди є альтернатива UTF-16, яка може бути настільки ж ефективною, як і Shift-JIS. Я б також стверджував, що головний біль при роботі з різними кодуваннями значно переважає незначне збільшення розмірів в цей день і вік. Якщо говорити по-іншому, я ніколи не чув аргументу ефективності для Shift-JIS від того, хто ще його використовує. ;-)

— дег

5

Я чув, що питання ефективності використовується як привід для лінощів та інертності.

— ДАЙТЕ МОЕ правильне ДУМКА

1

UTF-16 робить основні символи ASCII [з яких є значне число, наприклад, HTML] удвічі більше. Як я розумію, це в кінцевому підсумку робить UTF-16 ще гіршим, ніж UTF-8 для японських веб-сторінок.

— Випадково832

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).

Дешеве зберігання повинно було зробити це набагато меншою проблемою, але, мабуть, ні.

— ажеглов
джерело