820 votes

Quelle est la différence entre YAML et JSON ?

Quelles sont les différences entre YAML et JSON, en tenant compte notamment des éléments suivants ?

  • Performance (temps de codage/décodage)
  • Consommation de mémoire
  • Clarté de l'expression
  • Disponibilité des bibliothèques, facilité d'utilisation (je préfère le C)

Je prévoyais d'utiliser l'un de ces deux dans notre système embarqué pour stocker les fichiers de configuration.

En rapport :

Dois-je utiliser YAML ou JSON pour stocker mes données Perl ?

35 votes

Sachez que JSON peut être considéré comme un sous-ensemble de YAML : fr.wikipedia.org/wiki/JSON#YAML

2 votes

@Charles, oui, mais ils ont une différence subtile : ajaxian.com/archives/json-yaml-it-s'approcher-de-la-vérité

2 votes

Puisque YAML est (approximativement) un sur-ensemble de JSON, il est impossible de répondre à la question des performances sans savoir si vous utiliserez cette expressivité. Si vous n'en avez pas besoin : à quelle vitesse les analyseurs YAML lisent-ils JSON ? Si vous en avez besoin : dans quelle mesure les analyseurs JSON sont-ils plus lents lorsque vous autorisez une représentation JSON éventuellement plus longue de la même idée ?

727voto

AndyL Points 4134

Techniquement, YAML est un sur-ensemble de JSON. Cela signifie que, en théorie du moins, un analyseur YAML peut comprendre JSON, mais pas nécessairement l'inverse.

Voir les spécifications officielles, dans la section intitulée "YAML : Relation avec JSON " .

En général, il y a certaines choses que j'aime dans YAML qui ne sont pas disponibles dans JSON.

  • Comme @jdupont a souligné YAML est visuellement plus facile à regarder. En fait, le Page d'accueil YAML est lui-même un YAML valide, mais il est facile à lire pour un humain.
  • YAML a la capacité de référencer d'autres éléments dans un fichier YAML en utilisant des "ancres". Il peut donc gérer des informations relationnelles comme on peut en trouver dans une base de données MySQL.
  • YAML est plus robuste pour intégrer d'autres formats de sérialisation tels que JSON ou XML. sur un fichier YAML.

En pratique, aucun de ces deux derniers points n'aura d'importance pour les choses que vous ou moi faisons, mais à long terme, je pense que YAML sera un format de sérialisation des données plus robuste et plus viable.

Actuellement, AJAX et d'autres technologies web ont tendance à utiliser JSON. YAML est actuellement plus utilisé pour les traitements de données hors ligne. Par exemple, il est inclus par défaut dans le paquetage de vision informatique OpenCV basé sur le langage C, alors que JSON ne l'est pas.

Vous trouverez des bibliothèques C pour JSON et YAML. Les bibliothèques de YAML ont tendance à être plus récentes, mais je n'ai eu aucun problème avec elles dans le passé. Voir par exemple Yaml-cpp .

222 votes

