Convertisseur XML vers JSON

1. 1

   Ajoutez votre XML

   Collez le balisage dans l'éditeur ou déposez un fichier sur la page. XML, SVG, RSS, Atom, WSDL, XSD, KML, GPX, plist et OPML sont acceptés, et l'encodage est détecté à partir de la marque d'ordre des octets ou de la déclaration XML.

2. 2

   Choisissez une forme de sortie

   Compacte est la forme familière que produisent la plupart des outils. BadgerFish et GData sont les deux conventions utilisées par des API anciennes. Parker donne les valeurs les plus simples possibles. JsonML préserve l'ordre du document et permet de revenir au XML d'origine.

3. 3

   Réglez la lecture des valeurs

   Décidez si les attributs sont conservés et avec quel préfixe, si un élément unique devient un tableau d'un élément, ce que devient un élément vide, et si les nombres et booléens sont déduits plutôt que laissés en texte. L'aperçu se met à jour à chaque changement.

4. 4

   Convertissez, puis téléchargez ou copiez

   Appuyez sur Convertir pour écrire le fichier. Choisissez 2 espaces, 4 espaces, tabulations ou sortie minifiée, puis téléchargez le .json ou copiez-le. Avec Pro, convertissez jusqu'à 50 fichiers à la fois et emportez-les dans un seul ZIP.

La plupart des convertisseurs XML vers JSON prennent une décision silencieuse à votre place sans vous laisser la changer : ils choisissent une forme, abandonnent vos attributs et rendent un JSON qui a l'air correct. Celui-ci demande. Vous choisissez la convention de sortie, si les attributs survivent et avec quel préfixe, si un élément unique est une valeur ou un tableau d'un élément, ce que signifie un élément vide, et ce qu'il advient des préfixes d'espaces de noms — et l'aperçu à côté des réglages montre la réponse à mesure que vous changez chacun d'eux.

• Rien n'est abandonné — Attributs, sections CDATA, texte mixte et instructions de traitement survivent tous à la conversion. Chacun a son réglage : vous décidez de ce que vous gardez au lieu de découvrir après coup ce qui a été perdu.
• Cinq formes de sortie — Compacte, BadgerFish, GData, Parker et JsonML. Quatre sont les conventions utilisées par de vraies API ; JsonML est celle qui préserve l'ordre du document et se reconvertit exactement.
• Des erreurs exploitables — Une analyse en échec donne la ligne, la colonne, la ligne source et un curseur sous le caractère fautif, avec un message qui nomme la faute au lieu de répéter que le fichier est invalide.
• Les gros fichiers restent fluides — La lecture et l'écriture ont lieu hors de l'interface, la page ne gèle donc jamais. Un document de 25 Mo se convertit en environ une seconde, avec une barre de progression et un Annuler qui fonctionne.

Il n'existe pas une seule façon correcte de représenter XML en JSON, d'où l'existence de plusieurs conventions et le fait que les bibliothèques sérieuses vous laissent choisir. XML a des attributs, des enfants ordonnés, du texte mixte et des espaces de noms ; JSON a des objets, des tableaux et des chaînes. Chaque mapping sacrifie l'un de ces éléments. Choisir le bon sacrifice pour la suite de votre travail représente l'essentiel de la tâche.

