Convertisseur YAML-JSON

À propos du convertisseur YAML-JSON

YAML-JSON Converter est un outil gratuit pour transformer vos fichiers YAML (YAML Ain't Markup Language) en JSON (JavaScript Object Notation) et inversement. Téléversez vos fichiers ou collez vos données, ajustez les options puis téléchargez le résultat, sans quitter votre navigateur.

Dois-je utiliser JSON ou YAML pour mon projet ?

Utilisez JSON pour la communication machine-à-machine et YAML pour la configuration éditée par des humains. JSON est strict, rapide à parser et n'a qu'une seule orthographe valide pour tout document, ce qui le rend idéal pour les API, fichiers de logs et états sérialisés. YAML est un sur-ensemble strict de JSON 1.2 (selon la spécification YAML 1.2) qui ajoute commentaires, chaînes multi-lignes sans échappement, ancres et alias pour éviter la répétition, et une syntaxe à indentation bien plus concise — tout cela parfait pour les manifestes Kubernetes, workflows GitHub Actions et playbooks Ansible où un humain est l'auteur principal. Évitez YAML quand la sécurité importe avec une entrée non fiable (les attaques historiques « Billion Laughs » et d'exécution par tag y vivent) et évitez JSON quand vous voulez des commentaires. Le type de média officiel YAML enregistré dans la RFC 9512 est application/yaml ; JSON utilise application/json de la RFC 8259.

Pourquoi ma valeur YAML « 1.23 » devient-elle un nombre alors que je veux une chaîne ?

C'est le piège YAML le plus notoire et il mord chaque opérateur Kubernetes au moins une fois. YAML 1.1 auto-détecte les types scalaires depuis leur syntaxe : 1.23 est un float, 42 est un int, true / yes / on sont des booléens, null et ~ sont des nuls. Ainsi un champ version: 1.10 perd silencieusement le zéro final et devient 1.1 ; un champ country avec NO devient le booléen false ; et un numéro de série 0123 devient l'entier octal 83. Pour forcer une chaîne, soit citez la valeur (version: "1.10") soit utilisez le tag de type explicite (version: !!str 1.10). YAML 1.2 réduit l'ensemble booléen implicite à seulement true et false, mais la plupart des parsers du monde réel (PyYAML, JS yaml sans options, Kubernetes) utilisent encore par défaut le comportement 1.1. Citez toujours les valeurs chaînes qui pourraient ressembler à des nombres, booléens ou null.

Comment fonctionnent les ancres et alias en YAML — et JSON a-t-il un équivalent ?

Les ancres YAML (&nom) capturent un nœud et les alias (*nom) le réutilisent, vous permettant d'écrire une valeur une fois et de la référencer ailleurs dans le même document. La clé de fusion << permet aussi de mixer un mapping. JSON n'a pas d'équivalent — chaque valeur doit être écrite en entier — donc quand ce convertisseur va de YAML à JSON il doit matérialiser (étendre) chaque alias en une copie séparée des données, ce qui peut faire exploser la taille de documents qui s'appuient beaucoup sur l'aliasing. Dans l'autre sens, de JSON à YAML, ce convertisseur réintroduit optionnellement des ancres pour les nœuds qui apparaissent à l'identique plusieurs fois si vous activez l'option « compacter les sous-arbres identiques ». Les ancres sont aussi le vecteur de la fameuse attaque YAML « Billion Laughs », donc la plupart des bibliothèques YAML modernes limitent la profondeur d'alias et la taille d'expansion par défaut.

Quelle est la différence entre YAML 1.1, YAML 1.2 et YAML 1.2.2 ?

YAML 1.1 (2005) est la version que la plupart des parsers legacy implémentent encore par défaut — y compris PyYAML, snakeyaml et la stdlib Ruby. Elle autorise les booléens yes/no/on/off/true/false dans toute casse, accepte les nombres octaux via le zéro initial (0123 = 83) et parse la notation scientifique agressivement. YAML 1.2 (2009) a réaligné la spec pour être un sur-ensemble strict de JSON, a réduit les booléens à seulement true/false, a supprimé la règle octal par zéro initial (utilisez 0o123 comme JSON5) et a resserré beaucoup de cas limites. YAML 1.2.2 (2021) est une révision clarifiante de 1.2 sans changement cassant — la plupart des bibliothèques YAML JavaScript sont conformes à 1.2.2. Ce convertisseur cible YAML 1.2 par défaut. Si vous maintenez des playbooks Ansible, manifestes Kubernetes ou tout ce qui est généré par un outil Python, attendez-vous à des bizarreries 1.1 et citez les scalaires ambigus défensivement.

