Fonctionne sur votre appareil · Votre fichier ne quitte jamais votre appareil.
Déposez un fichier .xml ou collez du XML venant d’une API, d’un flux ou d’un fichier de configuration, et obtenez du JSON exploitable. Le document est lu par l’analyseur XML du navigateur lui-même, dans l’encodage que déclare sa première ligne : tout ce qui est bien formé se convertit, et un fichier mal formé est signalé avec la ligne et la colonne du problème, et ce qui ne va pas à cet endroit.
La correspondance est fixe et réversible : chaque élément devient une clé ; des frères portant le même nom deviennent un tableau ; les attributs sont conservés sous des clés commençant par @ (id="A3" devient "@id": "A3") ; et quand un élément contient à la fois du texte et des enfants ou des attributs, le texte va sous "#text". Un élément qui ne contient que du texte devient directement cette valeur.
Avec la détection des types activée, un texte comme 12, true ou un élément vide devient un nombre, un booléen ou null ; désactivez-la pour tout garder en texte. Les noms avec espace de noms (soap:Body) sont conservés tels quels. L’aperçu montre les 200 premières lignes avant le téléchargement.
Ne convient pas pour : Les documents qui ne sont pas du XML bien formé (balises non fermées, pages HTML) – l’analyseur signale le premier problème au lieu de deviner.
La détection des types s’applique aux attributs comme au texte, et ne change une valeur que là où rien n’est perdu. Activée, elle transforme id="3" en "@id": 3, tandis que id="007" reste le texte "007". 1.50 reste lui aussi du texte, car en nombre il serait réécrit 1.5. TRUE devient true. Un élément vide comme <note/>, ou qui ne contient que des espaces, devient null ; le mot NULL reste du texte. Les dates comme 2024-01-05 ne sont jamais converties.
Avec la détection désactivée, les éléments vides deviennent "" et chaque valeur reste du texte, exactement telle qu’elle est écrite.
Certaines parties d’un document XML n’ont pas de place en JSON et sont abandonnées : les commentaires, les instructions de traitement et le DOCTYPE. Les sections CDATA deviennent du texte ordinaire : <a><![CDATA[<b>x</b>]]></a> donne "a": "<b>x</b>".
L’ordre entre des éléments de noms différents est perdu, car chaque nom devient une seule clé. Dans <step>1</step><note/><step>2</step>, les deux step sont regroupés dans "step": [1, 2], et rien ne retient que la note se trouvait entre eux. Le texte mêlé de balises perd sa place de la même façon : <p>Bonjour <b>le monde</b> et <i>vous</i> !</p> donne "b": "le monde", "i": "vous" et "#text": "Bonjour et !". Pour les documents où cet ordre fait le contenu, comme de la prose mise en forme, cette correspondance ne convient pas.
Les noms préfixés sont gardés tels qu’ils sont écrits, et les déclarations d’espaces de noms apparaissent comme des attributs : <soap:Envelope xmlns:soap="…"> donne une clé "soap:Envelope" qui contient "@xmlns:soap", et /json-to-xml retransforme les deux en le même XML.
En dehors des entités que définit le DOCTYPE du document lui-même, seules les cinq entités intégrées à XML (& < > " ') et les entités numériques comme   sont comprises. Quand l’analyseur s’arrête, le message donne la ligne et la colonne et dit en mots simples ce qui ne va pas : un élément fermé sous un autre nom, un nom inconnu comme (écrivez   à la place), un & ou un < isolé, un deuxième élément au sommet, ou un fichier qui se termine trop tôt.
Le fichier est lu dans l’encodage que déclare sa première ligne, comme ISO-8859-1 ou windows-1256. Sans déclaration, il est lu en UTF-8 ou en UTF-16, et les anciennes pages de codes sont reconnues comme l’explique /csv-to-json.
Cette page dans d’autres langues: English · العربية · Deutsch · Español · Русский · Português · 中文 · हिन्दी · Türkçe · עברית · فارسی · اردو · Bahasa Indonesia · বাংলা