Quels problèmes poussent les utilisateurs à utiliser des encodages spécifiques au japonais plutôt qu'Unicode?


24

Au travail, je rencontre beaucoup de fichiers texte japonais en Shift-JIS et d'autres encodages. Il provoque de nombreux problèmes de mojibake (caractère illisible) pour tous les utilisateurs d'ordinateurs. Unicode était destiné à résoudre ce type de problème en définissant un jeu de caractères unique pour toutes les langues, et la sérialisation UTF-8 est recommandée pour une utilisation sur Internet. Alors pourquoi tout le monde ne passe-t-il pas des encodages spécifiques au japonais à UTF-8? Quels problèmes ou inconvénients de l'UTF-8 retiennent les gens?

EDIT: Le W3C répertorie certains problèmes connus avec Unicode , cela pourrait-il également être une raison?


En fait, de plus en plus de sites populaires sont en UTF-8, un exemple est ニ コ ニ コ 動画 et は て な
Ken Li

8
Pourquoi tout le monde ne passe-t-il pas d'ISO-8851-1 à UTF-8?
ysdx

1
Il est mentionné en passant ici que la conversion SHIFT-JIS -> UTF-8 n'est pas sans perte, ce qui serait une raison majeure de continuer à utiliser SHIFT-JIS là où il est déjà utilisé. J'ai trouvé ce factoïde ostensible surprenant, cependant, j'espérais que l'une des réponses ici pourrait entrer plus en détail ou au moins fournir une source pour la réclamation, mais aucune ne le fait.
Kyle Strand


@LudwigSchulze Merci. Toujours pas beaucoup de détails, mais au moins une source officielle ...
Kyle Strand

Réponses:


28

En un mot: l'héritage.

Shift-JIS et d'autres encodages ont été utilisés avant qu'Unicode ne soit disponible / populaire, car c'était le seul moyen d'encoder le japonais. Les entreprises ont investi dans des infrastructures qui ne prennent en charge que Shift-JIS. Même si cette infrastructure prend désormais en charge Unicode, ils sont toujours bloqués avec Shift-JIS pour diverses raisons allant de ça marche donc ne le touchez pas à l' encodage quoi? la migration de tous les documents existants est trop coûteuse .

Il existe de nombreuses sociétés occidentales qui utilisent toujours ASCII ou latin-1 pour les mêmes raisons, mais personne ne le remarque car cela ne cause jamais de problème.


8
L'industrie japonaise du logiciel ... plus lente que la saleté à utiliser de nouveaux logiciels / normes.
Mark Hosang

2
@Mark Truer n'a jamais été prononcé! (Je travaille dans / avec l'informatique japonaise ... -_- ;;)
Deceze

5
Certes, mais les entreprises occidentales ont l'excuse que notre logiciel hérité est plein d'hypothèses codées en dur de 1 octet = 1 caractère, ce qui rend la transition vers UTF-8 plus difficile que pour les Asiatiques qui ont longtemps dû écrire du code propre à MBCS.
dan04

@MarkHosang Je confirme que votre déclaration est correcte à 100% (je travaille pour une entreprise japonaise à Tokyo)
Hassan Tareq

9

Ce sont les raisons dont je me souviens avoir été invoquées pour ne pas avoir fait de UTF-8 ou d'une autre représentation Unicode le codage de caractères par défaut pour le langage de script Ruby, qui est principalement développé au Japon:

  • Raison 1: l' unification des Han . Les jeux de caractères (je ne sais pas si les "alphabets" seraient corrects ici) utilisés en Chine, en Corée et au Japon sont tous liés, ont évolué à partir de l'histoire commune, pas sûr des détails. Le consortium Unicode a décidé de ne gaspiller qu'un seul point de code Unicode pour encoder toutes les variantes (chinois, japonais et coréen) du même caractère historique, même si leur apparence diffère dans les 3 langues. Leur raisonnement est que l'apparence doit être déterminée par la police utilisée pour afficher le texte.

Apparemment, ce raisonnement est aussi perçu comme ridicule par les utilisateurs japonais qu'il le serait de faire valoir aux lecteurs anglais que, parce que l'alphabet latin s'est développé à partir de l'alphabet grec, il suffit de n'avoir qu'un seul point de code pour l'alpha grec ". α "et latin" a ", et laissez l'apparence être déterminée par la police utilisée. (Idem pour "β" = "b", "γ" = "g", etc.)

