Introduction détaillée à l'encodage de documents XML à l'aide d'UTF-8

Le service Sitemap de Google exige que tous les plans de site publiés soient encodés au format UTF-8 d'Unicode. Google n'autorise même pas d'autres encodages Unicode comme UTF-16, encore moins les encodages non Unicode comme ISO-8859-1. Techniquement, cela signifie que Google utilise un analyseur XML non standard, puisque la recommandation XML exige spécifiquement que "tous les gestionnaires XML doivent accepter les encodages UTF-8 et UTF-16 d'Unicode 3.1", mais c'est c'est vraiment un gros problème ?

Tout le monde peut utiliser UTF-8

L'universalité est la première et la plus convaincante raison de choisir UTF-8. Il peut gérer tous les scripts actuellement utilisés dans le monde. Même s’il existe encore quelques lacunes, celles-ci deviennent de moins en moins évidentes et se comblent progressivement. Les textes qui ne sont pas inclus ne sont généralement implémentés dans aucun autre jeu de caractères et ne peuvent pas être utilisés en XML même s'ils le sont. Dans le meilleur des cas, ces scripts sont transmis via l'emprunt de polices à un jeu de caractères à un octet comme Latin-1. La véritable prise en charge de ces scripts rares viendra probablement en premier d'Unicode, et probablement seul Unicode les prend en charge.

Mais ce n'est qu'une des raisons d'utiliser Unicode. Pourquoi choisir UTF-8 au lieu d'UTF-16 ou d'autres encodages Unicode ? L’une des raisons les plus immédiates est la prise en charge étendue des outils. Fondamentalement, tous les principaux éditeurs pour XML peuvent gérer UTF-8, y compris JEdit, BBEdit, Eclipse, emacs et même Notepad. Aucun autre codage Unicode ne dispose d'une prise en charge aussi étendue parmi les outils XML et non XML.

Pour certains de ces éditeurs, tels que BBEdit et Eclipse, UTF-8 n'est pas le jeu de caractères par défaut. Il est désormais nécessaire de modifier les paramètres par défaut. Tous les outils doivent sélectionner UTF-8 comme codage par défaut à la sortie de l'usine. Si cela n’est pas fait, nous nous retrouverons coincés dans un bourbier de non-interopérabilité lorsque les fichiers voyageront au-delà des frontières, des plates-formes et des langues. Mais jusqu'à ce que tous les programmes utilisent UTF-8 comme codage par défaut, il est facile de modifier vous-même les paramètres par défaut. Dans Eclipse, par exemple, le panneau de préférences Général/Éditeurs illustré dans la figure 1 vous permet de spécifier que tous les fichiers utilisent UTF-8. Vous remarquerez peut-être qu'Eclipse s'attend à ce que la valeur par défaut soit MacRoman, mais si tel est le cas, le fichier ne sera pas compilé lorsqu'il sera transmis à un programmeur utilisant Microsoft® Windows® ou à un ordinateur en dehors des États-Unis et de l'Europe occidentale.

Figure 1. Modification du jeu de caractères par défaut d'Eclipse

Bien sûr, pour que UTF-8 fonctionne, tous les fichiers échangés par les développeurs doivent également utiliser UTF -8, mais ce n'est pas un problème. Contrairement à MacRoman, UTF-8 ne se limite pas à quelques scripts ou plateformes. Tout le monde peut utiliser UTF-8. MacRoman, Latin-1, SJIS et divers autres jeux de caractères nationaux hérités ne peuvent pas faire cela.

UTF-8 fonctionne correctement dans les outils qui ne prennent pas en charge les données multi-octets. D'autres formats Unicode tels que UTF-16 ont tendance à contenir de nombreux octets nuls. De nombreux outils interprètent ces octets comme une fin de fichier ou un autre délimiteur spécial, provoquant des résultats indésirables, inattendus et souvent désagréables. Par exemple, si les données UTF-16 sont chargées telles quelles dans C String, la chaîne peut être tronquée à partir du deuxième octet du premier caractère ASCII. Les fichiers UTF-8 ne contiennent que null où null est effectivement représenté. Bien entendu, un outil aussi naïf ne devrait pas être choisi pour traiter des documents XML. Cependant, les documents des systèmes existants finissent souvent dans des endroits étranges, et personne ne reconnaît ou ne comprend vraiment que ces séquences de caractères ne sont que du vieux vin dans des bouteilles neuves. UTF-8 est moins susceptible de causer des problèmes que UTF-16 ou d'autres codages Unicode sur les systèmes qui ne prennent pas en charge Unicode et XML.

