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

24

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?

legacy unicode character-encoding

— Nicolas Raoul
źródło

W rzeczywistości coraz więcej popularnych witryn znajduje się w UTF-8, jednym z przykładów jest ニコニコ動画 i はてな

— Ken Li

8

Dlaczego nie wszyscy przechodzą z ISO-8851-1 na UTF-8?

— ysdx

1

Wspomniano tutaj, że konwersja SHIFT-JIS -> UTF-8 nie jest bezstratna, co byłoby głównym powodem dalszego korzystania z SHIFT-JIS tam, gdzie jest już używany. Stwierdziłem jednak, że to pozorne zaskakujące faktoidy, więc miałem nadzieję, że jedna z odpowiedzi tutaj może być bardziej szczegółowa lub przynajmniej stanowić źródło roszczenia, ale żadna z nich tego nie robi.

— Kyle Strand,

@KyleStrand patrz support.microsoft.com/en-us/help/170559/…

— Ludwig Schulze

@LudwigSchulze Thanks. Wciąż nie ma zbyt wielu szczegółów, ale przynajmniej oficjalne źródło ...

— Kyle Strand

28

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.

— deceze
źródło

8

Japoński przemysł oprogramowania ... wolniejszy niż brud przy korzystaniu z nowego oprogramowania / standardów.

— Mark Hosang,

2

@Mark Truer słowa nie zostały wypowiedziane! (Pracuję w / z japońskim IT ... -_- ;;)

— deceze

5

To prawda, ale zachodnie firmy mają wytłumaczenie, że nasze starsze oprogramowanie jest pełne zakodowanych na stałe założeń, że 1 bajt = 1 znak, co sprawia, że przejście na UTF-8 jest trudniejsze niż dla Azjatów, którzy od dawna musieli pisać czysty kod MBCS.

— dan04

@ MarkHosang Potwierdzam, że twoje oświadczenie jest w 100% poprawne (pracuję dla japońskiej firmy w Tokio)

— Hassan Tareq

9

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.

— Ludwig Schulze
źródło

Wygląda na to, że od 2.0 Ruby przyjęła domyślnie UTF-8. Ale zjednoczenie Hana wydaje się być bardzo ważnym zmarszczką (i dość kontrowersyjną kwestią ) w świecie Unicode, który najwyraźniej nie przyciąga wystarczającej uwagi, ponieważ nigdy wcześniej o nim nie słyszałem.

— Kyle Strand

A oto artykuł w Wikipedii na temat zjednoczenia Hana: en.wikipedia.org/wiki/Han_unification To rzeczywiście wydaje się być poprawnym problemem, świetna odpowiedź! Również utrata daty byłaby dobrym powodem.

— spbnick

8

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.

— WŁAŚNIE MOJA poprawna OPINIA
źródło

7

Chociaż jest to prawda, zawsze istnieje alternatywa dla UTF-16, która może być równie wydajna jak Shift-JIS. Twierdziłbym również, że ból głowy związany z różnymi kodowaniami znacznie przewyższa niewielki wzrost wielkości w dzisiejszych czasach. Ujmując to w inny sposób, nigdy nie słyszałem argument wydajności dla Shift-JIS przez nikogo nadal go używa. ;-)

— deceze

5

Słyszałem jednak, że problem z wydajnością jest usprawiedliwieniem lenistwa i bezwładności.

— PO PROSTU MOJA poprawna OPINIA,

1

UTF-16 sprawia, że podstawowe znaki ASCII [których jest znaczna liczba np. W HTML] dwa razy większe. Jak rozumiem, w rzeczywistości sprawia to, że UTF-16 jest jeszcze gorszy niż UTF-8 dla japońskich stron internetowych.

— Random832

2

@JUST Moja poprawna OPINIA: Spróbuj „View Source” lub jej odpowiednika. Zakładając, że cały tekst jest w języku japońskim, prawdopodobnie istnieje wiele słów kluczowych i tym podobnych, które pochodzą z języka angielskiego i są reprezentowane w ASCII.

— David Thornley,

4

Wydaje mi się, że to powód, aby znaleźć to później . Jestem prawie pewien, że wydajność nie ma absolutnie nic wspólnego ze status quo. Dla mnie to po prostu bezwładność i dziedzictwo. Właściwie myślę, że ma to również związek z faktem, że większość kodu produkowanego przez japońskich programistów jest przeznaczona dla innych Japończyków, więc nawet oni nie czują potrzeby używania czegoś takiego jak Unicode.

— Julien Guertault,

2

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.

— Denis de Bernardy
źródło

2

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.

— azheglov
źródło