L'intégration qui m'a appris à respecter la conversion XML-JSON était une API d'un transporteur. Modern Rest partout ailleurs dans la pile, puis ce noeud final hérité qui parlait SOAP et renvoyait des enveloppes de XML que j'avais besoin de plier dans un pipeline JSON. "C'est juste de XML à JSON", pensai-je, et j'ai atteint un convertisseur à une ligne. Puis les cas de bord sont arrivés : un <Package> élément qui était parfois un seul objet et parfois une liste, selon le nombre de packages dans la commande. un id Attribuez que mon convertisseur naïf a complètement abandonné car il n'a regardé que le texte d'élément. un <Description> enveloppé dans CDATA car il contenait un esperluette. Chacune de ces personnes a silencieusement corrompu les données - le JSON a semblé plausible et avait tort d'une manière qui n'avait affiché que trois services en aval.
XML et JSON semblent devoir convertir les uns et les autres, et ils ne le font pas, car ils modélisent des données avec différentes primitives. JSON a des objets, des tableaux, des chaînes, des nombres, des booléens et null - un petit ensemble propre. XML contient des éléments, des attributs, des nœuds de texte, un contenu mixte, des espaces de noms, des CDATA, des commentaires et des instructions de traitement, et surtout il a Aucun tableau et Aucun type. Un convertisseur doit donc décider qu'un format sans perte ne serait pas : où vont les attributs lorsque JSON n'en a aucune idée ? Comment distinguer un seul élément d'une liste d'un seul élément lorsque XML marque les deux de la même manière ? Qu'advient-il d'un élément qui a à la fois des attributs et du texte ?
un Convertisseur XML en JSON Cela rend ces décisions délibérées - et de manière cohérente - est la différence entre une intégration propre et une semaine de débogage en aval. Celui que j'ai construit pour les attributs Toolz.dev mappe les clés préfixées afin que rien ne soit perdu, réduise les balises répétées dans des tableaux JSON afin de préserver la structure, conserve le texte mixte sous une clé dédiée et lit textuellement CDATA. Et il fait tout cela avec un analyseur sans dépendance qui s'exécute dans votre navigateur, ce qui compte, car les charges utiles d'intégration sont exactement le type de données que vous ne devriez pas télécharger sur le serveur d'un inconnu.
Ce guide explique comment la conversion gère les bizarreries structurelles de XML, lorsque des éléments répétés deviennent des tableaux, comment gérer les attributs et les espaces de noms, ainsi que les flux de travail SOAP et RSS où cette conversion se produit constamment.
tl;dr : Collez XML dans le Convertisseur XML de Toolz.dev en JSON, choisissez l'indentation et obtenez un JSON propre là où les attributs deviennent
@-Les clés préfixées, les balises répétées deviennent des tableaux, le texte mixte se trouve sous#text, et cdata est lu textuellement. Tours d'analyse de type optionnel"44.95"en un nombre réel. Il utilise un analyseur sans dépendance, exécute 100 % du côté client, de sorte que les charges utiles SOAP et d'intégration ne téléchargent jamais et s'associent à JSON vers Yaml et le Formateur JSON pour la prochaine étape de votre pipeline.
Pourquoi le XML à JSON n'est-il pas un simple mappage un à un ?
L'intuition selon laquelle XML et JSON sont interchangeables provient de leur travail partagé - représentant des données structurées - et se casse sur leurs différents blocs de construction. La discordance apparaît dans quatre endroits spécifiques, et la qualité d'un convertisseur concerne entièrement la façon dont il les gère.
Les attributs n'ont pas d'équivalent JSON. <book id="bk101">War and Peace</book> a un attribut (id) et le contenu du texte (War and Peace). JSON n'a aucune idée d'un attribut, tout est une paire clé-valeur. Un convertisseur doit inventer une convention, et la plus répandue consiste à préfixer les clés d'attributs — { "book": { "@id": "bk101", "#text": "War and Peace" } }. Déposez les attributs, comme le font les convertisseurs naïfs, et vous avez silencieusement perdu des données.
JSON a des tableaux ; XML n'est pas. En XML, une liste est la même balise répétée : trois <item> éléments sous un seul parent. Mais un seul <item> Semble structurellement identique à une liste de un. JSON doit savoir s'il faut émettre un objet ou un tableau, et le seul signal disponible est l'occurrence, de sorte que les balises répétées deviennent des tableaux et que les balises uniques restent des objets.
Contenu mixte. Un élément peut contenir à la fois des éléments enfant et du texte en vrac. Les objets JSON ne peuvent pas représenter naturellement "cet objet a également une valeur de chaîne nue", de sorte que le texte passe sous une clé réservée comme #text.
Les types n'existent pas en XML. Chaque valeur en XML est du texte. <price>44.95</price> est la chaîne "44.95", pas un nombre, à moins qu'un convertisseur ne choisisse de le contraindre - et ce choix peut être erroné, car <zip>08544</zip> Doit garder une chaîne ou perdre son zéro principal.
le convertisseur gère chacun de ces éléments explicitement plutôt que de prétendre qu'ils n'existent pas. C'est pourquoi la sortie reste fidèle à la source au lieu de laisser tomber tranquillement les parties de XML pour lesquelles JSON n'a pas de logement.
Quand les éléments répétés deviennent-ils des tableaux ?
C'est la partie la plus déroutante de la conversion XML-JSON, et cela vaut la peine de comprendre plutôt que d'être surpris. la règle le convertisseur Les utilisations sont basées sur une occurrence : dans un parent donné, si un nom de balise apparaît plus d'une fois, ses valeurs s'effondrent dans un tableau JSON ; s'il apparaît exactement une fois, il reste un seul objet ou valeur.
Alors un <catalog> avec deux <book> Les enfants produisent { "catalog": { "book": [ {...}, {...} ] } } — Un tableau. Mais un <catalog> avec un <book> produit { "catalog": { "book": {...} } } — Un objet simple, pas de tableau.
La conséquence de planifier : Une liste d'un élément ne ressemble pas à une liste. Si votre code en aval attend catalog.book Pour toujours être un tableau et itère dessus, une réponse à un seul livre le cassera, car book sera un objet à ce moment particulier. Ce n'est pas un bogue dans la conversion - c'est une conséquence inévitable de la non-marquage des listes XML - mais c'est un véritable piège dans les intégrations où le nombre d'éléments varie. Ma catastrophe d'expédition était exactement la suivante : les commandes à un paquet renvoyaient un objet où les commandes multi-packages renvoyaient un tableau et mon code a pris le tableau.
Le modèle défensif de votre code de consommation est de normaliser : si un champ peut être l'un ou l'autre, forcez-le à un tableau avant d'itérer ([].concat(catalog.book)). connaissance pourquoi La forme varie, c'est ce qui vous permet d'écrire ce garde au lieu de vous y faire brûler.
Comment les attributs et les espaces de noms sont-ils gérés ?
Les attributs convertissent en clés d'objet avec un @ Préfixe. <user role="admin" active="true"> se transforme { "user": { "@role": "admin", "@active": "true" } }. Le préfixe garde les attributs visuellement distincts des éléments enfants et empêche une collision où un attribut et un élément enfant partagent un nom. Si vous n'avez pas besoin d'attributs du tout — vous ne voulez que les données de l'élément — le convertisseur A une option "ignorer les attributs" qui les laisse entièrement tomber pour un résultat plus propre.
Les espaces de noms sont intégrés au nom de la balise. <soap:Body> devient une clé littéralement nommée "soap:Body", et xmlns:soap="..." est un attribut comme un autre, atterrissant sous @xmlns:soap. C'est le choix pragmatique : la résolution complète des espaces de noms vers leurs URI produirait des clés encombrantes et correspondrait rarement à ce que le code d'intégration souhaite réellement, ce qui consiste à adresser soap:Body par son nom préfixé familier. Si vous traitez SOAP ou SVG ou un vocabulaire espacé de noms, les préfixes que vous connaissez à partir du XML sont les clés que vous obtenez dans le JSON.
Sections de CDATA — le <![CDATA[ ... ]]> Les blocs qui permettent au XML de transporter du texte brut avec des caractères spéciaux - sont lus textuellement, sans décodage d'entité, ce qui est exactement leur objectif. un <script> ou <description> Enveloppé dans CDATA pour protéger ses esperluettes et ses crochets d'angle, ces caractères sont intacts. En dehors de CDATA, entités standard (<, &, et amis) et références numériques (é, é) sont décodés de leurs caractères réels.
Comment convertir XML en JSON avec l'outil ?
Étape 1 : Collez votre XML
Tout XML bien formé fonctionne - avec ou sans <?xml ?> Déclaration, avec ou sans espaces de noms. Les instructions de déclaration, de type de document, de commentaires et de traitement sont reconnues et ignorées, afin que vous puissiez coller un document complet directement à partir d'une réponse API ou d'un fichier. Le bouton Charger un exemple vous donne un catalogue avec des attributs, des éléments imbriqués et une balise répétée, afin que vous puissiez voir chaque comportement de conversion à la fois.
Étape 2 : Choisissez vos options
Choisissez un indentation de 2 ou 4 espaces pour le JSON. Décidez d'inclure des attributs ou de les supprimer. Et choisissez d'analyser les types d'analyse : laissez-le et chaque valeur reste une chaîne (sans risque, sans perte) ; activez-le et les nombres et les booléens deviennent de vrais nombres et booléens. OFF est le bon défaut lorsque des valeurs telles que les codes postaux ou les identifiants peuvent avoir des zéros non significatifs que vous devez conserver.
Étape 3 : Convertir et réviser
Le convertisseur analyse en premier et signale un balisage malformé - une balise de fermeture incompatible, un élément non fermé, un bloc CDATA non terminé - avec un message spécifique plutôt que de produire des ordures. En cas de succès, le JSON apparaît avec le nombre de lignes et d'octets. Écrémez-le pour confirmer que les décisions Array-VS-Object correspondent à vos attentes.
Étape 4 : Copiez ou téléchargez
Copiez le JSON dans votre presse-papiers pour le coller dans le code, ou téléchargez-le en tant que .json fichier. De là, il tombe dans un corps de requête, un magasin de données ou la prochaine étape de votre pipeline. Si la prochaine étape est un format de configuration, le Convertisseur JSON en YAML va plus loin.
Quels sont les flux de travail courants pour cette conversion ?
Intégration des anciennes API SOAP
SOAP est toujours partout dans les systèmes d'entreprise, bancaire, logistique et gouvernemental, et il parle exclusivement de XML. Lorsqu'un service de noeud ou de noeud JavaScript doit consommer une réponse SOAP, la conversion de l'enveloppe XML en JSON est la première étape. La conversion préservant l'espace de noms signifie soap:Body et soap:Envelope Conservez leurs noms familiers et la gestion des attributs conserve les métadonnées que SOAP aime accrocher aux éléments. Il s'agit de la même catégorie de travaux de colle couverts dans le Guide de débogage de l'API.
Lecture des flux RSS et Atom
Les flux RSS et Atom sont XML, et les extraire dans une application JavaScript signifie les convertir. un flux <item> Les éléments sont le cas du manuel répété. Ils deviennent un éventail d'éléments JSON, exactement ce que vous souhaitez .map() sur pour rendre une liste. Attributs comme un boîtier url et type sont conservés sous leurs clés préfixées, de sorte que les flux de podcast et de médias conservent leurs liens audio intacts.
Migration de fichiers de configuration et de données
Les applications plus anciennes stockent la configuration et les données en XML - pensez .config Fichiers, Sitemaps, Datasets exportés, fragments XML ouverts d'Office. La conversion de ces fichiers en JSON est la première étape lors de la modernisation d'un système ou de l'importation de données héritées dans un magasin JSON-Native. L'option d'analyse de type est utile ici lorsque vous connaître Les champs numériques sont véritablement numériques et veulent qu'ils soient saisis dans la destination.
Tests et prototypage
Lorsque vous câlinez un flux de données et que vous n'avez qu'à voir la forme d'une charge utile XML en tant que JSON - pour concevoir une interface Typescript, pour simuler une réponse, vérifier un chemin de champ - une conversion rapide dans le navigateur bat l'écriture de code d'analyseur through. Convertissez, lisez la structure, écrivez vos types contre elle.
XML vs JSON : Quand est-ce que chaque format s'adapte ?
| XML | JSON | |
|---|---|---|
| ERA primordiale et écosystème | Entreprise, SOAP, Documents | API Web, Javascript, Config |
| attributs | de première classe | Aucun — mappé sur les clés préfixées |
| tableaux | Aucun — Les balises répétées impliquent des listes | de première classe |
| types | Tout le texte | Chaînes, nombres, booléens, null |
| observation | soutenu | pas dans la spécification |
| Espaces de noms | de première classe | Aucun — Conservé comme noms de clés préfixés |
| verbosité | Plus haut — Fermeture des balises, attributs | Inférieur — Bretelles et supports |
| Habitat naturel | SOAP, RSS/ATOM, formats de bureau, configuration | API REST, données frontales, package.json |
Le modèle derrière la table : XML a été construit pour les documents et les échanges d'entreprise où la structure, la validation et l'auto-description sont importantes ; JSON a été construit pour le Web où la légèreté et la correspondance directe des objets JavaScript sont importantes. La direction de conversion est extrêmement importante en XML-JSON, car le mouvement dans l'industrie provient de systèmes XML plus anciens vers des frontaux et services natifs JSON - vous rencontrez des données héritées là où elles vivent et les intègrent dans un pipeline moderne. L'ensemble des outils de format plus large pour ce pipeline se trouve dans le Guide des outils de codage.
Est-il sûr de convertir XML contenant des données sensibles ?
Les charges utiles d'intégration sont denses avec des éléments que vous ne souhaitez pas fuir : les réponses SOAP portant des dossiers de clients, des fichiers de configuration avec des terminaux et des informations d'identification internes, des exportations de données avec des informations personnelles. Et ce sont exactement ce qui est collé dans des convertisseurs en ligne, généralement à mi-intégration, généralement pressés.
le Convertisseur Toolz.dev Analyse et convertit entièrement dans votre navigateur avec un analyseur sans dépendance, non DOMParser, pas d'appel de serveur, pas de données quittant la page. Déconnectez votre réseau après le chargement de la page et qu'il fonctionne toujours. C'est un fait architectural sur la façon dont l'outil est construit, pas une promesse dans un document de politique, et c'est le premier principe du navigateur derrière toute la boîte à outils, détaillée dans le Guide de confidentialité des données.
La mise en garde standard s'applique : la conversion côté client protège l'étape de conversion. Ce que vous faites avec le JSON par la suite - là où vous le collez, à quoi vous l'envoyez - est une décision distincte. Mais la transformation elle-même conserve votre XML sur votre machine.
FAQ
Comment convertir XML en JSON en ligne ?
Collez votre XML dans le convertisseur XML en JSON et cliquez sur Convertir. L'outil analyse le XML, le convertit en JSON avec les options et options choisies, et vous permet de copier ou de télécharger le résultat. Le traitement est 100 % dans le navigateur, rien n'est téléchargé.
Comment les attributs XML sont-ils représentés dans la sortie JSON ?
Les attributs deviennent des clés d'objet préfixées avec @, donc un élément de livre avec id = "BK101" est converti en une clé "@id". Cela maintient les attributs distincts des éléments enfants. Vous pouvez désactiver complètement la sortie d'attribut avec l'option Ignorer-attributs si vous n'avez besoin que des données d'élément.
Pourquoi certains éléments XML deviennent-ils des tableaux et d'autres restent-ils des objets ?
JSON n'a aucun moyen de marquer qu'un élément pourrait répéter, de sorte que le convertisseur utilise l'occurrence : si une balise apparaît plus d'une fois sous le même parent, elle devient un tableau, et si elle apparaît une fois qu'elle reste un seul objet. Cela reflète fidèlement la source, bien que cela signifie une liste avec un élément ressemble à un seul objet plutôt qu'à un tableau.
Le convertisseur gère-t-il les sections CDATA et les entités XML ?
Oui. Les blocs CDATA sont lus textuellement sans décodage d'entités, ce qui est leur objectif. En dehors de CDATA, les entités standard comme <, >, &, ", et ' et les références numériques comme &lbse sont décodées en leurs caractères réels.
Puis-je convertir une réponse SOAP ou un flux RSS en JSON ?
Oui. Les enveloppes SOAP et les flux RSS ou Atom sont des XML ordinaires, ils convertissent donc comme n'importe quel autre document. Les balises d'espace de noms conservent leur préfixe dans le nom de la clé — SOAP:BODY devient une "clé SOAP:BODY"; et des éléments répétés tels que les éléments RSS deviennent un tableau JSON sur lequel vous pouvez mapper.
Les nombres et les booléens resteront-ils comme texte après conversion ?
Par défaut, oui, car XML n'a aucun type de système et de valeurs telles que "007" ou "1.10" peut avoir un sens comme texte. Activez l'option d'analyse des types pour convertir le texte numérique et le texte booléen sans ambiguïté en nombres JSON réels et booléens lorsque c'est ce que vous voulez.
Est-il sûr de convertir XML contenant des données sensibles ?
Oui. L'analyseur s'exécute entièrement en JavaScript dans votre navigateur. Aucune requête réseau ne transporte vos données, rien n'est enregistré ou stocké, et l'outil fonctionne hors connexion. XML avec des enregistrements clients, des identifiants internes ou des secrets d'intégration ne quittent jamais votre machine.
Quelle est la différence entre XML et JSON ?
XML est un langage de balisage avec des balises, des attributs, des espaces de noms et des commentaires d'ouverture et de fermeture, conçus pour les documents et l'échange de données d'entreprise. JSON est un format plus léger construit à partir d'objets, de tableaux et de valeurs primitives, et est la valeur par défaut pour les API Web modernes. La conversion de XML en JSON est courante lors de l'intégration de systèmes basés sur des fichiers SOAP ou des flux avec des frontaux JavaScript.
XML et JSON semblent interchangeables et ne sont pas, car JSON n'a pas d'attributs, aucun tableau par répétition et aucun texte avec les enfants - les endroits exacts pour une conversion naïf perdent silencieusement des données. Un convertisseur qui gère ces cas exprès vous donne JSON fidèle à la source : Collez votre XML, vérifiez comment il a mappé les attributs et les balises répétées, et amenez des données propres dans votre pipeline au lieu d'une corruption d'apparence plausible.
