CDATA

Le terme CDATA, signifie character data, dans des langages par balisages SGML et XML où il est utilisé à des fins distinctes mais liées, pour délimiter des sections (ou zones) de texte sans balisage et sans référence. Le terme délimite une partie de document contenant des caractères quelconques du jeu de caractère utilisé, plutôt que des données de "non-character" dont la structure est spécifiquement définie.

Sections CDATA en XML

Dans un document XML ou une entité externe, une section CDATA est un morceau de contenu qui doit être interprété tel quel, en tant que donnée textuelle, et non comme du balisage. Une section CDATA est une autre syntaxe d'expression des données de caractères, pour exprimer la même sémantique, par exemple, "<" et "&" sont représentés par "<" et "&", respectivement.

Syntaxe et interprétation

Une section CDATA commence avec la séquence suivante:

<![CDATA[

et se termine avec l'occurrence:

]]>

Toutes les données présentes entre ces deux séquence sont interprétées comme des caractères, et non pas des références d'entité ou de balisage. Chaque caractère porte sa propre valeur, à la seule exception étant la séquence des deux crochets fermants ]]>. En:

<sender>Jean Dupont</sender>

les balises de début et fin de "sender" sont interprétées comme une balise. Alors que:

<![CDATA[<sender>Jean Dupont</sender>]]>

est équivalent à:

<sender>Jean Dupont</sender>

Ainsi, ce qui ressemble à une balise sera considéré comme "Jean Dupont"; comme du texte.

Similairement, dans la référence de caractère numérique (en anglais: numeric character reference) ð apparaissant dans un contenu, est simplement interprété en tant que caractère Unicode 00F0 qui représente la lettre minuscule (small letter en:eth). La même séquence dans une section CDATA, sera considéré comme six caractères distincts: ampersand, dièse, chiffre 2, chiffre 4, chiffre 0, point-virgule.

Utilisation des sections

Les nouveaux auteurs de documents XML peuvent se méprendre le but de section CDATA, croyant erronément que le but serait de "protéger" les données d'un traitement en tant que caractère ordinaire durant le traitement. Certaines APIs pour travailler avec des documents XML offrent des options pour un accès "indépendant" aux (ou plutôt discriminant des) sections CDATA, mais ces options sont en dehors (au dessus et au-delà) des exigences normale du traitement du XML, et ne change en rien la signification implicite du texte. Des caractères sont des caractères, qu'il soient exprimés dans une section CDATA ou en dehors. Les sections CDATA sont utiles à l'écriture de code XML en tant que texte à l'intérieur d'un document XML. Par exemple, pour écrire un livre en XSL expliquant le fonctionnement de données XML, le balisage XML devant apparaître dans le livre pourra être dans une section CDATA, car il ne fait pas partie du balisage XSL, mais des caractères à présenter au lecteur du livre..

Imbrication

Une section CDATA ne peut pas contenir la chaîne "]]>" ce qui ne permet pas à une section CDATA de contenir des sections CDATA imbriquées. Une approche courante pour coder le triplet de caractères "]]>" dans une section CDATA est d'utiliser plusieurs sections CDATA en découpant chaque occurrence du triplet juste avant la caractère ">". Par exemple le triplet "]]>" peut s'écrire:

<![CDATA[]]]]><![CDATA[>]]>

Ceci signifie que pour encoder le triplet "]]>" au milieu d'une section CDATA, chaque occurrence du triplet est remplacée par:

]]]]><![CDATA[>

Ceci arrête une section CDATA pour en commencer une autre.

Issues avec l'encodage

Les données texte, permettent l'utilisation de tous les caractères Unicode avec la syntaxe &#nnn; (numerical character reference), mais à l'intérieur de section CDATA seuls sont disponibles les caractères de l'encodage de caractères déclaré dans l'en-tête<?xml ...?>.

Pour cette raison, l'utilisation programmatique d'une section CDATA pour baliser des données qui pourraient potentiellement contenir des caractères '&' ou '<' peut poser des questions d'interprétation quand ces caractères n'existent pas dans l'encodage utilisé. Suivant l'implémentation de l'encodeur, ces caractères peuvent être perdus, être convertis dans un encodage quelconque &#nnn;, ou conduire à l'échec du décodage des caractères. Toutefois, ils ne seront pas maintenu en l'état.

Cette question se pose également lorsqu'un document XML est transcodé d'un encodage de caractères vers un autre au cours du transport (c'est-à-dire au cours d'un échange). Quand un document XML est convertit dans un jeu de caractère plus limité, comme l'ASCII, les caractères qui ne peuvent plus être représentés sont convertis en références de caractères &#nnn; pour une conversion sans perte. Dans une section CDATA, ces caractères ne peuvent pas du tout être représentés, ey doivent être supprimés, convertis, altérant le contenu de la section CDATA.

Utilisation de CDATA et sortie d'un programme

Les sections CDATA du documents XHTML sont sujettes à être parsées differament par des navigateurs web quand ils rendent le document comme du HTML, puisque les parseurs HTML ne reconnaissent ni les marques de début et de fin de sections CDATA, ni les references entity HTML telles que < à l'intérieur d'une balise <script>. Ceci peut poser question sur le rendu dans les navigateurs web et peut mener à des vulnérabilités cross-site scripting lors de l'affichage de données en provenance de sources "untrusted", puisque les deux types de parseurs ne s'accordent pas sur les caractères de fin de la section CDATA.

Voir aussi

• PCDATA

Notes et références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « CDATA » (voir la liste des auteurs).

Liens externes

• CDATA Confusion
• Character Data and Markup (in XML)