Convertir JSON en XML
JSON vers XML convertit un document dans votre navigateur. Les membres dont le nom commence par le préfixe d’attribut deviennent des attributs XML, un tableau répète le nom de son membre au lieu de recevoir un élément englobant, et une clé JSON qui n’est pas un nom XML légal est réécrite avec l’original préservé dans un attribut name plutôt que d’être abîmée en silence.
Comment fonctionne Convertir JSON en XML ?
Le sens difficile est généralement XML vers JSON, car XML a plus de structure. Aller dans l’autre sens demande moins de décisions, mais trois d’entre elles sont déterminantes, et se tromper sur l’une produit une sortie qui n’est pas du tout du XML bien formé.
Les clés JSON ne sont pas des noms XML
Une clé JSON peut être n’importe quoi : 2024 total, user.name, "", un émoji. Un nom d’élément XML ne peut pas commencer par un chiffre, ne peut pas contenir d’espace, et ne peut pas être vide. La réponse habituelle est de substituer des underscores, ce qui détruit la clé en silence. Ici, le nom est réparé de la même façon, et l’original est écrit dans un attribut name — si bien que le document est bien formé et que rien n’est perdu. Le nombre de clés réparées est signalé plutôt qu’enseveli.
Une racine tableau produirait deux éléments racine
Un document XML a exactement un élément racine ; ce n’est pas une règle de style, c’est ce qui fait qu’un document est un document. Écrire les éléments d’un tableau JSON de premier niveau au premier niveau produit autant de racines qu’il y a d’éléments, et chaque parser XML le rejette. Une racine tableau est donc enveloppée, et ses éléments prennent le nom d’item.
Un tableau qui est un membre est différent : il répète le nom d’élément du membre lui-même, car c’est ainsi que XML exprime une liste. Il n’y a pas d’élément conteneur à moins que le JSON en ait eu un, et c’est ce qui permet à la sortie de repasser par le convertisseur XML vers JSON avec le même élément dans une liste force-array.
L’échappement n’est pas optionnel
&, < et > dans le texte, plus " et les sauts de ligne littéraux dans les valeurs d’attributs, doivent tous être échappés, sinon la sortie est malformée. Le saut de ligne à l’intérieur d’un attribut est celui que les gens ratent : les parsers XML le normalisent en espace, sauf s’il est écrit , si bien que la valeur change silencieusement au retour.
XML est plus gros, et c’est le marché
Chaque nom d’élément est écrit deux fois. La différence de taille est signalée dans la barre de stats pour que le coût soit visible. Ce que cela achète, ce sont les attributs, les namespaces, les commentaires, les instructions de traitement et la validation par schéma — tout ce que JSON n’a pas, et dont n’importe lequel peut être la raison pour laquelle vous convertissez.
JSON
{
"@id": "1",
"line": ["a", "b"],
"note": null
}XML
<?xml version="1.0" encoding="UTF-8"?> <root id="1"> <line>a</line> <line>b</line> <note/> </root>
Quelles options et quels cas limites Convertir JSON en XML prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| Nom de la racine | nom d’élément | root | L’élément d’enrobage unique. Obligatoire, car un document XML possède exactement un élément racine, alors que le niveau supérieur du JSON n’en fournit pas. |
| Préfixe d’attribut | string | @ | Les membres commençant par ce préfixe deviennent des attributs. Correspond au convertisseur XML en JSON par défaut, afin qu’un document survive un aller-retour dans les deux sens. |
| Clé du texte | string | #text | Le membre écrit comme contenu d’élément plutôt que comme élément enfant. C’est ainsi qu’un élément peut posséder à la fois des attributs et du texte. |
| Nom de l’élément | nom d’élément | élément | Nom de l’élément pour les éléments d’un tableau de niveau supérieur, qui n’a pas de nom de membre à emprunter. Les tableaux qui sont des répètent le nom du membre à la place. |
| Indentation | espaces | 2 | Zéro émet une seule ligne, ce qui est souhaité pour le transport — les espaces entre les éléments sont significatifs pour un analyseur strict et le formatage modifie le document. |
| Déclaration | booléen | on | Émet <?xml version="1.0" encoding="UTF-8"?>. À désactiver lorsque la sortie est un fragment destiné à être intégré dans un document plus large. |
| Auto-fermer les vides | booléen | on | Les objets null et vides deviennent <a/> plutôt que <a></a>. Les deux sont identiques pour tout analyseur XML ; certains outils en aval sont plus stricts que la spécification. |
| Clé invalide | réparée | originale conservée | Une clé qui ne peut pas être un nom d’élément est réécrite et l’originale est écrite dans un attribut de nom. Le nombre de clés réparées est indiqué au-dessus de la sortie. |
| Échappement | automatique | — | & < > dans le texte ; & < > " et sauts de ligne dans les valeurs d’attribut. Un saut de ligne non échappé dans un attribut est normalisé en espace par le lecteur, ce qui change la valeur. |
Questions fréquentes
Comment obtenir des attributs plutôt que des éléments enfants ?
Préfixez le nom du membre avec @ — {"@id": "1"} devient id="1" sur l’élément. Le préfixe est configurable, et c’est la même valeur par défaut que celle qu’utilise le convertisseur XML vers JSON, pour qu’un document puisse aller de XML → JSON → XML et revenir avec la même forme.
Pourquoi ma clé a-t-elle été renommée ?
Parce que ce n’est pas un nom d’élément XML légal : il commençait par un chiffre, contenait un espace ou un caractère que XML n’autorise pas, ou était vide. Le nom d’élément est réparé et la clé d’origine est écrite dans un attribut name, si bien que rien n’est perdu et que le document est bien formé. Le nombre est affiché au-dessus de la sortie pour que vous sachiez que c’est arrivé.
Pourquoi n’y a-t-il pas d’élément englobant autour de mon tableau ?
Parce que XML exprime une liste en répétant l’élément, pas en l’enveloppant. {"line": ["a","b"]} devient deux éléments <line>, ce qui est du XML idiomatique et ce qui repasse correctement dans l’aller-retour. Si vous voulez <lines><line>…</line></lines>, mettez cette imbrication dans le JSON : {"lines": {"line": ["a","b"]}}.
Faut-il indenter la sortie ?
Pas pour ce qui part sur le réseau. Les espaces entre les éléments sont significatifs en XML — un parser strict voit votre indentation comme des nœuds texte, et pour du contenu mixte cela change réellement le document. Indentez pour la lecture, mettez indent à zéro pour l’envoi. C’est une vraie différence avec le JSON, où les espaces n’ont jamais d’importance.
Peut-il produire un document qui valide par rapport à mon XSD ?
Uniquement par coïncidence. Un schéma contraint l’ordre des éléments, la cardinalité, les types de données et les namespaces, et aucune de ces informations n’existe dans le JSON — les membres d’un objet n’ont pas d’ordre signifiant, donc le convertisseur ne peut pas savoir quelle séquence votre schéma exige. Servez-vous en pour obtenir la forme, puis réordonnez et ajoutez les namespaces pour correspondre au schéma.
Mon JSON est-il envoyé ?
Non. Le parsing et la conversion s’exécutent dans l’onglet déjà ouvert, ce que vous pouvez confirmer dans le panneau Réseau. La raison habituelle de convertir du JSON en XML est d’alimenter un ancien système d’entreprise, et les charges utiles en jeu sont rarement celles que vous voudriez voir passer par un serveur inconnu.