Convertir JSON en XML

Un document XML a un seul élément extérieur. Un document JSON peut être un objet de quinze clés, ou un tableau, ou un simple nombre, et aucun d’eux ne porte de nom pour le conteneur. La conversion a donc une règle : un objet avec exactement une clé utilise cette clé comme racine, et tout le reste est enveloppé dans un élément appelé root. L’exception mérite d’être sue parce qu’elle attrape une des formes les plus courantes — si cette clé unique tient un tableau, {"items": [1, 2]}, l’utiliser comme racine écrirait <items> deux fois et produirait un document sans élément extérieur, si bien que <root> enveloppe l’ensemble à la place.

Le premier cas est celui qu’il faut viser, et c’est une petite édition du JSON si vous le contrôlez. Envelopper votre charge utile dans une seule clé nommée d’après ce qu’elle est — invoice, order, shipment — fait que le XML sort avec le nom d’élément que le système récepteur attend, plutôt qu’un wrapper générique que vous devrez renommer dans la sortie.

XML n’a pas de type tableau et n’en a jamais eu besoin : une liste est la même balise écrite plusieurs fois dans le même parent. Donc un objet tenant trois étiquettes produit trois éléments <tags> côte à côte, ce qui est exactement la forme que chaque consommateur XML gère déjà.

C’est l’endroit où XML est un meilleur contenant pour le JSON que les formats tabulaires. Convertir le même tableau en CSV oblige à choisir entre colonnes supplémentaires, chaîne jointe et lignes supplémentaires, et chacune de ces options est fausse pour quelque chose. En XML, la répétition est native, si bien qu’une commande comportant cinq lignes d’articles convertit sans qu’aucune décision doive être prise à votre place.

XML a deux façons d’attacher une valeur à un élément — un attribut dans la balise, ou un élément enfant — et les schémas se soucient beaucoup de laquelle. JSON n’en a qu’une. La convention ici fait le pont : une clé commençant par @ est écrite en attribut, et une clé appelée #text fournit le texte propre de l’élément aux côtés de ses enfants.

Cette convention n’est pas arbitraire ; c’est ce que produit le lecteur XML de ce site dans l’autre sens. Un document converti en JSON, édité, et reconverti en XML rend les attributs en tant qu’attributs plutôt que de les promouvoir en éléments, ce qui fait d’un aller-retour par JSON une manière utilisable d’éditer une charge utile XML. Si la réception attend id en attribut et que votre JSON l’a en clé simple, renommer cette clé en @id avant la conversion est toute la correction.

Les clés JSON peuvent être n’importe quelle chaîne : espaces, barres obliques, emoji, chiffre en première position, chaîne vide. Les noms d’élément XML ne le peuvent pas. L’écriture réécrit plutôt que d’échouer, et elle réécrit selon une liste délibérément étroite — A-Z, a-z, 0-9, souligné, point et trait d’union survivent, tout le reste devient un souligné, et un nom commençant par un chiffre en reçoit un devant. Donc « 2024 report » arrive en <_2024_report>.

La liste est plus étroite que celle de XML 1.0, et c’est le cas le plus susceptible de vous prendre : les noms d’éléments XML peuvent contenir des lettres accentuées, du grec, du cyrillique, du devanagari et du CJK, et cette écriture n’en garde aucun. Une clé nommée café arrive en <caf_> et 名前 arrive en <__>, donc une charge utile indexée autrement qu’en ASCII perd les noms plutôt que les valeurs. Le fichier est bien formé et les noms ne sont pas ceux que votre schéma déclare. Renommez ces clés dans le JSON, ou restructurez de sorte que la partie variable soit une valeur plutôt qu’une clé, ce que la partie XML allait de toute façon exiger.

XML apporte les espaces de noms, les schémas XSD, les DTD, les instructions de traitement, les sections CDATA et les signatures numériques — le registre note le support de signature comme l’un de ses traits, et c’est la raison pour laquelle le format reste l’épine dorsale des échanges bancaires et gouvernementaux. Rien de tout cela ne peut être dérivé d’un fichier JSON, parce que rien de tout cela ne s’y exprime.

