Convertisseur JSON vers XML

1. 1

   Collez ou déposez votre JSON

   Collez du JSON dans le champ, ou déposez un fichier .json, .jsonl, .ndjson, .geojson ou .txt. JSON Lines est détecté tout seul — vous n'avez aucun mode à activer.

2. 2

   Nommez la racine et les éléments répétés

   Définissez l'élément de plus haut niveau (root par défaut). Choisissez si les éléments d'un tableau s'appellent tous item, portent le nom de la clé du tableau, ou son singulier — books devient alors book.

3. 3

   Décidez comment les valeurs sont écrites

   Choisissez ce que devient un null : un élément vide, xsi:nil, ou rien du tout. Activez l'association d'attributs si vos clés suivent la convention @nom et #text. Choisissez l'indentation, la déclaration et l'encodage de sortie.

4. 4

   Convertissez, puis téléchargez ou copiez

   Cliquez sur Convertir en XML. L'aperçu se met à jour à chaque réglage, vous voyez donc la forme avant d'exporter. Téléchargez le .xml, copiez-le ou générez le schéma .xsd correspondant.

Ce convertisseur gratuit transforme du JSON en XML bien formé, sur votre appareil. Collez ou déposez un fichier, nommez l'élément racine et les éléments répétés produits par un tableau, décidez ce que deviennent un null et une clé inutilisable, puis exportez. L'aperçu se met à jour à chaque réglage : vous voyez la forme avant de vous engager. Un JSON invalide affiche le problème, sa ligne et sa colonne, et un extrait — avec des liens vers le Formateur et le Validateur JSON.

• Élément racine — La balise de plus haut niveau qui enveloppe le document — root, data, response, tout nom XML valide. Un nom invalide est réparé et la modification vous est montrée au lieu d'être appliquée en silence.
• Nom des éléments de tableau — Une étiquette fixe pour chaque tableau, la clé dont il dépend, ou le singulier de cette clé — un tableau books écrit alors des éléments book, ce qu'une personne aurait écrit à la main.
• Attributs et texte — Activez la convention @nom et #text : une clé écrite @id devient un attribut XML tandis que #text devient le texte de l'élément. C'est le pendant exact de l'outil XML vers JSON.
• Null, vide et absent — Un null JSON peut être un élément vide, un élément xsi:nil qu'un schéma comprend, ou rien du tout. Trois sens réellement différents, là où la plupart des convertisseurs en offrent un.
• Détail de l'erreur — Un JSON invalide affiche le message, la ligne et la colonne, et un extrait avec la position marquée. Les clés en double sont signalées aussi, parce qu'elles sont valides et ambiguës.

JSON a six sortes de valeurs et XML a des éléments, des attributs et du texte. La correspondance est directe, et les seules décisions sont celles que les réglages exposent.

• Les objets deviennent des éléments imbriqués — Chaque clé devient un élément enfant portant son nom, dans l'ordre où les clés apparaissent dans la source.
• Les tableaux deviennent des éléments répétés — Un tableau ne devient pas un élément contenant une liste ; il devient le même élément écrit une fois par entrée, ce qui est la manière dont XML a toujours exprimé une valeur répétée.
• Chaînes, nombres et booléens deviennent du texte — XML n'a de type propre pour aucun des trois, donc chacun est écrit comme contenu textuel. Avec les annotations de type, chaque élément porte en plus type="number", type="string" ou type="boolean".
• Les nombres sont recopiés, pas recalculés — Les chiffres que vous avez écrits sont ceux qui ressortent. Un identifiant à vingt chiffres reste exact, -0 reste -0 et 1e-7 reste 1e-7 — rien de tout cela ne survit à un passage par une valeur flottante.
• La racine doit être inventée — JSON peut avoir un tableau, voire une simple chaîne, au niveau le plus haut ; XML doit avoir exactement un élément racine. C'est ce que nomme le réglage élément racine.

C'est la seule chose que la plupart des convertisseurs JSON vers XML ratent, et cela ne se voit pas dans la sortie. XML ne sait pas marquer un espace comme décoratif — chaque caractère entre les balises d'un élément fait partie de sa valeur. Un élément dont le contenu est du texte ne peut donc pas être indenté sans changer ce qu'il dit.

