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

24

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?

Nicolas Raoul
fuente
En realidad, más y más sitios populares están en UTF-8, un ejemplo es ニ コ ニ コ 動画 y は て な
Ken Li
8
¿Por qué no todos cambian de ISO-8851-1 a UTF-8?
ysdx
1
De paso aquí se menciona que la conversión SHIFT-JIS -> UTF-8 no es sin pérdidas, lo que sería una razón importante para continuar usando SHIFT-JIS donde ya está en uso. Sin embargo, descubrí que ese hecho aparente era sorprendente, por lo que esperaba que una de las respuestas aquí entrara en más detalles o al menos proporcionara una fuente para el reclamo, pero ninguna de ellas lo hace.
Kyle Strand
@KyleStrand ver support.microsoft.com/en-us/help/170559/…
Ludwig Schulze
@LudwigSchulze Gracias. Todavía no hay muchos detalles, pero al menos una fuente oficial ...
Kyle Strand

Respuestas:

28

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.

difunto
fuente
8
Industria de software japonesa ... más lenta que la suciedad en la utilización de nuevos software / estándares.
Mark Hosang
2
@Mark Truer palabras nunca fueron dichas! (Estoy trabajando en / con TI japonés ... -_- ;;)
deceze
55
Es cierto, pero las empresas occidentales tienen la excusa de que nuestro software heredado está lleno de suposiciones codificadas de 1 byte = 1 carácter, lo que hace que la transición a UTF-8 sea más difícil que para los asiáticos que han tenido que escribir código MBCS.
dan04
@ MarkHosang Confirmo que su declaración es 100% correcta (trabajo para una empresa japonesa en Tokio)
Hassan Tareq
9

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.

Ludwig Schulze
fuente
Parece que a partir de 2.0 Ruby adoptó UTF-8 como predeterminado. Pero la unificación de Han parece ser una arruga realmente importante (y un tema bastante controvertido ) en el mundo de Unicode que aparentemente no recibe suficiente atención, ya que nunca antes había oído hablar de ella.
Kyle Strand
Y aquí hay un artículo de Wikipedia sobre el problema de la unificación de Han: en.wikipedia.org/wiki/Han_unification ¡ Eso sí que parece ser un problema válido, una gran respuesta! Además, la pérdida de fecha sería una buena razón.
spbnick
8

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.

SOLO MI OPINIÓN correcta
fuente
77
Si bien eso es cierto, siempre existe la alternativa de UTF-16, que puede ser tan eficiente como Shift-JIS. También diría que el dolor de cabeza de lidiar con diferentes codificaciones supera con creces el ligero aumento de tamaño en la actualidad. Para decirlo de otra manera, nunca he escuchado el argumento de eficiencia para Shift-JIS por parte de alguien que todavía lo esté usando. ;-)
deceze
55
Sin embargo, he oído que el problema de la eficiencia se utiliza como excusa para la pereza y la inercia.
SOLO MI OPINIÓN correcta
1
UTF-16 crea caracteres ASCII básicos [de los cuales hay un número considerable en, por ejemplo, HTML] el doble de grande. Según tengo entendido, esto termina haciendo que UTF-16 sea aún peor que UTF-8 para las páginas web japonesas.
Random832
2
@ SOLO Mi OPINIÓN correcta: Pruebe "Ver código fuente" o el equivalente. Suponiendo que todo el texto real esté en japonés, es probable que haya muchas palabras clave y similares derivadas del inglés, y que estén representadas en ASCII.
David Thornley
44
Esto me parece una razón para hacerlo, así que lo encontramos después . Estoy bastante seguro de que la eficiencia no tiene absolutamente nada que ver con el statu quo. Para mí es solo inercia y legado. En realidad, también creo que tiene que ver con el hecho de que la mayoría del código producido por los programadores japoneses es para otros japoneses, por lo que ni siquiera sienten la necesidad de usar algo como Unicode.
Julien Guertault
2

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.

Denis de Bernardy
fuente
2

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.

azheglov
fuente