XML to JSON Converter

The attribute forces the element to become a JSON object rather than a plain string, since a plain string value has nowhere to hang the attribute. The text content moves to a #text key alongside the attribute key: {"price": {"@currency": "USD", "#text": "19.99"}}. If the element had no attributes, the same tag would have simplified to a plain string value instead.

Per the XML 1.0 spec, a self-closing tag and an explicitly-closed empty tag are equivalent — there's no way to distinguish them once parsed, so both convert identically. With no attributes and no text or child content, there's nothing to populate the JSON value with, so this typically comes through as an empty string or null rather than an empty object, since there are no attribute or child keys to place inside one.

No. JSON's grammar (RFC 8259 / ECMA-404) has no comment syntax and no node type analogous to a processing instruction (<?xml-stylesheet type="text/xsl" href="style.xsl"?>), so both are stripped during conversion. Only element structure, attributes, and character data survive the conversion; anything that isn't data in the XML infoset sense is discarded.

Two separate spec gaps compound here. First, XML often contains whitespace-only text nodes between elements purely for pretty-printing indentation, which can surface as stray #text entries unless explicitly stripped. Second, the JSON grammar (ECMA-404) never mandates that object members preserve insertion order — most parsers do in practice, but it isn't a spec guarantee — so attribute order captured as @keys isn't reliably round-trippable either.

C'est une ambiguïté inhérente, pas un bug propre à tel ou tel outil. XML n'a aucun type numérique ou booléen natif — selon la spécification XML 1.0, le contenu de chaque élément est une donnée de caractères — donc une conversion XML vers JSON doit toujours faire un choix quant au moment où un texte doit devenir un nombre/booléen JSON plutôt que de rester une chaîne. Ce choix est réellement risqué pour des valeurs comme "007" (un code postal ou un code produit, pas le nombre 7) ou "1.50" (un prix, où la conversion en nombre supprime silencieusement le zéro final pour donner 1.5). Le comportement par défaut le plus sûr, et celui que privilégient la plupart des conversions, est de conserver toutes les valeurs d'éléments et d'attributs sous forme de chaînes JSON et de laisser le code consommateur décider quand et comment les convertir — ainsi, aucune information n'est détruite silencieusement.

Les navigateurs et Node.js n'ont aucun équivalent natif de JSON.parse pour le XML — il faut utiliser DOMParser (uniquement dans le navigateur) ou une bibliothèque XML (côté Node), puis écrire à la main du code de parcours pour extraire les valeurs de l'arbre DOM via getElementsByTagName ou XPath. JSON.parse, à l'inverse, est un simple appel natif qui fournit directement des objets et des tableaux prêts à être déstructurés. C'est exactement pour cette raison que les API SOAP héritées, les flux RSS/Atom et les fichiers sitemap.xml sont si souvent convertis en JSON en périphérie d'une base de code JavaScript : ce n'est pas que JSON soit plus puissant, c'est que l'outillage JS pour le consommer est déjà prêt à l'emploi.

XML précède JSON d'environ une décennie : XML 1.0 est devenu une Recommandation du W3C en février 1998, dérivé du SGML et conçu comme un langage de balisage de documents (d'où les attributs, le contenu mixte et les espaces de noms). JSON a été extrait de la syntaxe des littéraux objets de JavaScript par Douglas Crockford au début des années 2000, formellement spécifié une première fois sous RFC 4627 en 2006, puis re-spécifié sous ECMA-404 (2013) et sa forme actuelle, RFC 8259 (2017). Le minimalisme de JSON — quatre types de données, pas d'attributs, pas de contenu mixte — reflète son origine : un format d'échange destiné à transmettre des structures de données à et depuis un programme en cours d'exécution, et non à baliser des documents.

Non — et la convention de préfixe @ que cet outil utilise pour les attributs en est elle-même la preuve. Cette convention (@clé pour les attributs, #text pour le contenu mixte) ne fait pas partie de la spécification JSON ; c'est une convention largement répandue mais informelle, et différents outils de conversion XML vers JSON traitent la même entrée différemment — certains aplatissent les attributs en simples clés, d'autres enveloppent le contenu de l'élément dans une clé $ ou _text, d'autres encore utilisent les conventions BadgerFish ou Parker. JSON n'a aucune notion native d'attribut, donc tout outil de conversion XML vers JSON superpose sa propre convention à de simples objets JSON, et la sortie JSON d'un convertisseur ne correspondra pas nécessairement à celle d'un autre pour la même entrée XML.

Comme ce convertisseur conserve les préfixes d'espace de noms tels quels dans le nom de la clé plutôt que de les résoudre vers leur URI d'espace de noms complète, "a:id" et "b:id" se convertissent en deux clés JSON distinctes et n'entrent pas en collision — mais uniquement tant que les préfixes eux-mêmes diffèrent. Si deux parties différentes d'un même document utilisent par hasard le même préfixe pour des URI d'espaces de noms différentes (ce qui est légal en XML, puisque les associations de préfixes sont limitées à l'élément où elles sont déclarées), ou si un outil en aval reparse le JSON sans contexte d'espace de noms, cette clé basée sur le préfixe n'identifie plus de façon fiable l'espace de noms auquel appartenait réellement l'élément. Pour les documents où les URI d'espaces de noms comptent plus que les préfixes, il est plus sûr de normaliser les préfixes avant la conversion.