JSON à YAML : rendre à nouveau lisible la sortie machine

Pourquoi convertir JSON en YAML

Les deux formats contiennent des données identiques, mais ils sont optimisés pour des lecteurs différents. JSON dépense des caractères en accolades, virgules et guillemets ; YAML les dépense sur une structure que l'œil peut suivre comme une indentation. Pour les données générées et consommées par les programmes, JSON l'emporte. Pour les données qu'une personne modifie — Helm valeurs, définitions CI, inventaires Ansible, Docker Composer des fichiers — YAML gagne, c'est pourquoi cette direction apparaît chaque fois que les données générées ont besoin d'un propriétaire humain.

Les commentaires sont la seule chose qui ne peut pas survivre

La conversion peut restaurer la lisibilité mais elle ne peut pas restaurer l'intention : la source JSON n'avait aucun commentaire à reporter. Si votre YAML généré sera géré par des personnes, ajoutez un court commentaire d'en-tête décrivant d'où il vient et ce qui le régénère, afin que personne ne modifie un fichier qui sera écrasé lors du prochain déploiement.

Citant : où le YAML converti se brise tranquillement

YAML traite plusieurs mots comme des valeurs plutôt que comme des chaînes. Un convertisseur qui supprime les guillemets de manière agressive peut changer de type sans changer un seul caractère visible :

                country: NO        # parses as boolean false in YAML 1.1
version: 1.10      # parses as the number 1.1
time: 22:30        # parses as a sexagesimal integer
name: "on"         # quoted on purpose — must stay a string
              

Un bon résultat cite toute chaîne qui pourrait être mal lue — `yes`/`no`/`on`/`off`, des identifiants d'apparence numérique, des valeurs avec des zéros non significatifs, des heures et des dates — plutôt que de tout citer, ce qui produit le mur de ponctuation auquel vous essayiez d'échapper.

Indentation et chaînes multilignes

Deux espaces constituent la valeur par défaut sûre : c'est ce que supposent la documentation Kubernetes, les modèles Helm et la plupart des éditeurs, et ils survivent au copier-coller entre les outils. L'imbrication profonde dans un style à quatre espaces devient difficile à parcourir au-delà d'environ six niveaux. Les chaînes longues sont l'autre décision de formatage : une valeur JSON avec des nouvelles lignes intégrées peut apparaître comme une ligne d'échappement avec échappement ou comme un bloc scalaire YAML qui se lit naturellement. Si le champ est un script shell ou un extrait de configuration, demandez le formulaire de blocage.

Le tri des clés donne du sens aux différences

L'ordre des clés d'objet JSON n'est pas significatif, les convertisseurs sont donc libres de réorganiser. Le tri des clés par ordre alphabétique permet de différencier proprement les fichiers régénérés : sans cela, un ordre de déploiement modifié apparaît comme une réécriture de l'ensemble du fichier. Si vous suivez les YAML générés dans git, le tri est la différence entre une différence sur une ligne et une différence sur deux cents lignes.

Gardez l'aller-retour au même endroit

Étant donné que les deux directions sont inverses, il vaut la peine d'avoir les deux dans le même outil afin que vous puissiez convertir, modifier et reconvertir sans changer de contexte ni coller votre configuration dans trois services différents. Le convertisseur basé sur un navigateur sur ce site s'associe à l'outil YAML vers JSON, fonctionne hors ligne et ne télécharge jamais la charge utile – ce qui est important lorsque le JSON en question est une réponse API de production.