Conversion YAML en JSON en ligne, gratuite

Qu'est-ce que YAML ?

YAML (YAML Ain't Markup Language) est un format de sérialisation de données convivial pour les humains, conçu pour être facile à lire et à écrire. Il est largement utilisé pour les fichiers de configuration, les pipelines CI/CD et l'échange de données entre langages de programmation.

Pourquoi convertir YAML en JSON ?

• Compatibilité universelle · JSON est pris en charge par pratiquement tous les langages de programmation et outils.
• Gestion de configuration · De nombreux outils attendent du JSON pour la configuration ou l'échange de données.
• Intégration d'API · Les API web exigent généralement le format JSON.
• Traitement des données · Convertissez vos fichiers de configuration YAML pour les utiliser dans des flux de travail automatisés.

Questions fréquentes

Quelles fonctionnalités YAML sont prises en charge ?

Le convertisseur prend en charge toutes les fonctionnalités standard de YAML 1.2, y compris les mappages, les listes, les types scalaires (chaînes, nombres, booléens, null), les ancres et les alias, les documents multiples et les structures imbriquées.

Ma structure YAML complexe sera-t-elle convertie correctement ?

Oui. Le convertisseur gère les structures profondément imbriquées, les tableaux d'objets, les références d'ancres et les types de données mixtes. Si votre YAML est valide, il produira un JSON équivalent, en préservant toutes les relations entre les données.

Les commentaires YAML sont-ils préservés ?

Non. JSON ne prend pas en charge les commentaires ; ils sont donc supprimés lors de la conversion. Seules les données structurées de votre YAML sont converties au format JSON.

Une brève histoire de YAML, un dérivé de liste de diffusion né en 2001

La préhistoire de YAML commence sur la liste de diffusion sml-dev, une émanation des années 2000 de xml-dev qui rassemblait des gens estimant que XML était excessif pour des données éditées à la main. Deux pistes parallèles ont convergé : le module Perl Data::Denter d'Ingy döt Net, écrit comme format de sérialisation pour le module Inline Perl, et un travail conjoint d'Oren Ben-Kiki et Clark Evans visant à simplifier XML. Le 11 mai 2001, Clark Evans a publié « YAML Draft 0.1 » sur sml-dev, et le format a été rendu public pour la première fois dans un article xmlhack le lendemain.

Le développement initial de l'acronyme était ironique : Yet Another Markup Language, un tacle à la prolifération des formats de balisage en 2001. Entre décembre 2001 et avril 2002, les auteurs ont rétroactivement adopté l'acronyme récursif YAML Ain't Markup Language : en partie pour souligner que YAML est un format de sérialisation de données plutôt qu'un format de balisage de documents comme XML ou HTML, et en partie parce que la blague avait vieilli. Le développement récursif reste aujourd'hui la signature officielle sur yaml.org.

Chronologie de la spécification

• Brouillon 0.1 : 11 mai 2001, annonce sur la liste de diffusion sml-dev.
• YAML 1.0 : 29 janvier 2004, la première spécification stable, par Ben-Kiki, Evans et Ingy döt Net.
• YAML 1.1 : 18 janvier 2005, la version que la plupart des analyseurs « hérités » émulent encore par défaut. Source du problème norvégien et de la plupart des verrues du typage implicite.
• YAML 1.2.0 : 21 juillet 2009, la première révision avec un objectif explicite de « sur-ensemble de JSON ». Typage implicite réécrit pour s'aligner sur les jetons de JSON.
• YAML 1.2.1 : 1er octobre 2009, une mise à jour de 1.2.0 limitée aux errata.
• YAML 1.2.2 : 1er octobre 2021, la révision de corrigenda par la nouvelle YAML Language Development Team formée en 2020.

La spécification 1.2.2 indique explicitement qu'« il n'y a aucun changement normatif par rapport à la spécification YAML v1.2 » ; le travail a consisté à convertir la source de DocBook vers Markdown, à régénérer les diagrammes à partir de LaTeX en texte brut, et à ouvrir le processus de développement pour que des contributeurs externes puissent soumettre des pull requests sur la spécification elle-même. Aucune version du langage n'est sortie depuis 2009 : chaque bogue de conformité d'analyseur depuis lors est soit un vestige de la 1.1, soit un écart par rapport à une spécification qui tient désormais depuis plus de quinze ans. Le type MIME officiel application/yaml a été finalisé en 2024 ; les extensions de fichier .yaml et .yml sont toutes deux reconnues depuis environ 2006, .yaml étant l'extension recommandée.

La relation avec JSON, « presque un sur-ensemble »

La spécification YAML 1.2.2 le formule avec prudence : « Par pure coïncidence, JSON était presque un sous-ensemble complet de YAML. » JSON est apparu entre YAML 1.0 (2004) et YAML 1.1 (2005) ; les auteurs de YAML n'ont découvert le recoupement qu'après coup. L'objectif explicite de la révision 1.2, selon ses propres termes, était de « faire de YAML un sur-ensemble strict de JSON », et c'est presque vrai pour les documents YAML 1.2 au format JSON, mais ce n'est pas vrai pour YAML 1.1.

Concrètement : tout document JSON est un YAML 1.2 valide, le mappage en style flux {"a": 1, "b": [true, null]} s'analyse de façon identique dans les deux. La plupart des documents JSON ne sont pas des YAML 1.1 valides à cause des pièges des booléens et de la Norvège : un document JSON contenant la chaîne littérale "NO" serait réémis comme false s'il faisait un aller-retour dans un analyseur 1.1 avec les réglages par défaut. L'inverse n'est jamais vrai : YAML peut exprimer des choses que JSON ne peut pas, les commentaires (perdus à la conversion), les ancres et les alias (résolus à la conversion), les tags (généralement écartés), les flux multi-documents (seul le premier ou tous-en-tableau survivent) et les clés non textuelles dans les mappages.

Le problème norvégien

Le piège le plus cité de YAML. Il porte le nom de la Norvège parce que le code de pays à deux lettres ISO 3166-1 de la Norvège est NO, et que l'expression régulière des booléens de YAML 1.1 reconnaît NO comme le booléen faux. Écrivez country: NO en YAML 1.1 (ou dans tout analyseur 1.2 fonctionnant encore par défaut selon le comportement 1.1, ce qui est le cas de la plupart d'entre eux), analysez-le, exportez-le en JSON, et vous obtenez {"country": false}. Le bogue est silencieux : aucun avertissement, aucune erreur de type, juste une corruption de données.

