Convertir YAML en JSON
YAML vers JSON convertit un document YAML en JSON dans votre navigateur selon le schéma core de YAML 1.2. C’est plus important qu’il n’y paraît : sous l’ancien prédécesseur de la 1.2, encore utilisé par PyYAML et Ruby, les tokens non quotés NO, yes, on et off sont résolus comme des booléens, si bien qu’une liste de codes pays ISO perd la Norvège. Ici, ils restent des chaînes, et tout ce qui serait résolu différemment en 1.1 est signalé.
Comment fonctionne Convertir YAML en JSON ?
YAML a l’air simple et ne l’est pas. Sa spécification est plus longue que celles de JSON, XML et TOML réunies, et la plupart des surprises viennent d’une seule décision de conception : les scalaires non quotés sont résolus par motif plutôt que déclarés par la syntaxe. Ce que vaut un token dépend de la table de résolution qu’utilise le lecteur.
Le problème de la Norvège est un problème de version
YAML 1.1 résolvait y, yes, on, n, no et off comme des booléens. Du coup, countries: [NO, SE, DK] se chargeait en [false, "SE", "DK"], et un fichier de configuration qui disait norway: no signifiait quelque chose que personne n’avait voulu. YAML 1.2 les a tous supprimés, ainsi que les nombres sexagésimaux — c’est pourquoi la 1.1 lisait 12:30 comme l’entier 750.
Le hic, c’est que les logiciels que les gens font réellement tourner sont divisés. Le loader par défaut de PyYAML et le Psych de Ruby sont en 1.1 ; le yaml.v3 de Go et les parseurs JavaScript modernes sont en 1.2. Ce convertisseur applique la 1.2 et vous signale nommément chaque token pour lequel un lecteur 1.1 serait en désaccord — parce que la sortie utile, ce n’est pas seulement le JSON, c’est aussi de savoir que le fichier est ambigu.
Les ancres sont développées, avec un budget
&name définit une ancre et *name la référence. JSON n’a pas d’équivalent, donc chaque référence est développée en une copie. Ce développement, c’est l’attaque « billion laughs » : dix ancres référençant chacune deux fois la précédente se développent en 1,024 nœuds, vingt en un million, trente en plus d’un milliard. Un fichier de 200 octets peut épuiser le heap. Le développement est plafonné à 100,000 nœuds et le plafond est signalé, ce qui fait la différence entre une erreur claire et un onglet figé.
Les scalaires en bloc conservent leurs sauts de ligne
| conserve les sauts de ligne, > les replie en espaces, et l’indicateur de chomping décide du sort du dernier : | en garde exactement un, |- les supprime tous, |+ les garde tous. Cette dernière distinction compte pour une clé PEM ou un script shell dont la dernière ligne doit être terminée. Un # dans un scalaire en bloc est du contenu, pas un commentaire — un parseur qui le retire avale le shebang de chaque script.
Les clés dupliquées sont signalées, pas cachées
YAML dit qu’une clé dupliquée est une erreur. La plupart des parseurs gardent silencieusement la dernière. Celui-ci garde la dernière, comme JSON.parse, et dit de quelle clé il s’agit et à quelle ligne — parce qu’un doublon dans un fichier de config est presque toujours une fusion qui a mal tourné.
YAML
regions: [NO, SE] version: "007" retry: 012
JSON
{
"regions": ["NO", "SE"],
"version": "007",
"retry": 12
}
// warning: 012 — leading zero, 1.1 reads it as octalQuelles options et quels cas limites Convertir YAML en JSON prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| true / false | booléen | résolus | Uniquement ces deux graphies, casse indifférente. C’est toute la différence avec YAML 1.1 — et la raison pour laquelle la Norvège survit. |
| yes / no / on / off / y / n | string | signalés | Chaînes en 1.2, booléens en 1.1. Chacun est signalé par son nom, pour que vous sachiez que le fichier ne veut pas dire la même chose selon le runtime. |
| ~ / null / (vide) | null | résolus | Les trois s’écrivent null en JSON. Une valeur vide après une clé est null, pas une chaîne vide. |
| 012 | entier | 12, signalé | 1.2 lit le zéro de tête comme décimal ; 1.1 comme octal 10 ; l’auteur voulait sans doute la chaîne. Mettez-le entre guillemets pour garder le zéro. |
| 0o17 / 0x1f | entier | 15 / 31 | Octal et hexadécimal explicites. 1.2 exige le préfixe 0o pour l’octal, voilà pourquoi un 017 nu ne vaut pas 15. |
| .inf / .nan | string | gardés comme texte | JSON n’a ni l’un ni l’autre ; en émettre un produit un document que JSON.parse rejette. Le token est gardé tel quel et signalé. |
| Ancres et alias | développés | plafond de 100,000 nœuds | Chaque *alias devient une copie, car JSON n’a pas de références. Le plafond empêche une expansion billion-laughs d’épuiser la mémoire. |
| Clés de fusion (<<) | non pris en charge | signalés | Refusé plutôt qu’implémenté à moitié. La sémantique de fusion interagit avec l’écrasement et l’ordre de façons où il est facile de se tromper subtilement et difficile de s’en apercevoir. |
| Multi-documents | séparés par --- | tableau | Plusieurs documents deviennent un tableau JSON. Désactivez l’option pour ne convertir que le premier, ce que veut habituellement un lot de manifestes Kubernetes. |
| Taille d’entrée | octets | 8 MB | L’analyse tourne sur le thread principal. Au-delà du plafond, l’outil refuse plutôt que de geler l’onglet. |
Questions fréquentes
Pourquoi mon `no` est-il une chaîne et non false ?
Parce que ce parseur applique le schéma core de YAML 1.2, où seuls true et false sont des booléens. YAML 1.1 — encore ce qu’utilisent le loader par défaut de PyYAML et le Psych de Ruby — résout no, yes, on, off, y et n comme des booléens, voilà comment une liste de codes pays ISO perd la Norvège en silence. Si vous voulez un booléen, écrivez true ou false ; si vous voulez la chaîne, vous l’avez déjà.
Quelle version de YAML mes outils sont-ils censés utiliser ?
Vérifiez plutôt que de supposer, car la scission est réelle et, en pratique, non versionnée : le safe_load de PyYAML et le Psych de Ruby sont en 1.1, le gopkg.in/yaml.v3 de Go et la plupart des parseurs JavaScript actuels sont en 1.2. La réponse fiable consiste à mettre entre guillemets tout ce qui est ambigu — un scalaire quoté est une chaîne dans toutes les versions de YAML jamais publiées, ce qui rend la question sans objet.
Qu’est-il arrivé à mes ancres ?
Elles ont été développées. JSON n’a aucun moyen d’exprimer une référence, donc chaque *alias devient une copie complète de ce que l’ancre contenait. C’est sans perte pour les données et avec perte pour la structure : le fait que deux parties du document étaient le même objet disparaît. Si vous avez besoin que ce soit préservé, JSON est la mauvaise cible.
Pourquoi a-t-il refusé de développer mes alias ?
Les alias imbriqués se multiplient. Si chaque ancre référence deux fois la précédente, trente niveaux se développent en plus d’un milliard de nœuds à partir d’un fichier qui tient sur un écran — l’attaque billion-laughs, qui a fait tomber de vrais services. Le développement s’arrête à 100,000 nœuds et le dit, plutôt que de continuer à croître jusqu’à la mort de l’onglet.
Pourquoi mon nombre garde-t-il ses guillemets dans la sortie ?
Parce que vous l’avez quoté dans le YAML, et qu’un scalaire quoté est une chaîne dans toutes les versions de YAML. C’est le comportement correct, et c’est généralement l’intention : version: "007" et version: 007 sont des valeurs réellement différentes, et une seule des deux survit à un aller-retour telle qu’elle a été écrite.
Mon YAML est-il envoyé ?
Non. L’analyse et la conversion s’exécutent toutes les deux dans l’onglet que vous avez déjà ouvert — regardez le panneau Réseau pendant que vous collez. Cela compte spécifiquement pour le YAML, parce que le YAML que les gens ont besoin de convertir est généralement un manifest Kubernetes, un workflow CI ou un fichier docker-compose, c’est-à-dire un fichier plein de détails d’infrastructure et parfois de secrets.