Formater et valider du XML en ligne

Un formateur et validateur XML qui reste dans votre navigateur

XML sert à échanger des données structurées : flux RSS, plans de site, factures électroniques, fichiers de configuration, exports de logiciels de gestion. Ils arrivent souvent sur une seule ligne, ou avec une balise mal fermée qui bloque l'import. Cet outil vérifie que le document est bien formé, le met en forme ou le compacte, l'affiche en arborescence et le convertit en JSON.

Collez le texte dans « Votre XML » ou ouvrez un fichier. La vérification se fait à chaque modification : « XML bien formé. », ou bien la ligne, la colonne et la cause de l'erreur avec un extrait surligné et le bouton « Aller à l'erreur ».

Mode d'emploi

1. Choisissez le « Résultat » : « Formater », « Minifier », « XML → JSON » ou « JSON → XML ».
2. Réglez l'« Indentation » (2 espaces, 4 espaces ou tabulation), la place des « Attributs » (Sur la ligne de la balise ou Un par ligne) et cochez ou non « Conserver les commentaires ».
3. Passez en « Arborescence » pour déplier les éléments. Un clic sur une balise ou un attribut affiche son chemin XPath, par exemple /catalog/product[2]/@ref, que « Copier le chemin » met dans le presse-papiers. La recherche parcourt balises, attributs et textes.
4. Cliquez sur « Copier » ou « Télécharger ».

Bien formé ou valide ?

Un document bien formé respecte la syntaxe de XML ; un document valide respecte en plus un schéma (DTD ou XSD) qui fixe les balises permises. Cet outil contrôle la bonne formation, pas la conformité à un schéma. Les règles : un seul élément racine, des balises fermées dans l'ordre inverse de leur ouverture, des valeurs d'attributs entre guillemets, des noms sensibles à la casse, et & et < échappés dans le texte.

Exemple : avec <commande> en ligne 1, <article>Stylo en ligne 2 (deux espaces de retrait) et </commande> en ligne 3, l'outil annonce « ligne 3, colonne 1 : </commande> trouvé alors que <article>, ouverte ligne 2, colonne 3, n'est pas fermée ». Le DOMParser du navigateur contrôle ensuite le même texte et affiche son propre message s'il relève un autre défaut.

CDATA, espaces de noms et entités

Une section <![CDATA[ … ]]> contient du texte brut où < et & n'ont pas besoin d'être échappés. Son contenu est recopié tel quel, au formatage comme à la minification. Même chose pour le texte des éléments, le contenu mixte et les éléments marqués xml:space="preserve".

Un préfixe comme p:price doit être déclaré par xmlns:p="…" sur l'élément ou sur un parent, sinon l'outil le signale. Sans DTD, seules cinq entités nommées existent : &amp;, &lt;, &gt;, &quot; et &apos;, plus les références numériques comme &#233;. Les entités externes ne sont jamais chargées : le DOMParser du navigateur ne va chercher aucun fichier ni aucune adresse déclarés dans un DOCTYPE, ce qui écarte les attaques XXE.

Convertir XML en JSON, et l'inverse

La conversion suit une convention simple : attributs préfixés par @, texte par #text, CDATA par #cdata, éléments répétés regroupés dans un tableau, valeurs toujours en chaînes. Ainsi <article ref="X1" qte="2">Stylo</article> donne {"article":{"@ref":"X1","@qte":"2","#text":"Stylo"}}, et le chemin inverse redonne la même balise. Les commentaires et l'ordre entre balises de noms différents ne sont pas conservés.

Questions fréquentes

Un fichier de 20 Mo va-t-il bloquer la page ?

Non. La mise en forme tourne en arrière-plan ; seule la vérification par le navigateur occupe brièvement la page. Au-delà de 2 Mo, seul le début du résultat est affiché, mais « Copier » et « Télécharger » portent sur la totalité.

Pourquoi mon chemin XPath ne trouve-t-il rien dans mon programme ?

Le plus souvent à cause d'un espace de noms par défaut (xmlns="…") : la plupart des bibliothèques exigent alors un préfixe déclaré dans le code.

Le formatage modifie-t-il mes données ?

Non. Les blancs entre balises sont réécrits, les espaces à l'intérieur des balises sont normalisés, mais textes, valeurs d'attributs et guillemets restent identiques. Un élément qui ne contient que des blancs devient vide.