L'expression régulière complète des booléens de YAML 1.1, issue du schéma officiel yaml.org/type/bool.html, est :

y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

Cela fait six lexèmes (y/n, yes/no, on/off, true/false) avec trois variantes de casse chacun, vingt-deux chaînes qui deviennent toutes des booléens sans avertissement. Une liste de réponses valides [y, n, maybe] devient [true, false, "maybe"] ; un indicateur de fonctionnalité dark_mode: on s'analyse comme dark_mode: true ; un réglage de mode de port écrit OFF devient false. YAML 1.2 a corrigé cela au niveau de la spécification : le schéma de base aligné sur JSON ne reconnaît que true, True, TRUE, false, False, FALSE et ne reconnaît pas du tout y/n/yes/no/on/off. Mais ce correctif ne s'est pas propagé sur le terrain : PyYAML et LibYAML restent en 1.1 par défaut dans toutes les versions actuellement diffusées. Ce convertisseur utilise js-yaml v4, qui adopte par défaut le schéma YAML 1.2 / compatible JSON ; c'est l'une des raisons pour lesquelles un convertisseur côté navigateur est en réalité plus sûr que d'exécuter yaml.load() dans PyYAML et de convertir à partir de là.

Autres mines du typage implicite

Nombres octaux. YAML 1.1 suivait la convention du C : un zéro initial signifiait l'octal. Ainsi, 010 s'analysait comme l'entier 8, et permissions: 0777 (une façon parfaitement naturelle d'écrire un mode de fichier Unix) s'analysait comme 511. Le correctif de YAML 1.2 a consisté à exiger un préfixe 0o explicite, à l'image du Python moderne : 0o777 vaut 511, et 0777 vaut simplement 777. Les analyseurs restés sur les valeurs par défaut de 1.1 se trompent encore là-dessus.

Nombres sexagésimaux. YAML 1.1 a hérité de formats de sérialisation antérieurs la convention selon laquelle toute suite de groupes de chiffres décimaux séparés par des deux-points devait être analysée comme un entier ou un flottant en base 60 (sexagésimal). Le cas d'usage mis en avant était les durées : 1:11:00 s'analyserait comme l'entier 4260 (une heure et onze minutes, en secondes). Cette règle continue de piéger les gens en pratique lorsqu'ils écrivent des horodatages comme 21:00 ou des numéros de version comme 2:3:4 et les voient silencieusement convertis en entiers. Le sexagésimal a été supprimé sans bruit dans YAML 1.2, mais PyYAML et d'autres analyseurs en 1.1 par défaut l'appliquent encore.

Conversion automatique des dates et heures. YAML 1.1 détecte aussi automatiquement les horodatages ISO 8601 et les analyse comme le type date/heure natif du langage hôte, ce qui pose problème si vous vouliez une chaîne. Écrivez version: 2024-01-15 et vous obtenez un objet date Python, et non la chaîne "2024-01-15". La leçon générale, martelée par l'essai « YAML document from hell » de Ruud van Asseldonk : mettez toujours entre guillemets les chaînes susceptibles d'être analysées comme autre chose. Les codes de pays, les numéros de version, les modes de fichier, les horodatages et toute valeur tirée d'un vocabulaire fixe devraient être entourés de guillemets simples ou doubles.

