Convertisseur YAML vers JSON

1. 1

   Collez ou déposez votre YAML

   Collez dans l'éditeur, faites glisser un fichier .yaml ou .yml sur la zone de dépôt, ou ouvrez l'un des trois exemples. La conversion se fait à la frappe : aucun bouton à presser pour voir le résultat.

2. 2

   Choisissez la forme de sortie

   2 espaces, 4 espaces, tabulations ou minifié. Si le fichier contient plusieurs documents séparés par ---, décidez s'ils deviennent un tableau JSON, le premier document seul, ou un fichier chacun. Activez Trier les clés lorsque la sortie sera comparée.

3. 3

   Vérifiez ce que la conversion a changé

   Le panneau sous le résultat nomme tout ce que JSON ne peut pas reprendre tel quel : les valeurs comme .nan et .inf, les données binaires écrites en base64, et les balises comme !Ref résolues vers la valeur en dessous. Rien ne change en silence.

4. 4

   Convertissez, puis téléchargez ou copiez

   Appuyez sur Convertir pour produire les fichiers, puis téléchargez le .json, copiez-le dans le presse-papiers, ou récupérez tout un lot en une seule archive ZIP. Si le YAML ne se lit pas, l'erreur indique la ligne, la colonne et le texte alentour.

Collez du YAML, déposez un fichier .yaml ou .yml, ou chargez un exemple : le JSON apparaît à la frappe. Les manifestes multi-documents, les clés de fusion, les ancres et les balises inhabituelles sont traités plutôt que refusés, et tout ce que la conversion a dû changer est compté sous le résultat au lieu de se produire discrètement. Choisissez 2 espaces, 4 espaces, tabulations ou minifié, triez les clés lorsque le fichier sera comparé, puis téléchargez le .json ou copiez-le.

• YAML 1.2 core — Mappages, séquences, styles bloc et flux, scalaires multilignes, ancres, alias et clés de fusion. Les règles scalaires sont celles du schéma core 1.2, donc yes et no restent des chaînes.
• Multi-documents — Un manifeste séparé par --- devient un tableau JSON, son premier document, ou un fichier par document. La version précédente de cet outil refusait ces fichiers.
• Quatre formes de sortie — 2 espaces, 4 espaces, vraies tabulations, ou minifié sur une ligne. Trier les clés met chaque objet dans un ordre stable pour que deux conversions des mêmes données se comparent proprement.
• Des erreurs situées — Le message, la ligne, la colonne, et trois lignes de votre propre source avec un curseur sous le défaut — pas un numéro extrait d'une phrase.
• Rien ne change en silence — Les nombres non finis, les données binaires et les balises résolues sont comptés et nommés sous le résultat, car chacun est une valeur que JSON ne peut pas reprendre telle quelle.
• Lot et ZIP — Mettez jusqu'à 50 fichiers en file avec Pro, récupérez-les en une archive, ou repliez tous les documents de tous les fichiers dans un unique tableau JSON.

Un fichier YAML peut contenir plusieurs documents, séparés par trois tirets sur leur propre ligne. C'est la forme normale d'un manifeste Kubernetes — un Namespace, un Deployment et un Service dans un seul fichier — et c'est aussi ainsi que kubectl, kustomize et helm template écrivent leur sortie. JSON n'a pas de séparateur équivalent : un convertisseur doit donc trancher, et refuser le fichier est la décision que prennent la plupart d'entre eux.

• Automatique — Un document devient un objet ; plusieurs deviennent un tableau d'objets. C'est ce que l'on attend, et c'est le réglage par défaut.
• Toujours un tableau — Toujours un tableau, même pour un document unique. À utiliser quand le consommateur du JSON itère sans vérifier et qu'un objet isolé le casserait.
• Premier document seulement — Prend le document de tête et abandonne le reste. Utile quand un manifeste a été concaténé à un fichier dont vous n'avez besoin que du début.
• Fichiers séparés — Un .json par document, numéroté avec des zéros de tête pour qu'un listage de dossier suive l'ordre d'origine. Aucun des concurrents cités sur cette page ne le propose.
• Les documents vides comptent — Une suite de --- sans rien entre les marqueurs est une suite de documents null : ils sont conservés plutôt qu'abandonnés, car leurs positions portent du sens dans un correctif.

