Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Si vous vous posez une question, vous n'êtes peut-être pas le premier...Les traductions en français des bibles XML.Ces articles sont des références dans leur domaine.Tout ce qu'il faut savoir pour démarrer sur un sujet XML...


Encodages, entités et caractères spéciaux.

Cette introduction explique comment et pourquoi en accordant à Unicode un rôle central, en ne définissant que cinq entités prédéfinies et en adoptant un modèle d'architecture en couches, XML modifie les habitudes des développeurs habitués à HTML.

Eric van der Vlist, Dyomedea (vdv@dyomedea.com).
lundi 15 janvier 2001

XML et Unicode

Meta-langage destiné à être universellement utilisé sur Internet, XML accorde un rôle particulier à l'encodage Unicode un standard ISO qui est également l'encodage intégrant le plus grand nombre d'alphabets.

Les deux encodages Unicode (UTF-8 et UTF-16) sont ainsi les seuls encodages que la recommandation XML 1.0 impose à tous les parseurs XML:

    "Tous les processeurs XML doivent être à même de lire les entités en UTF-8 ou UTF-16."

La recommandation ajoutant toutefois que:

    "Bien que seul le soutien des codages UTF-8 et UTF-16 ne soit requis des processeurs XML, il est clair que d'autres codages sont couramment utilisés et qu'il peut être souhaitable que les processeurs XML puissent lire les entités qui les emploient. En absence d'information de codage de caractères externe (comme des en-têtes MIME), les entités analysables stockées dans un codage autre qu'UTF-8 ou UTF-16 doivent commencer par une déclaration de texte contenant une déclaration de codage"

S'il est donc possible d'écrire des documents XML utilisant d'autres encodages que UTF-8 ou UTF-16, ces encodages pourront donc ne pas être gérés pas tous les processeurs XML et ces documents devront spécifier explicitement l'encodage utilisé, Unicode étant considéré comme l'encodage par défaut en l'absence de déclaration.

Cette préférence pour Unicode est accentuée par l'interprétation qu'en on fait les API DOM et SAX qui sont à la base de la majorité des outils XML. Ceux-ci ont fait d'Unicode leur unique encodage de travail.

La recommandation DOM Level 1 spécifie ainsi que:

    "Les applications doivent encoder une DOMString en utilisant UTF-16 (définit dans l'annexe C.3 de [UNICODE] et l'amendement 1 de [ISO-10646]). L'encodage UTF-16 fut choisi parce qu'il s'agit d'un standard largement utilisé dans l'industrie."

Et l'API SAX, initialement conçue pour Java s'appuie sur les types de caractères Java qui, eux aussi, utilisent Unicode.

Quel que soit l'encodage utilisé dans votre document XML, celui-ci sera donc traduit par les parseurs SAX ou DOM en caractères Unicode avant traitement.

Le deuxième point qui frappe les développeurs HTML s'attaquant à XML est le petit nombre de "caractères spéciaux" permettant de désigner des caractères non- ascii.

Les caractères spéciaux HTML appelés "entités générales internes" ou plus communément entités dans la terminologie XML et permettant de définir des caractères accentués, des symboles monétaires et autres copyright ou espaces insécables dans des encodages où ils peuvent ne pas exister ne sont pas nécessaires pour XML qui s'appuyant sur Unicode permet d'insérer tous ces caractères sans avoir recours à cet artifice.

Ces caractères spéciaux ne sont donc pas prédéfinis en XML et doivent être définis dans une DTD avant de pouvoir être utilisés.

Si cette définition est réalisée dans certaines DTDs comme XHTML (pour des raisons de compatibilité) ou DocBook, pour la plupart des vocabulaires XML et en particulier pour XSLT, ces entités ne sont pas définies et un parseur XML générera une erreur s'il rencontre par exemple " " ou "é".

