Convertir un XML en JSON

Comment ça marche

Collez le texte XML dans le panneau de gauche ; le résultat apparaît à droite pendant que vous écrivez. La conversion suit quatre règles. Les attributs entrent dans l'objet avec un @ devant leur nom, pour ne pas entrer en collision avec une balise enfant qui porterait le même nom. Une balise qui ne contient que du texte devient directement ce texte ; si elle porte aussi un attribut ou une balise enfant, le texte est rangé sous la clé « #text ». Les balises qui se répètent sous le même parent, avec le même nom, sont regroupées dans un seul tableau et gardent leur ordre. Le contenu des sections CDATA est repris tel quel ; les commentaires et la déclaration <?xml?> sont ignorés. Si le document est mal formé, l'erreur indique la balise et la ligne où l'analyse s'est arrêtée — balise non fermée, fermeture qui ne correspond pas et valeur d'attribut sans guillemets sont signalées séparément. Vous pouvez copier le résultat en un clic ou le télécharger en fichier .json.

Cet outil est aussi connu sous le nom de convertir xml en json, xml en json, xml to json, parser xml en ligne, lire un fichier xml.

Qu'est-ce que XML ?

XML (Extensible Markup Language) est un format de document qui marque les données avec des balises imbriquées : chaque donnée vit entre une balise ouvrante et une balise fermante, et des informations supplémentaires s'accrochent aux balises sous forme d'attributs. Il ressemble à HTML, mais son jeu de balises n'est pas figé — les noms sont choisis par celui qui décrit les données. Beaucoup de systèmes d'entreprise et d'échanges entre administrations reposent encore sur XML : services SOAP, flux RSS, intérieur des fichiers bureautiques et fichiers de configuration utilisent ce format. Pour qu'un document soit « bien formé », il faut une seule balise racine, chaque balise fermée et chaque valeur d'attribut entre guillemets.

Qu'est-ce que CDATA ?

Une section CDATA est un bloc spécial qui dit à l'analyseur XML « traite tout ce qui suit comme du texte brut » ; elle s'écrit entre <![CDATA[ et ]]>. En temps normal, les caractères < et & présents dans un texte sont pris pour un début de balise ou d'entité et cassent le document ; pour y échapper, il faut soit écrire chaque caractère sous la forme &lt; ou &amp;, soit placer le texte dans une section CDATA. Pour un extrait de code, un fragment HTML ou un commentaire libre rempli de symboles, CDATA améliore nettement la lisibilité. Cet outil reprend le contenu CDATA tel quel, sans toucher aux caractères qu'il contient.

Quelle est la différence entre XML et JSON ?

Les deux transportent des données sous forme de texte, mais ils répondent à des questions différentes. XML est un langage de balisage : il enveloppe les données dans des balises, peut accrocher des attributs à une même balise, mêler du texte et de la structure, et répondre officiellement — via un schéma XSD — à la question « quels champs sont obligatoires dans ce document ». Ce niveau de détail sert dans les documents à valeur contractuelle. JSON est une notation de structures de données : objets, tableaux, nombres, chaînes et booléens, sans notion d'attribut, et plus compact. Les services web sont passés à JSON pour cette simplicité — presque tous les langages le lisent en une ligne. La vraie difficulté de la conversion vient de cette asymétrie : les attributs et les balises répétées de XML n'ont pas d'équivalent direct en JSON, d'où les règles comme le préfixe @ et le regroupement en tableau.

Les règles de conversion

Le modèle de données de XML et celui de JSON ne se recouvrent pas exactement ; chaque convertisseur doit donc annoncer ses règles. Voici celles que cet outil applique :

• Attribut → clé « @nom » : la balise <produit code="FR-11"> donne le champ « @code »
• Balise ne contenant que du texte → chaîne directe : <client>Karim</client> donne la valeur « Karim »
• Texte + attribut ou balise enfant → le texte va sous la clé « #text »
• Balises sœurs répétées sous le même nom → tableau ; l'ordre du document est conservé
• Balise vide (<note/>) → chaîne vide
• Le contenu CDATA est repris tel quel ; commentaires et déclaration <?xml?> sont ignorés

Objet seul ou tableau ? Le piège à connaître

La décision dépend du nombre de répétitions dans le document : une balise présente deux fois devient un tableau, une balise présente une fois devient un objet. XML lui-même ne porte aucune marque disant « ceci est toujours une liste » ; cette information ne vit que dans le schéma (XSD), qui n'est pas lu ici.

Conséquence pratique : deux documents de même structure peuvent produire des JSON différents. Une commande avec un seul produit donne un objet, une commande avec deux produits donne un tableau. Si votre code lit ce champ, vérifiez s'il s'agit d'un tableau — c'est l'erreur la plus fréquente dans les systèmes qui passent de XML à JSON.

Limites du périmètre : namespace, DTD et entités

Cet outil utilise un petit analyseur écrit à la main qui tourne dans le navigateur. Son périmètre est volontairement étroit, et ses limites sont écrites noir sur blanc :

• Les espaces de noms (namespace) ne sont pas résolus : « ns:balise » devient la clé « ns:balise », préfixe compris, et les attributs xmlns sont traités comme des attributs ordinaires
• La DTD et la déclaration <!DOCTYPE> sont ignorées ; les entités qui y seraient définies ne sont pas développées
• Seuls &amp; &lt; &gt; &quot; &apos; et les références numériques &#NNN; et &#xNN; sont résolus ; une entité inconnue reste telle quelle dans le texte
• Aucune validation de schéma (XSD) : l'outil vérifie seulement que le document est bien formé

Pourquoi le développement des entités est-il désactivé ?

Des entités définies dans une DTD peuvent s'appeler entre elles. Dix lignes de définitions peuvent, une fois développées, produire des gigaoctets de texte : c'est l'attaque classique dite « bombe d'entités » ou « milliard de rires », qui épuise la mémoire. Un analyseur qui développe les entités se fige en essayant de traiter un tel document.

Comme la conversion tourne sur votre appareil, c'est vous qui en paieriez le prix. La résolution d'entités est donc limitée à cinq abréviations connues et aux références numériques ; aucune définition qui lit une source externe ou se développe récursivement n'est traitée.

Questions fréquentes

Pourquoi les attributs commencent-ils par @ ?

En XML, une balise peut avoir à la fois un attribut « code » et une balise enfant « code » ; en JSON, les deux tomberaient sur la même clé et l'un des deux disparaîtrait. Le @ devant le nom de l'attribut évite cette collision. C'est une convention largement adoptée dans les conversions XML vers JSON.

Pourquoi le même XML donne-t-il parfois un objet, parfois un tableau ?

Ce n'est pas la structure qui change, ce sont les données : une balise présente une seule fois devient un objet, présente deux fois ou plus elle devient un tableau. Si un champ doit toujours être une liste, faites cette vérification du côté du code qui lit le résultat.

Les balises préfixées (ns:balise) fonctionnent-elles ?

Elles sont lues et converties, mais l'espace de noms n'est pas résolu : le préfixe reste dans la clé, donc « ns:balise » s'écrit aussi « ns:balise » en JSON. Les attributs xmlns ne sont pas supprimés non plus ; ils apparaissent comme champs « @xmlns ».

Le XML que je colle est-il envoyé quelque part ?

Non. L'analyse et la conversion se font entièrement dans votre navigateur ; que vous colliez une facture, une commande ou un fichier de configuration, rien ne quitte cette page.