Quali problemi portano le persone a utilizzare codifiche specifiche giapponesi anziché Unicode?

24

Al lavoro mi imbatto in molti file di testo giapponesi in Shift-JIS e altre codifiche. Causa molti problemi di mojibake (carattere illeggibile) per tutti gli utenti di computer. Unicode intendeva risolvere questo tipo di problema definendo un singolo set di caratteri per tutte le lingue e la serializzazione UTF-8 è consigliata per l'uso su Internet. Allora perché non tutti passano da codifiche specifiche giapponesi a UTF-8? Quali problemi o svantaggi di UTF-8 stanno trattenendo le persone?

EDIT: Il W3C elenca alcuni problemi noti con Unicode , potrebbe essere anche questo un motivo?

legacy unicode character-encoding

— Nicolas Raoul
fonte

In realtà sempre più siti popolari sono in UTF-8, un esempio è ニコニコ動画 e はてな

— Ken Li

8

Perché non tutti passano da ISO-8851-1 a UTF-8?

— ysdx,

1

Si dice qui passando che la conversione SHIFT-JIS -> UTF-8 non è senza perdita di dati, il che sarebbe uno dei motivi principali per continuare a utilizzare SHIFT-JIS dove è già in uso. Ho scoperto che questo apparente factoide è sorprendente, quindi speravo che una delle risposte qui potesse andare più in dettaglio o almeno fornire una fonte per l'affermazione, ma nessuna di esse lo fa.

— Kyle Strand,

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

— Ludwig Schulze

@LudwigSchulze Grazie. Ancora non molti dettagli, ma almeno una fonte ufficiale ...

— Kyle Strand

28

In una parola: eredità.

Shift-JIS e altre codifiche sono state utilizzate prima che Unicode diventasse disponibile / popolare, poiché era l'unico modo per codificare il giapponese. Le aziende hanno investito in infrastrutture che supportano solo Shift-JIS. Anche se l'infrastruttura che ora supporta Unicode, sono ancora bloccati con Shift-JIS per vari motivi che vanno da da-opere-così-non-touch-it over codificano-cosa? di migrazione-all-esistenti-documenti-è-troppo-costosa .

Ci sono molte compagnie occidentali che usano ancora ASCII o latino-1 per le stesse ragioni, solo nessuno se ne accorge dato che non causa mai problemi.

— deceze
fonte

8

Industria del software giapponese ... più lenta della sporcizia nell'utilizzo di nuovi software / standard.

— Mark Hosang,

2

@Mark Le parole più vere non sono mai state dette! (Sto lavorando in / con il giapponese IT ... -_- ;;)

— ingannare l'

5

È vero, ma le aziende occidentali hanno la scusa che il nostro software legacy è pieno di ipotesi codificate in base a 1 byte = 1 carattere, il che rende più difficile il passaggio a UTF-8 rispetto agli asiatici che hanno a lungo dovuto scrivere un codice pulito da MBCS.

— dan04,

