Conversion XML en JSON en ligne, gratuite

Qu'est-ce que XML ?

XML (Extensible Markup Language) est un format utilisé pour stocker et transporter des données. Il utilise des balises personnalisées pour décrire la structure des données, ce qui le rend lisible par un humain et largement pris en charge. Contrairement à JSON, XML permet d'inclure des attributs sur les éléments.

Pourquoi convertir XML en JSON ?

• Taille de fichier réduite · JSON est plus compact que XML.
• API web · La plupart des services web modernes utilisent JSON plutôt que XML.
• Analyse simplifiée · JSON correspond directement aux objets JavaScript.
• Intégration de systèmes hérités · Convertissez d'anciennes données XML vers le format JSON moderne.

Questions fréquentes

Comment les attributs XML sont-ils gérés ?

Les attributs XML sont convertis en propriétés JSON préfixées par « @ ». Par exemple, Anne devient {"user": {"@id": "1", "#text": "Anne"}}. Cela préserve la distinction entre attributs et contenu textuel.

Qu'en est-il des espaces de noms ?

Les préfixes d'espaces de noms XML sont conservés dans les noms de clés JSON. Les déclarations d'espaces de noms (xmlns) apparaissent comme des attributs classiques préfixés par « @xmlns » dans la sortie.

Puis-je reconvertir du JSON en XML ?

Cet outil convertit uniquement XML vers JSON. Pour la conversion inverse, essayez notre convertisseur JSON vers XML, qui inverse le processus en utilisant la même convention pour les attributs et les nœuds de texte.

Deux formats, à trois décennies d'écart

XML 1.0 est devenu une recommandation du W3C le 10 février 1998. Les éditeurs d'origine étaient Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) et C. M. Sperberg-McQueen (université de l'Illinois à Chicago) ; le groupe de travail était présidé par Jon Bosak de Sun Microsystems. La lignée de XML remonte à SGML (ISO 8879:1986), la norme de balisage de documents qui a elle-même grandi à partir du GML d'IBM dans les années 1970. SGML était puissant mais intimidant ; le cahier des charges de conception de XML était « concevoir une version 'allégée' de SGML », en réduisant les fonctionnalités optionnelles à un profil implémentable en quelques milliers de lignes de code tout en préservant Unicode, les espaces de noms et les documents riches en attributs.

JSON (JavaScript Object Notation) a été découvert, et non conçu. Douglas Crockford et Chip Morningstar ont envoyé le premier message JSON en avril 2001 chez State Software, en dérivant le format de la syntaxe des littéraux d'objet de JavaScript. Crockford a enregistré json.org en 2002 et a publié une spécification d'une page. Le format a d'abord été formalisé sous le nom de RFC 4627 en juillet 2006, réédité sous le nom de RFC 7159 en 2014, et stabilisé sous le nom de RFC 8259 / STD 90 en décembre 2017, la même année où ECMA-International a publié ECMA-404. L'intention de conception de JSON (d'après la rétrospective de Crockford) : minimal, indépendant du langage, facile à générer et à analyser, sans numéro de version (« il n'y a pas de numéro de version »), et délibérément sans commentaires (« j'ai supprimé les commentaires parce que je voyais des gens les utiliser pour contenir des directives d'analyse »).

Le JSON s'est imposé dans les API web à la fin des années 2000, à mesure que REST remplaçait SOAP et que XMLHttpRequest cédait la place au JSON via fetch. En 2015, le JSON était le format de réponse par défaut de presque toutes les API publiques ; le XML a survécu dans les SOA d'entreprise de longue traîne, les formats de documents (Office Open XML, OpenDocument) et les niches liées aux normes.

En quoi XML et JSON diffèrent

	XML	JSON
Attributs	De première classe (<item id="5"/>)	Pas d'attributs, tout est une paire clé/valeur
Espaces de noms	Natifs (xmlns:prefix="uri")	Noms plats ; les collisions de préfixes sont le problème de l'application
Commentaires	<!-- … -->	Aucun selon la spécification
Contenu mixte	Natif (<p>text <b>and</b> markup</p>)	Laborieux, nécessite des tableaux ou une conversion en chaîne
Schéma	DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron	JSON Schema (spécification communautaire, brouillon 2020-12)
Ordre	L'ordre des éléments est significatif selon la spécification	L'ordre des clés d'objet n'est pas garanti (la plupart des analyseurs préservent en pratique l'ordre d'insertion) ; les tableaux sont ordonnés
Nombres	Des chaînes jusqu'à ce qu'un schéma les type	Double IEEE 754 ; pas de distinction entier/flottant au niveau de la spécification
Verbosité	Élevée (chaque valeur enveloppée dans des balises	Faible) ponctuation uniquement

