JSON vs XML
JSON et XML sont tous deux largement employés et choisis pour des raisons différentes. Cette page les oppose sur les points qui tranchent entre eux, et renvoie aux convertisseurs dans les deux sens — chacun s'exécutant dans votre navigateur, sans que le fichier soit jamais envoyé.
La réponse courte
Tous deux portent des données imbriquées et tous deux sont du texte : l'un peut donc exprimer presque tout ce qu'exprime l'autre. Le JSON le fait avec bien moins de cérémonie : pas de balises fermantes, pas de choix entre attributs et éléments, et une forme qui correspond directement aux structures de données de tout langage moderne. C'est pourquoi il a supplanté le XML pour les API, presque intégralement.
Le XML conserve les avantages de son âge et de son ambition. Il a de vrais langages de schéma, des espaces de noms pour mêler des vocabulaires, et un langage de requête avec XPath, et il traite les documents — de la prose parsemée de balises — d'une manière que le JSON ne sait pas exprimer du tout. L'édition, les données publiques et les formats bureautiques tournent encore dessus pour ces raisons.
Si vous convertissez du XML en JSON, ce qu'il faut vérifier, ce sont les attributs. Chaque convertisseur doit leur inventer une convention, et les deux plus répandues — préfixer la clé ou les imbriquer sous un objet distinct — produisent du JSON différent à partir du même XML. Quelle que soit celle qu'emploie votre outil, le résultat ne se reconvertit plus vers le fichier de départ.
Côte à côte
| Propriété | JSON | XML |
|---|---|---|
| Stocké sous forme de | Texte brut, lisible dans n'importe quel éditeur | Texte brut, lisible dans n'importe quel éditeur |
| Ce qu'il peut contenir | Des valeurs imbriquées dans des valeurs | Des valeurs imbriquées dans des valeurs |
| Les nombres restent des nombres | Oui | Non |
| Commentaires | Non | Oui |
| Plusieurs dans un fichier | Non | Non |
| Publié | 2001 | 1998 |
Là où ils diffèrent réellement
- Seul JSON sait quel genre de valeur il contient. Dans l'autre tout est texte, d'où les zéros initiaux qui s'évaporent et les nombres longs qui deviennent des notations scientifiques.
- Seul XML a une syntaxe de commentaire. En partir perd toute explication contenue dans le fichier tout en conservant l'ensemble des données.
- Ils sont quasi contemporains, d'où leur recouvrement si important.
Ce qui se passe mal
- Convertir vers le format sans types transforme chaque valeur en texte. Les zéros initiaux disparaissent, les nombres longs deviennent des notations scientifiques, et les dates reviennent sous la forme que le programme lecteur devine.
- Les commentaires ne survivent pas vers un format qui n'a pas de syntaxe pour eux. Les données arrivent intactes et toute explication a disparu, ce qui rend ce sens effectivement unique.
Lequel choisir
- Choisissez JSON quand
- Prenez le JSON pour les API, la configuration et les données circulant entre programmes, où moins de cérémonie et la correspondance directe avec les types natifs l'emportent.
- Choisissez XML quand
- Prenez le XML pour les documents, pour tout ce qui exige validation par schéma ou espaces de noms, et là où un système existant le parle déjà.
Convertir de l'un à l'autre
Questions fréquentes
- Le XML se convertit-il proprement en JSON ?
- Pas toujours. Le XML distingue les attributs des éléments enfants et permet de mêler texte et éléments dans un même nœud, et le JSON n'a d'équivalent ni de l'un ni de l'autre. Les convertisseurs adoptent des conventions — un préfixe devant le nom d'attribut, par exemple — et le résultat est du JSON valide qui ne revient plus au XML d'origine.
- Lequel vaut mieux, JSON ou XML ?
- Aucun des deux en général — si l'un était simplement meilleur, l'autre aurait disparu. Ils sont bons à des choses différentes, et la réponse courte ci-dessus dit lequel à quoi. La question utile est de savoir ce que le fichier doit faire ensuite : être retouché, être publié, être ouvert par quelqu'un d'autre, ou tenir dans une limite de taille.
- Convertir de l'un à l'autre fait-il perdre quelque chose ?
- Cela dépend du sens. Convertir vers un format qui stocke tout ne perd rien mais ne récupère rien non plus ; convertir vers un format qui écarte du détail en perd un peu à chaque fois. Le tableau ci-dessus dit lequel de ces deux fait quoi.
- Puis-je reconvertir ensuite ?
- Le fichier se reconvertira, mais savoir s'il revient inchangé dépend du sens. Entre deux formats qui stockent tout, l'aller-retour est sans perte. Là où l'un des deux écarte du détail, ce détail a disparu et le retour ne peut pas l'inventer.
- Puis-je utiliser les deux ?
- Sur une page web, souvent oui, et c'est généralement la bonne réponse : servez le format moderne le plus léger et indiquez-en un plus ancien en repli, pour que chaque navigateur prenne ce qu'il comprend. Pour un fichier que vous remettez à une personne, choisissez-en un — celui qu'elle pourra ouvrir.
- Lequel mon logiciel prend-il en charge ?
- Le tableau côte à côte ci-dessus indique quels navigateurs lisent chacun, ce qui est la partie qui varie le plus. La prise en charge sur ordinateur est plus difficile à énoncer en général et accuse souvent des années de retard sur les navigateurs : si le fichier part vers quelqu'un d'autre, le plus ancien et le plus largement lu des deux est le choix le plus sûr.
- Convertir de l'un à l'autre est-il gratuit ?
- Oui, sans compte et sans limite sur le nombre de fichiers convertis. Chaque convertisseur lié depuis cette page s'exécute dans votre navigateur : le fichier est lu depuis votre appareil, converti par du code qui s'y exécute, et rendu en téléchargement.
- Mon fichier est-il envoyé ?
- Non. Il n'y a ici aucun serveur de conversion vers lequel l'envoyer, et aucun service tiers n'intervient. Vous pouvez le vérifier vous-même : ouvrez les outils de développement de votre navigateur, passez à l'onglet Réseau sans filtre, et lancez une conversion — aucune requête ne transporte votre fichier.