@MarkHosang Confermo che la tua affermazione è corretta al 100% (lavoro per un'azienda giapponese a Tokyo)

— Hassan Tareq

9

Queste sono le ragioni che ricordo sono state fornite per non aver reso UTF-8 o un'altra rappresentazione Unicode la codifica dei caratteri predefinita per il linguaggio di script Ruby, che è sviluppato principalmente in Giappone:

Motivo 1: unificazione Han . I set di caratteri (non sono sicuro che "alfabeti" siano corretti qui) utilizzati Cina, Corea e Giappone sono tutti correlati, si sono evoluti dalla storia comune, non sono sicuro dei dettagli. Il consorzio Unicode ha deciso di sprecare solo un singolo punto di codice Unicode per codificare tutte le varianti (cinese, giapponese e coreano) dello stesso personaggio storico, anche se il loro aspetto differisce in tutte e 3 le lingue. Il loro ragionamento è che l'aspetto dovrebbe essere determinato dal carattere usato per visualizzare il testo.

Apparentemente, questo ragionamento è percepito tanto ridicolo dagli utenti giapponesi quanto sarebbe argomentare ai lettori inglesi che, poiché l'alfabeto latino si è sviluppato dall'alfabeto greco, è sufficiente avere un solo punto di codice per l'alfa greca " α "e latino" a ", e lascia che l'aspetto sia deciso dal font in uso. (Lo stesso per "β" = "b", "γ" = "g", ecc.)

(Nota che non sarei in grado di includere caratteri greci qui su StackExchange se così fosse.)

Motivo 2: conversioni di caratteri inefficienti. La conversione di caratteri da Unicode a codifiche giapponesi precedenti e viceversa richiede tabelle, ovvero non esiste un semplice calcolo dal valore del punto di codice Unicode al valore del punto di codice legacy e viceversa. Inoltre, si verifica una perdita di informazioni durante la conversione poiché non tutti i punti di codice in una codifica hanno una rappresentazione univoca nell'altra codifica.

Potrebbero essere state date altre ragioni che non ricordo più.

— Ludwig Schulze
fonte

Sembra che a partire dal 2.0 Ruby abbia adottato UTF-8 come predefinito. Ma l'unificazione Han sembra essere una ruga molto importante (e una questione abbastanza controversa ) nel mondo di Unicode che apparentemente non riceve abbastanza attenzione, dal momento che non ne ho mai sentito parlare prima.

— Kyle Strand,

Ed ecco un articolo di Wikipedia sul problema dell'unificazione Han: en.wikipedia.org/wiki/Han_unification Questo in effetti sembra essere un problema valido, un'ottima risposta! Inoltre, la perdita della data sarebbe una buona ragione.

— spbnick,

8

La risposta di ingannare ha un forte elemento di verità, ma c'è un'altra ragione per cui Shift-JIS e altri sono ancora in uso: UTF-8 è orribilmente inefficiente per alcune lingue, soprattutto nel set CJK. Shift-JIS è, IIRC, una codifica larga a due byte mentre UTF-8 è tipicamente a 3 byte e occasionalmente anche a 4 byte nelle sue codifiche con CJK e altri.

— SOLO IL MIO OPINIONE corretta
fonte

7

Anche se questo è vero, c'è sempre l'alternativa di UTF-16, che può essere efficiente come Shift-JIS. Direi anche che il mal di testa nel trattare con diverse codifiche supera di gran lunga il leggero aumento delle dimensioni in questo giorno ed età. Per dirla in altro modo, non ho mai sentito l'argomento dell'efficienza per Shift-JIS da parte di nessuno ancora in uso. ;-)

— ingannare l'

5

Tuttavia, ho sentito il problema dell'efficienza usato come scusa per l'accidia e l'inerzia.

— SOLO IL MIO OPINIONE corretta,

1

UTF-16 rende i caratteri ASCII di base [di cui esiste un numero considerevole in eg HTML] il doppio. A quanto ho capito, questo alla fine rende UTF-16 persino peggiore di UTF-8 per le pagine Web giapponesi.

— Casuale 832

2

@JUST Il mio OPINION corretto: prova "Visualizza sorgente" o equivalente. Supponendo che tutto il testo sia in giapponese, è probabile che ci siano molte parole chiave e simili che sono state derivate dall'inglese e sono rappresentate in ASCII.

— David Thornley,

4

Questo mi sembra un motivo per farlo, quindi lo scopriamo in seguito . Sono abbastanza sicuro che l'efficienza non abbia praticamente nulla a che fare con lo status quo. Per me è solo inerzia ed eredità. In realtà penso anche che abbia a che fare con il fatto che la maggior parte del codice prodotto dai programmatori giapponesi è per altri giapponesi, quindi non sentono nemmeno il bisogno di usare qualcosa come Unicode.

— Julien Guertault,

2

Conta le dimensioni della stringa / l'utilizzo della memoria tra i motivi principali.

In UTF-8, le lingue dell'Asia orientale hanno spesso bisogno di 3 o più byte per i loro personaggi. In media hanno bisogno del 50% di memoria in più rispetto a quando utilizzano UTF-16, quest'ultimo dei quali è già meno efficiente della codifica nativa.

L'altro motivo principale sarebbe l'eredità, come sottolineato dall'inganno.

— Denis de Bernardy
fonte

2

Eredità e dimensioni dello spazio di archiviazione, come dicevano altri, ma c'è un'altra cosa: i personaggi di Katakana.

Ci vuole solo un byte per rappresentare i caratteri Katakana in Shift-JIS, quindi il testo giapponese incluso Katakana richiede meno di 2 byte per carattere (1,5 per un mix 50/50), rendendo Shift-JIS un po 'più efficiente di UTF-16 (2 byte / char) e molto più efficiente di UTF-8 (3 byte / char).

Lo storage economico avrebbe dovuto rendere questo un problema molto più piccolo, ma apparentemente no.

— azheglov
fonte