Les seules exceptions sont, bien entendu, les entités nécessaires à inclure les caractères de balisage ("&", "<", ">", "'" et """).

Par contre, il est possible d'insérer un caractère en utilisant sa valeur numérique décimale ("&NNNNN;") ou hexadécimal ("&xXXXX;"), cette valeur étant, quelque soit l'encodage utilisé par le document, la valeur Unicode du caractère.

Pour en terminer avec cette introduction sur les entités, il faut encore remarquer que la recommandation XML 1.0 indique que lorsqu'un processeur XML inclut une entité, le texte de remplacement est substitué à celui de l'appel:

    "Une entité est incluse quand son texte de remplacement est récupéré et traité, à la place de l'appel lui-même, comme s'il se trouvait dans le document à l'endroit où l'appel est reconnu. Le texte de remplacement peut contenir des données textuelles et du balisage (sauf des entités paramètres) qui doit être reconnu de la manière habituelle, sauf que le texte de remplacement des entités utilisées pour déguiser des délimiteurs de balisage (les entités amp, lt, gt, apos, quot) est toujours traité comme des données. (La chaîne « AT&T; » devient « AT&T; » et l'esperluette restante n'est pas reconnue comme un délimiteur d'appel d'entité). Un appel de caractère est inclus quand le caractère en question est traité à la place de l'appel lui-même."

Ces deux facteurs (définition d'un encodage unique comme encodage "pivot" et remplacement pur et simple des entités ont favorisé le développement d'une architecture en couches dans laquelle les parseurs XML dégagent complètement les applications du traitement des caractères non-ascii.

Comment représenter les caractères "spéciaux" dans vos documents XML?

La conséquence pratique est que quels que soient l'encodage utilisé et la manière d'inclure un caractère (en le tapant directement, en indiquant sa valeur ou en utilisant une entité définie dans une DTD), les parseurs XML fourniront exactement la même information sous la même forme aux applications qui manipuleront vos documents.

Ainsi donc des documents qui incluent directement les caractères:

<?xml version="1.0" encoding="UTF-8"?>
<mon-document>
      Ceci est un document
écrit en français.
</mon-document>

qui font référence à leurs valeurs:

<?xml version="1.0" encoding="UTF-8"?>
<mon-document>
      Ceci est un document
&#233;crit en fran&#231;ais.
</mon-document>

ou utilise des entités définies dans une DTD (interne ou externe):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mon-document [
      <!ENTITY e-accent-aigu "&#233;">
      <!ENTITY c-cedille "&#231;">
]>
<mon-document>
      Ceci est un document
&e-accent-aigu;crit en fran&c-cedille;ais.
</mon-document>

seront vus exactement de la même manière par les applications XML.

Pour écrire vos documents XML, le seul conseil est donc d'utiliser Unicode si l'éditeur que vous utilisez le permet.

Le support d'Unicode étant loin d'être un cas général au niveau des éditeurs de texte, un encodage courant tel que "ISO-8859-1" supporté par la plupart des outils constitue un second choix très acceptable.

Pour le reste, puisque le résultat au niveau des applications est le même, choisissez simplement la formulation qui vous semble la plus facile en fonction des outils que vous utilisez!

Solution extrême, l'utilisation systématique de références aux caractères non-ascii par leur valeur permet d'éditer des documents "labellisés" "UTF-8" en utilisant un éditeur de texte ascii, puisque le jeu des caractères ascii constitue le tronc commun des encodages UTF-8 et ISO-8859-1.

Comment contrôler l'écriture des "caractères spéciaux" après traitement ?

La deuxième angoisse lorsque l'on débute en XML est le contrôle de la manière dont ces caractères vont être écrits après traitement et notamment après transformation XSLT.

Ce problème est plus délicat à résoudre qu'il n'y parait. En effet, l'interface permettant de contrôler la syntaxe utilisée pour sauvegarder un arbre XML sous forme de document n'a pas fait l'objet de normalisation.

Il faudra donc choisir l'outil répondant à vos exigences au niveau du formatage et utiliser les mécanismes de contrôle propres à cet outil.

Heureusement, dans la majorité des cas, le problème ne se pose pas puisque si vous cherchez à sauvegarder un arbre sous forme de document XML la manière dont seront exprimés les caractères ne devrait pas être importante, les différentes syntaxes étant réputées équivalentes.

Le cas de XSLT est un peu particulier, notamment lorsque le document généré est un document HTML.

Une transformation XSLT met en jeu un minimum de trois documents: un document XML source, le source de la transformation XSLT et un document résultat.

Le processeur XSLT est une application XML qui accède à ces documents sources en utilisant un parseur SAX ou DOM classique et, comme nous l'avons vu, il ne voit qu'une représentation de ces documents, codée en Unicode, de laquelle il ne peut tirer aucune information sur la manière dont les caractères ont été codés dans les documents source.

Cela signifie que les seules informations dont dispose un processeur XSLT pour contrôler la syntaxe des documents résultats sont celles qui sont contenues dans l'instruction xsl:output dont je rappelle la syntaxe:

<!-- Catégorie: élément de haut niveau -->
         <xsl:output
               method = "xml"| "html" | "text" | qname-but-not-ncname
               version = nmtoken
               encoding = string
               omit-xml-declaration = "yes" | "no"
               standalone = "yes" | "no"
               doctype-public = string
               doctype-system = string
               cdata-section-elements = qnames
               indent = "yes" | "no"
               media-type = string />

C'est dans cette instruction que vous pourrez notamment spécifier le type de document généré (XML, HTML ou texte) et l'encodage à utiliser.

A part cela, vous ne pourrez guère que faire confiance au processeur XSLT que vous utiliserez pour générer un document qui sera lisible par les outils XML, les navigateurs HTML ou sous forme de texte simple.

Dans le cas de la méthode de sortie HTML, il convient de faire attention à l'encodage choisi et, UTF-8 n'étant pas correctement affiché par tous les navigateurs, on pourra préférer utiliser "ISO-8859-1". La méthode de sortie HTML codera ensuite, indépendamment de la manière dont ils étaient représentés dans les documents sources et suivant des critères propres à chaque outil, les caractères spéciaux sous forme numérique ou sous forme de références à des entités HTML prédéfinies.

Conclusion.

L'architecture en couches retenue pour le traitement des documents XML permet de dégager totalement les applications XML des détails syntaxiques que sont les caractères non-ascii.

Cela présente de gros avantages et permet, dans la grande majorité des cas, de ne pas vous soucier de la manière dont seront codés et décodés ces caractères.

Pour les rares cas plus spécifiques, si les outils classiques ne vous permettent pas d'obtenir le résultat que vous souhaitez, il ne vous restera plus qu'à écrire un outil (parseur ou méthode de sortie) spécialisé tel que celui que j'ai décrit dans un article publié sur XML.com.

  

Copyright 2001, Eric van der Vlist.


 

Mots clés.



L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.


Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org