Convertisseur JSON vers XML
Qu'est-ce que la conversion JSON vers XML ?
JSON to XML convertit des données JSON structurées en balisage XML afin que l’information circule entre systèmes qui attendent des formats d’échange différents. JSON utilise objets, tableaux, nombres, chaînes, booléens et null, tandis que XML repose sur éléments, attributs, nœuds texte et espaces de noms. La conversion n’est donc pas toujours directe: noms de tableaux, mapping d’attributs, valeurs vides, caractères spéciaux et ordre doivent être représentés avec soin. L’outil sert aux intégrations proches de SOAP, systèmes d’entreprise anciens, migrations, payloads de test et documentation. En production, il faut valider contre le XSD, contrat API ou format partenaire attendu.
Comment utiliser
Comment utiliser
- Collez ou saisissez des données JSON dans la zone de saisie de gauche
- Personnalisez éventuellement le nom de l'élément racine
- Sélectionnez la taille d'indentation (2 espaces, 4 espaces ou tabulation)
- Le XML converti s'affiche à droite avec coloration syntaxique
- Cliquez sur « Copy » ou « Download » pour enregistrer le résultat
Vérifications de conversion
- Vérifiez les tableaux, les valeurs null et les champs de type attribut après la conversion : le JSON et le XML ne modélisent pas les données de la même manière.
- Choisissez un nom d'élément racine stable avant de coller le XML dans une requête API, un fichier de configuration ou un jeu de test.
Cas d’utilisation
Principe technique
JSON (RFC 8259, dérivé des littéraux objets JavaScript) et XML (W3C XML 1.0, initialement 1998) sont tous deux des formats de sérialisation arborescents, mais leurs grammaires diffèrent. JSON possède des objets (cartes clé/valeur à clés de type chaîne), des tableaux (listes ordonnées) et six types scalaires (chaîne, nombre, booléen, null, ainsi que les types structurels). XML possède des éléments (paires de balises ouvrante/fermante entourant du texte ou des éléments enfants), des attributs (paires nom/valeur sur la balise ouvrante), des nœuds texte, des commentaires, des instructions de traitement et des sections CDATA. La conversion est une transformation structurelle sans réponse canonique — chaque convention existante (BadgerFish, JSONML, SOAP/RPC encoding, le schéma plat d'OOXML, le format linkbase de XBRL) constitue un ensemble de règles différent pour la même entrée. La décision « attribut vs élément enfant » est l'ambiguïté centrale. Les seuls métadonnées de JSON résident dans le nom de clé, donc un objet JSON comme `{"id": "42", "name": "Alice", "admin": true}` ne précise pas quelles clés sont des « métadonnées » et lesquelles sont des « données ». Trois conventions courantes : (1) celle par défaut de la page — les scalaires deviennent du contenu texte, tandis que la clé JSON originale d'un sac d'attributs imbriqué (reconnu comme un objet non-tableau dont toutes les valeurs sont scalaires) devient un attribut XML préfixé par `@` (convention BadgerFish). (2) JSONML — chaque objet JSON devient un élément avec la clé 'tag' comme nom d'élément, la clé 'attr' comme carte d'attributs, et les entrées enfants comme enfants. (3) oData / Atom — les objets JSON deviennent des éléments et les tableaux sont imbriqués avec un élément conteneur portant le nom du tableau. Chaque règle est prouvablement correcte pour un certain consommateur en aval et prouvablement incorrecte pour un autre, ce qui explique qu'aucun convertisseur vers XML n'a jamais été universellement accepté. Les tableaux constituent la seconde ambiguïté. Les tableaux JSON sont des listes ordonnées ; XML n'a pas de type tableau natif. Les trois solutions standard : (a) répéter les éléments enfants (celle par défaut de la page, la convention OOXML/SOAP) : `[1, 2, 3]` → `<root><item>1</item><item>2</item><item>3</item></root>`. (b) Envelopper dans un conteneur : `<root><items><item>1</item>...</items></root>`. (c) Encoder le tableau sous forme d'une chaîne délimitée unique et documenter le délimiteur (CSV dans XML, uniquement lorsque le consommateur l'analyse). Chaque solution est correcte pour un XSD en aval différent ; l'étape de conversion doit savoir laquelle émettre. Les noms d'éléments XML doivent être des jetons QName valides (XML 1.0 §2.3 / XML Namespaces 1.0 §3) : commencer par une lettre, un underscore ou deux-points, puis lettres, chiffres, tirets, underscores, points ou deux-points. JSON autorise des clés comme '123' ou 'first name' qui violent cette règle — le convertisseur doit soit les renommer (slugifier en first_name, préfixer avec _) soit échouer. Le contenu des chaînes JSON nécessite également l'échappement des entités dans le texte des éléments et les valeurs d'attributs : `&` → `&`, `<` → `<`, `>` → `>` (uniquement requis dans le texte en XML ancien, mais toujours sûr), `"` → `"` et `'` → `'` dans les attributs, et tout caractère hors de la portée de l'encodage sous forme `&#xHHHH;`. Les cinq entités intégrées plus les références numériques de caractère sont obligatoires en XML ; les entités nommées supplémentaires de HTML (` `, `©`) ne sont pas définies en XML brut et nécessitent un DOCTYPE explicite si utilisées. Le document de sortie nécessite également un prologue et des déclarations d'espaces de noms : `<?xml version="1.0" encoding="UTF-8"?>` en premier, puis les déclarations xmlns. Si le système cible utilise des espaces de noms (SOAP utilise `http://www.w3.org/2003/05/soap-envelope`, XSLT utilise `http://www.w3.org/1999/XSL/Transform`), les correspondances de préfixes sont ajoutées sous forme d'attributs `xmlns:prefix="uri"` sur un élément racine. JSON n'a pas de concept d'espace de noms, donc le choix de l'URI à utiliser est propre au projet. Pour les valeurs vides, null en JSON est généralement exprimé sous forme de `<key xsi:nil="true"/>` (la convention XML Schema) ou `<key></key>` (la convention élément vide). Le convertisseur en choisit une ; la bonne réponse dépend de la validation XSD du consommateur. Pour la direction inverse (XML → JSON), les mêmes ambiguïtés se présentent en sens inverse : les attributs sont mappés vers une clé `@attributes` en BadgerFish, les CDATA sont mappés vers une clé `$` ou `#text`, les éléments à contenu mixte (texte + éléments enfants entremêlés) n'ont pas de représentation JSON propre et sont généralement émis sous forme de concaténation de chaînes. Les convertisseurs du monde réel exposent toujours des options 'clé d'attribut', 'clé de texte', 'conteneur de tableau' — il n'y a pas d'autre solution.
- JSON (RFC 8259) et XML (W3C XML 1.0, 1998) sont tous deux des formats de sérialisation arborescents ; la conversion est une transformation structurelle sans réponse canonique, de sorte que plusieurs conventions (BadgerFish, JSONML, SOAP, OOXML) coexistent pour la même entrée.
- Attribut vs élément enfant : les scalaires deviennent par défaut du contenu texte ; les objets sacs d'attributs imbriqués (valeurs uniquement scalaires) deviennent des attributs préfixés par @ (BadgerFish). JSONML utilise les clés 'tag' / 'attr'. oData / Atom utilise des éléments conteneurs.
- Tableaux : la page répète par défaut les éléments enfants (convention OOXML/SOAP). Alternatives : envelopper dans un élément conteneur, ou encoder sous forme de chaîne délimitée. L'ordre du tableau JSON est préservé dans la sortie XML.
- Règles de nommage des éléments XML : doivent commencer par une lettre, un underscore ou deux-points, puis lettres/chiffres/tires/underscores/points/deux-points (XML 1.0 §2.3). Les clés JSON comme '123' ou 'first name' sont des noms XML invalides et doivent être slugifiées ou rejetées.
- Échappement des entités : `&` → `&`, `<` → `<`, `>` → `>`, `"` → `"`, `'` → `'`, tout autre caractère d'encodage sous forme `&#xHHHH;`. Les 5 entités intégrées sont obligatoires ; les extras HTML comme ` ` nécessitent un DOCTYPE explicite.
- Prologue du document : `<?xml version="1.0" encoding="UTF-8"?>` est la première ligne standard. Les déclarations xmlns sur l'élément racine déclarent les préfixes d'espaces de noms ; JSON n'a pas de concept d'espace de noms, le convertisseur choisit par projet.
- null en JSON → XML : soit `<key xsi:nil="true"/>` (convention XML Schema), soit `<key></key>` (élément vide). Le choix doit correspondre au XSD du consommateur, sinon la validation échoue.
- La direction inverse XML → JSON présente les mêmes ambiguïtés : les sections CDATA deviennent des clés `$` ou `#text` (BadgerFish), les éléments à contenu mixte (texte + éléments enfants entremêlés) n'ont pas de forme JSON propre et sont généralement concaténés en une chaîne.
Exemples
Objet -> Élément
{"name": "Alice"}
->
<root>
<name>Alice</name>
</root>Tableau -> Éléments
[1, 2, 3]
->
<root>
<item>1</item>
<item>2</item>
<item>3</item>
</root>Structure imbriquée
{"user": {"name": "Alice", "age": 25}}
->
<root>
<user>
<name>Alice</name>
<age>25</age>
</user>
</root>FAQ
Comment le convertisseur fait-il correspondre JSON et XML ?
Chaque objet JSON devient un élément XML. Les clés d'objet deviennent des noms d'éléments enfants ; les valeurs primitives deviennent le texte de l'élément. Les tableaux répètent l'élément parent plusieurs fois. Les caractères spéciaux dans le texte sont échappés (& → &, < → <).
Pourquoi la conversion JSON vers XML n'est-elle pas toujours sans perte ?
JSON a des types explicites nombre/booléen/null ; XML n'a que du texte. JSON autorise des clés avec espaces ou caractères spéciaux ; les noms d'éléments XML, non. Les tableaux au niveau racine n'ont pas d'équivalent XML évident. La page utilise des heuristiques (élément racine « root », clés invalides nettoyées) pour combler ces écarts.
Comment les valeurs de tableau sont-elles représentées en XML ?
Chaque élément du tableau devient un élément frère portant le même nom. [{a:1},{a:2}] → <items><item><a>1</a></item><item><a>2</a></item></items>. L'enveloppe est configurable ; certaines pages permettent de choisir explicitement le nom singulier de l'élément.
Et les clés JSON qui ne sont pas des noms XML valides ?
Les noms d'éléments XML ne peuvent pas commencer par un chiffre, contenir des espaces ou inclure certains symboles. La page nettoie en remplaçant les caractères invalides par des underscores ou en les enveloppant dans une CDATA. Le résultat est un XML valide, mais l'aller-retour n'est pas exact.
Les valeurs JSON null et booléennes sont-elles préservées ?
null devient un élément vide ou est omis selon les paramètres. true/false deviennent le texte littéral « true » ou « false ». Il n'existe pas de standard XML pour ces types — les analyseurs en aval doivent appliquer leur propre interprétation de type.
Puis-je ajouter des attributs XML ?
JSON n'a pas de notion d'attribut, donc le générateur émet tout en éléments par défaut. Certains convertisseurs utilisent un préfixe de clé spécial (par exemple « @id ») pour indiquer un attribut — vérifiez les options de la page si la sortie en attributs est importante pour votre schéma XML.
La conversion est-elle locale ?
Oui. L'analyse JSON et la génération XML se déroulent dans votre navigateur. Les entrées ne sont pas téléversées.