• L'erreur — Écrit naïvement, le tableau ["a","b"] se formate en un élément item avec un saut de ligne avant le a et un saut de ligne plus deux espaces après. Relu par n'importe quel parser conforme, cette valeur n'est pas "a" : c'est un saut de ligne, un a, un saut de ligne et deux espaces.
• La conséquence — Activer le formatage change les données, et la sortie compacte et la sortie indentée du même convertisseur ne veulent pas dire la même chose. Rien ne signale d'erreur et rien n'a l'air faux.
• La règle ici — Des espaces ne sont ajoutés dans un élément que si tous ses enfants sont des éléments. Un élément contenant du texte est écrit sur une ligne, quelle que soit l'indentation. L'aller-retour par deux parsers XML indépendants fait partie de la suite de tests de cet outil.

JSON n'a pas d'attributs, un convertisseur a donc besoin d'une convention pour en produire. Cet outil emploie celle que parlent déjà les bibliothèques XML vers JSON : une clé commençant par @ devient un attribut de l'élément qui la contient, et la clé #text devient son contenu textuel. Désactivée par défaut, car vos données peuvent légitimement utiliser ces clés.

• Ce que cela produit — {"@id": "7", "name": "Ada"} devient un élément portant id="7" avec un enfant name, plutôt que deux éléments enfants dont l'un s'appelle _id.
• Aller-retour — C'est la convention que lit l'outil XML vers JSON de ce site : un document converti dans un sens puis dans l'autre garde sa forme.
• Quand une valeur ne peut pas être un attribut — Un attribut contient du texte plat. Un objet ou un tableau sous une clé @ est écrit comme un élément enfant ordinaire — jamais supprimé, jamais transformé en bloc JSON à l'intérieur de votre XML — et le nombre est affiché.
• Contenu mixte — Si un élément se retrouve avec du texte et des éléments enfants, l'élément entier est écrit sur une ligne. C'est la seule façon de garder le texte intact ; voir la section ci-dessus.

Les clés JSON sont des chaînes quelconques. Les noms d'éléments XML, non : ils doivent commencer par une lettre ou un tiret bas, ne peuvent contenir ni espaces ni la plupart des signes de ponctuation, et ne peuvent pas commencer par les lettres xml. Quelque chose doit céder, et ici la manière dont cela cède est un réglage, pas une décision silencieuse.

• Réparer et afficher la liste — "first name" devient first_name et "2024" devient _2024. Un chiffre initial est préfixé plutôt que supprimé, pour que 2024 et 024 ne donnent pas le même nom. Chaque renommage figure dans le panneau à côté de l'aperçu.
• Ou garder le texte d'origine — L'autre option écrit un élément key portant name="first name", de sorte que la chaîne d'origine survit telle quelle dans le document. Plus laid, sans perte, et c'est ce que cette page produisait avant la refonte.
• Accents et écritures non latines sont conservés — Führung, señor et 名前 sont tous des noms d'éléments XML parfaitement valides et sont écrits tels quels. Les convertisseurs qui suppriment tout ce qui n'est pas A–Z massacrent sans le dire les noms de champs de la plupart des exports non anglophones.
• Les collisions sont séparées — Si "first name" et "first-name" se réparent tous deux en first_name, le second devient first_name_2 — les fusionner serait une perte de données qui ressemble à une réussite. Une clé déjà valide garde toujours son propre nom.
• Les emoji deviennent un tiret bas, délibérément — La spécification XML les autorise ; les parsers réels ne sont pas d'accord entre eux. Un parser strict refuse purement et simplement un document dont un nom d'élément contient un emoji, un autre supprime silencieusement l'élément et son contenu. Un tiret bas se relit à l'identique partout.

« Pas de valeur » a plusieurs sens en JSON et plusieurs orthographes en XML, et choisir entre elles fait la différence entre un document qu'un schéma peut valider et un autre non.

• Un élément vide — Le réglage par défaut. Un null devient un élément sans contenu, la forme qu'attendent la plupart des consommateurs.
• xsi:nil — Écrit l'élément comme nil et déclare l'espace de noms d'instance de schéma sur la racine. C'est la seule orthographe qu'un consommateur peut distinguer de « l'exportateur a oublié ce champ », et c'est ce qu'attend un XSD.
• Omis — L'élément n'est pas écrit du tout. Cela ne s'applique qu'aux membres d'objets : un null dans un tableau est tout de même écrit, car la longueur d'un tableau est une donnée et retirer une entrée décale silencieusement tous les indices suivants.
• Objets et tableaux vides — Les deux deviennent un élément vide. Un tableau vide ne produit pas une ligne blanche entre deux balises, ce qu'émet un rédacteur naïf.

