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


24

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?


Na verdade locais mais populares estão em UTF-8, um exemplo éニコニコ動画eはてな
Ken Li

8
Por que todo mundo não muda de ISO-8851-1 para UTF-8?
ysdx

11
É mencionado aqui que a conversão SHIFT-JIS -> UTF-8 não tem perdas, o que seria um dos principais motivos para continuar usando o SHIFT-JIS onde já está em uso. Contudo, achei esse fato ostensivo surpreendente, então esperava que uma das respostas aqui pudesse entrar em mais detalhes ou pelo menos fornecer uma fonte para a alegação, mas nenhuma delas o faz.
Kyle Strand


@LudwigSchulze Thanks. Ainda sem muitos detalhes, mas pelo menos uma fonte oficial ...
Kyle Strand

Respostas:


28

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.


8
Indústria japonesa de software ... mais lenta que a sujeira na utilização de novos softwares / padrões.
Mark Hosang

2
As palavras @ Mark Truer nunca foram ditas! (Estou trabalhando em / com TI japonês ... -_- ;;))
deceze

5
É verdade, mas as empresas ocidentais têm a desculpa de que nosso software legado está cheio de suposições codificadas com 1 byte = 1 caractere, o que dificulta a transição para o UTF-8 do que para os asiáticos que há muito tempo escrevem códigos limpos do MBCS.
dan04

@MarkHosang Confirmo que sua declaração está 100% correta (trabalho para empresa japonesa em Tóquio)
Hassan Tareq 01/04

9

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.


Parece que a partir do 2.0 Ruby adotou o UTF-8 como padrão. Mas a unificação Han parece ser uma ruga realmente importante (e um assunto bastante controverso ) no mundo do Unicode que aparentemente não recebe atenção suficiente, já que nunca ouvi falar disso antes.
Kyle Strand

E aqui está um artigo da Wikipedia sobre a questão da unificação Han: en.wikipedia.org/wiki/Han_unification Isso realmente parece ser um problema válido, ótima resposta! Além disso, a perda de data seria uma boa razão.
Spnick #

8

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.


7
Embora isso seja verdade, sempre há a alternativa do UTF-16, que pode ser tão eficiente quanto o Shift-JIS. Eu também argumentaria que a dor de cabeça ao lidar com codificações diferentes supera em muito o ligeiro aumento de tamanho nos dias de hoje. Dito de outra maneira, nunca ouvi o argumento de eficiência do Shift-JIS por alguém ainda o usando. ;-)
deceze

5
Ouvi dizer que a questão da eficiência é usada como desculpa para preguiça e inércia.
APENAS MINHA OPINIÃO correta

11
UTF-16 cria caracteres ASCII básicos [dos quais há um número considerável em, por exemplo, HTML] duas vezes maior. Pelo que entendi, isso acaba tornando o UTF-16 ainda pior do que o UTF-8 para páginas da web em japonês.
usar o seguinte código

2
@ APENAS Minha OPINIÃO correta: Tente "Exibir fonte" ou o equivalente. Supondo que todo o texto real esteja em japonês, é provável que existam muitas palavras-chave derivadas do inglês e representadas em ASCII.
precisa

4
Isso me parece uma razão para fazê-lo, depois encontramos . Tenho certeza de que a eficiência tem quase nada a ver com o status quo. Para mim, é apenas inércia e legado. Na verdade, eu também acho que tem a ver com o fato de que a maioria dos códigos produzidos por programadores japoneses é para outros japoneses, então eles nem sentem a necessidade de usar algo como Unicode.
Julien Guertault

2

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.


2

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.