¿Qué problemas llevan a las personas a usar codificaciones específicas de japonés en lugar de Unicode?

En el trabajo me encuentro con muchos archivos de texto en japonés en Shift-JIS y otras codificaciones. Causa muchos problemas de mojibake (caracteres ilegibles) para todos los usuarios de computadoras. Unicode tenía la intención de resolver este tipo de problema definiendo un solo juego de caracteres para todos los idiomas, y se recomienda la serialización UTF-8 para su uso en Internet. Entonces, ¿por qué no todos cambian de codificaciones específicas de japonés a UTF-8? ¿Qué problemas o desventajas de UTF-8 están frenando a las personas?

EDITAR: El W3C enumera algunos problemas conocidos con Unicode , ¿podría ser esta también una razón?

En una palabra: legado.

Shift-JIS y otras codificaciones se usaron antes de que Unicode estuviera disponible / popular, ya que era la única forma de codificar japonés. Las empresas han invertido en infraestructura que solo era compatible con Shift-JIS. Incluso si esa infraestructura ahora es compatible con Unicode, todavía están atrapados con Shift-JIS por varias razones que van desde que funciona, así que no lo toques hasta la codificación, ¿qué? que migran-all-documentos-existentes-es demasiado costosa .

Hay muchas compañías occidentales que todavía usan ASCII o latin-1 por las mismas razones, pero nadie se da cuenta ya que nunca está causando un problema.

Estas son las razones que recuerdo que se dieron para no hacer que UTF-8 u otra representación Unicode sea la codificación de caracteres predeterminada para el lenguaje de script Ruby, que se desarrolla principalmente en Japón:

• Razón 1: unificación Han . Los conjuntos de caracteres (no estoy seguro si los "alfabetos" serían correctos aquí) usados ​​en China, Corea y Japón están todos relacionados, han evolucionado a partir de la historia común, no estoy seguro de los detalles. El consorcio Unicode decidió desperdiciar un solo punto de código Unicode para codificar todas las variantes (chino, japonés y coreano) del mismo carácter histórico, incluso si su apariencia difiere en los 3 idiomas. Su razonamiento es que la apariencia debe estar determinada por la fuente utilizada para mostrar el texto.

Aparentemente, este razonamiento es percibido como tan ridículo por los usuarios japoneses como lo sería argumentar a los lectores ingleses que, debido a que el alfabeto latino se ha desarrollado a partir del alfabeto griego, es suficiente tener un solo punto de código para el alfabeto griego " α "y en latín" a ", y deja que la apariencia se decida por la fuente en uso. (Lo mismo para "β" = "b", "γ" = "g", etc.)

(Tenga en cuenta que, si ese fuera el caso, no podría incluir caracteres griegos aquí en stackexchange).

• Razón 2: conversiones de caracteres ineficientes. La conversión de caracteres de Unicode a codificaciones japonesas heredadas y viceversa requiere tablas, es decir, no existe un cálculo simple del valor de punto de código Unicode al valor de punto de código heredado y viceversa. También hay una cierta pérdida de información al convertir porque no todos los puntos de código en una codificación tienen una representación única en la otra codificación.

Es posible que se hayan dado más razones que ya no recuerdo.

La respuesta de deceze tiene un elemento de verdad muy fuerte, pero hay otra razón por la cual Shift-JIS y otros todavía están en uso: UTF-8 es terriblemente ineficiente para algunos idiomas, principalmente en el conjunto CJK. Shift-JIS es, IIRC, una codificación de dos bytes de ancho, mientras que UTF-8 es típicamente de 3 bytes y ocasionalmente incluso de 4 bytes en sus codificaciones con CJK y otros.

Cuente el tamaño de cadena / uso de memoria entre las razones principales.

En UTF-8, los idiomas de Asia oriental con frecuencia necesitan 3 o más bytes para sus caracteres. En promedio, necesitan un 50% más de memoria que cuando se usa UTF-16, el último de los cuales ya es menos eficiente que la codificación nativa.

La otra razón principal sería el legado, como lo señala el engaño.

Legado y tamaño de almacenamiento, como otros decían, pero hay una cosa más: los personajes Katakana.

Solo se necesita un byte para representar los caracteres Katakana en Shift-JIS, por lo que el texto japonés que incluye Katakana toma menos de 2 bytes por carácter (1.5 para una mezcla 50/50), lo que hace que Shift-JIS sea algo más eficiente que UTF-16 (2 bytes / char), y mucho más eficiente que UTF-8 (3 bytes / char).

El almacenamiento barato debería haber hecho de esto un problema mucho más pequeño, pero aparentemente no.