• Compacte — par défaut — Les éléments deviennent des clés, les attributs sont préfixés par @_ et le texte se place sous #text. C'est la forme que produisent la plupart des outils et des tutoriels : elle paraîtra familière à la personne qui lira le fichier ensuite. Choisissez-la sauf raison contraire.
• BadgerFish — uniforme — Chaque élément est un objet, le texte est toujours sous $, les attributs sous @nom et les déclarations d'espaces de noms sous @xmlns. Rien n'est jamais une chaîne nue : le code qui la consomme n'a jamais à vérifier si un champ est revenu en objet ou en valeur. Verbeuse, et prévisible en échange.
• GData — la forme de Google — Les attributs deviennent des clés ordinaires à côté des éléments enfants et le texte se place sous $t. Compacte à lire, et le bon choix quand vous vous alignez sur une forme Google Data ou Atom existante.
• Parker — la plus simple — Les attributs sont abandonnés, le nom de l'élément racine disparaît et les feuilles deviennent leurs valeurs. Le résultat est ce qui se rapproche le plus de ce que vous auriez écrit à la main en partant directement de JSON. À utiliser pour la configuration et les données simples où les attributs n'apportent rien d'utile.
• JsonML — sans perte — Chaque élément devient un tableau de son nom de balise, de ses attributs et de ses enfants dans l'ordre du document. C'est la seule forme ici qui survit à un aller-retour, et la seule capable de représenter un élément, puis un autre, puis le premier de nouveau.

Un élément XML porte trois choses différentes à la fois — ses attributs, son texte et ses éléments enfants — et un objet JSON n'a qu'un seul espace de clés pour les trois. Chaque convention résout cette collision différemment, et la collision est réelle : un élément ayant un attribut nommé nom et un élément enfant nommé nom doit conserver les deux.

• Le préfixe d'attribut — @_ par défaut, et configurable. Son seul rôle est d'empêcher la clé d'un attribut d'entrer en collision avec un élément enfant du même nom : n'importe quel préfixe absent de vos noms de balises convient. Mettez une chaîne vide si vous savez qu'il n'y a pas de collision et voulez la sortie la plus plate.
• La clé de texte — #text par défaut. Elle sert quand un élément a du texte et autre chose : des attributs, des éléments enfants, ou les deux. Un élément qui n'a que du texte est écrit directement comme ce texte, les documents simples restent donc simples.
• Contenu mixte — Un paragraphe contenant un passage en gras a du texte avant, entre et après ses enfants. Ce texte est rassemblé et conservé sous la clé de texte plutôt qu'abandonné, ce qui signifie qu'un document que vous décririez comme de la prose plutôt que des données se convertit quand même en quelque chose de lisible.
• Espaces — Le texte est rogné par défaut, car l'indentation d'un fichier XML mis en forme est de la présentation et non des données. Réduire ramène chaque suite d'espaces à un seul ; Tel quel garde le texte exactement comme il a été écrit, ce que vous voulez pour tout ce dont la mise en forme compte, comme du code embarqué.

La surprise la plus fréquente en conversion XML vers JSON est que la forme de la sortie dépend du nombre d'enregistrements en entrée. Une commande dans le fichier donne un objet ; deux donnent un tableau. Le code écrit sur un échantillon à deux commandes casse le jour où un client en envoie une, et la panne ressemble à un problème de données plutôt qu'à un mapping ambigu.

• Quand répété (par défaut) — Une balise apparaissant plusieurs fois entre frères devient un tableau, préservant l'ordre et le nombre. Une balise apparaissant une fois reste une valeur simple. C'est ce que fait presque tout convertisseur, et c'est la sortie la plus lisible.
• Toujours — Chaque élément susceptible de se répéter devient un tableau, même avec une seule occurrence. La sortie est un peu plus verbeuse et complètement prévisible, ce que vous voulez quand le JSON part directement dans du code plutôt que d'être lu par une personne.
• L'ordre entre balises différentes — Les tableaux préservent l'ordre des frères de même nom, mais aucune forme indexée par clé ne peut préserver celui des frères différents : les clés d'un objet ne portent aucune séquence. Si l'entrelacement compte, JsonML est la forme qui le conserve.

Les espaces de noms expliquent l'apparence du XML d'entreprise, et c'est là qu'un convertisseur naïf produit discrètement quelque chose de faux. Un préfixe comme soap: ne fait pas partie du nom de l'élément : c'est un pointeur vers une URI déclarée plus haut, et le même préfixe peut signifier des choses différentes selon l'endroit d'un même document.

