Convertir du JSON en XML

Ce qu’implique la conversion de JSON en XML

JSON et XML peuvent décrire les mêmes données, mais ils n’ont pas les mêmes articulations. JSON dispose d’objets et de tableaux ; XML dispose d’éléments qui peuvent se répéter, d’attributs accrochés à une balise, et de texte pouvant cohabiter dans un élément à côté de ses enfants. Passer de JSON à XML revient donc à décider quelle clé devient une balise, laquelle devient un attribut, et que faire d’un tableau — autant de choses que JSON lui-même ne signale pas.

Aucune norme ne régit cette décision. Le W3C n’a jamais défini d’encodage JSON du XML : chaque outil adopte donc une convention, et les conventions divergent. Ce convertisseur utilise la plus répandue, celle de Json.NET de Newtonsoft, de xml2js et de Spark : une clé commençant par @ devient un attribut, une clé nommée #text devient le texte propre de l’élément, et toute autre clé devient un élément enfant. BadgerFish utilise $ pour le texte, et la convention Parker abandonne purement et simplement les attributs.

Puisque la correspondance relève d’un choix et non d’une règle, cette page nomme la convention qu’elle applique et vous avertit, pour votre document précis, de tout ce qui ne reviendra pas à l’identique si vous convertissez dans l’autre sens.

Comment convertir du JSON en XML

1. Collez votre JSON dans le volet de gauche. Le XML apparaît à droite au fil de la frappe, sans bouton à cliquer. « Charger un exemple » remplit le volet avec un petit catalogue montrant des attributs, un élément répété et un tableau.
2. Réglez la mise en forme de la sortie. Choisissez une seule ligne ou une indentation de deux ou quatre espaces, et décidez d’inclure ou non la déclaration XML en tête. Ces deux réglages n’affectent que le texte obtenu, jamais la structure.
3. Lisez les avertissements, puis copiez. Sous les volets, l’outil énumère tout ce que la forme de vos données ne permet pas de récupérer, et le nombre d’occurrences. S’il indique que rien n’a été perdu, votre document entre dans la convention. « Copier le résultat » place le XML dans le presse-papiers.

Ce que la convention attend de votre JSON

XML n’admet qu’un seul élément racine : le JSON doit donc être un objet doté d’une unique clé pour le nommer. Un tableau au niveau supérieur, ou un objet à deux clés, n’a pas d’écriture fidèle en tant que document, et l’outil le dit plutôt que d’inventer une balise enveloppante que vous n’avez pas demandée.

Sous la racine, les clés commençant par @ deviennent des attributs et une clé #text devient le texte propre de l’élément. C’est ce qui permet à un élément de porter à la fois un attribut et du contenu : un objet doté de @id et de #text produit une balise avec un attribut id enveloppant un fragment de texte, exactement ce que vous auriez écrit à la main.

Un tableau devient la même balise répétée une fois par élément, car c’est ainsi que XML exprime une liste — il n’y a pas de crochets. Cette règle se lit naturellement dans la sortie, et elle est aussi à l’origine de la limite principale ci-dessous, puisque XML n’a aucun moyen de signaler qu’une répétition était censée être une liste.

Ce qui ne survit pas au trajet retour, honnêtement

La conversion de JSON en XML puis retour a été mesurée sur environ 1 700 documents générés : 72,8 % sont revenus identiques octet pour octet. Tous les échecs, sans exception, tenaient à exactement deux causes, et une fois celles-ci déduites le résidu inexpliqué était nul — les limites ci-dessous sont donc précisément celles-là et aucune autre.

La première est un tableau d’un seul élément. Il s’écrit comme une balise unique, et une balise unique se relit comme une valeur simple, car rien dans le XML n’indique qu’une liste était voulue. Un tableau de deux éléments ou plus revient parfaitement : le trou concerne spécifiquement le tableau d’un seul. L’outil le signale dès qu’il en rencontre un.

La seconde est un tableau imbriqué dans un autre tableau. Répéter une balise permet d’exprimer un niveau de liste et pas davantage, si bien que les tableaux internes s’aplatissent dans le tableau externe. Ce cas est également signalé.

Deux détails sur les noms méritent d’être connus. Une clé JSON peut être n’importe quelle chaîne, mais un nom de balise XML non : une clé comportant une espace, ou commençant par un chiffre, n’est pas une balise légale. Plutôt que d’émettre du XML malformé, le convertisseur renomme ces clés — « first name » devient « first_name » — et signale qu’il l’a fait, puisque la clé elle-même a changé. Par ailleurs, une clé contenant un deux-points est écrite comme un nom qualifié par espace de noms. C’est du XML bien formé, mais ce n’est valide au sens de la spécification Namespaces in XML que si la déclaration xmlns correspondante figure elle aussi dans votre JSON — à vérifier si vous écrivez des préfixes à la main plutôt que de faire l’aller-retour d’un document qui les portait déjà.

Pourquoi est-ce gratuit ?

La conversion consiste en une analyse et une réécriture, toutes deux effectuées dans votre navigateur au fil de la frappe. Rien n’est envoyé : il n’y a donc aucun coût serveur à récupérer, ni aucune raison de vous demander un compte avant de vous laisser convertir vos propres données.

Cela signifie aussi aucun filigrane sur la sortie, aucune limite de taille posée pour vous pousser vers un abonnement, et aucun plafond sur le nombre de documents traités.