Qu’est-ce qu’un fichier XML ?

XML est un format texte que n’importe quel éditeur ouvre. Il est utilisé pour l’échange entre programmes.

L’extension est .xml et le nom complet Extensible Markup Language. L’un et l’autre comptent moins que ce que le fichier peut contenir, et c’est le sujet du reste de cette page.

W3C l’a publié en 1998. La spécification est XML 1.0.

À un format resté lisible aussi longtemps, on peut confier quelque chose qu’on veut retrouver dans dix ans.

Elle est publiée intégralement : n’importe qui peut l’implémenter à partir du document plutôt qu’en l’observant, et c’est pourquoi ce format apparaît dans tant de programmes et pourquoi des fichiers écrits il y a vingt ans s’ouvrent encore. Une spécification publiée n’est pas pour autant libre de redevances : quand un format enveloppe un codec, les brevets sont une question à part, que la norme ne tranche pas.

XML enregistre son contenu à l’identique. Le réenregistrer ne change rien : vous pouvez l’ouvrir, le modifier et le réenregistrer autant de fois que vous voulez sans accumuler de dégâts, et c’est ce qui en fait un format de travail plutôt qu’un format de livraison.

XML a une syntaxe de commentaires, et c’est la différence entre un fichier qu’une personne entretient et un fichier qu’un programme écrit. Les commentaires sont la première chose perdue en convertissant vers un format qui n’en a pas, et rien ne vous prévient.

Visual Studio Code et oXygen XML Editor le lisent, comme la plupart des programmes du même genre.

Quand un fichier ne s’ouvre pas, le format est rarement en cause : le plus souvent, c’est le programme qui est plus ancien que lui. Convertir vers quelque chose de plus ancien est le contournement fiable, et c’est à cela que sert le reste de ce site.

Tous les navigateurs actuels le lisent.

Vous pouvez donc le poser sur une page ou l’attacher à un message sans vous demander ce que le destinataire a installé.

XML est fait pour être ouvert et modifié. Gardez le fichier dans ce format tant que le travail dure, et exportez depuis lui chaque fois qu’une version finie est nécessaire.

XML ne décrit rien par lui-même. C’est un ensemble de règles pour baliser un document avec des éléments et des attributs imbriqués, et le sens vient de tout vocabulaire construit par-dessus — RSS, SVG, SOAP, XBRL, HL7, fichiers sitemap, mises en page Android, l’intérieur de chaque fichier Office et OpenDocument. Le format est l’ossature d’une demi-douzaine d’autres formats utilisés tous les jours, et c’est ce qui explique à la fois sa longévité et sa difficulté d’apprentissage : il n’a jamais été conçu pour un seul usage, et chaque usage a empilé ses propres conventions par-dessus.

Donc « un fichier XML » en dit autant sur le contenu que « un fichier texte ». Ce qui compte, c’est le vocabulaire qu’il suit, et celui-ci est en général déclaré dans l’élément racine ou par un schéma que le document pointe. C’est aussi pour cela qu’ouvrir un fichier XML dans un navigateur affiche un arbre générique plutôt qu’une mise en forme : sans le vocabulaire connu, le navigateur ne sait qu’en faire, et c’est en général le bon comportement parce qu’il force à aller voir ce que contient le fichier plutôt qu’à le rendre comme quelque chose qu’il n’est pas.

Bien formé signifie que la syntaxe est correcte : un élément racine unique, chaque balise fermée, des éléments correctement imbriqués, des attributs entre guillemets, et les caractères & et < échappés là où ils sont censés être du texte. Les trois autres caractères réservés sont plus étroits qu’on ne l’enseigne d’habitude : > ne doit être échappé qu’à l’intérieur de ]]>, et les guillemets seulement là où ils termineraient l’attribut dans lequel ils se trouvent. Un analyseur refuse tout ce qui s’en écarte — XML est délibérément strict, et à la différence de HTML il n’y a pas de récupération d’erreur.

Valide signifie en plus conforme à un schéma : cet élément peut contenir tels éléments, cet attribut est obligatoire, cette valeur doit être une date. Un document peut être parfaitement bien formé et complètement inadapté à son propos, et un analyseur validant est ce qui saisit la différence. Dans les échanges réglementés, cette validation est le contrat, et c’est largement la raison pour laquelle XML reste là où il est.

