Convertisseur JSON ↔ YAML · Encoding
Convertissez JSON ↔ YAML — et voyez exactement ce qui change.
Tous les convertisseurs transforment du YAML en JSON. Celui-ci vous dit en plus ce que ça a coûté : les commentaires qu'il a supprimés, les ancres qu'il a développées, la date qu'il a réécrite, l'entier qu'il a arrondi. Vrai parseur YAML 1.2, entièrement dans votre navigateur.
S’exécute dans votre navigateur — rien de ce que vous collez ne quitte cette page. Comment nous le prouvons
Playground du convertisseur JSON ↔ YAML
Every JSON file is already valid YAML — YAML 1.2 is a superset of JSON. The reverse is not true, which is why the direction is yours to pick.
Off by default: the order you wrote is kept, except for integer-like keys.
Results update as you type — press Enter to run now.
Press Esc to release keyboard focus from the editor; ⌘/Ctrl + Enter converts and leaves the editor. Nothing you paste is uploaded.
An anchor (&name) marks a value so an alias (*name) can reuse it. JSON has neither, so every alias is written out as a full copy.
Paste JSON or YAML above — or tap an example — to see the converted document here, plus every comment, anchor, timestamp and out-of-range number the conversion costs you.
Le manque
Des convertisseurs muets, et des réponses qui dépendent du parseur.
La douzaine de convertisseurs financés par la publicité qui occupent le haut des résultats de recherche font tous la même chose : ils affichent l'autre format et ne disent rien. Vos commentaires ont disparu. Vos ancres ont été développées en copies. Cette date non quotée est désormais une chaîne avec un fuseau horaire que vous n'avez jamais écrit. L'identifiant à 19 chiffres a perdu ses deux derniers. Rien sur la page n'en dit un mot : la première fois que vous l'apprenez, c'est en revue. Ou en production.
Demandez plutôt à un assistant IA et vous héritez d'un second problème : la réponse dépend de la version de YAML que le modèle a apprise. verify: no est la chaîne "no" en YAML 1.2 et le booléen false en YAML 1.1, et les deux réponses sont affirmées avec la même assurance. 0777 vaut 777 dans l'une et 511 dans l'autre — ce qui, pour un mode de fichier, fait la différence entre un déploiement cassé et un déploiement qui marche.
Cet outil répond avec des faits vérifiables plutôt qu'avec une supposition : un vrai parseur YAML 1.2 tourne dans votre onglet, la sortie est déterministe, et chaque étape avec perte est nommée avec la ligne ou le chemin concerné. Le tableau de référence ci-dessous fixe les valeurs sur lesquelles les deux versions de YAML divergent, pour que vous puissiez vérifier une affirmation en quelques secondes.
Vous travaillez sur un pipeline ? Le validateur GitHub Actions et le validateur GitLab CI analysent le YAML lui-même.
Le pipeline
Comment ça marche.
Quatre étapes déterministes s'exécutent pendant que vous tapez — toutes dans votre onglet, et chaque étape avec perte se signale elle-même.
-
Analyser avec un vrai parseur.
js-yaml 4 sur le schéma core de YAML 1.2, ou JSON.parse — jamais une expression régulière. Si ça n'analyse pas, vous obtenez la ligne et la colonne, pas « invalide ».
-
Normaliser, et le consigner.
Un seul parcours convertit les horodatages en chaînes ISO-8601, !!binary en base64 et ±Infinity/NaN en null, chaque conversion émettant un diagnostic avec le chemin où elle a eu lieu.
-
Émettre de façon déterministe.
Pas de repliement de lignes ni d'ancres générées : la même entrée produit toujours les mêmes octets, et la sortie se relit exactement telle qu'elle apparaît.
-
Signaler chaque perte.
Commentaires, ancres, clés de fusion, documents supplémentaires, clés numériques réordonnées et entiers arrondis sont listés à côté de la sortie : c'est vous qui décidez si la conversion était acceptable.
Par l'exemple
Quatre pertes en six lignes.
Un commentaire, une ancre, une clé de fusion et une date non quotée : le YAML de tous les jours qu'aucun convertisseur ne peut faire passer intact.
Entrée
Du YAML ordinaire : un commentaire, une ancre, une clé de fusion, une date nue.
# valeurs par défaut du déploiement, partagées par les deux jobs
defaults: &defaults
retries: 2
verify: no # une chaîne en YAML 1.2, false en YAML 1.1
release:
<<: *defaults
date: 2024-01-15Sortie, avec le reçu
Quatre pertes signalées : le commentaire a disparu, *defaults a été copié, <<: a été aplati, et la date est devenue une chaîne ISO-8601. no est resté une chaîne — et il est signalé, parce que PyYAML le lirait comme false.
{
"defaults": { "retries": 2, "verify": "no" },
"release": {
"retries": 2,
"verify": "no",
"date": "2024-01-15T00:00:00.000Z"
}
}Référence
Là où YAML 1.2 et YAML 1.1 divergent.
Le même scalaire non quoté, lu par cet outil (js-yaml 4, schéma core de YAML 1.2) et par un parseur YAML 1.1 comme PyYAML. Quand un outil et un collègue ne s'accordent pas sur une valeur, la réponse est presque toujours dans ce tableau.
| Entrée non quotée | YAML 1.2 — cet outil | YAML 1.1 — PyYAML |
|---|---|---|
| no | "no" (chaîne) | false (booléen) Le problème norvégien. Idem pour yes / on / off / y / n. |
| true | true (booléen) | true (booléen) Les deux versions ne s'accordent que sur true et false. |
| ~ | null | null null, Null, NULL, ~ et une valeur vide valent null dans les deux. |
| 2024-01-15 | 2024-01-15T00:00:00.000Z | 2024-01-15T00:00:00.000Z Les deux résolvent une date non quotée en horodatage ; JSON n'a pas de type date, elle est donc écrite comme chaîne ISO-8601. |
| 0777 | 777 (décimal) | 511 (octal) La divergence la plus dangereuse de toutes : les modes de fichier changent de sens en silence. Écrivez 0o777. |
| 0o777 | 511 | "0o777" (chaîne) YAML 1.1 ne comprend pas du tout la forme octale explicite de YAML 1.2. |
| 1:30 | "1:30" (chaîne) | 90 (sexagésimal) YAML 1.1 lisait les nombres séparés par deux-points en base 60. YAML 1.2 l'a supprimé. |
| .inf | Infinity | Infinity JSON n'a pas d'infini : la valeur devient null, avec un avertissement. |
| 9007199254740993 | 9007199254740992 | 9007199254740993 Ce n'est pas une divergence YAML mais JavaScript : au-delà de 2^53 − 1, la valeur exacte est perdue. |
Quoter supprime toutes les divergences de ce tableau. Quand un scalaire doit rester une chaîne dans les deux mondes, quotez-le — et quand cet outil émet du YAML, il les quote pour vous.
Étape suivante
Vérifiez maintenant que le YAML lui-même est valide.
Convertir prouve qu'un document s'analyse ; cela ne prouve pas que le pipeline l'acceptera. Passez le YAML de votre workflow dans le validateur GitHub Actions ou le validateur GitLab CI pour repérer les problèmes de schéma et de sécurité qu'un convertisseur ne peut pas voir.
YAML → JSON · 2 docs · 31 keys · 1 warning · 3 notes
note: comments were dropped
note: 1 alias expanded into a copy
note: "no" stayed a string (YAML 1.1 reads false)
warning: 9007199254740993 → 9007199254740992FAQ
Vos questions, nos réponses.
Appuyez sur une question pour afficher la réponse.
Que fait le convertisseur JSON ↔ YAML ?
Il convertit du JSON en YAML ou du YAML en JSON dans votre navigateur, puis vous dit ce que la conversion a coûté. Les commentaires, les ancres et les alias, les clés de fusion, les horodatages, les flux multi-documents et les entiers trop grands pour être représentés exactement par JavaScript ne survivent pas au voyage : chacun d'eux est signalé comme un avertissement ou une note nommée à côté de la sortie, au lieu de disparaître discrètement.
Quelle version de YAML est utilisée ?
YAML 1.2, via js-yaml 4 et son schéma par défaut (core) — le même lecteur qu'utilise la plupart des outils JavaScript modernes. C'est important parce que YAML 1.2 a supprimé les orthographes booléennes de YAML 1.1 : ici no, yes, on et off sont de simples chaînes, et seuls true et false sont des booléens. PyYAML, Psych de Ruby et les anciens outils Kubernetes suivent encore YAML 1.1 : le tableau de référence de cette page fixe donc les valeurs sur lesquelles les deux versions divergent.
Qu'est-ce que le « problème norvégien » ?
Un parseur YAML 1.1 lit le scalaire non quoté NO comme le booléen false : une liste de pays contenant le code ISO de la Norvège devient donc une liste contenant false. Le même piège attrape ON, OFF, YES, Y et N. Ce convertisseur suit YAML 1.2, donc ces valeurs restent des chaînes — et chaque occurrence rencontrée est signalée, pour que vous sachiez qu'un outil YAML 1.1 plus loin dans la chaîne serait d'un autre avis. Dans l'autre sens, elles sont quotées en sortie (« NO » devient 'NO'), et c'est précisément ce qui rend le fichier sûr pour PyYAML.
Mon document quitte-t-il un jour mon navigateur ?
Non. L'analyse, la conversion et le rapport s'exécutent à 100 % côté client, dans votre onglet : pas de serveur, pas de compte, pas de journalisation. Vous pouvez coller sans risque des manifestes de production, des configurations CI et des fichiers contenant des noms d'hôtes internes ou des secrets.
Que deviennent les commentaires YAML ?
Ils sont perdus, et l'outil le dit. JSON n'a pas de syntaxe de commentaire, et les conserver lors d'un aller-retour exigerait un arbre syntaxique conscient des commentaires plutôt qu'un parseur de valeurs : c'est un non-objectif assumé ici. Si les commentaires doivent survivre, modifiez le YAML directement plutôt que de le faire passer par JSON.
Comment les ancres et les alias YAML sont-ils convertis ?
Ils sont développés sur place. Une ancre (&defaults) marque une valeur ; un alias (*defaults) la réutilise. JSON n'a ni l'un ni l'autre, donc chaque alias devient une copie complète de la valeur ancrée : le document a le même sens, mais il est plus long et le partage a disparu. Les clés de fusion (<<:) sont développées de la même façon, les clés héritées étant écrites en entier. Un alias récursif, où un nœud se contient lui-même, ne peut pas être représenté en JSON du tout : il est signalé comme une erreur au lieu de faire planter la page.
Pourquoi mon grand nombre a-t-il changé ?
JavaScript stocke les nombres en doubles IEEE-754, donc les entiers au-delà de 2^53 − 1 (9007199254740991) ne peuvent pas être représentés exactement. 9007199254740993 devient 9007199254740992 dès qu'il est analysé — par cet outil, par JSON.parse dans votre propre code et par n'importe quel autre convertisseur de navigateur. La différence, c'est que celui-ci vous avertit et cite les chiffres d'origine. Si la valeur est un identifiant et non une quantité, conservez-la sous forme de chaîne quotée.
Comment convertir un manifeste YAML Kubernetes en JSON pour kubectl patch ?
Collez le manifeste, laissez le sens sur YAML → JSON et copiez la sortie. kubectl patch --type=merge -p attend un document JSON, et un manifeste multi-documents (plusieurs ressources séparées par ---) devient ici un tableau JSON, que kubectl n'accepte pas comme patch : séparez-le et convertissez une ressource à la fois. Les quantités comme 256Mi et 500m restent des chaînes dans les deux formats, ce qui est exactement ce qu'attend Kubernetes.
Puis-je convertir un modèle CloudFormation ?
Pas tant qu'il utilise les balises abrégées. !Ref, !GetAtt et !Sub sont des balises YAML propres à CloudFormation, absentes du schéma standard : un parseur conforme les rejette, et cet outil indique exactement sur quelle balise il a buté et où. Réécrivez-les dans leur forme longue (Ref: BucketName au lieu de !Ref BucketName) et le modèle se convertit.
L'ordre de la sortie correspond-il à celui de mon entrée ?
Oui, avec une exception incontournable. L'ordre des clés est préservé par défaut, et « Sort keys » trie chaque niveau quand vous voulez un diff stable. L'exception, ce sont les clés de forme entière : les objets JavaScript énumèrent toujours des clés comme « 1 » et « 2 » en premier, dans l'ordre numérique croissant, avant toute autre clé — quel que soit l'ordre dans lequel elles ont été écrites, et qu'elles aient été quotées ou non. L'outil vous avertit lorsque votre document en contient.
More free, private DevOps tools.
Le convertisseur JSON ↔ YAML est l'un des outils d'OpsCanopy — une canopée grandissante de validateurs, convertisseurs et testeurs de navigateur qui ne touchent jamais un serveur.
Plus dans Encodage
39 outils gratuits, tous utilisables hors ligne — opscanopy.com fonctionne sans inscription et sans rien téléverser.
À voir aussi : le validateur GitHub Actions et le validateur GitLab CI pour analyser le YAML de pipeline, le convertisseur Docker Run vers Compose pour transformer une commande en YAML, le testeur de routes Alertmanager pour parcourir un arbre de routage, et l' encodeur / décodeur Base64 quand la charge utile est encodée plutôt que structurée — ou parcourez le répertoire des outils complet.
Fourni en l'état, par commodité ; vérifiez toujours une configuration critique auprès de l'outil qui la consommera. OpsCanopy est gratuit et ouvert.