• Conserver — Les préfixes restent exactement tels qu'écrits, donc soap:Envelope reste soap:Envelope et le JSON correspond au document que vous avez sous les yeux. C'est le bon défaut pour les réponses SOAP et pour WSDL, où les préfixes sont ce à quoi tout le monde se réfère.
• Supprimer — Les préfixes sont retirés pour une forme plus propre et plus courte. Deux éléments d'espaces de noms différents peuvent alors atterrir sur la même clé, ce qui est une vraie perte d'information — quand cela arrive, l'outil compte les collisions et vous le dit au lieu de laisser la fusion passer en silence.
• Développer — Chaque préfixe est remplacé par son URI complète entre accolades. Rien n'est ambigu et rien ne peut entrer en collision, au prix de clés longues. C'est la forme à choisir quand le JSON sera validé ou comparé plutôt que lu.
• Attributs sans préfixe — Un attribut sans préfixe n'est dans aucun espace de noms : il n'hérite pas de l'espace par défaut de l'élément. C'est une règle que les convertisseurs se trompent régulièrement, et s'y tromper invente un espace de noms que le document n'a jamais déclaré.

XML n'a pas de types. Chaque valeur d'un document est du texte, et tout convertisseur qui vous rend un nombre a décidé à votre place que le texte avait l'air suffisamment numérique. Cette décision est souvent utile et parfois destructrice, d'où le réglage ici et d'où son état désactivé tant que vous ne l'activez pas.

• Ce qui est converti — Les entiers et décimaux simples, true, false et null. Rien d'autre.
• Ce qui ne l'est délibérément pas — Une valeur avec des zéros de tête reste du texte, car un numéro de commande écrit 007 n'est pas 7. Un plus initial reste du texte, car un préfixe téléphonique n'est pas un nombre. Une valeur au-delà de la plage des entiers sûrs reste du texte, car la convertir changerait silencieusement les chiffres. Idem pour la notation exponentielle ou hexadécimale, et pour Infinity et NaN, qu'une conversion numérique naïve accepté et qu'aucun document XML ne veut dire.
• La règle de l'aller-retour — Une valeur ne devient un nombre que si réécrire ce nombre redonne exactement les caractères présents dans le fichier. C'est ce qui protège 1.0, que la plupart des convertisseurs transforment en 1 et rendent comme si de rien n'était.
• Éléments vides — Un élément vide peut raisonnablement être une chaîne vide, un null ou un objet vide, et le bon choix dépend de la suite. Plutôt que de choisir à votre place, c'est un réglage, afin de pouvoir distinguer un champ nullable d'un champ réellement vierge.

Le XML cassé est le cas normal, pas l'exception, et il l'est généralement pour l'une d'environ six raisons. Un convertisseur qui répond par le mot Invalide ne vous a rien appris ; ce qu'il vous faut, c'est le caractère en cause.

• La ligne, la colonne et un curseur — Chaque échec indique où il s'est produit, affiche la ligne source et place un curseur sous le caractère exact. Les longs documents sur une seule ligne sont fenêtrés autour de la faute pour qu'un fichier minifié ne s'imprime pas entier dans la zone d'erreur.
• Une esperluette non échappée — La faute la plus fréquente du XML écrit à la main. Un & isolé dans Q&A ou dans une chaîne de requête d'URL n'est pas du balisage valide et doit s'écrire &. Le message le dit, au lieu de signaler une erreur d'entité obscure.
• Des balises qui ne correspondent pas — Une balise ouvrante fermée par un autre nom, ou une balise laissée ouverte en fin de fichier. Les deux nomment la balise concernée, et le cas non fermé pointe l'endroit où l'élément a été ouvert plutôt que la fin du document.
• Espaces de noms et doublons — Un préfixe utilisé sans être déclaré, ou le même attribut écrit deux fois sur un élément. Les deux sont des erreurs et non des fusions silencieuses, car garder discrètement l'une de deux valeurs met dans votre sortie des données que personne n'a écrites.
• Entités et DTD — Un DOCTYPE est analysé puis ignoré, non suivi. Les entités déclarées sont reconnues par leur nom mais jamais développées : une référence à l'une d'elles est signalée clairement au lieu d'être substituée — ce qui rend aussi impossible ici l'attaque classique par expansion d'entités.

