XML à JSON : attributs, nœuds de texte et problème un contre plusieurs

Pourquoi un <item> devient un objet alors que deux deviennent un tableau — le flux XML dont la forme JSON change selon le nombre d’entrées.

Un flux avec `<item>one</item>` produit `"item": "one"` ; l'ajout d'un deuxième frère modifie cette propriété en `"item": ["one", "two"]`. L'analyseur ne peut pas déduire qu'un élément était conceptuellement une liste d'un élément car les deux significations ont une syntaxe XML identique. Le code construit uniquement sur le premier échantillon peut donc échouer lorsque la production envoie le second.

ToolAcre ne cache pas cette instabilité derrière une option de tableau permanent. Il enregistre un nom une fois sous forme de valeur et les frères et sœurs répétés sous forme de tableau. Ce mappage direct est facile à inspecter, mais les consommateurs ayant besoin d'une forme de collection stable doivent utiliser la connaissance du schéma ou normaliser eux-mêmes le résultat après la conversion.

Ce que XML a que JSON n'a pas : attributs, texte mélangé à des éléments, frères et sœurs ordonnés, espaces de noms, commentaires et instructions de traitement

XML sépare les attributs des éléments enfants, préserve l'ordre des frères et sœurs, autorise le texte entre les éléments, porte des préfixes d'espace de noms et peut contenir des commentaires et des instructions de traitement. JSON propose des objets et des tableaux mais n'a pas d'équivalents intégrés pour ces catégories de nœuds. Tout résultat XML-to-JSON est par conséquent une projection choisie, pas une traduction universelle.

Ce lecteur supprime la déclaration, les commentaires et les instructions de traitement. Les préfixes d'espace de noms restent textuels plutôt que d'être résolus : `<ns:item>` devient la clé `ns:item`, tandis que `xmlns:ns` devient `@xmlns:ns`. Le texte mixte est joint sous une seule clé, de sorte que sa position d'origine autour des éléments enfants est perdue et un avertissement indique que la conversion ne peut pas effectuer un aller-retour.

Conventions d'attribut : préfixes tels que @ ou $, pourquoi ils existent et comment un attribut et un élément enfant portant le même nom entrent en collision

Les attributs utilisent un préfixe `@`. `<user id="7"><id>other</id></user>` devient un objet avec `@id` égal à `"7"` et l'enfant `id` égal à `"other"`. Le préfixe empêche deux constructions XML différentes d'entrer en collision dans une seule propriété d'objet. Il fait également partie du contrat du convertisseur lorsque JSON est réécrit à XML.

D'autres bibliothèques peuvent utiliser `$`, un objet d'attributs ou une autre convention. ToolAcre prend uniquement en charge le mappage `@` visible. Changer ce préfixe dans le code de l'application sans changer le rédacteur transformerait les attributs en éléments, alors conservez-le lorsque vous utilisez la valeur convertie comme formulaire d'inspection intermédiaire.

Conventions des nœuds de texte — #text ou _ pour le contenu d'un élément, et que se passe-t-il lorsqu'un élément a à la fois du texte et des enfants

Un élément contenant uniquement du texte se réduit à cette chaîne. Lorsque des attributs ou des enfants sont également présents, le texte réside sous `#text` ; CDATA est conservé séparément sous `#cdata`. Une balise à fermeture automatique devient une chaîne vide. Ces clés réservées permettent à l'auteur de distinguer les noms d'enfants ordinaires des catégories de contenu que JSON lui-même ne définit pas.

Le contenu mixte reste avec perte. Dans `<p>before<b>bold</b>after</p>`, la position « avant » et « après » par rapport à l'enfant ne peut pas être reconstruite à partir d'une propriété `#text` jointe. L'outil détecte ce modèle structurel et avertit. Utilisez une API XML préservant les nœuds lorsque l'ordre des documents fait partie de la signification.

Le problème un contre plusieurs : les éléments répétés ne deviennent des tableaux que lorsqu'ils sont répétés, et pourquoi les consommateurs doivent coder de manière défensive

