Pourquoi mon code pays NO est-il entre guillemets ?

Parce que `NO` nu est la chaîne `NO` pour un lecteur YAML 1.2 et le booléen **faux** pour un lecteur 1.1 — et PyYAML, qu’utilise une très large part du monde, applique la 1.1. Ici la valeur arrive en chaîne JSON : on sait ce qu’elle est, et les guillemets sont la seule écriture qui la garde telle.

Mon identifiant de 20 chiffres va-t-il survivre ?

Oui. Le nombre est lu comme le texte qu’il est : `12345678901234567890` ressort avec ses vingt chiffres. Ce n’est pas gratuit — `JSON.parse` l’aurait d’abord arrondi en `12345678901234567000`, et c’est ainsi que la plupart des convertisseurs le perdent.

Puis-je obtenir des commentaires ou des ancres en sortie ?

Non, et rien ne le pourrait. JSON n’a ni les uns ni les autres : il n’y a rien à faire traverser, et un convertisseur ne peut pas inventer un commentaire que personne n’a écrit. S’il vous faut un YAML documenté, écrivez les commentaires après la conversion et gardez le YAML comme source à partir de là.

JSON en YAML — prêt pour votre configuration

Convertissez du JSON en YAML. L’indentation est au choix, les valeurs ambiguës sont citées, et le résultat se colle dans un Compose ou une CI.

Instantané Privé Zéro cookie

Indentation

Inverser : YAML → JSON

Entrée JSON

Sortie YAML

Ce que fait cet outil

YAML est un sur-ensemble de JSON : la correspondance est directe. Les objets deviennent des dictionnaires, les tableaux des séquences, et chaque scalaire garde son type.

{ "nom": "Ada", "tags": ["math", "moteur"], "actif": true }

nom: Ada
tags:
  - math
  - moteur
actif: true

Cité là où le sens changerait

{ "pays": "NO", "drapeau": "yes", "a": "12:30" }

pays: "NO"
drapeau: "yes"
a: "12:30"

Écrits nus, ces trois-là seraient lus faux, vrai et 750 par tout analyseur YAML 1.1 — celui qu’implémente PyYAML, et PyYAML est ce avec quoi une très large part du monde lit du YAML. On appelle cela le problème norvégien, du nom du code pays qui n’arrête pas de devenir un booléen.

Ici la valeur arrive de JSON en chaîne : aucune ambiguïté sur ce qu’elle est. La citer est la seule écriture qui la garde chaîne pour tous les lecteurs. Les vrais booléens restent nus : true reste true.

Les longs identifiants gardent leurs chiffres

{ "id": 12345678901234567890 }

ressort avec ses vingt chiffres. La plupart des convertisseurs analysent d’abord le JSON en valeur JavaScript, ce qui fait passer chaque nombre par un flottant double précision et arrondit au-delà d’une quinzaine de chiffres — en silence. Le nombre est lu ici comme le texte qu’il est.

Les chaînes multilignes deviennent des scalaires de bloc

Une chaîne contenant des sauts de ligne s’écrit sous la forme de bloc, lisible, plutôt qu’avec des \n :

description: |-
  première ligne
  seconde ligne

Ce qui ne peut pas traverser

Les commentaires et les ancres. JSON n’a ni les uns ni les autres : il n’y a rien à porter. Un convertisseur qui proposerait de les ajouter inventerait la documentation de votre fichier, et c’est un travail de personne, pas d’outil.

Confidentiel par conception

Tout s’exécute localement dans votre navigateur en JavaScript. Vos données ne sont jamais envoyées sur un serveur, ce qui rend l’outil sûr pour des contenus sensibles, et il fonctionne hors ligne.

Questions fréquentes

Pourquoi mon code pays NO est-il entre guillemets ?: Parce que `NO` nu est la chaîne `NO` pour un lecteur YAML 1.2 et le booléen **faux** pour un lecteur 1.1 — et PyYAML, qu’utilise une très large part du monde, applique la 1.1. Ici la valeur arrive en chaîne JSON : on sait ce qu’elle est, et les guillemets sont la seule écriture qui la garde telle.
Mon identifiant de 20 chiffres va-t-il survivre ?: Oui. Le nombre est lu comme le texte qu’il est : `12345678901234567890` ressort avec ses vingt chiffres. Ce n’est pas gratuit — `JSON.parse` l’aurait d’abord arrondi en `12345678901234567000`, et c’est ainsi que la plupart des convertisseurs le perdent.
Puis-je obtenir des commentaires ou des ancres en sortie ?: Non, et rien ne le pourrait. JSON n’a ni les uns ni les autres : il n’y a rien à faire traverser, et un convertisseur ne peut pas inventer un commentaire que personne n’a écrit. S’il vous faut un YAML documenté, écrivez les commentaires après la conversion et gardez le YAML comme source à partir de là.