Tout ce qui suit est du XML, et chacun était un fichier que la version précédente de cette page vous laissait choisir avant de ne rien en faire, parce qu'elle ne reconnaissait que l'extension .xml alors que le système d'exploitation ne signale aucun type pour la plupart des autres.

• Flux et syndication — RSS et Atom, y compris les ensembles item et entry qui donnent la sortie délimitée par lignes la plus utile. OPML pour les listes d'abonnements.
• Services web — Définitions de service WSDL et schémas XSD, tous deux chargés d'espaces de noms et raison pour laquelle Conserver est la politique par défaut.
• Graphismes et géographie — Documents SVG, où la conversion en JSON est la façon dont un script de build lit un path ou un viewBox. KML et GPX pour les données cartographiques et les tracés enregistrées.
• Configuration et documents — Listes de propriétés plist d'Apple, fichiers .config et .csproj, fichiers POM Maven, feuilles de style XSLT et XHTML.

Le document est lu et écrit en dehors de l'interface : la page reste réactive pendant la conversion d'un gros fichier, avec une progression réelle et un bouton Annuler qui prend effet immédiatement.

• Forme de sortie — Compacte, BadgerFish, GData, Parker ou JsonML. Change toute la structure ; l'aperçu se met à jour immédiatement.
• Attributs — Conservez-les ou abandonnez-les, et définissez le préfixe de leurs clés. Ignoré en Parker, qui abandonne les attributs par définition.
• Clé de texte — La clé contenant le texte propre d'un élément lorsqu'il a aussi des attributs ou des enfants.
• Tableaux — Éléments répétés seulement, ou forcer un tableau pour chaque élément répétable.
• Espaces de noms — Conserver le préfixe, le supprimer, ou le développer en URI complète.
• Types — Laisser chaque valeur en texte, ou déduire nombres, booléens et null avec la règle de l'aller-retour.
• Éléments vides — Une chaîne vide, un null, ou un objet vide.
• Espaces — Rogner, réduire les suites à un espace, ou garder le texte tel quel.
• CDATA — Fusionner avec le texte de l'élément, ou garder sous sa propre clé.
• Commentaires et instructions — Abandonnés par défaut ; gardez l'un ou l'autre au besoin, ce que seules les formes préservant l'ordre peuvent exprimer pleinement.
• Indentation — 2 espaces, 4 espaces, tabulations, ou minifié sur une seule ligne.
• Encodage — Détecté à partir de la marque d'ordre des octets ou de la déclaration XML, et forçable quand un fichier en déclare un mauvais.

Énormément de données réelles vivent encore en XML — relevés bancaires, flux publics, services SOAP, fichiers de build, exports cartographiques et tous les flux RSS jamais publiés — alors que presque tout ce qui se construit aujourd'hui pour consommer des données attend du JSON. Convertir est généralement le chemin le plus court entre les deux, et il ne reste court que si la conversion ne perd rien en route.

• Services anciens vers code moderne — Une réponse SOAP devient quelque chose qu'un appel fetch peut lire sans bibliothèque XML dans le bundle.
• Flux vers pipelines — Un flux RSS ou Atom devient un ensemble d'enregistrements, et avec la sortie délimitée par lignes il devient quelque chose qu'un outil de données peut traiter en flux.
• Configuration vers outillage — Un plist, un POM ou un fichier .config devient lisible pour un script dépourvu d'analyseur XML.
• Inspection — Un document très imbriqué se lit mieux en JSON dans un éditeur qui le replie, ce qui est souvent la vraie raison de convertir.
• Cela reste privé — Les relevés bancaires et les réponses de services sont précisément les documents que personne ne devrait coller dans un site qui les téléverse. Celui-ci ne les téléverse pas.

• JSON vers XML
• Formateur JSON
• Validateur JSON
• Visionneuse JSON
• YAML vers JSON
• Minifieur JSON