Ancres, alias et clé de fusion

Le système d'ancres et d'alias de YAML vous permet d'étiqueter un nœud avec &name et de le réutiliser plus loin avec *name. L'exemple classique :

defaults: &defaults
  timeout: 30
  retries: 3
production:
  <<: *defaults
  host: prod.example.com

Ici, &defaults ancre le mappage, et <<: *defaults (la clé de fusion, une fonctionnalité du schéma 1.1 conservée par la plupart des analyseurs) l'insère dans le bloc. Lorsque cela est converti en JSON, l'alias est entièrement résolu : la sortie JSON contient le contenu répété littéral, et non une référence. Les ancres et les alias disparaissent, et toute clé de fusion est aplatie.

Le célèbre mode de défaillance de ce système est l'attaque billion laughs : parce que les ancres peuvent être aliasées plusieurs fois et que les cibles d'alias peuvent elles-mêmes contenir des alias, un petit fichier YAML peut se déployer en une structure en mémoire énorme (10 niveaux × une imbrication décuplée = 10¹⁰ éléments de chaîne). PyYAML, LibYAML et d'autres ont dû ajouter des limites d'expansion pour atténuer cela. Les convertisseurs côté navigateur ont des plafonds de mémoire naturels (l'onglet saturera bien avant que l'hôte n'en souffre), mais le risque structurel est réel.

Les flux multi-documents et le front matter

Un flux YAML peut contenir plus d'un document. Les documents sont séparés par une ligne contenant exactement --- (également utilisée comme marqueur de fin de directives au début du premier document, ce qui explique pourquoi le front matter de Jekyll, Hugo et Eleventy est encadré par des lignes ---). Une ligne contenant ... marque la fin d'un document sans en commencer un nouveau, utile dans les protocoles de flux.

Kubernetes utilise --- pour regrouper plusieurs manifestes de ressources dans un même fichier. JSON n'a pas d'équivalent. Un convertisseur a trois choix lorsqu'il rencontre du YAML multi-documents : n'émettre que le premier document, émettre un tableau JSON de documents, ou émettre un document JSON par --- séparé par des sauts de ligne (JSON Lines). La plupart des convertisseurs choisissent par défaut la première ou la deuxième option ; la fonction loadAll de js-yaml renvoie un tableau.

Les chaînes multilignes : pliée ou littérale

YAML possède deux styles de scalaire de bloc. Le style littéral (|) préserve exactement les sauts de ligne. Le style plié (>) remplace les sauts de ligne simples par des espaces et conserve les lignes vides comme séparateurs de paragraphes. Les deux acceptent des indicateurs de raccourcissement : |- et >- suppriment tous les sauts de ligne finaux, |+ et >+ les conservent tous, et le | ou > non modifié (« clip ») préserve un seul saut de ligne final. Une fois convertis en JSON, les deux styles produisent des valeurs de chaîne ordinaires : le bloc plié devient une longue chaîne avec des \n intégrés uniquement aux lignes vides préservées ; le bloc littéral comporte des \n à chaque saut de ligne.

Ce qui se perd à la conversion

• Les représentations de null s'effondrent. YAML accepte null, Null, NULL, ~ et une valeur vide (key: sans rien après) comme null. Les cinq deviennent le null de JSON, sans distinction possible.
• Les commentaires disparaissent en silence. Les commentaires YAML commencent par # et la spécification 1.2 indique explicitement qu'ils relèvent de la seule présentation, et non du modèle de données. JSON n'a pas de syntaxe de commentaire. Si vous devez les préserver, stockez-les comme des données (par exemple, un champ _comment) avant la conversion.
• Les clés non textuelles sont converties. Les mappages YAML autorisent n'importe quel nœud comme clé, y compris les entiers (1: foo), les booléens (true: yes) et même les séquences imbriquées. JSON exige des clés de type chaîne. La plupart des convertisseurs les transforment en chaînes ("1": "foo") ; certains lèvent une erreur.
• Les tags sont généralement abandonnés. Les tags personnalisés comme !!set, !!omap, ou propres à une application comme !myapp/Type n'ont pas d'équivalent JSON.
• Les dates et heures font l'aller-retour sous forme de chaînes. Une date ou un horodatage YAML devient généralement une chaîne ISO 8601 en JSON, puisque JSON n'a pas de type de date natif.
• Les grands entiers perdent en précision en JavaScript. Les nombres JSON sont des doubles IEEE 754 en JS, de sorte qu'un entier YAML comme 9007199254740993 devient silencieusement 9007199254740992 après conversion.
• Les ancres sont développées. Un graphe YAML qui partage un sous-arbre entre plusieurs positions devient un arbre JSON où ce sous-arbre est dupliqué. Les références cycliques (que YAML autorise) ne sont pas du tout représentables en JSON.

Où YAML est réellement utilisé

YAML est partout dans l'infrastructure moderne : les manifestes Kubernetes (tout le modèle objet est en YAML par convention ; les fichiers multi-documents séparés par --- sont la norme), Docker Compose (docker-compose.yml pour les services, les réseaux, les volumes), GitHub Actions (.github/workflows/*.yml : schéma YAML 1.2 strict globalement respecté, mais l'analyseur reconnaît encore on: comme une clé, un quasi-accident de problème norvégien que GitHub contourne explicitement), GitLab CI/CD, les playbooks Ansible, CircleCI / Travis CI / Drone / Bitbucket Pipelines, le front matter de Jekyll / Hugo / Eleventy / Gatsby / Astro, les spécifications OpenAPI / Swagger (officiellement « un objet JSON qui peut être représenté soit en JSON, soit en YAML »), la configuration de la pile de supervision Prometheus / Grafana / Loki / Tempo, cloud-init (provisionnement au premier démarrage des VM EC2/GCE/Azure) et AWS CloudFormation / Azure Resource Manager / Google Cloud Deployment Manager. Pour la plupart de ces cas, la conversion de YAML en JSON est essentielle dès que vous intégrez une configuration dans des protocoles uniquement JSON, que vous comparez des fichiers avec jq, ou que vous fournissez la sortie à un outil qui attend du JSON.

