Quais problemas levam as pessoas a usar codificações específicas do japonês em vez do Unicode?

No trabalho, encontro muitos arquivos de texto em japonês no Shift-JIS e outras codificações. Causa muitos problemas de mojibake (caracteres ilegíveis) para todos os usuários de computador. O Unicode pretendia resolver esse tipo de problema, definindo um único conjunto de caracteres para todos os idiomas, e a serialização UTF-8 é recomendada para uso na Internet. Então, por que todo mundo não muda de codificações específicas do japonês para UTF-8? Quais problemas ou desvantagens do UTF-8 estão impedindo as pessoas?

EDIT: O W3C lista alguns problemas conhecidos com Unicode , isso também poderia ser um motivo?

Em uma palavra: legado.

Shift-JIS e outras codificações foram usadas antes que o Unicode se tornasse disponível / popular, pois era a única maneira de codificar o japonês. As empresas investiram em infraestrutura que suportava apenas o Shift-JIS. Mesmo que essa infraestrutura agora suporte Unicode, elas ainda estão presas ao Shift-JIS por vários motivos, variando de como funciona, para que não toque na codificação, o que? a migração de-tudo-documentos existentes, é demasiado caro .

Existem muitas empresas ocidentais que ainda usam ASCII ou latin-1 pelos mesmos motivos, mas ninguém percebe, pois nunca está causando um problema.

Essas são as razões pelas quais me lembro de não terem transformado em UTF-8 ou outra representação Unicode a codificação de caracteres padrão para a linguagem de script Ruby, desenvolvida principalmente no Japão:

• Razão 1: unificação Han . Os conjuntos de caracteres (não tenho certeza se "alfabetos" estariam corretos aqui) usados ​​China, Coréia e Japão são todos relacionados, evoluíram a partir da história comum, não tendo certeza dos detalhes. O consórcio Unicode decidiu desperdiçar apenas um único ponto de código Unicode para codificar todas as variantes (chinês, japonês e coreano) do mesmo caractere histórico, mesmo que sua aparência seja diferente nos três idiomas. O raciocínio deles é que a aparência deve ser determinada pela fonte usada para exibir o texto.

Aparentemente, esse raciocínio é tão ridículo para os usuários japoneses quanto seria para argumentar aos leitores de inglês que, como o alfabeto latino se desenvolveu a partir do alfabeto grego, é suficiente ter apenas um único código para o alfa grego " α "e latim" a "e deixe a aparência ser decidida pela fonte em uso. (O mesmo para "β" = "b", "γ" = "g" etc.)

(Observe que eu não seria capaz de incluir caracteres gregos aqui no stackexchange, se fosse esse o caso.)

• Razão 2: conversões ineficientes de caracteres. A conversão de caracteres de Unicode em codificações e vice-versa japonesas herdadas requer tabelas, ou seja, não há computação simples do valor do ponto de código Unicode para o valor do ponto de código herdado e vice-versa. Além disso, há alguma perda de informações durante a conversão, porque nem todos os pontos de código em uma codificação têm uma representação exclusiva na outra codificação.

Podem ter sido dadas mais razões pelas quais não me lembro mais.

A resposta de deceze tem um elemento de verdade muito forte, mas há outra razão pela qual Shift-JIS e outros ainda estão em uso: o UTF-8 é terrivelmente ineficiente para alguns idiomas, principalmente no conjunto CJK. O Shift-JIS é, IIRC, uma codificação de dois bytes de largura, enquanto o UTF-8 é tipicamente de 3 bytes e, ocasionalmente, mesmo de 4 bytes em suas codificações com CJK e outros.

Contar o tamanho da string / uso de memória entre os principais motivos.

No UTF-8, os idiomas do leste asiático frequentemente precisam de 3 ou mais bytes para seus caracteres. Em média, eles precisam de 50% mais memória do que quando usam UTF-16 - o último dos quais já é menos eficiente que a codificação nativa.

A outra principal razão seria o legado, como apontado por deceze.

Legado e tamanho de armazenamento, como outros disseram, mas há mais uma coisa: personagens Katakana.

Leva apenas um byte para representar caracteres Katakana no Shift-JIS, portanto, o texto em japonês, incluindo Katakana, leva menos de 2 bytes por caractere (1,5 para um mix 50/50), tornando o Shift-JIS um pouco mais eficiente que o UTF-16 (2 bytes / char) e muito mais eficiente que UTF-8 (3 bytes / char).

O armazenamento barato deveria ter feito desse um problema muito menor, mas aparentemente não.