Puis-je inclure des commentaires en convertissant YAML vers JSON ?

Strictement non. La RFC 8259 interdit les commentaires en JSON, et tout parser JSON qui se respecte les rejettera comme erreur de syntaxe. Les commentaires YAML (# n'importe quoi) sont supprimés pendant la conversion et disparaissent entièrement du JSON de sortie. Si préserver les commentaires est critique — par exemple, vous générez du JSON depuis une config YAML éditée à la main et voulez que le JSON reste révisable — écrivez les commentaires dans un fichier séparé, ou changez le format de sortie en JSON5 (qui autorise les commentaires // et /* */) ou JSONC (JSON avec commentaires, largement utilisé par les fichiers de configuration VS Code). Dans l'autre sens (JSON vers YAML), ce convertisseur n'a aucun commentaire à ajouter car la source n'en contient aucun, mais vous pouvez coller le YAML résultant dans votre éditeur et ajouter librement des commentaires de documentation.

Comment fonctionnent les chaînes multi-lignes et quel style YAML choisir ?

YAML propose deux styles de scalaire de bloc pour le texte multi-ligne. Le bloc littéral | préserve chaque saut de ligne exactement — choisissez-le pour les fragments de code, l'art ASCII ou tout ce où les sauts de ligne sont sémantiques. Le bloc plié > effondre chaque saut de ligne simple en espace (traitant les lignes successives comme un paragraphe) mais préserve les séparateurs de lignes vides — choisissez-le pour la prose. Les deux styles supportent des indicateurs de chomping : |+ garde tous les sauts de ligne finaux, |- supprime tous les sauts de ligne finaux et | (sans indicateur) garde exactement un saut de ligne final. JSON n'a pas de syntaxe multi-ligne — chaque saut de ligne dans une valeur doit être encodé en \n — donc ce convertisseur étend un bloc littéral YAML de trois lignes en une seule chaîne JSON avec deux caractères \n. Faites attention à l'indentation : l'indentation du contenu de bloc est retirée de chaque ligne, donc des lignes mal alignées produisent une sortie en dents de scie.

Comment convertir en streaming un fichier YAML multi-document ou un énorme JSON ?

Un fichier YAML peut contenir plusieurs documents séparés par des marqueurs --- (souvent utilisés dans les manifestes Kubernetes regroupant plusieurs ressources). Ce convertisseur les charge tous et produit un tableau JSON de documents en sortie ; l'inverse convertit un tableau JSON en flux YAML multi-document. Pour les fichiers plus gros que ce que le navigateur peut tenir confortablement (au-delà de ~50 Mo), utilisez les outils en ligne de commande : yq (jq pour YAML) gère les deux directions avec yq -o=json input.yaml > out.json et yq -P input.json > out.yaml, tandis que les gros documents JSON streament via jq, ijson (Python) ou JSONStream (Node). Le type de média officiel YAML selon la RFC 9512 est application/yaml et la syntaxe multi-document fait partie de la spécification YAML 1.2, donc la plupart des parsers modernes gèrent la forme streaming nativement sans aucun flag spécial.

Le style flow de YAML ({key: value, list: [1, 2]}) et le style block sont-ils équivalents ?

Oui, sémantiquement identiques, mais stylistiquement très différents. Le style flow utilise des accolades et crochets à la JSON et tient sur une ligne — pratique pour les objets courts dans des documents plus grands. Le style block n'utilise que l'indentation et est la forme YAML canonique pour tout ce qui est multi-ligne. La plupart des outils (Helm, Kustomize, Ansible, GitHub Actions) préfèrent le style block pour la lisibilité et pour garder des diffs minimaux. Ce convertisseur vous laisse choisir : en sortie JSON-vers-YAML, choisissez « préférer block » (le défaut) ou « préférer flow » ou « flow uniquement pour les primitifs ». Un piège subtil : en style flow, les chaînes contenant virgules, deux-points, crochets ou accolades doivent être citées car ces caractères sont structurels ; le style block est plus indulgent. En cas de doute, passez le YAML par yamllint pour attraper les scalaires ambigus non cités avant qu'ils ne vous mordent en production.