JSON vs YAML
JSON et YAML 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
Ils expriment les mêmes structures — la même imbrication, les mêmes valeurs — et diffèrent par la façon dont on les écrit et par qui doit les lire. Le YAML abandonne accolades et guillemets et laisse l'indentation faire le travail, ce qui rend un fichier de configuration bien plus agréable à modifier à la main. Il autorise aussi les commentaires, que le JSON n'a pas, et pour un fichier de configuration c'est souvent l'argument décisif.
L'avantage du JSON est d'être ennuyeux. Il n'y a qu'une façon de l'écrire, tous les langages l'analysent à l'identique, et aucun changement d'espacement ne peut en modifier le sens. Le YAML comporte assez de subtilités dans ses règles — indentation, typage implicite, valeurs comme `no` et `on` — pour qu'un fichier signifie autre chose que ce qu'il paraît dire.
Un arrangement courant consiste à écrire du YAML et à en générer du JSON : les commentaires et la lisibilité là où travaillent les humains, la version non ambiguë pour les programmes. Cela fonctionne tant que le YAML reste la source de vérité — convertir dans l'autre sens produit un fichier à la structure intacte et sans un seul commentaire.
Côte à côte
| Propriété | JSON | YAML |
|---|---|---|
| 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 | Oui |
| Commentaires | Non | Oui |
| Plusieurs dans un fichier | Non | Oui |
| Publié | 2001 | 2001 |
Là où ils diffèrent réellement
- Seul YAML a une syntaxe de commentaire. En partir perd toute explication contenue dans le fichier tout en conservant l'ensemble des données.
- Seul YAML peut contenir plusieurs documents dans un fichier, ce qui compte quand une conversion a plus d'une chose à écrire.
- Ils sont quasi contemporains, d'où leur recouvrement si important.
Ce qui se passe mal
- 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 tout ce qu'un programme écrit ou lit, pour les API, et partout où une analyse sans ambiguïté compte plus que la lisibilité.
- Choisissez YAML quand
- Prenez le YAML pour une configuration qu'une personne modifiera, où les commentaires et l'absence de ponctuation valent plus que la rigueur.
Convertir de l'un à l'autre
Questions fréquentes
- Les commentaires sont-ils perdus en convertissant du YAML en JSON ?
- Oui, et il n'y a pas moyen de l'éviter : le JSON n'a aucune syntaxe de commentaire, il n'existe donc nulle part où les mettre. Cela rend la conversion à sens unique en pratique — les données survivent, leur explication non. Gardez le YAML si les commentaires comptent.
- Lequel vaut mieux, JSON ou YAML ?
- 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.