Pourquoi la conversion XML → JSON est fondamentalement avec perte

Il n'existe pas de correspondance canonique avalisée par le W3C de XML vers JSON. Chaque convertisseur doit inventer des réponses à des questions que XML permet d'exprimer mais pour lesquelles JSON n'a aucun vocabulaire natif. Les décisions récurrentes :

• Attributs ou éléments enfants : XML vous permet d'exprimer les mêmes données des deux façons. JSON n'a qu'une seule notion (des clés sur un objet), de sorte que le convertisseur doit inventer un marqueur. Les conventions courantes : BadgerFish utilise @ pour les attributs et $ pour le texte ; Parker abandonne entièrement les attributs (avec perte mais simple) ; JsonML représente les éléments sous forme de tableaux avec des balises de type (préserve l'ordre et la structure) ; GData / Newtonsoft / xml2js utilisent un sous-objet @attributes plus une clé #text au besoin. Ce convertisseur suit la convention de style GData : les attributs sous @attributes, le texte de contenu mixte sous #text, les enfants répétés deviennent des tableaux.
• Éléments enfants répétés : si le convertisseur crée aveuglément une clé par enfant, le deuxième enfant écrase le premier. Correctif standard : détecter la répétition et émettre un tableau. Mais cela signifie que la forme du JSON dépend des données : un seul <book> produit une chaîne, deux produisent un tableau de chaînes. Certains consommateurs veulent la forme en tableau même pour un seul élément ; certains convertisseurs exposent une option « toujours en tableau » pour des noms d'éléments spécifiques.
• Contenu mixte : <p>Hello <b>world</b>!</p> entremêle texte et éléments dans un ordre significatif. JSON ne peut pas exprimer nativement cet entrelacement sans un tableau de types mixtes ou une clé sentinelle #text. De nombreux convertisseurs abandonnent le texte entre les éléments ; les plus prudents le découpent en plusieurs entrées de nœuds de texte.
• Espaces de noms : <soap:Envelope xmlns:soap="…"> possède à la fois un préfixe et une URI de liaison. La plupart des convertisseurs préservent le préfixe dans la clé JSON (soap:Envelope) et abandonnent la liaison, ce qui convient tant que le consommateur n'a pas besoin de résoudre l'espace de noms.
• Commentaires et instructions de traitement : généralement abandonnés en silence, puisque JSON n'a pas de syntaxe de commentaire.
• Sections CDATA : aplaties en chaînes simples ; l'enveloppe <![CDATA[…]]> est perdue.
• Espaces : XML dispose de xml:space="preserve" pour les espaces significatifs ; JSON n'a pas d'équivalent. La plupart des convertisseurs suppriment les nœuds de texte composés uniquement d'espaces entre les éléments.

Quand y recourir

• Consommer d'anciens services SOAP depuis un frontend JS moderne. Les réponses SOAP sont en XML ; convertir une fois à la frontière permet au reste de l'application de travailler en JSON.
• Traitement des flux RSS / Atom : les deux sont des formats XML ; les lecteurs d'actualités et les agrégateurs modernes veulent généralement du JSON.
• Sitemaps XML (sitemap.xml) : les convertir en JSON les rend plus faciles à inspecter et à traiter par programme.
• Données OSM OpenStreetMap : publiées en XML, souvent nécessaires en JSON pour la cartographie côté client.
• Fichiers KML / GPX de Google Earth : des formats de données géographiques qui arrivent en XML.
• Internes d'Office Open XML : les .docx, .xlsx et .pptx sont des fichiers XML compressés ; si vous en avez extrait un et souhaitez inspecter sa structure en JSON, c'est l'étape de conversion.
• Manipulation de SVG : le SVG est du XML. Le convertir en JSON facilite le parcours et la modification de l'arbre en JavaScript avant la resérialisation.
• POM Maven, fichiers de build Ant, configuration Spring, ressources Android, plists Apple, données financières XBRL, dossiers médicaux HL7, MusicXML, documents juridiques NMX : des formats XML de longue traîne qui nécessitent souvent du JSON pour l'outillage en aval.

