Jakie problemy powodują, że ludzie używają kodowania specyficznego dla języka japońskiego zamiast Unicode?

W pracy natrafiam na wiele japońskich plików tekstowych w Shift-JIS i innych kodowaniach. Powoduje wiele problemów mojibake (nieczytelnych znaków) dla wszystkich użytkowników komputerów. Unicode miał na celu rozwiązanie tego rodzaju problemu poprzez zdefiniowanie jednego zestawu znaków dla wszystkich języków, a serializacja UTF-8 jest zalecana do stosowania w Internecie. Dlaczego więc nie wszyscy przełączają się z japońskiego kodowania na UTF-8? Jakie problemy lub wady UTF-8 powstrzymują ludzi?

EDYCJA: W3C wymienia niektóre znane problemy z Unicode , czy to też może być powód?

Jednym słowem: dziedzictwo.

Shift-JIS i inne kodowania były używane, zanim Unicode stał się dostępny / popularny, ponieważ był to jedyny sposób na kodowanie japońskiego. Firmy zainwestowały w infrastrukturę obsługującą tylko Shift-JIS. Nawet jeśli ta infrastruktura obsługuje teraz Unicode, nadal tkwią w Shift-JIS z różnych powodów, począwszy od tego, że działa, więc nie dotykaj go po kodowaniu, co? do migracji wszystko istniejących dokumentów elektronicznych, jest nazbyt kosztowne .

Istnieje wiele zachodnich firm, które nadal używają ASCII lub Latin-1 z tych samych powodów, tylko nikt nie zauważa, ponieważ nigdy nie powoduje problemu.

Oto powody, dla których pamiętam, że nie uczyniono UTF-8 lub innej reprezentacji Unicode domyślnym kodowaniem znaków dla języka skryptowego Ruby, który jest rozwijany głównie w Japonii:

• Powód 1: Zjednoczenie Hana . Zestawy znaków (nie jestem pewien, czy „alfabety” byłyby tutaj poprawne) używane Chiny, Korea i Japonia są ze sobą powiązane, wyewoluowały ze wspólnej historii, nie są pewne szczegóły. Konsorcjum Unicode postanowiło zmarnować tylko jeden punkt kodu Unicode, aby zakodować wszystkie warianty (chiński, japoński i koreański) tego samego historycznego znaku, nawet jeśli ich wygląd różni się we wszystkich 3 językach. Ich rozumowanie jest takie, że wygląd powinien być określony czcionką użytą do wyświetlenia tekstu.

Najwyraźniej to rozumowanie jest tak samo śmieszne dla japońskich użytkowników, jak argumentowanie czytelnikom angielskim, że skoro alfabet łaciński rozwinął się z alfabetu greckiego, wystarczy mieć tylko jeden punkt kodowy dla greckiej alfy ” α ”i łaciński„ a ”i niech wygląd zależy od używanej czcionki. (To samo dla „β” = „b”, „γ” = „g” itp.)

(Zauważ, że nie byłbym w stanie umieścić tutaj znaków greckich na stosie wymiany, gdyby tak było).

• Powód 2: Nieefektywne konwersje postaci. Konwersja znaków z Unicode na starsze japońskie kodowanie i odwrotnie wymaga tabel, tzn. Nie ma prostego obliczenia od wartości punktu kodowego Unicode do wartości punktu kodowego starszego i odwrotnie. Ponadto występuje pewna utrata informacji podczas konwersji, ponieważ nie wszystkie punkty kodowe w jednym kodowaniu mają unikalną reprezentację w drugim kodowaniu.

Podano więcej powodów, że już nie pamiętam.

Odpowiedź deceze zawiera w sobie bardzo silny element prawdy, ale jest jeszcze jeden powód, dla którego Shift-JIS i inne są nadal w użyciu: UTF-8 jest strasznie nieefektywny w niektórych językach, głównie w zestawie CJK. Shift-JIS jest, IIRC, dwubajtowym kodowaniem, podczas gdy UTF-8 jest zwykle 3-bajtowy, a czasami nawet 4-bajtowy w swoich kodowaniach z CJK i innymi.

Policz rozmiar łańcucha / użycie pamięci wśród głównych powodów.

W UTF-8 języki wschodnioazjatyckie często wymagają 3 lub więcej bajtów dla swoich znaków. Średnio potrzebują o 50% więcej pamięci niż przy użyciu UTF-16 - ten ostatni jest już mniej wydajny niż kodowanie natywne.

Innym głównym powodem byłaby spuścizna, na co wskazuje deceze.

Dziedzictwo i wielkość pamięci, jak powiedzieli inni, ale jest jeszcze jedna rzecz: postacie Katakana.

Tylko jeden bajt reprezentuje znaki Katakana w Shift-JIS, więc japoński tekst zawierający Katakana zajmuje mniej niż 2 bajty na znak (1,5 dla mieszanki 50/50), dzięki czemu Shift-JIS jest nieco bardziej wydajny niż UTF-16 (2 bajty / char) i znacznie bardziej wydajny niż UTF-8 (3 bajty / char).

Tanie przechowywanie powinno sprawić, że będzie to znacznie mniejszy problem, ale najwyraźniej nie.