Les frères et sœurs répétés ne se transforment en tableaux qu'une fois la répétition observée. Un seul `<book>` est un objet ; deux livres sont un ensemble d'objets. C'est ce qu'on appelle parfois le problème un contre plusieurs, mais il ne s'agit pas d'un défaut de l'analyseur. Le document source ne contient tout simplement pas de déclaration de liste indépendante de ses occurrences.

Les consommateurs défensifs peuvent normaliser les chemins connus grâce à la connaissance du schéma : enveloppez `catalogue.book` lorsqu'il ne s'agit pas déjà d'un tableau. N'appliquez pas cette règle à toutes les propriétés, car un scalaire ordinaire ne doit pas devenir une liste simplement pour des raisons de symétrie. Le convertisseur évite délibérément d'inventer de telles informations de domaine.

Exemple pratique : conversion d'un petit document de style RSS – attributs, un élément répété et un espace de noms, avec le JSON résultant annoté

Convertissez `<feed xmlns:m="https://example.invalid/meta"><item id="1"><m:title>One</m:title></item><item id="2"><m:title><![CDATA[Two & More]]></m:title></item></feed>`. La racine est `feed` ; `@xmlns:m` conserve la déclaration d'espace de noms ; `item` est un tableau ; chaque `@id` est du texte ; et le deuxième titre contient `#cdata`.

L'inférence de type est désactivée par défaut, donc même `id="2"` reste la chaîne `"2"`. L'activation de l'inférence permet à l'analyseur de lire du texte numérique et booléen comme ces types JavaScript, mais XML n'a pas déclaré cette intention. L'option est une supposition contrôlée par l'utilisateur et non une preuve fournie par le document.

Ce que cela ne couvre pas : conversion basée sur un schéma qui sait qu'un élément est toujours une liste, ce qui nécessite un XSD ou un mappage manuel

Aucun XSD n'est chargé et aucune information de liste basée sur un schéma n'est disponible. Le convertisseur ne peut pas savoir qu'un élément est répétable lorsqu'un seul apparaît, valider les enfants requis, résoudre les URI d'espace de noms en types d'application ou générer un client typé. Une analyse réussie établit uniquement XML bien formé accepté par le lecteur configuré.

Les déclarations DOCTYPE sont refusées avant analyse, y compris les déclarations inoffensives. Cette limite empêche les demandes d’entités externes, les lectures de fichiers locaux et l’expansion d’entités. La suppression d'un DOCTYPE peut également supprimer les déclarations dont dépendait le document, alors ne le faites que lorsque vous possédez les données et comprenez les conséquences.

À retenir : XML à JSON est un mappage, pas une traduction – et comment le panneau des convertisseurs de syntaxe vous permet d'inspecter ce mappage dans votre navigateur

Traitez le résultat comme le mappage documenté de ToolAcre : `@` pour les attributs, `#text` pour le texte d'éléments mixtes, `#cdata` pour CDATA, les tableaux après les frères et sœurs répétés et les préfixes d'espace de noms littéraux. Ces règles rendent la sortie prévisible sans prétendre que XML et JSON partagent un même modèle de données.

Pour l'inspection, cette projection est rapide et lisible. Pour une intégration durable, testez une et plusieurs occurrences, les attributs partageant des noms avec des enfants, des éléments vides, du contenu mixte et des espaces de noms. Si l'ordre des éléments ou les contraintes de schéma sont importantes, analysez XML par rapport à ce contrat plutôt que de dépendre d'une forme convertie générique.

Gardez le luminaire brut XML à côté des attentes normalisées. Ce couplage préserve les preuves si une mise à niveau de dépendance modifie la gestion du tableau, la suppression des espaces ou le décodage des entités. Il donne également aux réviseurs un endroit pour voir les distinctions que la vue JSON ne peut pas comporter. Un objet converti à lui seul ne peut pas prouver si une chaîne vide provient d'un élément à fermeture automatique, de balises appariées ou d'une autre convention dans la source.