XML à JSON : les décisions que chaque convertisseur doit

L'ambiguïté qu'aucun convertisseur ne peut éviter

Considérons `<items><item>x</item></items>`. `item` doit-il être une chaîne ou une liste d'une chaîne ? XML ne le dit pas, et la différence compte au moment où vous écrivez du code dessus : un consommateur s'attendant à ce qu'un tableau soit toujours interrompu sur une réponse à un seul élément, et un consommateur s'attendant à ce qu'un objet se brise lorsqu'un deuxième élément arrive. Les convertisseurs matures vous permettent de forcer les tableaux pour les éléments de liste connus plutôt que de deviner silencieusement, car la supposition est juste assez souvent pour atteindre la production.

Les attributs nécessitent une convention de dénomination

JSON n'a pas d'attributs, donc un attribut doit devenir soit une clé sœur, soit un objet imbriqué. La convention largement utilisée préfixe les noms d'attribut avec `@` — `<image src="a.png"/>` devient `{"@src": "a.png"}` — tandis que le texte de l'élément va dans une clé réservée telle que `#text` lorsqu'un élément a à la fois des attributs et du contenu. Quelle que soit la convention utilisée par le convertisseur, elle doit être appliquée de manière cohérente, car le XML à moitié converti est pire que le XML non converti.

                <rss version="2.0"><channel><title>Feed</title></channel></rss>
→ {
  "rss": {
    "@version": "2.0",
    "channel": { "title": "Feed" }
  }
}
              

Espaces de noms

Les documents avec espace de noms (services SOAP, plans de site, formats Office) qualifient les noms d'éléments comme `ns:element`. JSON n'a pas d'équivalent, donc un convertisseur soit supprime le préfixe, le conserve dans la clé, soit réorganise le document autour de l'URI de l'espace de noms. Le supprimer est courant et parfois désastreux lorsque deux espaces de noms utilisent le même nom local. Si votre document utilise des espaces de noms, vérifiez le résultat pour détecter les collisions avant de lui faire confiance et préférez conserver le préfixe dans la clé.

Où cette conversion est réellement utilisée

• Flux RSS et Atom : la lecture d'un flux en JavaScript est beaucoup plus facile après la conversion.
• SOAP et API existantes : transformer une réponse en quelque chose qu'un client moderne peut consommer.
• Plans de site et fichiers de configuration : inspection de la structure sans éditeur comprenant les schémas.
• Migrations de données : déplacement d'enregistrements d'un système de l'ère XML vers un système basé sur l'ère JSON.

La fidélité aller-retour est un mythe. La conversion de XML en JSON et inversement renvoie rarement le document original octet par octet, car l'ordre de déclaration, les espaces, les commentaires et CDATA ne survivent pas. Convertissez lorsque vous devez consommer les données ailleurs, et non comme stratégie de sauvegarde.

Validez d'abord, puis convertissez

Les analyseurs XML sont stricts concernant les balises non fermées et les entités invalides, et les messages d'erreur sont généralement précis. Corrigez le document avant de le convertir — une entrée bien formée est le seul moyen d'obtenir une structure JSON qui mérite d'être conservée. La conversion s'exécute ensuite localement dans le navigateur, ce qui est important lorsque le XML est une exportation client ou une réponse de service interne, et elle continue de fonctionner hors ligne.