Tous les convertisseurs concurrents écrivent item pour chaque tableau du document, et perdent ainsi la seule information que le tableau portait : ce qu'il contenait. Trois options ici, et personne d'autre ne propose la troisième.

• Une étiquette fixe — Chaque entrée de tableau reçoit l'étiquette que vous saisissez — item par défaut. Prévisible, et ce qu'attendra un consommateur écrit pour un autre convertisseur.
• La clé parente — Les entrées portent le nom de la clé dont dépendait le tableau : un tableau books produit des éléments books dans un élément books.
• Le singulier de la clé parente — books donne book, categories donne category, children donne child. C'est ce qu'une personne aurait écrit à la main. Quand le mot ne peut pas être raccourci, l'étiquette fixe est utilisée plutôt que d'imbriquer un nom dans lui-même.
• Un tableau au niveau racine — Un tableau tout en haut du document n'a pas de clé qui puisse le nommer : le nom de l'élément racine sert alors de parent.

Les trois réglages qui décident de l'aspect du fichier, pas de ce qu'il dit. Celui de l'encodage mérite lecture : c'est le réglage le plus souvent implémenté comme une étiquette plutôt que comme un fait.

• La déclaration XML — Activée par défaut. Elle indique la version et l'encodage, et un consommateur qui la lit la croit — c'est pourquoi les octets doivent y correspondre.
• Indentation — Deux espaces, quatre espaces, tabulations ou aucune. Sans indentation le document tient sur une ligne, ce que l'on veut quand le consommateur est un programme et non une personne.
• UTF-8 — Le réglage par défaut, et presque toujours la bonne réponse. Écrit sans marque d'ordre des octets, parce que la déclaration le dit déjà et qu'une telle marque casse les consommateurs qui attendent un chevron en premier caractère.
• UTF-16 — Écrit en véritables octets UTF-16 avec une marque d'ordre des octets, car un document UTF-16 sans elle n'est pas détectable de façon fiable et plusieurs parsers le refusent.
• ISO-8859-1 — Réellement encodé en Latin-1. Chaque caractère que l'encodage ne peut pas contenir est d'abord écrit comme référence numérique de caractère, ce qui est du XML valide et ne perd rien — un document qui annonce ISO-8859-1 en est donc vraiment un. Un convertisseur qui écrit l'étiquette et émet quand même de l'UTF-8 produit un fichier faux d'une manière qu'aucun validateur ne détecte.

Une valeur JSON par ligne, sans tableau englobant. C'est ce qu'émettent les chaînes de journalisation, les exports en masse d'API et les extractions d'entrepôts de données, et le parser JSON standard le refuse catégoriquement — la plupart des convertisseurs ne peuvent donc pas ouvrir les fichiers que les gens ont le plus souvent.

• Détecté, pas activé — Déposez un fichier .jsonl ou .ndjson et il est reconnu. Un fichier .json ou .txt qui contient en fait une valeur par ligne est reconnu aussi, car l'extension est un indice et non une promesse.
• Ce que cela produit — Chaque ligne devient un élément répété sous la racine, exactement comme si les lignes avaient formé un tableau. Tous les réglages de tableau s'appliquent normalement.
• Les lignes vides sont ignorées — Un saut de ligne final est universel et n'est pas une erreur. Toute autre ligne qui n'est pas du JSON valide signale son numéro de ligne, la seule coordonnée qui ait un sens dans ce format.

JSON n'a pas de schéma : un XSD doit donc être induit du document lui-même. Celui-ci est collecté pendant l'écriture du XML plutôt que par un second passage sur le JSON, ce qui veut dire qu'il ne peut décrire que des éléments réellement produits, avec les noms qu'ils ont réellement reçus.

