Convertisseur JSON en XML

JSON vers XML et inversement : un convertisseur pratique pour deux mondes de données

La plupart des développeurs travaillent avec le XML et le JSON, qu'ils le veuillent ou non. Les API web modernes parlent presque exclusivement le JSON, mais dès que vous touchez à une banque, un assureur, un point d'accès gouvernemental, un ERP d'entreprise ou un ancien service SOAP, le XML refait surface. Le convertisseur JSON vers XML de cette page transforme le JSON en XML et le XML de nouveau en JSON directement dans votre navigateur, ce qui vous permet de naviguer entre ces deux formats sans copier des charges utiles sensibles dans un service distant.

Ce que sont réellement le XML et le JSON

Le XML (Extensible Markup Language) est un format de balisage bâti autour de balises imbriquées, d'attributs et d'espaces de noms. Il a été conçu pour les documents et l'échange de données structurées, et il transporte beaucoup de machinerie : schémas (XSD), espaces de noms, instructions de traitement, commentaires, sections CDATA et une déclaration formelle en tête. Cette richesse explique pourquoi le XML domine encore dans les systèmes anciens et d'entreprise. On le trouve dans les services web SOAP, les flux RSS et Atom, les fichiers de configuration (Spring, Maven, configurations d'applications .NET), les formats de documents bureautiques et les normes de messagerie financière comme SWIFT et ISO 20022, où banques et assureurs continuent d'échanger du XML chaque jour.

Le JSON (JavaScript Object Notation) est bien plus simple : des objets avec des paires clé-valeur, des tableaux, des chaînes, des nombres, des booléens et null. Il correspond presque un à un aux structures de données de presque tous les langages de programmation, ce qui explique précisément pourquoi il s'est imposé dans les API web modernes, les points d'accès REST, les applications mobiles et les fichiers de configuration comme package.json. Le JSON est généralement 30 à 50 pour cent plus petit que le XML équivalent et s'analyse nettement plus vite, en partie parce qu'il abandonne les balises de fermeture et la machinerie d'attributs qui rendent le XML verbeux.

Les différences clés qui comptent pour la conversion

Les deux formats se recouvrent suffisamment pour se correspondre, mais pas proprement. Quelques différences structurelles causent presque toute la friction :

• Attributs contre nœuds enfants. Le XML distingue <user id="1"> (un attribut) de <user><id>1</id></user> (un élément enfant). Le JSON n'a pas une telle notion, donc les convertisseurs en inventent une. Par convention, les attributs sont regroupés dans une clé comme @attributes ou préfixés d'un @, tandis que le texte de l'élément aboutit dans une clé comme #text.
• Tableaux. Le JSON possède des tableaux natifs. Le XML non. Une liste en XML n'est que la même balise répétée, comme trois éléments <item> à la suite. Les convertisseurs doivent deviner quand des frères répétés doivent se regrouper en un tableau JSON, et quand un élément unique doit rester un simple objet.
• Espaces de noms. Le XML utilise des espaces de noms (les préfixes xmlns:soap) pour éviter les collisions de noms entre schémas. Le JSON n'a rien d'équivalent : les préfixes survivent donc soit en caractères littéraux dans les clés, soit sont retirés.
• Verbosité et métadonnées. Le XML peut attacher des métadonnées à un nœud via des attributs ; le JSON exprime tout sous forme de clés et de valeurs. Cela rend le JSON plus compact et plus lisible, tandis que le XML conserve un pouvoir de validation grâce aux schémas XSD.

Pièges de conversion à surveiller

Faire un aller-retour JSON vers XML vers JSON en s'attendant à un résultat identique est l'erreur classique. La conversion est avec perte dans les deux sens à moins que vous ne maîtrisiez les règles. Gardez ceci à l'esprit :

• Les attributs sont malmenés. Quand vous convertissez du JSON en XML, l'outil a besoin d'une règle pour décider quelles clés deviennent des attributs et lesquelles des éléments. Dans l'autre sens, les attributs doivent atterrir quelque part, et ce « quelque part » (préfixe @, bloc @attributes) diffère d'une bibliothèque à l'autre. Si un analyseur en aval attend une convention différente, les données paraissent fausses même si rien n'a été perdu.
• Élément unique contre tableau. Un flux XML avec un seul <item> produit un objet JSON ; le même flux avec deux éléments produit un tableau JSON. Le code qui suppose un tableau casse dans le cas de l'élément unique. C'est une source fréquente de bugs d'analyse RSS et SOAP.
• Les espaces de noms fuient ou disparaissent. Selon l'outil, soap:Body peut devenir une clé littéralement nommée soap:Body, ou le préfixe peut être entièrement supprimé, changeant le sens du document.
• Contenu mixte et types. Le XML traite tout comme du texte, donc une valeur comme true ou 42 peut rester une chaîne après conversion en JSON, tandis que le sens inverse n'a pas d'emplacement natif pour les commentaires ou le CDATA.

Pourquoi une conversion en local uniquement compte

Les charges utiles JSON et XML sont souvent ce qu'un développeur manipule de plus sensible : réponses d'API avec des jetons, messages SOAP avec des numéros de compte, fichiers de configuration avec des identifiants. Un convertisseur qui s'exécute dans votre navigateur ne téléverse rien de tout cela. L'analyse et la sérialisation se déroulent sur votre machine, rien n'est envoyé à un serveur, et vous pouvez utiliser l'outil hors ligne une fois la page chargée. Pour déboguer des données de production ou tout ce qui relève d'un régime de conformité, c'est la différence entre une vérification rapide et sûre et une fuite de données accidentelle.

Si vous devez nettoyer le résultat ensuite, associez ceci à nos autres convertisseurs de données, ou peaufinez votre sortie avec le formateur JSON avant de la transmettre à l'outil suivant de votre pipeline.

Questions fréquentes