Convertisseur YAML vers JSON
Convertissez YAML vers JSON et JSON vers YAML dans votre navigateur, avec des erreurs claires plutôt qu'un résultat faux.
Ce convertisseur YAML vers JSON transforme du YAML en JSON et du JSON en YAML, entièrement dans votre navigateur. Collez un fichier, choisissez un onglet, et récupérez un résultat à copier. Il parse le YAML de config que les gens écrivent vraiment : mappings imbriqués, listes, flow collections inline, scalaires quotés ou plain typés selon le core schema YAML 1.2, et blocs multilignes literal et folded. Quand un fichier utilise quelque chose qu'il ne peut pas gérer proprement, comme les anchors, les aliases, les tags custom ou un multi-document stream, vous obtenez une erreur avec un numéro de ligne au lieu d'une sortie silencieusement cassée. Dans l'autre sens, il quote les chaînes ambiguës exprès pour que no, on et les numéros de version survivent à chaque parser.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
YAML vers JSON et JSON vers YAML, dans votre navigateur
Collez du YAML, récupérez du JSON. Ou changez d'onglet et faites l'inverse. Tout tourne en local dans votre navigateur, et quand un fichier utilise quelque chose que ce convertisseur ne sait pas gérer proprement (anchors, tags custom, multi-document streams), vous obtenez une erreur claire avec un numéro de ligne au lieu d'un résultat silencieusement faux. Je préfère vous embêter avec un message d'erreur plutôt que vous refiler une config massacrée.
Pris en charge : mappings et listes en block et en inline, scalaires quotés ou plain typés selon le core schema YAML 1.2, blocs multilignes | et >, commentaires. Rejetés avec une erreur claire plutôt que devinés : anchors et aliases (& et *), tags (! et !!), multi-document streams (un second ---), directives (%).
Les chaînes que YAML lirait de travers ressortent quotées exprès : yes, no, on, off, tout ce qui ressemble à un nombre, les zéros en tête comme 08540, et les valeurs avec deux-points ou dièses. Sans guillemets, un parser les transformerait en booléens ou en nombres dans votre dos.
Ce que ce convertisseur YAML vers JSON prend en charge, et ce qu'il refuse de deviner
Ce convertisseur YAML vers JSON gère les fichiers de config que les gens écrivent vraiment : mappings imbriqués, listes à tirets, flow style inline avec accolades et crochets, chaînes quotées ou plain, booléens, null, entiers et floats typés comme le veut le core schema YAML 1.2, plus les blocs | literal et > folded. Les commentaires sont retirés, comme le ferait n'importe quel parser.
Ce qu'il refuse volontairement : anchors et aliases (&base, *base), merge keys, tags custom comme !!python/object, multi-document streams séparés par ---, et les directives YAML. Pas parce que c'est impossible à implémenter. Parce qu'une implémentation à moitié faite, c'est pire que rien. Un convertisseur qui expanse certains aliases et en laisse tomber d'autres en silence vous brûlera exactement une fois, en production, un vendredi. Donc à la place, vous avez une erreur avec un numéro de ligne, et vous décidez quoi en faire.
Les clés dupliquées sortent aussi en erreur ici. La plupart des parsers gardent une valeur et jettent l'autre sans un mot. Ce silence, c'est exactement de là que viennent les sessions de debug à deux heures du matin.
Le Norway problem et les autres pieges celebres de YAML
yes, no, on, off
Le grand classique. En YAML 1.1, une liste de codes pays tombe sur NO pour la Norvège et le parser le lit comme le booléen false. Même histoire pour yes, on, off et compagnie. YAML 1.2 a corrigé ça dans son core schema (seuls true et false sont des booléens désormais), et ce convertisseur suit la 1.2, donc votre no reste une chaîne au parsing. Mais voilà le truc : vous ne contrôlez pas quel parser lira votre fichier ensuite. Des tonnes d'outils se comportent encore comme la 1.1. C'est pour ça que la direction JSON vers YAML quote ces mots par précaution. "no" entre guillemets veut dire no pour tous les parsers jamais écrits.
Octaux et zéros en tête
En YAML 1.1, 0755 était de l'octal, donc parsé comme 493. En 1.2, c'est 755 en décimal. Dans les deux cas, ce n'est probablement pas ce que vous vouliez si vous écriviez une permission de fichier, et un code postal US comme 08540 a le même problème dans l'autre sens. La règle qui marche vraiment : si ça commence par un zéro et que ça compte, quotez-le. Cet outil lit 0o755 et 0x1F comme de l'octal et de l'hexa selon la spec 1.2, traite un 0755 nu comme du décimal, et quote les chaînes à zéro en tête au retour.
La règle des tabs
Les tabs sont interdits dans l'indentation YAML. Point final, aucune exception, et votre éditeur qui en glisse un sans que vous le voyiez est sans doute la première cause d'un fichier qui parsait très bien hier et plus du tout aujourd'hui. Le convertisseur sort l'erreur sur la ligne exacte, pour vous éviter de plisser les yeux sur des espaces.
Quand JSON est juste le format le plus sûr
Honnêtement, si un fichier n'est jamais écrit et lu que par des programmes, prenez JSON. Pas de sémantique d'indentation, pas de typage implicite, pas de Norway problem, et tous les langages le parsent pareil. YAML ne mérite son risque que dans un seul cas : des humains qui éditent de la config à la main, là où les commentaires et la lisibilité comptent vraiment. Les commentaires sont la killer feature de YAML et le plus gros manque de JSON, et je ne crois pas que ce manque soit comblé un jour.
D'où un pattern que j'aime bien : garder la source éditée par les humains en YAML, convertir en JSON au build ou au déploiement, et laisser tout l'aval consommer le JSON. Vous gardez les diffs lisibles et les commentaires pendant que les gens travaillent, et les machines reçoivent un format qui ne peut pas les surprendre. Cette page couvre la moitié conversion de ce workflow, dans les deux sens.
Anchors, aliases et tags : une erreur, pas de la divination
Les anchors et aliases permettent à YAML de réutiliser un bloc à plusieurs endroits, et les merge keys construisent par-dessus. Utile dans les gros fichiers docker-compose, oui. Mais le comportement d'expansion varie d'un parser à l'autre, la précédence des merge keys est franchement confuse, et une implémentation partielle produirait du JSON qui a l'air juste sans l'être. C'est peut-être moi, mais je préfère un outil qui assume ses limites à voix haute. Si votre fichier en utilise, expansez les aliases à la main ou passez-le dans le parser que votre toolchain utilise vraiment, puis ramenez le résultat ici.
Sources et lectures pour aller plus loin
Questions fréquentes
Est-ce un parser YAML 1.2 complet ?
Non, et il ne prétend pas l'être. C'est un sous-ensemble pragmatique qui couvre le YAML de config que vous collez tous les jours, avec le typage core schema 1.2 pour les scalaires. Les recoins qu'il ne couvre pas (anchors, tags, multi-doc, directives) produisent des erreurs explicites au lieu d'un résultat faux, et c'est tout l'intérêt.
Que deviennent les anchors, aliases et merge keys ?
Vous obtenez une erreur qui nomme la ligne et la construction. Le convertisseur n'essaiera pas de les expanser, parce qu'une expansion à moitié juste est pire qu'un refus. Résolvez-les d'abord avec votre parser de production, puis convertissez le résultat expansé ici.
Pourquoi le convertisseur quote no et on en passant de JSON à YAML ?
De l'autodéfense. Les parsers YAML 1.1, et il en reste plein dans la nature, lisent un no sans guillemets comme le booléen false. Le code pays de la Norvège en est la victime célèbre. Quoter coûte deux caractères et enlève l'ambiguïté pour tous les parsers, vieux ou récents.
Puis-je convertir un fichier YAML multi-document ?
Pas d'un coup. Un second marqueur --- arrête la conversion avec une erreur claire, parce que JSON n'a pas d'équivalent du document stream. Coupez le fichier à chaque --- et convertissez les documents un par un.
Est-ce que ma config quitte le navigateur ?
Non. Le parsing et la sérialisation se passent tous les deux dans votre onglet, rien n'est envoyé nulle part. Cela dit, par principe, ne collez pas de secrets de production dans une page web, celle-ci comprise, et masquez les tokens avant de partager des captures d'écran.