Quali problemi inducono le persone a utilizzare codifiche specifiche per giapponese piuttosto che Unicode?

In una parola: legacy.

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 ora supporta Unicode, sono ancora bloccati con Shift-JIS per vari motivi che vanno da it-works-so-don -t-touch-it su encoding-what? per migrare-tutti-esistenti-documenti-è-troppo-costoso .

Ci sono molte aziende occidentali che usano ancora ASCII o latin-1 per gli stessi motivi, solo nessuno se ne accorge perché non causa mai un problema.

la risposta di deceze ha un strong 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, principalmente nel set CJK. Shift-JIS è, IIRC, una codifica wide a due byte mentre UTF-8 è tipicamente a 3 byte e occasionalmente persino a 4 byte nelle sue codifiche con CJK e altri.

Questi sono i motivi per cui mi ricordo che sono stati dati per non rendere UTF-8 o un'altra rappresentazione Unicode la codifica dei caratteri predefinita per il linguaggio di scripting Ruby, che è sviluppato principalmente in Giappone:

• Motivo 1: Unificazione Han . I set di caratteri (non so se "alfabeti" sarebbero corretti qui) usati in 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 un solo codice Unicode per codificare tutte le varianti (cinese, giapponese e coreano) dello stesso carattere storico, anche se il loro aspetto è diverso in tutte e 3 le lingue. Il loro ragionamento è che l'aspetto dovrebbe essere determinato dal carattere utilizzato per visualizzare il testo.

Apparentemente, questo ragionamento è percepito come ridicolo dagli utenti giapponesi, come sarebbe per sostenere i lettori inglesi che, poiché l'alfabeto latino si è sviluppato dall'alfabeto greco, è sufficiente avere un solo punto di codice per Alfa greca "α" e latina "a" e lasciare che l'aspetto sia deciso dal carattere in uso. (Lo stesso vale per "β"="b", "γ"="g", ecc.)

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

• Motivo 2: conversioni di caratteri inefficienti. La conversione di caratteri da Unicode a codifiche e legacy giapponesi precedenti richiede tabelle, vale a dire che non esiste un semplice calcolo dal valore del punto di codice Unicode al valore del punto di codice legacy e viceversa. C'è anche una perdita di informazioni durante la conversione perché non tutti i punti di codice in una codifica hanno una rappresentazione univoca nell'altra codifica.

Potrebbero esserci altre ragioni che non ricordo più.

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

In UTF-8, le lingue est-asiatiche richiedono spesso 3 o più byte per i loro caratteri. In media hanno bisogno di il 50% di memoria in più rispetto a quando si utilizza UTF-16, l'ultimo dei quali è già meno efficiente di quello nativo codifica.

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

Dimensioni legacy e di archiviazione, come altri hanno detto, ma c'è ancora una cosa: i caratteri 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 / carattere) e molto più efficiente di UTF-8 (3 byte / carattere).

Lo storage a basso costo avrebbe dovuto rendere questo problema molto più piccolo, ma apparentemente no.