Pourquoi Java utilise-t-il UTF-16 pour la représentation des chaînes internes?

J'imagine que la raison était rapide, comme l'accès au caractère à l'index, mais certains caractères ne tiennent pas en 16 bits, donc cela ne fonctionnerait pas ...

Donc, si vous devez gérer des cas spéciaux de toute façon, pourquoi ne pas simplement utiliser UTF-8?

java strings unicode mrpyo
la source

Quelque chose à demander aux concepteurs Java, pas à la communauté en général. Voter pour clôturer n'est pas constructif.

Odé

@Oded: absolument injustifié, comme le montre la réponse de DeadMG.

Michael Borgwardt

Je suis confus: j'étais presque sûr que cette question avait déjà reçu une réponse (ici et sur SO), mais je ne trouve pas le ou les doublons.

Joachim Sauer

Pour les raisins secs hystériques. Voir utf8everywhere.org

Pavel Radzivilovsky

Réponses:

Parce que c'était UCS-2 , qui était un joli 16 bits de longueur fixe. Bien sûr, 16 bits ne s'est pas avéré suffisant. Ils ont modernisé UTF-16 en haut.

DeadMG
la source

Voici une citation de la FAQ Unicode :

Originally, Unicode was designed as a pure 16-bit encoding, aimed at representing all modern scripts. (Ancient scripts were to be represented with private-use characters.) Over time, and especially after the addition of over 14,500 composite characters for compatibility with legacy sets, it became clear that 16-bits were not sufficient for the user community. Out of this arose UTF-16.

Au moment de la sortie de Java, UTF-16 n'était pas encore apparu et UTF-8 ne faisait pas partie de la norme Unicode.

Malcolm

UCS-2 est un terme technique, pas un mot à la mode.

DeadMG

Pour l'essentiel, dans un souci de pérennité clair et simple. Que ce soit une raison erronée et la mauvaise façon de procéder est une question différente.

Vous pouvez voir quelques raisons derrière certaines de leurs décisions de conception dans ce document sur le passage de 2004 à Java 5 et UTF-16, qui explique également certaines des lacunes: Caractères supplémentaires dans la plate-forme Java , et voir Pourquoi l'écosystème Java utilise-t-il différents encodages tout au long de leur pile? .

Pour plus de détails sur les pièges de l'utilisation de l'UTF-16, et pourquoi UTF-8 est susceptible d'être une meilleure option en général, voir UTF-16 devrait-il être considéré comme dangereux? et le manifeste UTF-8 Everywhere .

haylem
la source

+1 pour le lien vers le "UTF-16 doit-il être considéré comme dangereux?" question. J'ai récemment découvert le manifeste UTF-8 Everywhere et je crois que je suis maintenant assez convaincu. Pour ce que ça vaut, bien que Java se soit trompé, je suis assez convaincu que Windows a fait bien pire.

Daniel Pryden

Eh bien, ce n'est pas une surprise que Windows se soit trompé : ils ont fait le basculement vers Unicode plus tôt, ils avaient donc moins de choix corrects et moins d'expérience. Java a plus tard, il a obtenu plus droit , mais encore un peu de mal. Désormais, les deux doivent vivre avec de vieilles API incorrectes au sens général qu'ils doivent continuer à prendre en charge.

Joachim Sauer

C'est la vie dans le monde du logiciel, vous devez faire des choix sans avoir toutes les données, et quand vous vous trompez, vous en subissez les conséquences pendant longtemps. :-)

Brian Knoblauch

Je me demande quelles auraient été les implications en termes de performances de créer stringun type "spécial" en Java (tout comme l' Arrayest), plutôt que d'avoir Stringune classe "ordinaire" contenant une référence à un tableau "ordinaire" contenant les caractères réels. Selon la façon dont une chaîne est générée, UTF-8, UTF-16 ou même UTF-32 peut être le moyen le plus efficace de la stocker. Je ne pense pas qu'il existe un moyen particulièrement efficace pour une classe "ordinaire" Stringde gérer plusieurs formats, mais un type "spécial" avec prise en charge JVM le pourrait.

supercat

@supercat: Je n'ai pas exactement de réponse précise à cela, mais j'ai une réponse SO connexe pour cela. :) Ne traite pas vraiment de l'approche de type spécial, mais discute du gain potentiel d'avoir des chaînes rationalisées.

haylem