Je n'ai jamais compris le point de l'encodage UTF-16. Si vous avez besoin d'être en mesure de traiter les chaînes de caractères comme à accès aléatoire (c'est à dire un point de code est le même qu'une unité de code), alors vous avez besoin d'UTF-32, depuis UTF-16 est toujours de longueur variable. Si vous n'en avez pas besoin, puis UTF-16 semble être un gaspillage colossal de l'espace par rapport à l'UTF-8. Quels sont les avantages de l'UTF-16 au cours de l'UTF-8 et UTF-32 et pourquoi Windows et Java de l'utiliser comme leur encodage natif?
Réponses
Trop de publicités?
Lorsque Windows NT a été conçu UTF-16 n'existait pas (NT 3.51 est né en 1993, tout en UTF-16 est né en 1996 avec l'Unicode 2.0 de la norme); il y avait à la place de l'UCS-2, qui, à l'époque, était suffisante pour contenir tous les caractères disponibles dans Unicode, donc le 1 code = 1 code unité d'équivalence est vrai - pas de longueur variable logique nécessaire pour les chaînes.
Ils se sont déplacés vers l'UTF-16 ans plus tard, à l'appui de l'ensemble du jeu de caractères Unicode; cependant ils ne pouvaient pas passer à l'UTF-8 ou UTF-32, parce que cela aurait cassé la compatibilité binaire dans l'interface API (entre autres choses).
Comme pour Java, je ne suis pas vraiment sûr; car il a été publié en ~1995 je soupçonne que UTF-16 était déjà dans l'air (même si ce n'était pas normalisée encore), mais je pense que la compatibilité avec les systèmes d'exploitation de NT a peut-être joué un rôle dans leur choix (en continu UTF-8 <-> UTF-16 le nombre de conversions pour chaque appel à l'Api Windows peuvent introduire un certain ralentissement).
Modifier
Wikipedia explique que, même pour Java, il est allé dans le même sens: c'initialement pris en charge UCS-2, mais a déménagé en UTF-16 dans J2SE 5.0.
Ainsi, en général, quand vous voyez UTF-16 utilisé dans certaines API/Framework c'est parce qu'il a commencé UCS-2 (pour éviter les complications dans la chaîne de gestion des algorithmes), mais il se déplaçait vers l'UTF-16 pour soutenir les points de code en dehors de la BMP, en maintenant toujours le même code de la taille de l'unité.
user3162129
Points
21
Aucune des réponses indiquant un avantage de l'UTF-16 au cours de l'UTF-8 a aucun sens, sauf pour la rétro-compatibilité répondre.
Eh bien, il y a deux bémols à mon commentaire.
Erik états: "UTF-16, couvre l'ensemble de BMP avec des unités individuelles - Donc, sauf si vous avez un besoin pour les plus rares personnages à l'extérieur de la BMP, UTF-16 est effectivement 2 octets par caractère."
Mise en garde 1)
Si vous pouvez être certain que votre application n'a pas besoin de n'importe quel caractère à l'extérieur de la BMP, et que toute bibliothèque de code que vous écrivez pour une utilisation avec elle ne sera JAMAIS utilisé avec n'importe quelle application avez besoin d'un personnage à l'extérieur de la BMP, vous pouvez utiliser l'UTF-16, et d'écrire un code qui fait l'hypothèse implicite que chaque personnage sera exactement deux octets de longueur.
Qui semble extrêmement dangereux (en fait, stupide).
Il y pourrait jamais être un caractère unique à l'extérieur de la BMP qu'une application ou un code de bibliothèque peuvent, à un certain point, la nécessité de traiter avec, code qui suppose que tous UTF-16 caractères à deux octets dans la longueur de la pause.
Par conséquent, le code qui examine ou manipule UTF-16 doivent être écrites pour gérer le cas d'un caractère UTF-16 nécessitant plus de 2 octets.
Donc, je suis "rejetant" cette mise en garde.
Par conséquent, UTF-16 n'est pas plus simple de code pour que l'UTF-8 (code pour les deux doivent gérer de longueur variable des caractères).
Mise en garde 2)
UTF-16 POURRAIENT être plus efficaces de calcul, dans certaines circonstances, si convenablement écrit.
Comme ceci: Supposons que certaines chaînes sont rarement modifiées, mais souvent examinés (ou mieux, jamais modifiée, une fois intégré, c'est à dire, un générateur de chaîne de la création de inmodifiable de chaînes de caractères). Un indicateur peut être défini pour chaque chaîne, indiquant si la chaîne ne contient que des "fixe de caractères de longueur (c'est à dire, ne contient pas de caractères qui ne sont pas exactement les deux octets de longueur). Les chaînes pour lesquelles le drapeau est vrai, pourrait être examinée avec un code optimisé qui suppose de longueur fixe (2 octets) caractères.
Comment l'espace-efficacité?
UTF-16 est, évidemment, le plus efficace pour A) les caractères pour lesquels UTF-16 exige moins d'octets pour coder que de l'UTF-8.
UTF-8 est, évidemment, le plus efficace pour B) les caractères pour lesquels UTF-8 nécessite moins d'octets pour coder que UTF-16.
Sauf pour de très "spécialisé" du texte, il est probable que le comte(B) dépasse de loin le comte(Un).
Martin Beckett
Points
60406
UTF16 est généralement utilisé comme un mapping direct sur multi-byte character sets, c'est à dire onyl l'origine 0-0xFFFF caractères assignés.
Cela vous donne le meilleur des deux mondes, vous avez fixé la taille des caractères mais on peut toujours l'impression que tous les personnages n'importe qui est susceptible de l'utiliser (orthodoxe Klingon religous scripts sont exclus)
Ted Hopp
Points
122617
UTF-16 permet à l'ensemble des basic multilingual plane (BMP) pour être représentée comme de simples unités de code. Les points de code Unicode au-delà de U+FFFF sont représentés par des paires de substitution.
La chose intéressante est que Java et Windows (et d'autres systèmes que l'utilisation de l'UTF-16) fonctionnent toutes à l'unité de code de niveau, pas le point de code Unicode niveau. Si la chaîne de caractères composée du seul caractère U+1D122 (SYMBOLE MUSICAL F CLEF) est codé en Java, comme "\ud824\udd22" et "\ud824\udd22".length() == 2 (pas 1). Si c'est le genre de hack, mais il s'avère que les personnages ne sont pas de longueur variable.
L'avantage de l'UTF-16 au cours de l'UTF-8 est que l'on serait donner trop si le même hack ont été utilisés avec de l'UTF-8.
