À quoi sert le 'encodage' 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 de déclarer que l'attribut encoding est
- arrive trop tard (vous ne pouvez pas le lire correctement sauf si vous connaissez l'encodage...)
- redondant, donc sujet aux erreurs: il est trop facile de le remplacer par" Big5 " mais Enregistrer le fichier en UTF-8
Ou cet attribut ne concerne-t-il pas le contenu du flux?
Est-ce que je mélange les choses ici?
4 réponses
Comme vous l'avez mentionné, vous devez connaître l'encodage du fichier pour lire l'attribut encoding.
Cependant, il existe une heuristique qui peut facilement vous rapprocher suffisamment de l'encodage "réel" pour vous permettre de lire l'attribut d'encodage. Cela fonctionne, car la partie <?xml par définition ne peut contenir que des caractères dans la plage ASCII (mais ils sont encodés).
La norme XML even décrit le processus exact utilisé pour trouver l'encodage.
Et le codage étiquette n'est pas redondant soit. Par exemple, si vous utilisez l'algorithme dans la spécification XML pour découvrir qu'un codage ASCII (ou compatible ASCII) est utilisé, Vous devez toujours lire l'encodage pour savoir lequel est réellement utilisé (les candidats valides seraient ASCII, UTF-8, l'un des encodages ISO-8859-* , l'un des encodages Windows-*, KOI8-R et beaucoup, beaucoup d'autres). Pour la partie <?xml elle-même, elle ne fera pas de différence, mais pour la partie <?xml reste du document, il peut faire une énorme différence.
En ce qui concerne les fichiers XML mal étiquetés: oui, il est facile de les produire, cependant: la spécification XML spécifie clairement que ces fichiers sont mal formés et en tant que tels NE SONT PAS XML correct. Les encodages incorrects doivent être signalés comme une erreur (tant qu'ils peuvent être détectés!). C'est donc le problème de celui qui produit le XML.
Vous avez tout à fait raison que cela ressemble à un design étrange. Cela ne fonctionne que parce que la déclaration XML utilise uniquement des caractères ASCII, et presque tous les encodages sont des supersets D'ASCII. Si vous êtes prêt à accepter quelque chose qui ne l'est pas, par exemple EBCDIC, vous pouvez vérifier si le fichier commence par quelle que soit la représentation EBCDIC de "<?xml". Ce qui signifie que vous comptez 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 pour beaucoup de choses en XML, c'est pragmatique et fonctionne, mais n'est pas particulièrement élégant.
Les analyseurs XML ne sont requis que pour prendre en charge au moins UTF-8 et UTF-16. L'analyseur XML commence par essayer les encodages 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 nomenclature factice). Si aucun n'est trouvé, l'analyseur essayera les encodages UTF-32, UTF-16, UTF-8, ASCII et autres encodages mono-octet compatibles ASCII. C'voir l'attribut de codage, et redémarrer l'analyse si nécessaire.
Je pense en principe que vous pourriez avoir un point que l'instruction encoding est 'en retard' dans le fichier, cependant, toute la première ligne n'utilise que des caractères de base. AFAIK, ce sont les mêmes dans presque tous les encodages, donc quoi que vous le décodiez, il lira <?xml ... ?> de toute façon.
Tout ce qui vient après que cependant, pourrait avoir son importance. Par exemple, le texte dans une section CDATA peut être codé dans un codage Cyrillique.