Formateur XML

Un formateur construit sur des expressions régulières — insérant un saut de ligne avant chaque `<` et indentant selon un compte continu de balises ouvertes — fonctionne passablement sur du XML simple écrit à la main et échoue sur des documents réels pour des raisons faciles à manquer jusqu'à ce qu'elles causent un fichier corrompu. Une section CDATA, écrite `<![CDATA[...]]>`, existe spécifiquement pour contenir du texte arbitraire pouvant lui-même contenir des caractères ressemblant à des balises, et une expression régulière cherchant `<` n'a aucun moyen de savoir qu'elle devrait ignorer tout entre ces marqueurs plutôt que de traiter le contenu comme de la structure. Les commentaires portent le même risque, et les valeurs d'attribut sont pires encore : un attribut comme `note="a > b"` contient un caractère `>` littéral qu'un scanner naïf peut confondre avec la fin de la balise, la tronquant silencieusement au mauvais endroit.

Formater du XML correctement signifie que le scanner doit reconnaître ces régions spéciales — blocs CDATA, commentaires, instructions de traitement, déclarations DOCTYPE, et valeurs d'attribut entre guillemets — avant de chercher quoi que ce soit ressemblant à une structure de balises, pour que leur contenu soit transféré octet par octet plutôt que réinterprété comme du balisage.

Cet outil vérifie que chaque balise est correctement fermée et correctement imbriquée — les règles structurelles rendant un document XML « bien formé » — et signale la balise précise déséquilibrée ou non fermée quand cette vérification échoue. Ce qu'il ne fait pas, c'est valider le document contre une DTD ou un XML Schema (XSD), ce qui vérifierait en plus si les éléments, attributs et leurs valeurs précises respectent les règles d'un type de document particulier — si un attribut requis est présent, si un élément apparaît dans le bon contexte, si une valeur correspond à un type de donnée attendu. C'est une vérification réellement différente et plus élaborée nécessitant le document de schéma lui-même comme entrée supplémentaire, pas quelque chose qu'un formateur à usage général peut déduire du seul XML.

Le XHTML strict est du XML valide et se formate correctement ici, mais le HTML ordinaire du monde réel ne l'est pas, pour des raisons intégrées dans la spécification HTML elle-même : des éléments vides comme `<br>` et `<img>` ne se ferment jamais et n'ont aucune balise de fermeture, plusieurs balises ont des balises de fermeture optionnelles que les navigateurs déduisent automatiquement, et les navigateurs tolèrent une imbrication malformée que l'analyse XML stricte rejetterait directement. Un formateur XML strict appliqué à du HTML typique signalerait des erreurs sur chaque page parfaitement normale et bien formée, ce qui explique précisément pourquoi le HTML a un formateur séparé construit autour d'un vrai analyseur HTML comprenant ces règles spécifiques au HTML plutôt que de traiter le document comme du XML strict.

Le JSON a remplacé le XML comme choix par défaut pour les nouvelles API web, mais une grande partie de l'infrastructure a été construite avant ce changement et fonctionne encore dessus : services web SOAP, flux RSS et Atom, images SVG (elles-mêmes du XML), formats de documents Office en interne, et une longue traîne de systèmes d'entreprise et formats de configuration antérieurs à la popularité du JSON. Quiconque s'intègre avec l'un de ces systèmes plus anciens ou plus formels doit encore lire, déboguer et produire du XML bien formé, ce qui est précisément le public que continue de servir un formateur XML dédié même quand le XML a reculé dans la conception de nouvelles API.