Pourquoi la conversion côté navigateur est plus sûre que côté serveur

Le yaml.load() de PyYAML, avec les réglages par défaut, pouvait exécuter du code Python arbitraire sur n'importe quelle entrée non fiable via le tag !!python/object, qui se désérialise en de véritables objets Python avec effets de bord : CVE-2017-18342, score CVSS v3.1 de 9,8 (critique), corrigé dans PyYAML 5.1 (mars 2019) en dépréciant la valeur par défaut non sûre et en faisant de safe_load() le point d'entrée recommandé. Le SnakeYAML de Java avait son propre équivalent (CVE-2022-1471, également CVSS 9,8) autour de la classe Constructor permettant une instanciation arbitraire. La crate serde_yaml, de facto standard de Rust, a été dépréciée en mars 2024 ; l'écosystème s'accorde encore sur un successeur (serde_yml, serde_yaml_ng, serde_norway).

Exécuter l'analyse dans le navigateur via js-yaml v4 contourne tout cela : il n'y a aucun serveur à compromettre, js-yaml n'a aucune notion d'exécution de code arbitraire via les tags (les tags inconnus deviennent de simples scalaires plutôt que des objets construits), et la v4 adopte par défaut le schéma 1.2, plus sûr. L'outil Absolutool en bénéficie par défaut.

Plus de questions

Comment le convertisseur gère-t-il les fichiers YAML multi-documents ?

Il les charge avec la fonction loadAll de js-yaml, qui renvoie un tableau de documents analysés : la sortie JSON est donc un tableau JSON comportant un élément par document séparé par ---. Si vous n'avez qu'un seul document, vous obtiendrez un tableau JSON à un élément ; encadrez votre entrée par des marqueurs ---/... si vous voulez une sémantique explicite de document unique.

Mon manifeste Kubernetes sera-t-il converti correctement ?

Presque toujours oui. Kubernetes utilise pour l'essentiel un contenu compatible YAML 1.2, et js-yaml v4 gère toutes les primitives standard (chaînes, entiers, booléens, nuls, séquences, mappages) ainsi que les ancres et les alias. Les deux éléments qui ne survivent pas sont les commentaires (supprimés) et toute ancre développée en contenu répété plutôt qu'en référence.

Pourquoi mon code de pays NO est-il lu comme un booléen ?

Cela ne devrait pas être le cas dans ce convertisseur : js-yaml v4 adopte par défaut le schéma YAML 1.2 / compatible JSON, qui ne reconnaît pas y/n/yes/no/on/off comme des booléens. Si vous rencontrez cela dans un autre outil (PyYAML, par exemple), le correctif consiste à entourer la valeur de guillemets : country: "NO".

Quelle est la limite de taille de fichier ?

5 Mo sur le widget de téléversement, mais le contenu collé peut être plus volumineux si votre navigateur a la mémoire nécessaire. Le goulot d'étranglement est la représentation en mémoire, pas le réseau : il n'y a aucun serveur dans la boucle. Pour les fichiers de plus de 50 Mo environ, envisagez plutôt une chaîne d'outils YAML de bureau (yq en ligne de commande, par exemple).

Outils associés