XML vers JSON : C'est plus difficile qu'il n'y paraît

Tu as des données XML. Ton application JavaScript a besoin de JSON. Convertis-les et passe à autre chose, non ?

Sauf que la conversion produit des résultats inattendus. Les tableaux qui devraient exister n'existent pas. Les attributs finissent à des endroits bizarres. Les éléments uniques deviennent des tableaux aléatoirement.

XML et JSON modélisent les données différemment. Convertir entre eux nécessite des décisions.

L'incompatibilité fondamentale

JSON a : objets, tableaux, chaînes, nombres, booléens, null.

XML a : éléments, attributs, contenu texte, namespaces, commentaires, CDATA.

Il n'y a pas de mapping 1:1.

Le problème des tableaux

XML n'a pas de tableaux. Il a des éléments répétés.

<users>
  <user>Alice</user>
  <user>Bob</user>
</users>

Cela devrait probablement devenir :

{"users": {"user": ["Alice", "Bob"]}}

Mais qu'en est-il de :

<users>
  <user>Alice</user>
</users>

Un élément. Est-ce un tableau avec un élément, ou juste une chaîne ? Différents convertisseurs décident différemment.

La cohérence compte. Si user est parfois un tableau et parfois une chaîne, ton code casse.

Le problème des attributs

XML a des attributs. JSON non.

<product id="123">Widget</product>

Stratégies de conversion courantes :

{"product": {"_id": "123", "_text": "Widget"}}
{"product": {"@id": "123", "#text": "Widget"}}
{"product": {"$": {"id": "123"}, "_": "Widget"}}

Chaque convention est différente. Sache ce que ton convertisseur produit.

Le problème des namespaces

Les namespaces XML créent des noms qualifiés comme soap:Envelope. JSON n'a aucun concept de namespaces.

Les convertisseurs soit :

• Incluent les préfixes dans les noms de propriétés : "soap:Envelope"
• Retirent les préfixes : "Envelope"
• Créent des structures imbriquées pour la gestion des namespaces

Chaque approche a des compromis.

Conseils pratiques

Sois cohérent. Choisis une bibliothèque de conversion et tiens-t'y. Mélanger les convertisseurs produit des structures incohérentes.

Force les tableaux. Si un élément peut avoir plusieurs instances, configure le convertisseur pour toujours produire des tableaux, même pour des éléments uniques.

Teste les cas limites. Convertis de vraies données, pas juste des échantillons. Les cas limites dans les données de production te surprendront.

Considère les alternatives. Si tu contrôles les deux bouts, considère utiliser JSON dès le départ. Convertir dans les deux sens perd de l'information.

Défis JSON vers XML

Aller dans l'autre sens a aussi des problèmes.

Pas de représentation de tableau. Les tableaux JSON deviennent des éléments répétés. Tu dois nommer ces éléments.

{"items": [1, 2, 3]}

Devient quoi ? <items><item>1</item>...</items> ? D'où vient "item" ?

Types de nombres. JSON distingue nombres et chaînes. XML non. 123 pourrait devenir <value>123</value>—est-ce un nombre ou une chaîne ?

Quand convertir

Intégration avec systèmes legacy. Les APIs SOAP et systèmes d'entreprise anciens utilisent XML. Convertis à la frontière.

Traitement de données XML. JavaScript gère JSON beaucoup mieux que XML. Convertis, traite, reconvertis si nécessaire.

Migrations ponctuelles. Passer de systèmes basés XML à systèmes basés JSON.

Quand ne pas convertir

Exigences aller-retour. XML → JSON → XML perd souvent de l'information. Attributs, namespaces, ordre.

Validation de schéma. XML a des langages de schéma puissants (XSD). JSON Schema est moins mature.

Traitement de documents. Le modèle de contenu mixte XML (texte avec éléments intégrés) ne mappe pas proprement vers JSON.

---

XML et JSON représentent les données différemment. La conversion nécessite des choix sur les tableaux, attributs et namespaces. Comprends le comportement de ton convertisseur et teste avec des données réalistes.