Les espaces de noms existent pour que deux vocabulaires puissent être combinés sans que leurs noms d’éléments se télescopent — un tableau XHTML et un tableau de catalogue de mobilier dans le même document. Un espace de noms est identifié par un URI, qui est un nom et pas une adresse : rien n’y est récupéré, et il n’a pas besoin de pointer sur quoi que ce soit.

Ils sont aussi la source principale de bogues d’analyse XML. Une requête écrite pour un élément sans tenir compte de son espace de noms ne trouve rien, en silence, et le document a l’air correct à un humain qui le lit. Si un analyseur affirme qu’un document ne contient pas un tel élément alors que vous le voyez, l’espace de noms est la première chose à vérifier. Un second piège courant est celui de l’espace de noms par défaut, qui s’applique aux éléments sans préfixe et que beaucoup d’auteurs oublient de déclarer en lisant le document, ce qui produit des requêtes qui ne trouvent rien et des messages d’erreur qui ne mentionnent pas la cause réelle.

La première ligne d’un fichier XML bien élevé déclare la version et l’encodage des caractères. À la différence d’un fichier texte brut, cela fait de l’encodage une partie du document plutôt qu’une devinette — ce qui explique pourquoi XML gère le texte international de façon plus fiable que CSV ou INI ne l’ont jamais fait.

Deux conséquences à connaître. Un fichier déclarant un encodage et enregistré dans un autre est cassé d’une manière qui produit des erreurs d’analyse déroutantes plutôt que des caractères visiblement faux. Et une marque d’ordre des octets placée avant la déclaration contrarie certains analyseurs, donc « UTF-8 sans BOM » est le réglage à préférer ici comme ailleurs.

XML dispose d’un mécanisme pour définir des abréviations — une entité — et historiquement elle pouvait pointer vers une ressource externe. Un analyseur qui résout ces entités lira des fichiers locaux ou effectuera des requêtes réseau pour le compte de celui qui a fourni le document.

C’est la vulnérabilité XXE, et elle a produit de vraies brèches en exposant des fichiers serveur à travers un téléversement d’apparence anodine. Une astuce apparentée, l’attaque « billion laughs », imbrique des définitions d’entités pour qu’un petit fichier se déploie en gigaoctets et épuise la mémoire. Le fait que les entités externes soient résolues par défaut varie d’une bibliothèque à l’autre plutôt que d’être tranché — les analyseurs intégrés de Java et lxml de Python les résolvent tous les deux sauf instruction contraire — donc c’est un réglage à vérifier plutôt qu’à présumer. Tout XML venu de l’extérieur est une entrée de confiance douteuse.

XPath adresse n’importe quelle partie d’un document avec une expression compacte, et c’est réellement excellent — une seule ligne extrait chaque élément de prix à l’intérieur d’un produit dont l’attribut catégorie correspond. XSLT transforme un document XML en un autre, ou en HTML ou en texte, de façon déclarative. XSD définit et applique un schéma. Les trois sont des standards, les trois sont matures, et les équivalents en JSON sont arrivés plus tard et sont moins uniformément pris en charge.

C’est ce que les gens veulent dire quand ils affirment que XML est verbeux mais capable. Les chevrons sont le prix ; la machinerie de requête, de transformation et de validation est ce qui s’achète, et dans les industries qui en ont besoin il n’y a toujours rien de tout à fait équivalent.

N’importe quel éditeur de texte l’ouvre, et un éditeur avec prise en charge XML vaut la peine d’être possédé : il replie les sections, vérifie la bonne formation au fil de la frappe, et met joliment en page un fichier arrivé en une seule ligne énorme — ce qui est la forme habituelle d’arrivée d’un XML généré par machine. Les navigateurs rendent aussi XML comme un arbre repliable, ce qui est la façon la plus rapide de regarder un fichier inconnu.

Convertir en JSON est courant et avec perte dans un sens : les attributs n’ont pas d’équivalent JSON et reçoivent un nom de clé inventé, et le contenu mixte — du texte avec du balisage à l’intérieur — n’a aucune représentation du tout. Un XML en forme de données se convertit proprement ; un XML en forme de document ne survit pas à l’aller-retour. Convertir en CSV ne fonctionne que là où le document est réellement une liste plate de fiches portant des chevrons.