Ce que disent les experts

XML est la première norme majeure à prendre entièrement en charge UTF-8, mais ce n'est que le début. Divers organismes de normalisation recommandent progressivement l'UTF-8. Par exemple, les URL contenant des caractères non-ASCII constituent un problème de longue date sur le Web. Les URL contenant des caractères non-ASCII qui fonctionnent sur un PC ne fonctionneront pas sur un Mac, et vice versa. Le World Wide Web Consortium (W3C) et l'Internet Engineering Task Force (IETF) ont récemment résolu ce problème en convenant que toutes les URL doivent être codées en UTF-8 et aucun autre encodage.

Le W3C et l'IETF deviennent plus stricts quant à l'utilisation de l'UTF-8 en premier, en dernier ou occasionnellement. Le modèle de caractères du W3C pour le World Wide Web 1.0 : principes fondamentaux indique : « Si un codage de caractères doit être choisi, il doit être UTF-8, UTF-16 ou UTF-32. US-ASCII est compatible vers le haut avec UTF-8 ( Les chaînes US-ASCII sont également des chaînes UTF-8, voir [RFC 3629]), donc si la compatibilité avec US-ASCII est requise, UTF-8 est très appropriée. « En fait, la compatibilité avec US-ASCII est si importante qu'elle l'est. presque obligatoire. Le W3C explique judicieusement : "Dans d'autres cas, comme pour les API, UTF-16 ou UTF-32 peuvent être plus appropriés. Les raisons du choix d'un codage peuvent inclure l'efficacité du traitement interne et l'interopérabilité avec d'autres processus." >Je suis d'accord avec la raison de l'efficacité du traitement interne. Par exemple, la représentation interne des chaînes dans le langage Java™ est UTF-16, ce qui rend l'indexation des chaînes plus rapide. Cependant, le code Java n'expose jamais cette représentation interne au programme avec lequel il échange des données. Au lieu de cela, pour l'échange de données externes, utilisez java.io.Writer, en spécifiant explicitement le jeu de caractères. Lors du choix, UTF-8 est fortement recommandé.

L'IETF est encore plus explicite. La politique de jeu de caractères de l'IETF [RFC 2277] stipule que dans les langages sans incertitude :

les protocoles doivent pouvoir utiliser le jeu de caractères UTF-8, qui comprend le jeu d'encodage ISO 10646 et le caractère UTF-8. méthode de codage, voir [10646] Annexe R (publiée dans la révision 2) pour le texte intégral.

De plus, le protocole peut spécifier comment utiliser d'autres jeux de caractères et schémas de codage de caractères ISO 10646, tels que UTF-16, mais l'impossibilité d'utiliser UTF-8 constitue une violation de cette politique. ne pas être inscrit ou promu dans la voie des normes. Au cours du processus, il est nécessaire de suivre la procédure de changement ([BCP9] Section 9) et de fournir des raisons claires et fiables dans le document de spécification du protocole.

Les protocoles existants, ou les protocoles de transfert de données à partir de magasins de données existants, peuvent devoir prendre en charge d'autres

ensembles de données

ou même utiliser des codages par défaut autres que UTF-8. Ceci est autorisé, mais doit pouvoir prendre en charge UTF-8. Point : La prise en charge des protocoles et des fichiers existants peut nécessiter l'acceptation de jeux de caractères et d'encodages autres que UTF-8 pendant un certain temps encore, mais je serais très prudent si cela devait être le cas. Chaque nouveau protocole, application et document doit utiliser UTF-8.

Chinois, japonais et coréen

Une idée fausse courante est que l'UTF-8 est un format compressé. Ce n'est pas le cas. En UTF-8, les caractères ASCII n'occupent que la moitié de l'espace par rapport aux autres codages Unicode, notamment UTF-16. Cependant, l'encodage UTF-8 de certains caractères occupe 50 % d'espace en plus, notamment les hiéroglyphes comme le chinois, le japonais et le coréen (CJK).

Mais même si CJK XML est codé en UTF-8, la taille réelle peut être inférieure à UTF-16. Par exemple, les documents XML chinois contiennent un grand nombre de caractères ASCII, tels que , &, =, ", ' et des espaces. Le codage UTF-8 de ces caractères est plus petit que UTF-16. Le codage spécifique /Les facteurs d'expansion varient selon le document, mais dans les deux cas, il est peu probable que la différence soit évidente