YAML permet de nommer un nœud avec &ancre et d'y renvoyer plus loin avec *alias, et permet à un mappage d'en absorber un autre avec la clé de fusion <<. Ensemble, ce sont les moyens par lesquels les fichiers docker-compose, les pipelines GitLab CI et les valeurs Helm évitent de se répéter. JSON n'a rien de tout cela : chaque référence doit donc être développée sur place, et la manière dont un convertisseur traite la clé de fusion fait la différence entre un résultat juste et un résultat plausible mais faux.

• Les alias sont développés — Chaque nœud référencé est réécrit là où il est utilisé. Deux alias vers la même ancre produisent deux sous-arbres identiques, car JSON ne peut pas exprimer qu'il s'agissait du même nœud.
• Les clés de fusion sont résolues — Un service écrit <<: *common ressort avec les clés partagées fusionnées. Un analyseur qui suit YAML 1.2 à la lettre laisse à la place une clé littérale "<<" contenant un objet imbriqué : du JSON valide, de mauvaises données, et aucune erreur.
• Les clés suivantes l'emportent — Les clés écrites directement sur le mappage remplacent celles qu'il a fusionnées, comportement sur lequel docker-compose et GitLab CI s'appuient.
• Le développement est borné — Les ancres peuvent être imbriquées de sorte qu'un fichier minuscule se développe en gigaoctets. Le développement possible est mesuré avant toute analyse, et un fichier susceptible de dépasser le budget est refusé en quelques millisecondes plutôt que de figer la page.

Les règles scalaires sont celles du schéma core de YAML 1.2, et elles diffèrent de YAML 1.1 précisément là où se joue le fait qu'une valeur arrive comme chaîne ou comme nombre. Se tromper ici n'est pas une question de mise en forme : cela change les données.

• Les booléens sont true et false, rien d'autre — yes, no, on, off, y et n restent des chaînes. Sous YAML 1.1 ils deviendraient des booléens, ce qui explique combien de pipelines l'indicatif NO de la Norvège a cassés.
• Les nombres sont décimaux, octaux et hexadécimaux — 42, 0o14 et 0x1F sont des nombres. 1_000 est une chaîne, car les séparateurs par tiret bas relèvent de 1.1 ; 0b1010 aussi, pour la même raison.
• Les horodatages restent tels quels — 2001-12-14 est la chaîne que vous avez tapée, pas une date décalée dans le fuseau de votre machine. Passez le réglage sur ISO 8601 pour les normaliser ; le décompte de ce qui a changé apparaît sous le résultat.
• Les scalaires de bloc gardent leurs sauts de ligne — Un bloc | conserve chaque retour à la ligne ; un bloc > les replie en espaces. Les deux arrivent comme des chaînes JSON ordinaires avec les espaces décrits par le YAML.
• Les balises se résolvent vers la valeur portée — !Ref, !GetAtt, !Sub et toute autre balise inhabituelle vous donnent le scalaire, la séquence ou le mappage auquel elles étaient attachées, et les noms de balises sont listés sous le résultat.

Une partie du YAML n'a aucun équivalent JSON. Tout convertisseur doit en faire quelque chose, et presque tous le font sans vous le dire. Ici la règle est que rien ne change en silence : chacun de ces cas est compté, nommé, et là où il existe un vrai choix, il est le vôtre.

• .nan, .inf et -.inf — JSON n'a de littéral pour aucun des trois. Par défaut null est écrit et le nombre de conversions est compté ; ils peuvent aussi être écrits sous forme de chaînes, ou la conversion peut s'arrêter pour que vous décidiez dans la source.
• Données binaires — Un nœud !!binary devient une chaîne base64 — le même texte que dans le YAML, donc rien n'est perdu, mais c'est désormais une chaîne et non des octets.
• Clés composées — Un mappage ou une séquence utilisé comme clé n'a pas d'équivalent JSON : il est rendu sous forme de texte. La clé est préservée au lieu d'être transformée en quelque chose comme [object Object], ce que produit une conversion naïve.
• Alias circulaires — Une ancre qui se référence elle-même est du YAML légal et du JSON impossible. C'est signalé comme alias circulaire avec le chemin du nœud, plutôt que d'échouer au fond d'un sérialiseur.
• Commentaires — Les commentaires YAML ne sont pas des données et aucun document JSON ne peut les porter. Ils sont abandonnés, comme chez tous les convertisseurs — bon à savoir si ces commentaires portaient la documentation d'une configuration.