Json est no un sous-ensemble (bien qu'il soit proche), et les incompatibilités sont exaspérantes lorsque vous les rencontrez. les bibliothèques json sont généralement plus rapides... ( stackoverflow.com/questions/2451732/ ). les partisans de yaml insisteront sur le fait qu'il s'agit d'un sous-ensemble. si la lisibilité est une préoccupation, utilisez yaml. si l'interopérabilité et la vitesse sont une préoccupation, utilisez JSON.

10 votes

YAML est un sur-ensemble d'une forme particulière de la syntaxe JSON. En d'autres termes, si vous utilisez JSON d'une manière compatible avec YAML, alors il s'agit d'un sous-ensemble approprié. Comme pierr l'a commenté plus haut, les spécifications sont [orientées vers la compatibilité] (ajaxian.com/archives/json-yaml-its-getting-closer-to-truth).

147 votes

YAML prend également en charge les commentaires, ce qui est pratique.

235voto

Erik Aronesty Points 2223

Différences :

  1. YAML, selon la façon dont vous l'utilisez, peut être plus lisible que JSON.
  2. JSON est souvent plus rapide et est probablement encore interopérable avec plus de systèmes
  3. Il est possible d'écrire très rapidement un analyseur JSON "suffisamment bon".
  4. Les clés dupliquées, qui sont potentiellement JSON valide, sont définitivement YAML invalide.
  5. YAML possède une tonne de fonctionnalités, notamment des commentaires et des ancres relationnelles. La syntaxe YAML est donc assez complexe et peut être difficile à comprendre.
  6. Il est possible d'écrire des structures récursives en yaml : {a: &b [*b]} qui tourne en boucle à l'infini dans certains convertisseurs. Même avec la détection circulaire, une "bombe yaml" est toujours possible (voir bombe xml ).
  7. Comme il n'y a pas de références, il est impossible de sérialiser des structures complexes avec des références d'objets dans JSON. La sérialisation YAML peut donc être plus efficace.
  8. Dans certains environnements de codage, l'utilisation de YAML peut permettre à un attaquant de exécuter un code arbitraire .

Observations :

  1. Les programmeurs Python sont généralement de grands fans de YAML, en raison de l'utilisation de l'indentation, plutôt que de la syntaxe entre crochets, pour indiquer les niveaux.
  2. De nombreux programmeurs considèrent que l'attachement du "sens" à l'indentation est un mauvais choix.
  3. Si le format des données doit quitter l'environnement d'une application, être analysé dans une interface utilisateur ou être envoyé dans une couche de messagerie, JSON peut être un meilleur choix.
  4. YAML peut être utilisé, directement, pour des tâches complexes comme les définitions de grammaire, et constitue souvent un meilleur choix que l'invention d'un nouveau langage.

10 votes

C'est le cas. Le but entier de Yaml 1.2 était de résoudre les quelques différences de compatibilité pour faire de JSON un sous-ensemble strict. Si vous pensez que la spécification n'a pas atteint son objectif, Erik, veuillez indiquer un exemple quelque part de JSON valide qui viole la spécification YAML et/ou qui casse un analyseur YAML conforme à la norme 1.2.

36 votes

@SFEley La spécification YAML indique qu'il existe des fichiers JSON potentiellement valides qui seraient des YAML invalides. Mais c'est peu probable en utilisation réelle. "La RFC4627 de JSON exige que les clés de mappings soient simplement "SHOULD" uniques, alors que YAML insiste sur le fait qu'elles "MUST". Techniquement, YAML est donc conforme à la spécification JSON et choisit de traiter les doublons comme une erreur. En pratique, puisque JSON est silencieux sur la sémantique de ces doublons, les seuls fichiers JSON portables sont ceux dont les clés sont uniques, qui sont donc des fichiers YAML valides." - yaml.org/spec/1.2/spec.html#id2759572

2 votes

Bonne remarque. (Bien qu'il soit peu probable que cela se produise dans la pratique, mais ce n'était pas la question.) Merci.

104voto

Jason Sebring Points 4309

Contourner la théorie ésotérique

Cela répond au titre, mais pas aux détails, car la plupart des gens lisent le titre à partir d'un résultat de recherche sur Google, comme moi, et j'ai donc jugé nécessaire de l'expliquer. du point de vue d'un développeur web .

  1. YAML utilise l'indentation par espace, ce qui est un terrain familier pour les développeurs Python.
  2. Les développeurs JavaScript adorent JSON parce qu'il s'agit d'un sous-ensemble de JavaScript et qu'il peut être directement interprété et écrit en JavaScript. De plus, il utilise une manière abrégée de déclarer JSON, ne nécessitant pas de guillemets doubles dans les clés lors de l'utilisation de noms de variables typiques sans espaces.
  3. Il existe une pléthore d'analyseurs syntaxiques qui fonctionnent très bien dans tous les langages, tant pour YAML que pour JSON.
  4. Le format d'espace de YAML peut être beaucoup plus facile à regarder dans de nombreux cas, car le formatage nécessite une approche plus lisible par l'homme.
  5. La forme de YAML, tout en étant plus compacte et plus facile à regarder, peut être faussement difficile à éditer manuellement si le formatage de l'espace n'est pas visible dans votre éditeur. Les tabulations ne sont pas des espaces, ce qui complique encore les choses si vous ne disposez pas d'un éditeur qui interprète vos frappes en espaces.
  6. JSON est beaucoup plus rapide à sérialiser et à désérialiser car il y a beaucoup moins de caractéristiques à vérifier que dans YAML, ce qui permet de traiter JSON avec un code plus petit et plus léger.
  7. Une idée fausse et répandue est que YAML nécessite moins de ponctuation et est plus compact que JSON, mais c'est complètement faux. Les espaces blancs sont invisibles, ce qui donne l'impression qu'il y a moins de caractères, mais si vous comptez les espaces blancs réels qui doivent être présents pour que YAML soit interprété correctement, ainsi qu'une indentation adéquate, vous constaterez que YAML nécessite en fait plus de caractères que JSON. Le JSON n'utilise pas d'espace pour représenter la hiérarchie ou le regroupement et peut facilement être aplati en supprimant les espaces inutiles pour un transport plus compact.

L'éléphant dans la pièce : L'internet lui-même

JavaScript domine clairement le web et les développeurs JavaScript préfèrent utiliser JSON comme format de données avec les API web les plus populaires. Il devient donc difficile d'argumenter en faveur de l'utilisation de YAML plutôt que de JSON lors de la programmation web au sens général, car vous serez probablement mis en minorité dans un environnement d'équipe. En fait, la majorité des programmeurs web ne savent même pas que YAML existe, et encore moins qu'ils envisagent de l'utiliser.

Si vous faites de la programmation web, JSON est la solution par défaut car aucune étape de traduction n'est nécessaire lorsque vous travaillez avec JavaScript. Vous devez donc trouver un meilleur argument pour utiliser YAML plutôt que JSON dans ce cas.

14 votes

Je ne suis pas d'accord avec le fait que les développeurs python préfèrent YAML. Python dict est fondamentalement JSON, une liste de dicts est aussi fondamentalement JSON. Python a une librairie json intégrée. En passant, je suis un développeur python et je préfère JSON (la plupart des développeurs python que je connais préfèrent JSON).

0 votes

Lorsque vous parlez d'une "étape de traduction", il convient de faire la distinction entre la traduction mentale et la traduction mécanique. Le lecteur humain familier de JavaScript sera également familier de JSON. Pour la machine, la différence entre JavaScript et YAML est marginale ; dans la pratique, il est rare que l'on fasse eval(jsonString) à cause des attaques par injection. L'avantage de JSON d'être natif JavaScript est perdu lorsque JSON et YAML doivent être analysés.

2 votes

@toolbear il est plus sûr d'utiliser JSON.parse(jsonString) plutôt que eval(jsonString)

54voto

Steve Bennett Points 4273

Cette question date de 6 ans, mais bizarrement, aucune des réponses n'aborde vraiment les quatre points (vitesse, mémoire, expressivité, portabilité).

Vitesse

Évidemment, cela dépend de l'implémentation, mais parce que JSON est si largement utilisé et si facile à implémenter, il a eu tendance à bénéficier d'un plus grand support natif, et donc d'une plus grande rapidité. Si l'on considère que YAML fait tout ce que JSON fait, et bien plus encore, il est probable que, parmi toutes les implémentations comparables des deux, celle de JSON sera plus rapide.

Cependant, étant donné qu'un fichier YAML peut être légèrement plus petit que son homologue JSON (en raison d'un nombre inférieur de " y , caractères), c'est possible qu'un analyseur YAML hautement optimisé pourrait être plus rapide dans des circonstances exceptionnelles.

Mémoire

En gros, le même argument s'applique. Il est difficile de voir pourquoi un analyseur YAML serait plus efficace en mémoire qu'un analyseur JSON, s'ils représentent la même structure de données.

Expressivité

Comme d'autres l'ont fait remarquer, les programmeurs Python ont tendance à préférer YAML, les programmeurs JavaScript JSON. Je ferai ces observations :

  • Il est facile de mémoriser l'ensemble de la syntaxe JSON, et donc d'être sûr de comprendre la signification de n'importe quel fichier JSON. YAML n'est pas vraiment compréhensible par un humain. Le nombre de subtilités et de cas limites est extrême.
  • Comme peu d'analyseurs syntaxiques mettent en œuvre l'ensemble de la spécification, il est encore plus difficile d'être certain de la signification d'une expression donnée dans un contexte donné.
  • L'absence de commentaires dans JSON est, en pratique, une véritable plaie.

Portabilité

Il est difficile d'imaginer un langage moderne sans une bibliothèque JSON. Il est également difficile d'imaginer un analyseur JSON implémentant moins que la spécification complète. YAML est largement supporté, mais il est moins omniprésent que JSON, et chaque analyseur implémente un sous-ensemble différent. Les fichiers YAML sont donc moins interopérables que vous ne le pensez.

Résumé

JSON est le vainqueur pour les performances (le cas échéant) et l'interopérabilité. YAML est meilleur pour les fichiers gérés par l'homme. HJSON est un bon compromis, bien que sa portabilité soit très réduite. JSON5 est un compromis plus raisonnable, avec une syntaxe bien définie.

5 votes

En fait, je pensais que YAML était plus petit à cause des caractères invisibles qui me trompaient comme tels. Invisible => Pas là, enfin pas vraiment. Si l'on compte les caractères invisibles qui doivent être là, surtout lorsque YAML devient plus imbriqué, il surpasse rapidement JSON. J'ai juste pensé que c'était très intéressant car la partie lisible par l'homme trompe la plupart d'entre nous dans cette notion jusqu'à ce que j'y réfléchisse vraiment, car vous pouvez aplatir JSON et YAML, pas tellement. J'ai également trouvé que YAML était très difficile à éditer à la main, pas à lire, juste à éditer comme vous avez besoin de guides d'édition activés, confondant facilement les éléments imbriqués parfois.

3 votes

J'ai l'impression qu'aucune des réponses ici ne le dit explicitement : "Pour les fichiers de paramètres/configuration, YAML est préférable (pour les raisons mentionnées ci-dessus par tout le monde). Pour l'interopérabilité machine/machine, utilisez JSON". En d'autres termes : si votre public cible est un humain, YAML est préférable. Si la cible est un autre programme (mais que vous voulez toujours que les données soient lisibles par l'homme), utilisez JSON.

0 votes

C'est vrai, mais la question définissait des paramètres assez spécifiques sur la façon dont ils voulaient que les deux soient comparés. Personnellement, je n'utiliserais jamais YAML pour quoi que ce soit. J'utiliserais JSON pour l'interopérabilité, ou JSON6 si la maintenance humaine est importante.

41voto

JohnAD Points 389

GIT et YAML

Les autres réponses sont bonnes. Lisez-les d'abord. Mais je vais ajouter une autre raison d'utiliser YAML de temps en temps : git .

De plus en plus, de nombreux projets de programmation utilisent des dépôts git pour la distribution et l'archivage. Et, alors que l'historique d'un dépôt git peut également stocker des fichiers JSON et YAML, la méthode "diff" utilisée pour suivre et afficher les modifications apportées à un fichier est orientée ligne. Puisque YAML est forcé d'être orienté ligne, toute petite modification dans un fichier YAML est plus facile à voir par un humain.

Il est vrai, bien sûr, que les fichiers JSON peuvent être "rendus jolis" en triant les chaînes/clés et en ajoutant une indentation. Mais ce n'est pas le cas par défaut et je suis paresseux.

Personnellement, j'utilise généralement JSON pour les interactions entre systèmes. J'utilise souvent YAML pour les fichiers de configuration, les fichiers statiques et les fichiers de suivi. (J'évite aussi généralement d'ajouter des ancres relationnelles YAML. La vie est trop courte pour traquer les boucles).

De plus, si la vitesse et l'espace sont vraiment une préoccupation, je n'utilise ni l'un ni l'autre. Vous devriez peut-être vous intéresser à BSON.

0 votes

YAML est souvent compilé en JSON, surtout lorsqu'on utilise git. Dans les actions GitHub, par exemple, un fichier .workflow.yml est nécessaire pour définir un flux de travail, mais il est simplement compilé en JSON lors de son exécution.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X