Convertisseur JSON vers YAML

1. 1

   Coller ou téléverser du JSON

   Collez du JSON dans l'éditeur, ou déposez un fichier .json, .ndjson ou .jsonl sur la page. Rien n'est téléversé : le fichier est lu sur votre appareil.

2. 2

   Choisir l'analyseur cible

   Portable est la valeur par défaut et met entre guillemets toute valeur qu'un analyseur YAML 1.1 ou reconnaissant les horodatages lirait comme un autre type. Choisissez YAML 1.2 pour un minimum de guillemets, ou tout mettre entre guillemets si le lecteur est inconnu.

3. 3

   Régler la mise en forme

   Choisissez l'indentation, l'écriture de null et si le document commence par ---. L'aperçu se met à jour à chaque changement.

4. 4

   Convertir et vérifier le résultat

   Cliquez sur Convertir en YAML. Le résultat est relu avec un analyseur indépendant et comparé à votre JSON d'origine ; le badge indique si chaque valeur a survécu.

5. 5

   Télécharger ou copier

   Téléchargez le fichier .yaml ou copiez-le. Pour le sens inverse, utilisez l'outil YAML vers JSON.

Ce convertisseur gratuit transforme du JSON en YAML sur votre appareil. Collez ou téléversez du JSON, choisissez l'analyseur pour lequel votre YAML est écrit, et le convertisseur met entre guillemets exactement les valeurs qui changeraient sinon de type en chemin. Chaque résultat est relu avec un analyseur indépendant et comparé à votre JSON d'origine avant de vous être proposé. Un JSON invalide est localisé au caractère près, avec un curseur et une porte de sortie.

• Des guillemets pour un analyseur nommé — Choisissez YAML 1.2, portable, ou tout mettre entre guillemets. Portable est la valeur par défaut et reste sûre avec PyYAML, js-yaml, Psych de Ruby et Go.
• Vérification aller-retour — Le YAML est relu avec un analyseur indépendant et comparé valeur par valeur à votre JSON. Le badge nomme le premier chemin qui diffère, s'il y en a un.
• Chaînes multilignes lisibles — Une chaîne contenant des sauts de ligne est écrite en littéral de bloc, pour que scripts, certificats et SQL restent lisibles au lieu de s'effondrer en séquences d'échappement.
• NDJSON en entrée, YAML multi-documents en sortie — Une valeur JSON par ligne devient un document YAML par ligne d'entrée, séparés par ---. Les lignes vides sont ignorées.
• Erreurs localisées sur votre appareil — Message, ligne, colonne, un curseur sous le caractère exact et ce qui était attendu là — identiques dans tous les navigateurs plutôt que ce que rapporte l'analyseur du navigateur.
• Rien ne quitte votre appareil — Le fichier est lu, analysé, converti et vérifié localement. Il n'y a pas d'étape de téléversement, donc rien à refuser.

C'est le réglage qui décide si la conversion est correcte, et c'est la raison d'être de cet outil. YAML n'a pas de manière unique et convenue de lire un mot sans guillemets : le même fichier signifie des choses différentes pour des analyseurs différents, et un convertisseur qui met le minimum de guillemets parie sur celui que vous utiliserez.

• Portable (par défaut) — Met entre guillemets l'union de tout ce qu'un analyseur YAML 1.2 de base, un analyseur YAML 1.1 et un analyseur reconnaissant les horodatages retypent. Un peu plus de guillemets ; les mêmes valeurs partout.
• YAML 1.2 — Guillemets minimaux, conformes au schéma de base YAML 1.2. Correct si — et seulement si — ce qui lit le fichier est un analyseur 1.2 sans reconnaissance des horodatages. L'outil compte et signale malgré tout les valeurs qu'un lecteur 1.1 changerait.
• Tout mettre entre guillemets — Chaque chaîne est mise entre guillemets. Verbeux, sans ambiguïté, et la bonne réponse quand vous ignorez ce qui lira le fichier.
• Qui lit YAML 1.1 — PyYAML et donc Ansible et SaltStack, Psych de Ruby, et une longue traîne d'outils bâtis dessus. Ce n'est pas un recoin hérité : c'est une grande part du monde de l'infrastructure.