Les défaillances dont il faut se prémunir ne sont pas celles qui produisent une erreur. Ce sont celles qui produisent un document net, plausible et faux. Une clé en double en est l'exemple le plus clair : YAML vous permet de l'écrire, JSON ne peut pas conserver les deux valeurs, et l'une d'elles disparaît donc à la conversion.

• Refuser, par défaut — La conversion s'arrête et nomme la ligne et la colonne de la deuxième clé. C'est le réglage sûr, car l'alternative est un fichier qui a l'air converti et auquel il manque une valeur.
• Ou garder la dernière — Changez le réglage et la conversion aboutit avec « la dernière l'emporte », ce que fait la plupart de l'outillage YAML. La différence, c'est que vous l'avez choisi.
• Le revers, c'est la tabulation — YAML interdit les tabulations pour l'indentation. Un fichier parfaitement aligné dans un éditeur réglé sur deux espaces par tabulation ne s'analysera pas, et l'erreur nomme la ligne.
• Triez les clés avant de comparer — Deux exports des mêmes données peuvent ne différer que par l'ordre des clés. Le tri fait que la comparaison montre les changements plutôt que l'ordre.

Un manifeste de 25 Mo se convertit en un peu plus d'une seconde sur la machine de référence, et tout se déroule sur votre appareil.

• Retrait — 2 espaces, 4 espaces, vraies tabulations, ou minifié sur une ligne. Les quatre sont gratuits — il n'y a pas d'axe de qualité sur un retrait.
• Documents — Automatique, toujours un tableau, le premier document seulement, ou un fichier par document.
• Trier les clés — Ordonne les clés de chaque objet par point de code, de la même manière dans toutes les langues, pour que la sortie ne dépende pas de la langue du navigateur.
• Clés en double — Refuser et signaler, ou garder la dernière. Ce réglage est un argument de l'analyseur, donc le modifier relit le document.
• Nombres non finis — null, une chaîne, ou arrêter la conversion.
• Horodatages — Les garder exactement tels qu'écrits, ou les normaliser en ISO 8601.
• Combiner (Pro) — Tous les documents de tous les fichiers en file, repliés dans un tableau JSON dans l'ordre de la file.

Le YAML est écrit par des humains et le JSON est lu par des programmes. La conversion est ce qui permet à une configuration agréable à éditer d'atteindre un système qui n'accepte que du JSON, et c'est le moyen le plus rapide de découvrir ce qu'un fichier dit vraiment quand l'indentation cesse d'être évidente.

• Les API prennent du JSON — Transformez une configuration YAML en corps de requête, en fixture, ou en bloc de réglages pour un service dépourvu d'analyseur YAML.
• Déboguer l'indentation — Quand un manifeste ne se comporte pas comme prévu, le convertir montre la structure vue par l'analyseur, souvent différente de celle que l'indentation suggérait.
• Comparer deux configurations — Convertissez les deux, triez les clés, comparez le JSON. L'ordre et les changements de commentaires cessent d'apparaître comme des différences.
• Alimenter une chaîne JSON — jq, les validateurs JSON Schema et tous les outils JSON de ce site fonctionnent sur le résultat.
• Rien ne quitte votre appareil — Les manifestes contiennent des noms d'hôtes, des registres d'images et parfois un secret. La conversion se fait dans la page : rien de cela n'est envoyé où que ce soit.

• JSON vers YAML
• Formateur JSON
• XML vers JSON
• Outils JSON
• Validate the JSON

  Confirm the converted document parses everywhere, with the position of anything that does not

• Explore a large result

  A collapsible tree beats scrolling forty thousand lines of a converted manifest