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

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 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.

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.

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.

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.

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.