Ce que cela signifie en pratique : la sortie est un document bien formé, pas un document valide. Si la réception valide contre un XSD, attendez-vous à devoir ajouter une déclaration d’espace de noms sur l’élément racine et possiblement à réordonner les éléments, puisque la séquence XSD est sensible à l’ordre et que l’ordre des objets JSON n’est pas significatif. Les deux sont des éditions de la sortie ou d’une petite étape XSLT, et les deux sont bien plus rapides une fois le document en main qu’ils ne le sont en théorie.

Les esperluettes, les chevrons et les guillemets doubles présents dans une valeur sont échappés à la sortie, ce qui empêche une description de produit contenant « Tom & Jerry <special> » de terminer le document prématurément. Tout le reste, y compris les apostrophes et tout caractère non ASCII, est écrit tel quel en UTF-8.

Un null JSON devient un élément vide : la balise est présente, sans rien entre ses moitiés ouvrante et fermante. C’est un choix délibéré et ce n’est pas le seul disponible — XML dispose aussi de xsi:nil précisément pour cela, et certains schémas l’exigent. Si le vôtre l’exige, les éléments vides sont à une recherche-remplacement près, et savoir lequel des deux votre consommateur attend mérite d’être vérifié avant la première livraison plutôt qu’après.

Le document est écrit avec une indentation de deux espaces et un élément par ligne, ce qui le rend lisible et rend lisible un diff entre deux charges utiles. Il ne commence pas par la ligne <?xml version="1.0"?>. XML 1.0 rend la déclaration facultative et définit UTF-8 comme encodage par défaut, si bien que le fichier est bien formé sans elle.

Un certain nombre de réceptions anciennes ne sont pas d’accord, et certaines échouent avec un message peu utile quand la ligne manque. C’est une ligne à ajouter en haut. Cela mérite d’être su avant une première soumission, parce que « le fichier est invalide » venant d’une file de middleware dit rarement laquelle des vingt choses possibles cela signifie.

Chaque valeur est enveloppée dans une balise ouvrante et une fermante, si bien que les noms de champ apparaissent deux fois par enregistrement au lieu d’une. Pour une charge utile de petites valeurs portant de longs noms de champ, le document peut être deux à trois fois plus gros que le JSON dont il vient, et l’indentation y ajoute.

C’est un coût réel sur une file avec une limite de taille de message et qui n’existe pas sur un transfert de fichier, qui est le cas de la plupart de ces livraisons en pratique. Là où cela compte, la réponse est la compression plutôt que la restructuration — XML est un texte hautement répétitif et se compresse extrêmement bien en gzip, et la plupart des réceptions qui limitent la taille de message acceptent une charge utile compressée.

Deux vérifications, dans l’ordre. La bonne formation d’abord : n’importe quel éditeur XML, navigateur ou analyseur en ligne de commande vous dira en une seconde si le document s’analyse, et une conversion qui aurait produit quelque chose d’inanalysable mérite d’être sue avant toute autre chose. Cela devrait toujours passer ici.

La validation contre le schéma ensuite, et attendez-vous à ce qu’elle échoue la première fois. Les échecs sont informatifs — un espace de noms manquant, un élément dans le mauvais ordre, un wrapper exigé que le JSON n’avait aucune raison d’inclure — et chacun est une petite correction dans le JSON ou dans la sortie. Faire cela une fois produit un modèle dans lequel vous pourrez convertir pour chaque charge utile suivante.

La conversion est du JavaScript dans cet onglet : le navigateur analyse le JSON, une petite écriture produit le XML, et aucune requête ne transporte le document ailleurs. Il n’y a ni inscription, ni file d’attente, ni quota journalier, et le niveau gratuit accepte jusqu’à 100 Mo.

Pour ce public, c’est souvent le facteur décisif plutôt qu’un détail. Les charges utiles qui doivent devenir du XML sont des paiements, des réclamations, des dépôts et des dossiers patients ou clients — les catégories exactes où coller un fichier dans un service web inconnu est un événement à signaler. Ici, rien n’est envoyé, il n’y a donc rien à signaler.