Enfin, il convient de mentionner que les écritures hiéroglyphiques telles que le chinois et le japonais utilisent des caractères par rapport aux écritures alphabétiques telles que comme le latin et le cyrillique. En raison du grand nombre de caractères, trois octets ou plus par caractère sont nécessaires pour représenter pleinement ces langues, c'est-à-dire que les mêmes mots ou phrases en anglais ou en russe peuvent être exprimés en moins. Par exemple, « arbre » est représenté par « bois » en japonais (un peu comme un arbre) et nécessite trois octets en UTF-8, tandis que le mot anglais « arbre » contient quatre lettres, nécessitant quatre octets. Le mot « grove » est « 林 » (deux arbres rapprochés). Le codage en UTF-8 nécessite trois octets, tandis que le mot anglais « grove » comporte cinq lettres et nécessite cinq octets. nécessite toujours trois octets, tandis que le mot anglais correspondant "forest" nécessite six octets

Si la compression est vraiment nécessaire, utilisez

zip

Après compression, les tailles de UTF-8. et UTF-16 sont similaires, quelle que soit la différence de taille d'origine. Quel que soit l'encodage, plus la taille d'origine est grande, moins la redondance est supprimée par l'algorithme de compression. >Le véritable avantage réside dans la conception, UTF-8 est un format plus robuste et plus facile à interpréter que tout autre encodage de texte jamais conçu avant ou depuis. Tout d'abord, par rapport à UTF-16, UTF-8 n'a pas le format . Le problème d'endianité. UTF-8 est représenté à la fois par big-endian et small-endian, car UTF-8 est basé sur des octets de 8 bits plutôt que sur des mots de 16 bits. UTF-8 n'a pas d'ambiguïté d'endianité, qui doit être résolue. via des drapeaux d'endianité ou d'autres heuristiques

L'une des caractéristiques les plus importantes de l'UTF-8 est l'apatridie. Chaque octet d'un flux ou d'une séquence UTF-8 est sans ambiguïté. En UTF-8, vous pouvez toujours connaître la position. Autrement dit, étant donné un octet, vous pouvez immédiatement déterminer s'il s'agit d'un caractère à un octet, du premier octet d'un caractère à deux octets ou du premier octet d'un caractère à deux octets. caractère à deux octets. Le deuxième octet, ou le deuxième, troisième ou quatrième octet d'un caractère à trois ou quatre octets (il existe d'autres possibilités, bien sûr, mais vous voyez l'idée). En UTF-16, il est impossible de déterminer si l'octet « 0x41 » est la lettre « A ». Parfois c’est le cas, parfois non. Un état suffisant doit être enregistré pour déterminer la position dans le flux. Si un octet est perdu, toutes les données suivantes seront inutilisables. En UTF-8, les octets manquants ou corrompus sont faciles à déterminer et n'affectent pas les autres données.

UTF-8 n'est pas une panacée. Les applications qui nécessitent un accès aléatoire à des emplacements spécifiques dans un document peuvent fonctionner plus rapidement en utilisant des codages à largeur fixe tels que UCS2 ou UTF-32. (Si vous prenez en compte les paires de substitution, UTF-16 est un codage de caractères de longueur variable.) Cependant, le traitement XML n'entre pas dans cette catégorie d'applications. La spécification XML exige spécifiquement que les analyseurs commencent l'analyse à partir du premier octet d'un document XML jusqu'au dernier octet, et tous les analyseurs existants le font. Un accès aléatoire plus rapide n'aide pas le traitement XML, et même si cela peut être une bonne raison d'utiliser un codage différent pour une base de données ou un autre système, cela ne s'applique pas à XML.

Conclusion

Dans un monde de plus en plus international, les frontières linguistiques et politiques s'estompent et les jeux de caractères qui dépendent de la région ne sont plus applicables. Unicode est le seul jeu de caractères pouvant interagir dans de nombreuses zones géographiques. UTF-8 est le meilleur encodage Unicode disponible :

Support étendu d'outils, y compris la meilleure compatibilité avec les systèmes ASCII existants.

Facile et efficace à manipuler.

Anti-corruption.

Indépendant de la plateforme.

Il est temps d'arrêter de discuter des jeux de caractères et des encodages, de choisir UTF-8 et de mettre fin au litige.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!