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
écrit en franç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 "é">
<!ENTITY c-cedille "ç">
]>
<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.
|