Ce ne sont pas des chaînes exotiques. Ce sont celles que l'on stocke réellement dans des fichiers de configuration, et chacune revient d'un analyseur non prévenu sous un autre type. Le mode portable les met toutes entre guillemets ; le mode YAML 1.2 ne traite que la première ligne et vous dit combien des autres il a laissées telles quelles.

• true, false, null, 12, 1.5, 0x1F — Retypés par tous les analyseurs, y compris YAML 1.2. Toujours entre guillemets, dans tous les modes.
• yes, no, on, off, y, n — Des chaînes en YAML 1.2. Des booléens en YAML 1.1 — une valeur de configuration « no » devient donc false dans Ansible.
• 0755, 0644 — Une permission de fichier, et un entier octal à zéro initial pour un analyseur YAML 1.1 : 0755 devient 493.
• 1:30, 12:30:45 — Pour vous une durée ou une heure ; pour un analyseur YAML 1.1, des entiers en base 60, qui lit 1:30 comme 90.
• 2024-01-01 — Un objet date pour tout ce qui reconnaît les horodatages, y compris le schéma par défaut de js-yaml, PyYAML et yaml.v3 de Go.
• 1_000, 0b1010 — Des chaînes à la lettre de la spécification 1.2, des entiers pour js-yaml. Mis entre guillemets quand même, car c'est le lecteur qui compte, pas la spécification.

La correspondance est directe et la structure de votre document est conservée exactement. Rien n'est réordonné, rien n'est perdu, aucune clé n'est renommée.

• Objets — Blocs clé-valeur indentés. L'ordre des clés est conservé sauf si vous demandez des clés triées.
• Tableaux — Listes à tirets. Une liste dans une table peut être indentée ou alignée sur la colonne de la clé.
• Objet vide et tableau vide — Écrits {} et [] plutôt que laissés vides, car une valeur vide serait relue comme null et changerait la forme en silence.
• null — Écrit null par défaut, ou en tilde, ou vide. La forme vide n'est utilisée que pour les valeurs de table — voir la note sur la mise en forme plus bas.
• Chaînes avec sauts de ligne — Littéraux de bloc, avec l'indicateur de troncature déduit des sauts de ligne finaux pour que la chaîne revienne exactement.
• Clés — Mises entre guillemets selon les mêmes règles que les valeurs. Une clé « n » ou « yes » est mise entre guillemets, car sans guillemets elle devient une clé booléenne pour un lecteur YAML 1.1.

Un script shell dans une ConfigMap, un certificat PEM, une requête SQL : ce sont les valeurs que l'on veut le plus garder lisibles, et celles qu'un convertisseur naïf réduit à une seule ligne d'échappements.

• Littéraux de bloc — Une chaîne multiligne est écrite après un | pour que les lignes restent des lignes. L'indicateur de troncature est déduit des sauts de ligne finaux, de sorte qu'aucun n'est gagné ni perdu.
• Quand un bloc est impossible — Une chaîne dont la première ligne est vide ou indentée, ou qui contient un retour chariot ou un caractère de contrôle, est mise entre guillemets à la place. Ces cas exigent un indicateur d'indentation explicite, et s'y tromper est une corruption silencieuse.
• Retour à la ligne des valeurs longues (Pro) — Une colonne de retour plie les valeurs longues avec un saut de ligne échappé, la seule forme de retour en YAML qui soit exactement réversible. Les scalaires simples et de bloc pliés ne le sont pas, donc une valeur à replier est d'abord mise entre guillemets.
• Aucun pliage accidentel — Sans retour à la ligne — le réglage par défaut — les chaînes longues restent sur une seule ligne, donc rien n'est reformaté en sortie.

NDJSON — aussi appelé JSON Lines — c'est une valeur JSON par ligne, et c'est ce que produisent les pipelines de journaux, les exports de bases de données et jq -c. Ce n'est pas du JSON valide en tant que fichier entier, aussi la plupart des convertisseurs le rejettent.