(Notez que je ne serais pas en mesure d'inclure des caractères grecs ici sur stackexchange si c'était le cas.)

  • Raison 2: conversions de caractères inefficaces. La conversion de caractères d'Unicode en encodages japonais anciens et inverses nécessite des tables, c'est-à-dire qu'il n'y a pas de calcul simple de la valeur de point de code Unicode en valeur de point de code hérité et vice versa. Il y a également une certaine perte d'informations lors de la conversion car tous les points de code d'un codage n'ont pas une représentation unique dans l'autre codage.

D'autres raisons ont peut-être été données dont je ne me souviens plus.


Il semble qu'à partir de 2.0 Ruby ait adopté UTF-8 par défaut. Mais l'unification Han semble être une ride très importante (et un problème assez controversé ) dans le monde d'Unicode qui, apparemment, n'attire pas suffisamment l'attention, car je n'en ai jamais entendu parler auparavant.
Kyle Strand

Et voici un article de Wikipédia sur la question de l'unification des Han: en.wikipedia.org/wiki/Han_unification Cela semble en effet être une question valide, une excellente réponse! De plus, la perte de date serait une bonne raison.
spbnick

8

La réponse de deceze contient un élément de vérité très fort, mais il y a une autre raison pour laquelle Shift-JIS et d'autres sont toujours utilisés: UTF-8 est horriblement inefficace pour certaines langues, principalement dans l'ensemble CJK. Shift-JIS est, IIRC, un codage large de deux octets alors que UTF-8 est généralement de 3 octets et parfois même de 4 octets dans ses codages avec CJK et autres.


7
Bien que cela soit vrai, il y a toujours l'alternative de l'UTF-16, qui peut être aussi efficace que Shift-JIS. Je dirais également que le mal de tête de gérer différents encodages l'emporte de loin sur la légère augmentation de la taille de nos jours. En d'autres termes, je n'ai jamais entendu l'argument de l'efficacité de Shift-JIS par quiconque l'utilise encore. ;-)
décompose le

5
J'ai entendu le problème d'efficacité utilisé comme excuse pour la paresse et l'inertie.
JUSTE MON AVIS correct le

1
UTF-16 fait deux fois plus de caractères ASCII de base [dont il y a un nombre important, par exemple HTML]. Si je comprends bien, cela finit par rendre l'UTF-16 encore pire que l'UTF-8 pour les pages Web japonaises.
Random832

2
@JUST Mon AVIS correct: Essayez "Voir la source" ou l'équivalent. En supposant que tout le texte réel est en japonais, il y aura probablement beaucoup de mots-clés et similaires dérivés de l'anglais et représentés en ASCII.
David Thornley

4
Cela me semble être une raison de le faire, nous le trouvons par la suite . Je suis sûr que l'efficacité n'a presque rien à voir avec le statu quo. Pour moi, c'est juste l'inertie et l'héritage. En fait, je pense aussi que cela a à voir avec le fait que la plupart du code produit par les programmeurs japonais est destiné à d'autres Japonais, donc ils ne ressentent même pas le besoin d'utiliser quelque chose comme Unicode.
Julien Guertault

2

Comptez la taille des chaînes / l'utilisation de la mémoire parmi les principales raisons.

Dans UTF-8, les langues est-asiatiques ont souvent besoin de 3 octets ou plus pour leurs caractères. En moyenne, ils ont besoin de 50% de mémoire en plus que lors de l'utilisation de l'UTF-16 - ce dernier étant déjà moins efficace que l'encodage natif.

L'autre raison principale serait l'héritage, comme le souligne le gel.


2

La taille de l'héritage et du stockage, comme d'autres l'ont dit, mais il y a encore une chose: les personnages Katakana.

Il ne faut qu'un octet pour représenter les caractères Katakana dans Shift-JIS, donc le texte japonais, y compris Katakana, prend moins de 2 octets par caractère (1,5 pour un mélange 50/50), ce qui rend Shift-JIS un peu plus efficace que UTF-16 (2 octets) / char), et beaucoup plus efficace que UTF-8 (3 octets / char).

Un stockage bon marché aurait dû en faire un problème beaucoup plus petit, mais apparemment pas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.