43 votes

À quoi sert le "codage" dans l'en-tête XML ?

En regardant l'en-tête XML

<?xml version="1.0" encoding="UTF-16" standalone="no"?>

Ai-je raison d'affirmer que le encoding L'attribut est

  • arrive trop tard (vous ne pouvez pas le lire correctement sans connaître l'encodage...)
  • redondant, donc source d'erreurs : il est trop facile de le remplacer par "Big5" tout en enregistrant le fichier en UTF-8.

Ou cet attribut ne concerne pas le contenu du ruisseau ?

Est-ce que je mélange les choses ici ?

41voto

Joachim Sauer Points 133411

Comme vous l'avez mentionné, vous devez connaître l'encodage du fichier pour pouvoir lire le code de l'utilisateur. encoding attribut.

Cependant, il existe une heuristique qui peut facilement vous rapprocher suffisamment du "vrai" encodage pour vous permettre de lire l'attribut encodage. Cela fonctionne, car l'attribut <?xml par définition, ne peut contenir que des caractères de la gamme ASCII (quel que soit leur codage).

La norme XML a même décrit le processus exact utilisé pour découvrir l'encodage .

Et l'étiquette d'encodage n'est pas non plus redondante. Par exemple, si vous utilisez l'algorithme de la spécification XML pour découvrir qu'un encodage basé sur l'ASCII (ou compatible avec l'ASCII) est utilisé vous toujours doivent lire l'encodage pour savoir lequel est réellement utilisé (les candidats valides seraient ASCII, UTF-8, n'importe lequel des codes d'encodage de l'UE). Les encodages ISO-8859-* , l'un des Windows-* codages, KOI8-R et beaucoup, beaucoup d'autres). Pour le <?xml En soi, cela ne fera pas de différence, mais pour le reste du document, cela peut faire une énorme différence.

En ce qui concerne les fichiers XML mal étiquetés : oui, il est facile d'en produire, cependant La spécification XML spécifie clairement que ces fichiers sont mal formés et qu'en tant que tels, ils ne constituent pas un XML correct. Les encodages incorrects doivent être signalés comme une erreur (pour autant qu'ils puissent être détectés !). C'est donc le problème de celui qui produit le XML.

6voto

Michael Kay Points 52194

Vous avez tout à fait raison de dire qu'il s'agit d'une conception étrange. Il ne fonctionne que parce que la déclaration XML n'utilise que des caractères ASCII et que presque tous les codages sont des surensembles de l'ASCII. Si vous êtes prêt à accepter quelque chose qui n'est pas, par exemple, EBCDIC, vous pouvez vérifier si le fichier commence par ce que la représentation EBCDIC de "<?xml" est. Cela signifie que vous vous appuyez sur le niveau général de redondance dans l'en-tête du fichier, plutôt que sur l'attribut d'encodage lui-même. Comme beaucoup de choses en XML, c'est pragmatique et fonctionne, mais ce n'est pas particulièrement élégant.

2voto

Delan Azabani Points 33013

Les analyseurs XML doivent uniquement prendre en charge au moins UTF-8 et UTF-16. L'analyseur XML commence par essayer les codages basés sur la marque d'ordre des octets (BOM), si elle est présente (pour UTF-16, UTF-32 et même UTF-8 avec la BOM fictive). Si aucun n'est trouvé, l'analyseur essaiera alors UTF-32, UTF-16, UTF-8, ASCII et d'autres encodages à un octet compatibles avec ASCII. Ce n'est qu'à ce moment-là qu'il verra l'attribut d'encodage, et recommencera l'analyse si nécessaire.

0voto

Zsub Points 921

Je pense qu'en principe vous pourriez avoir un point que le encoding est "en retard" dans le fichier, mais la première ligne entière n'utilise que des caractères de base. A priori, ces caractères sont les mêmes dans presque tous les codages, donc quel que soit le décodage, il sera lu comme suit <?xml ... ?> de toute façon.

Tout ce qui vient après que cependant, pourrait avoir de l'importance. Par exemple, le texte d'une section CDATA pourrait être codé en cyrillique.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X