Alternatives modernes

• API JSON natives. Si le service en amont propose une variante JSON, prenez-la. Les services SOAP ne le font généralement pas, mais la plupart des équivalents modernes le font.
• GraphQL. Un langage de requête qui permet au client de demander exactement la forme JSON dont il a besoin à partir d'un schéma typé.
• Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Des formats de sérialisation binaires dotés de schémas et de tailles de transmission bien plus petites que XML ou JSON. Courants au sein des maillages de microservices ; rarement utilisés à la frontière du navigateur, car ils nécessitent des bibliothèques de décodage explicites.
• Rester en XML. Si les données sont véritablement orientées document (contenu mixte, structure typée en profondeur, validation par schéma qui compte), XML est plus adapté. La force de JSON, ce sont les données en forme d'API ; la fidélité documentaire n'est pas sa spécialité.

Autres questions

Pourquoi le même XML produit-il une forme JSON différente selon les outils ?

Parce qu'il n'existe pas de correspondance canonique XML → JSON. Chaque convertisseur choisit une convention (BadgerFish, Parker, JsonML, style GData) et les formes JSON obtenues diffèrent dans la façon dont les attributs sont marqués, dont le contenu mixte est préservé et dont les enfants répétés sont mis en tableau. Faire transiter un XML par différents convertisseurs produit des JSON différents ; faire retransiter un JSON vers XML par différents convertisseurs peut changer le placement des attributs et même l'ordre des éléments. Pour l'interopérabilité, documentez la convention que vous utilisez et tenez-vous-y.

Qu'en est-il des sections CDATA, des commentaires et des instructions de traitement ?

Les sections CDATA (<![CDATA[…]]>) sont aplaties en contenu de chaîne simple : l'enveloppe disparaît, mais le texte à l'intérieur est préservé verbatim. Les commentaires XML (<!-- … -->) et les instructions de traitement (<?xml-stylesheet …?>) sont abandonnés, puisque JSON n'a de syntaxe pour ni l'un ni l'autre. Si vous avez besoin d'une fidélité d'aller-retour qui préserve les commentaires, un aller-retour uniquement en XML est la bonne approche.

Mon schéma XML (XSD) survivra-t-il à la conversion ?

Non. XSD décrit la structure et les types du XML ; JSON Schema est la norme analogue (distincte) pour JSON. Certains outils avancés peuvent traduire XSD en JSON Schema, mais c'est une opération avec perte : XSD possède des fonctionnalités (contenu mixte, groupes de substitution, types dérivés) qui n'ont pas d'équivalent propre en JSON Schema. Pour une validation de document qui compte, exécutez XSD sur le XML d'origine, pas sur la conversion JSON.

Pourquoi JSON l'a-t-il emporté pour les API web ?

Quelques raisons. JSON correspond directement aux objets JavaScript, de sorte que l'analyse côté navigateur ne demande qu'un appel à JSON.parse(). Le format est bien plus petit : pas de balises fermantes, pas de déclarations d'espaces de noms, pas de bagage de schéma. REST a remplacé SOAP pour la plupart des API publiques à la fin des années 2000, et JSON était la charge utile naturelle pour REST. Les forces de XML (schémas stricts, espaces de noms, contenu mixte) comptent pour les documents et les systèmes d'entreprise hérités, mais rarement pour « donne-moi l'objet utilisateur ». Le web s'est optimisé pour le cas le plus simple.

Des données sont-elles envoyées à un serveur ?

Non. Le XML est analysé par le DOMParser natif du navigateur, puis parcouru récursivement en JavaScript pour construire la sortie JSON. Le XML collé ne quitte jamais la page. L'outil fonctionne hors ligne une fois chargé, ce qui compte lorsque le XML source contient des points de terminaison d'API internes, des données clients ou des schémas propriétaires que vous préféreriez ne téléverser nulle part.

Outils associés