JSON et XML comme arbres interchangeables
JSON et XML représentent tous deux des données hiérarchiques, mais issus de traditions différentes. JSON est un modèle léger objet/tableau utilisé par la plupart des API web. XML est un modèle de document balisé avec éléments, attributs, espaces de noms et contenu mixte, encore central pour la messagerie d’entreprise, l’édition et de nombreux formats de configuration.
La conversion entre les deux est un mappage structurel, pas un simple restylage syntaxique. Noms, imbrication et indices de type doivent être choisis délibérément car les deux modèles ne sont pas isomorphes. Ce hub explique cette famille de mappage. Pour un chemin de conversion direct, ouvrez De JSON vers XML.
Sous-outils de cette famille
- De JSON vers XML — prend une valeur JSON et émet un document XML qui reflète les objets comme éléments et les tableaux comme enfants répétés (selon les règles du convertisseur).
- De XML vers JSON — analyse le XML et produit une représentation JSON des éléments, du texte et des attributs.
- Formater JSON — pretty-print ou minification du JSON lorsque vous avez besoin de contrôler la mise en forme dans le même flux que la conversion.
Utilisez les convertisseurs lorsque les systèmes de part et d’autre d’une intégration ne s’accordent pas sur l’encodage. Utilisez format-json lorsque la charge utile est déjà du JSON et que vous n’avez besoin que d’une forme lisible ou compacte avant ou après une transformation.
Où les modèles divergent
Objets vs éléments. Les objets JSON sont des maps non ordonnées de clés string vers des valeurs. Les éléments XML sont ordonnés dans le document et peuvent se répéter avec le même nom. Un tableau JSON d’objets devient souvent des éléments frères répétés ; un objet JSON devient un ensemble d’éléments enfants aux noms uniques — jusqu’à ce qu’une clé soit illégale comme nom XML.
Attributs vs propriétés. Les attributs XML sont uniquement des strings, non ordonnés sur un élément, et ne peuvent pas s’imbriquer. JSON n’a pas de canal d’attributs séparé ; les convertisseurs mappent typiquement les attributs vers des clés avec un préfixe conventionnel (par exemple @id) ou les imbriquent sous un objet réservé. Les allers-retours doivent s’accorder sur cette convention, sinon attributs et éléments enfants échangent leur sens.
Types. JSON distingue nombres, booléens, null, strings, tableaux et objets. Le texte XML reste du texte jusqu’à ce qu’un schéma (XSD) ou une convention le réinterprète. Sans métadonnées de type, true, 1 et "true" peuvent survivre comme strings — ou un convertisseur peut appliquer des heuristiques surprenantes.
Espaces de noms. Les espaces de noms XML (xmlns) désambiguïsent les vocabulaires. JSON n’a pas de nœud d’espace de noms natif ; les préfixes peuvent être aplatis dans les clés ou abandonnés. Perdre l’information d’espace de noms est un échec silencieux fréquent lorsque XML→JSON→XML sert de pipeline de « nettoyage ».
Contenu mixte. XML autorise texte et éléments entrelacés (<p>Bonjour <em>monde</em></p>). Les arbres JSON stockent en général soit une string, soit des enfants, pas les deux, sauf si le convertisseur utilise un tableau de contenu explicite. Le XML orienté document demande souvent un mappage plus riche que le XML orienté données.
JSON → XML (pipeline conceptuel)
- Analyser le JSON ; rejeter la syntaxe invalide avant toute construction XML.
- Choisir un nom d’élément racine (JSON n’exige pas une racine unique pour un tableau de premier niveau ; les convertisseurs inventent une enveloppe).
- Mapper chaque clé d’objet vers un élément enfant ou un attribut selon les règles de nommage.
- Mapper les tableaux vers des éléments répétés avec la même balise.
- Échapper les caractères spéciaux (
&,<,>, guillemets) dans le texte et les attributs. - Sérialiser avec ou sans déclaration XML et indentation.
Les noms XML illégaux (clés commençant par des chiffres, contenant des espaces ou entrant en collision avec les préfixes réservés xml) doivent être assainis ou rejetés. Préférez un échec explicite dans les pipelines de données plutôt qu’un markup mal formé.
XML → JSON (pipeline conceptuel)
- Analyser comme XML bien formé (et éventuellement valider contre un schéma ailleurs).
- Représenter chaque élément comme objet JSON ou comme valeur lorsqu’il n’a que du texte.
- Décider comment encoder attributs, enfants répétés et éléments vides (
""vsnullvs{}). - Fusionner ou préserver les nœuds texte selon la politique de contenu mixte.
- Émettre du texte JSON ; éventuellement pretty-print pour inspection via Formater JSON.
Les éléments frères de même nom deviennent en général un tableau JSON. Un seul enfant avec ce nom peut devenir un objet nu — autre risque d’aller-retour si le code suppose toujours des tableaux.
Formater JSON dans un flux de conversion
Les erreurs de conversion se diagnostiquent plus facilement sur du JSON indenté. Le JSON minifié convient mieux à l’intégration dans des logs ou au transport après édition. Format-json dans cette famille est le frère de mise en forme : il ne déplace pas les données vers XML ; il prépare le JSON pour une consommation humaine ou machine autour des convertisseurs.
Absence de perte et quand arrêter les allers-retours
Les allers-retours sont perteux par défaut sauf si les deux directions partagent un jeu de conventions documenté (préfixes d’attributs, enveloppe de tableaux, coercition de types, gestion des espaces de noms). Motifs sûrs :
- Convertir une fois à la frontière système et conserver un unique système d’enregistrement.
- Conserver le XML original lorsque la fidélité légale/archivistique compte ; traiter le JSON comme projection de travail.
- Préférer des outils conscient du schéma (XSD + data binding) pour les messages d’entreprise plutôt que des parcours d’arbre ad hoc.
Motifs risqués : utiliser JSON comme éditeur XML (XML→JSON, édition manuelle, JSON→XML) pour documents signés, espaces de noms ou contenu mixte sans golden tests.
Caractères, encodage et taille
Les documents XML déclarent souvent l’encodage dans le prologue ; le texte JSON des API est presque toujours UTF-8. Lors de la conversion, assurez-vous que la chaîne Unicode en mémoire est correcte avant la sérialisation. Les caractères de contrôle illégaux en XML 1.0 doivent être retirés ou échappés selon la politique — ils peuvent apparaître dans des strings JSON et casser des écrivains XML naïfs.
Les très gros documents sollicitent la mémoire du navigateur. Pour des exports multi-mégaoctets, préférez des convertisseurs en streaming dans l’écosystème standard de votre langage ; les outils navigateur conviennent aux échantillons, fixtures et tranches de débogage.
Exemples pratiques d’intégration
- Service SOAP/XML legacy, client JSON moderne : mapper le XML de réponse vers JSON pour l’UI ; garder les modèles de requête en XML lorsque le contrat distant l’exige.
- Pont de configuration : maintenir la config interne en JSON ; émettre du XML pour les outils qui ne lisent que le XML.
- Construction de fixtures : rédiger les données en JSON, convertir en XML pour un harness de parseur — conserver des paires golden entrée/sortie sous les mêmes règles de mappage qu’en production.
Limites
Ces outils ne valident pas contre XSD ou JSON Schema, n’exécutent pas XSLT et n’implémentent pas XML Canonicalization (C14N) pour les signatures. Ils se concentrent sur la projection pratique d’arbres. Pour le XML signé numériquement, utilisez des bibliothèques de signature dédiées.
Outils associés
Contrôles de syntaxe : Valide JSON, Valide XML. Mise en forme JSON pure : Pretty-print JSON. Convertissez lorsque le modèle doit changer ; formatez ou validez lorsqu’il reste le même.