• La cardinalité vient des données — Un élément enfant absent d'une seule instance de son parent est marqué facultatif. Un enfant vu plus d'une fois dans une même instance est marqué illimité.
• Les types ne sont restreints qu'en cas de certitude — Un élément reçoit un type entier seulement si toutes les valeurs vues étaient entières dans le texte source — y compris celles trop longues pour survivre en nombre flottant. Une seule décimale quelque part l'élargit.
• L'ambiguïté élargit au lieu de deviner — Un élément vu avec du texte et des enfants est marqué mixte ; un élément vu à la fois comme conteneur et comme valeur simple reste ouvert. Un schéma qui rejette le fichier dont il est issu est pire que pas de schéma du tout.
• Les espaces de noms concordent — Un espace de noms cible n'est déclaré que si le document lui-même a été écrit dans un espace de noms, car un schéma qui déclare un espace de noms que l'instance n'utilise pas ne valide rien.

Beaucoup de systèmes parlent encore XML et rien d'autre. Convertir permet de réutiliser des données déjà disponibles en JSON sans réécrire ce qui les produit, et c'est souvent l'étape la moins coûteuse d'une intégration.

• Intégration d'entreprise et SOAP — Les services SOAP, les passerelles EDI et les ERP anciens n'acceptent que du XML. Une charge convertie constitue souvent tout le travail.
• Fichiers de configuration et de build — Ant, Maven, Spring, les mises en page Android et la configuration .NET sont du XML. Des données produites en JSON doivent arriver sous cette forme.
• Validation par schéma — XML dispose de XSD, qui permet à un système récepteur de rejeter une charge malformée avant d'en faire quoi que ce soit. JSON Schema existe, mais bien moins de systèmes l'imposent.
• Documents plutôt que données — XML gère le contenu mixte — du texte contenant du balisage — que JSON ne sait pas exprimer du tout. C'est pourquoi les formats d'édition sont en XML.
• Confidentialité — La conversion s'exécute sur votre appareil. Rien de la charge n'en sort, ce qui compte quand la charge contient des données clients et que l'alternative serait de les coller sur le serveur d'un tiers.

Un fichier JSON de 9 Mo devient 17,8 Mo de XML en six dixièmes de seconde environ, sans que la page ne se fige.

• Élément racine — L'unique balise de plus haut niveau. Doit être un nom XML valide ; un nom invalide est réparé et la modification est affichée.
• Étiquette de tableau — Le nom d'élément utilisé pour chaque entrée d'un tableau quand le mode de nommage est réglé sur étiquette fixe.
• Nom des éléments de tableau — Étiquette fixe, clé parente, ou singulier de la clé parente.
• Clés invalides — Réparer la clé en un nom XML valide, ou conserver le texte d'origine dans un attribut name.
• Valeurs null — Un élément vide, xsi:nil, ou omis du document.
• Association d'attributs — Traiter les clés @ comme des attributs et #text comme le texte de l'élément.
• Annotations de type — Ajoute type="number", type="string" ou type="boolean" à chaque élément. Pro.
• Espace de noms et préfixe — Une URI d'espace de noms cible pour le document, liée par défaut ou à un préfixe. Pro.
• Déclaration XML — Faut-il écrire en tête la ligne indiquant la version et l'encodage.
• Encodage de sortie — UTF-8, UTF-16 ou ISO-8859-1 — déclaré et réellement encodé.
• Indentation — Deux espaces, quatre espaces, tabulations, ou une ligne compacte.
• Nom de fichier — La racine du nom des .xml et .xsd téléchargés.

Tout ce qui décide si la conversion est correcte est gratuit. Le forfait décide de la quantité que vous pouvez traiter d'un coup et de la présence des suppléments.

• Gratuit — Un fichier à la fois, jusqu'à 10 Mo — environ quarante mille enregistrements d'un export typique. Tous les réglages de structure, tous les modes de nommage, toutes les règles pour null, l'association d'attributs, les quatre indentations et les trois encodages.
• Pro — Aucune limite de taille imposée — jusqu'à ce que votre appareil peut gérer. Jusqu'à 50 fichiers convertis d'un coup et téléchargés dans une seule archive ZIP, plus la génération de XSD, les espaces de noms cibles et les annotations de type.
• Ce que reçoit un fichier refusé — La taille réelle, la limite et un lien vers le minificateur JSON, qui est vraiment le bon premier réflexe pour un fichier qui dépasse de quelques mégaoctets. Jamais une barre de progression qui échoue ensuite.

• XML vers JSON
• Formateur JSON
• JSON vers YAML
• Outils JSON
• Check it parses at all

  Confirms the document is valid JSON and says where it stops being valid if not

• Flatten it into a table

  When a person with a spreadsheet is the consumer rather than a system with a schema