• Détecté de deux façons — Par une extension .ndjson ou .jsonl, et par le contenu : un fichier qui n'est pas un document JSON valide unique mais dont chaque ligne non vide s'analyse séparément.
• Un document par enregistrement — Chaque valeur devient son propre document YAML, séparé par ---, ce qui est la façon dont tout analyseur relit un flux YAML.
• Un tableau sur une ligne n'est pas du NDJSON — [1,2] est un document JSON valide et est donc converti comme tel. C'est précisément pour cela que la lecture en document unique est tentée en premier.
• Une ligne fautive arrête la conversion — Le numéro de ligne est signalé, plutôt que de produire un flux à moitié converti avec des enregistrements silencieusement perdus.

Aucune ne change le sens du document. Toutes changent sa lecture, et l'aperçu se met à jour à mesure que vous les déplacez.

• Indentation — De 1 à 8 espaces par niveau. Deux est la valeur par défaut et ce qu'attend la plupart de l'outillage YAML.
• Style de null — null, un tilde, ou vide. La forme vide n'est utilisée que pour les valeurs de table : une entrée de liste vide en fin de liste imbriquée est lue différemment selon les analyseurs, elle y est donc écrite en tilde.
• Marqueur de document — Commencer le fichier par ---. Entre documents d'un flux, il est toujours émis, quel que soit ce réglage.
• Trier les clés (Pro) — Clés alphabétiques, pour des diffs qui ne bougent pas quand un producteur réordonne sa sortie.
• Style de guillemets (Pro) — Guillemets simples ou doubles là où c'est nécessaire. Les simples se rabattent sur les doubles pour toute chaîne qu'ils ne peuvent pas représenter.
• Indentation des listes (Pro) — Indenter une liste sous sa clé, ou l'aligner sur la colonne de la clé — le style maison des manifestes Kubernetes, et quatre colonnes de moins par liste.
• Style multiligne (Pro) — Littéraux de bloc lisibles, ou une seule ligne entre guillemets doubles avec échappements.

Tous les autres convertisseurs de cette catégorie vous remettent du YAML et vous laissent découvrir plus tard s'il signifie encore ce que signifiait votre JSON. Celui-ci vérifie, avant que vous ne téléchargiez quoi que ce soit.

• Un lecteur indépendant — Le résultat est analysé par une implémentation différente de celle qui l'a écrit. Un écrivain vérifié par son propre lecteur ne prouve rien : tous deux partageraient le même malentendu.
• Comparé valeur par valeur — Contre votre JSON d'origine, non contre une copie resérialisée. Les types sont comparés aussi, de sorte qu'une chaîne revenue en date échoue.
• La première différence est nommée — Par chemin — /servers/3/started — avec les deux types et les deux valeurs, plutôt qu'un « échec de vérification » nu sur un fichier de 40 000 lignes.
• Lu selon l'analyseur choisi — La vérification utilise le schéma de votre cible : vérifié signifie donc toujours vérifié pour le lecteur pour lequel vous aviez dit écrire.
• Désactivable — Elle coûte une seconde lecture du document. Sur un gros fichier de forme connue vous ne le voudrez peut-être pas ; le réglage vous appartient, et le résultat est marqué obsolète si vous le changez.

Propulsé par des algorithmes de traitement optimisés.

YAML est le format de configuration du monde de l'infrastructure, et JSON est ce que presque tout émet. Convertir de l'un à l'autre, c'est ainsi que les données d'une API, d'une base ou d'une application se retrouvent dans un manifeste Kubernetes, un fichier Compose, un workflow GitHub Actions ou un playbook Ansible.

• Flux de configuration — Réutiliser des données de forme JSON dans Kubernetes, Docker Compose, GitHub Actions, Ansible et tout ce qui lit du YAML.
• Lisibilité — YAML abandonne accolades et guillemets : un document imbriqué est plus facile à lire et à relire dans une pull request.
• Commentaires — YAML accepte les commentaires, pas JSON — convertir est donc souvent la première étape pour transformer des données générées en quelque chose qu'un humain maintiendra.
• La justesse compte davantage ici — Un fichier de configuration s'exécute. Une chaîne de version devenue nombre, ou une permission devenue octale, n'échoue pas bruyamment : elle se déploie.
• Confidentialité — Rien n'est téléversé : une réponse d'API contenant des identifiants ou des données clients est traitée sur votre appareil, pas sur nos serveurs.

• YAML vers JSON
• Formateur JSON
• Validateur JSON
• Minificateur JSON
• JSON vers XML
• Visionneuse JSON