Command Palette

Search for a command to run...

Convertisseur JSON en YAML : Convertissez les configurations sans problème de Norvège

Convertisseur JSON en YAML : Convertissez les configurations sans problème de Norvège

T
Toolz Team
|Jul 14, 2026|15 min read

La première fois que Yaml m'a bien brûlé, c'était un code de pays. Je déplaçais une configuration locale des fichiers JSON d'un projet Laravel dans un format YAML favorable au déploiement, convertissant à la main au fur et à mesure de la « modification des accolades » en indentation. "country": "NO". Dans YAML, non cité, ce n'est pas une chaîne - selon les règles de YAML 1.1 que PyYaml et de nombreux autres analyseurs s'appliquent encore, NO est le booléen false. Le script de déploiement, écrit en Python, a joyeusement évalué les utilisateurs norvégiens en tant que country: false et les a acheminés vers le lieu de secours. Ce bogue a un nom - la communauté l'appelle le problème de la Norvège - et j'ai pu le découvrir de manière artisanale, un ticket de support confus à la fois.

La conversion manuelle de JSON en YAML semble triviale et est en fait un champ de mines, car les deux formats ont des idées extrêmement différentes sur ce que signifie un mot nu. En JSON, tout est explicite : les chaînes ont des guillemets, les chiffres ne sont pas, true/false/null sont des mots-clés, fin de l'histoire. Dans YAML, un scalaire non coté interprété: no devient faux, 3000 devient un entier, 1.10 devient le flotteur 1.1 (Au revoir, chaîne de version), 08 Étouffe certains analyseurs comme un octal invalide, et une valeur avec un espace-colon parasite devient une carte imbriquée lorsque vous vous y attendez le moins. Chacun d'entre eux est une corruption silencieuse des données - les analyses de fichiers sont correctes, les types sont tout simplement erronés.

un Convertisseur JSON en YAML Cela comprend que ces règles vous permettent de la lisibilité pour laquelle YAML a été inventé sans la roulette de type. Celui que j'ai construit pour Toolz.dev détecte tous les scalaires ambigus - sosies booléens, sosies numériques, valeurs de Yaml 1.1, chaînes avec caractères spéciaux - et les cite exactement, donc ce qui était une chaîne dans votre JSON est toujours une chaîne après que le prochain outil analyse le YAML. C'est "exactement ces questions : citations tout Ce serait également sûr, mais la sortie s'arrête de ressembler à un YAML idiomatique, et idiomatique est tout.

Ce guide explique comment la conversion gère les arêtes vives de YAML, pourquoi JSON est techniquement déjà YAML (et pourquoi ce fait ne vous aide pas), et les flux de travail Kubernetes, CI et Docker composent chaque semaine.

tl;dr : Collez JSON dans le Toolz.dev JSON en YAML Convertisseur, choisissez un indentation de 2 ou 4 espaces et obtenez des YAML de style bloc propres avec un devis de type sécurisé - "3000" reste une chaîne, "no" reste une chaîne, "1.10" Reste une version. L'ordre des clés est conservé, les collections vides sortent comme [] et {}, et tout s'exécute côté client, donc les configurations avec des secrets ne quittent jamais votre navigateur. Retour aller-retour avec le Validateur de YAML, et formatez la source en premier avec le Formateur JSON.


n'est-il pas déjà valide YAML ?

Oui - et c'est le plus inutile "oui" dans la gestion de la configuration. YAML 1.2 a été explicitement conçu comme un sur-ensemble de JSON : chaque analyse de document JSON valide comme YAML valide. Vous pouvez coller du JSON brut dans un manifeste Kubernetes et kubectl l'accepterait.

Personne ne le fait, car la raison pour laquelle YAML existe est Ergonomie humaine. Kubernetes manifestes, workflows d'actions GitHub, fichiers de composition Docker, playbooks Ansible, configurations d'assistant domestique - ce sont des YAML parce que les gens les lisent et les éditent en permanence, et replicas: 3 sous un bloc en retrait, les analyses en bloc sont mieux que {"replicas":3} niché dans des accolades. Quand quelqu'un dit "convertir JSON en YAML", il veut dire de style bloc Yaml : indentation au lieu de bretelles, - Des tirets au lieu de tableaux entre crochets, aucun guillemet n'est nécessaire.

Cette dernière clause est celle où vit la difficulté. Passer de la syntaxe tout explicite de JSON à la syntaxe minimale de YAML Décider, pour chaque chaîne, s'il peut perdre ses devis en toute sécurité — Et cette décision nécessite de mieux connaître les règles de résolution scalaires de YAML que la plupart des humains ne le font de manière fiable à 17 heures un vendredi. C'est le travail réel d'un convertisseur, la partie attelle-à-indentation est triviale.

Qu'est-ce qui se casse silencieusement lorsque vous convertissez à la main ?

Les cas d'échec se répartissent en quatre familles, et j'ai frappé chacune d'entre elles dans des configurations réelles :

Les sosies booléens. YAML 1.1 se résout yes, no, on, off, y, n (dans divers boîtiers) comme booléens, et Yaml 1.2 garde true/false. PyYaml, toujours la bibliothèque YAML par défaut dans la plupart des bases de code Python, implémente la version 1.1. aussi "debug": "no" converti à la main en debug: no se transforme debug: false Dans votre outil Python, déployez des outils. Le problème de la Norvège (NOfalse) et son cousin le problème de l'Ontario (ONtrue) sont les plus grands succès de cette famille.

Nombres de sosies. "port": "3000" converti en port: 3000 est maintenant un nombre entier. Kubernetes ne se soucie pas de certains domaines et échoue dans d'autres - les valeurs env var, par exemple, doivent être des chaînes et kubectl apply y rejettera un entier avec une erreur qui nomme le champ mais pas le pourquoi. Les chaînes de version sont pires car rien n'échoue : version: 1.10 Analyse comme le flotteur 1.1, et votre script de déploiement rapporte avec joie la mauvaise version pour toujours. Zéros principaux - codes postaux, numéros de téléphone, identifiants octal 0755 — Complète la famille.

caractères spéciaux. Un deux-points suivi d'un espace à l'intérieur d'une valeur non cotée commence un mappage (message: error: not found est une erreur d'analyse ou une carte imbriquée, selon l'analyseur). un # Démarre un commentaire à mi-valeur. de premier plan *, &, ! entrer en collision avec l'ancre, l'alias et la syntaxe de tag. Les chaînes de nouvelles lignes doivent s'échapper ou bloquer les scalaires.

la chaîne vide. Le vide non coté dans YAML est null, pas "". Tout champ JSON contenant une chaîne vide doit sortir entre guillemets ou changer de type.

le convertisseur vérifie chaque chaîne par rapport aux quatre familles et cite celles qui en ont besoin - et uniquement celles-ci. production sort à nu parce que c'est sans ambiguïté ; "3000", "no", "1.10", et "" Sortez cité parce qu'ils ne le sont pas. Il y a aussi une "toute les chaînes" pour vous quand vous nourrissez un analyseur auquel vous ne faites pas confiance et que vous voulez que la résolution scalaire n'ait pas lieu.

Comment convertir JSON en YAML avec l'outil ?

Étape 1 : Collez votre JSON

Toute opération JSON valide — objets, tableaux, imbrication profonde, Unicode. Le bouton Charger un exemple vous donne une configuration de service réaliste qui exerce les cas intéressants : un port de chaîne numérique, un booléen, un tableau vide, des cartes imbriquées. Si votre entrée a des problèmes de syntaxe, le convertisseur signale l'erreur exacte de l'analyseur plutôt que de convertir un document tronqué ; pour la recherche alors que L'erreur est dans une grosse goutte, la Formateur JSON est le meilleur microscope.

Étape 2 : Choisissez l'indentation

deux espaces ou quatre. Deux est la convention écrasante - Kubernetes Docs, GitHub Actions, exemples, Docker compose des références et le yamllint Les valeurs par défaut l'utilisent tous, mais certaines équipes standardisent sur quatre pour la lisibilité dans la nestation profonde. Quel que soit le choix que vous choisissez, le convertisseur est cohérent à ce sujet, y compris le cas subtil des éléments de liste sous une clé, où l'indentation manuelle incohérente est une source classique d'erreurs "de mappage" ici.

Étape 3 : Convertir et réviser

La sortie apparaît avec le nombre de lignes et d'octets. Écrémez-le une fois - non pas pour l'exactitude (c'est le travail du convertisseur) mais pour vérifier la bonne santé des décisions de citation par rapport à vos attentes. vue PORT: "3000" cité tandis que NODE_ENV: production N'est-ce pas l'outil qui vous indique quelles valeurs étaient dangereuses.

Étape 4 : Copiez ou téléchargez

Copier dans le presse-papiers pour le coller dans un manifeste existant ou télécharger en tant que .yaml fichier. La sortie utilise uniquement des espaces — YAML interdit les onglets pour l'indentation, ce qui vaut la peine d'être connu lorsque vous modifiez plus tard le fichier dans un éditeur configuré pour l'indentation des onglets.

JSON vs Yaml : Quand chaque format gagne-t-il ?

JSON banane
Lire/édité par Machines, API Humains, équipes de l'OPS
observation pas dans la spécification # Commentaires : la fonctionnalité de tueur pour les configurations
Type explicite Total — Les devis décident de tout Résolution scalaire — Décidence du contexte
Chaînes multilignes \n s'échappe uniquement Bloquer les scalaires (`
Vitesse d'analyse et ubiquité Le plus rapide, partout Analyseurs plus lents et plus lourds
canons à pied Des virgules de fuite, c'est à peu près tout Problème de Norvège, onglets, dérive d'indentation, troncature de version
Habitat naturel Charges utiles API, package.json, échange de données Kubernetes, Pipelines CI, Composer, Ansible

Le modèle derrière la table : JSON gagne partout où une machine écrit et une machine lit ; YAML gagne partout où une machine lit mais un humain écrit. La configuration se situe carrément dans la deuxième catégorie, c'est pourquoi la direction JSON-à-YAML est la plus courante - les données commencent à vie dans une API ou une exportation de base de données et doivent devenir quelque chose qu'une équipe d'OPS peut maintenir. Le voyage inversé, Yaml, retour à JSON lisible par machine, est ce que le Validateur de YAML Handles — Collez YAML, obtenez une validation et le JSON équivalent.

Quels sont les flux de travail quotidiens de cette conversion ?

Manifestes Kubernetes à partir de la sortie de l'API

kubectl get deployment my-app -o json Vous donne JSON, le manifeste que vous recherchez dans Git est YAML. Convertir des réponses d'API en YAML propre est le moyen le plus rapide de démarrer un manifeste à partir d'une ressource en direct. Convertir, supprimer le serveur status et metadata.managedFields blocs, et vous avez un point de départ déclaratif. Le devis de type-safe gagne son obligation ici : valeurs env dans Kubernetes moût être des chaînes, et l'insistance du convertisseur sur le citation "3000" est la différence entre kubectl apply réussir et échouer.

Configuration du pipeline CI

Les actions GitHub et GitLab CI sont uniquement YAML. Lorsque je génère des étapes de workflow par programmation - une matrice de versions PHP et de nœud pour tester WP Adminify, par exemple - le générateur produit naturellement JSON, et la dernière étape est la conversion. Les chaînes de version dans les matrices de test sont exactement les valeurs qui sont mutilées par la conversion naïve : une matrice de ["1.9", "1.10", "1.11"] Convertis manuellement sans devis Tests contre PHP 1.1 deux fois. le Collection d'outils de codage Couvre davantage ce modèle de génération-puis-convertir.

Docker composer d'inspecter la sortie

docker inspect émet JSON ; docker-compose.yml veut Yaml. Inverser la technologie Un fichier de composition à partir d'un conteneur en cours d'exécution (ports, volumes, env) est un travail de conversion et d'élagage. Les tableaux et objets vides se convertissent en [] et {} Flow Syntaxe, qui est accepté et qui permet de garder la scène de taille lisible.

Rendre la configuration révisable

Celui-ci est sous-estimé : les configurations JSON avec des dizaines de clés imbriquées sont misérables dans la révision du code, en partie parce qu'elles ne peuvent pas porter de commentaires. La conversion en YAML vous permet d'annoter pourquoi rateLimit est 250 juste à côté de la valeur. Pour l'examen lui-même, jumeler la conversion avec un Diff structural d'avant/après JSON garde la question "ce qui a réellement changé" alors que la version YAML gère la "pourquoi".

Documents OpenAPI et de schéma

Les spécifications OpenAPI sont généralement créées dans YAML mais générées et servant en tant que JSON. La conversion d'une spécification générée en YAML pour une édition humaine - puis la validation du voyage aller-retour - est un workflow d'API standard, et les garanties de fidélité (ordre de clé préservé, types de guillemets) signifient que la version de YAML reste différable par rapport à son ancêtre JSON.

Pourquoi la conservation des commandes de clés est-elle importante ?

Selon la spécification JSON, l'ordre des clés de l'objet n'a aucune signification — {"a":1,"b":2} et {"b":2,"a":1} sont le même objet. Ainsi, un convertisseur peut trier les clés alphabétiquement et être techniquement correct. Ce serait aussi pratiquement hostile, car les fichiers de configuration sont lire Dans l'ordre : un déploiement Kubernetes se lit naturellement comme apiVersion, kind, metadata, spec — Les tris par ordre alphabétique produisent un manifeste qui analyse de manière identique et se lit comme une note de rançon.

Le convertisseur émet des clés dans l'ordre source. Votre modèle mental du document survit à la conversion, le YAML diffère proprement des conversions précédentes de la même source et des ordres conventionnels (nom avant la valeur, apiVersion Premièrement) Restez conventionnel. si vous avoir envie la commande canonique à des fins de comparaison, c'est une préoccupation diff-tool - le Vérificateur de différentiel JSON Compare par clé, quel que soit l'ordre, qui est le bon calque pour ce problème.

Est-il sécuritaire de convertir des configurations contenant des secrets ?

La configuration est le texte le plus secret qu'un développeur gère : les URL de base de données avec des mots de passe intégrés, les jetons API dans les blocs ENV, les noms d'hôte internes qui mappent votre infrastructure. C'est aussi exactement ce que les gens collent dans des convertisseurs en ligne, généralement à mi-déploiement, généralement pressés.

le Convertisseur Toolz.dev S'exécute entièrement dans votre navigateur : analyse, analyse scalaire, sérialisation - tout cela est un Javascript côté client, aucune demande de réseau ne transporte vos données et l'outil continue de fonctionner avec votre connexion. C'est un fait architectural, pas une promesse de politique de confidentialité. La philosophie de conception du navigateur derrière l'ensemble de la boîte à outils est présentée dans le Guide d'outils pour les développeurs Web; cet outil est cette philosophie appliquée au type de document le plus sensible de votre flux de travail.

La mise en garde évidente est que la conversion côté client protège le transformation. Là où vous collez la sortie par la suite, c'est sa propre décision de sécurité.

FAQ

Comment convertir JSON en YAML en ligne ?

Collez votre JSON dans le Convertisseur JSON en YAML, choisissez l'indentation à 2 ou 4 espaces, puis cliquez sur Convertir. Vous obtenez des YAML de style bloc avec un devis de type sécurisé, prêt à copier ou à télécharger en tant que fichier .yaml. La conversion s'exécute entièrement dans votre navigateur, rien n'est téléchargé.

JSON est-il déjà valide YAML ?

Techniquement oui, YAML 1.2 est un sur-ensemble de JSON, donc tout document JSON valide est en tant que YAML. Mais la syntaxe JSON bat le but de la lisibilité de YAML. La conversion produit des YAML de style bloc avec indentation au lieu de accolades, ce que Kubernetes manifeste, CI et compose des fichiers, attendez-vous à ce que les humains lisent et modifient.

Quel est le problème de la Norvège dans YAML ?

Selon les règles scalaires YAML 1.1, que des analyseurs comme PyYaml s'appliquent toujours, les valeurs non cotées non, oui, activées et désactivées sont des booléens. Le code du pays non devient donc faux. Le convertisseur empêche cela en citant automatiquement toute chaîne qu'un analyseur YAML pourrait interpréter comme un booléen, un nombre ou un NULL.

Les chaînes numériques comme "3 000" restent-elles des chaînes après la conversion ?

Oui. Le convertisseur détecte les chaînes qui ressemblent à des nombres et les citent dans la sortie, donc "3 000" reste une chaîne au lieu de devenir l'entier 3 000. Cela compte pour les ports, les numéros de version tels que "1.10" (qui seraient autrement tronqués au float 1.1), les codes postaux et les identifiants avec des zéros en tête.

Le convertisseur conserve-t-il l'ordre de mes clés JSON ?

Oui. Les clés sont émises dans l'ordre dans lequel elles apparaissent dans le JSON source. Les clés de tri seraient techniquement valides - la commande d'objets JSON n'a aucune signification pour la RFC 8259 - mais l'ordre des sources maintient les configurations lisibles dans leur structure conventionnelle et maintient le YAML diffable par rapport à sa source JSON.

Puis-je utiliser la sortie directement dans Kubernetes ou Docker Compose ?

Oui. La sortie est un YAML de style bloc standard déplié avec des espaces (jamais des onglets), que Kubectl, Docker composent, GitHub Actions et GitLab CI acceptent tous. Les valeurs qui doivent être des chaînes, comme les valeurs de Kubernetes env var, sortent entre guillemets, évitant les erreurs de type que Kubectl déclenche sur des chiffres non cotés.

Comment reconvertir YAML en JSON ?

Utilisez le Validateur de YAML Sur toolz.dev — Il analyse votre YAML, signale les erreurs de syntaxe et produit le JSON équivalent. Avec le convertisseur JSON en YAML, il vous donne un aller-retour complet entre les deux formats.

Est-il sécuritaire de convertir des fichiers de configuration contenant des secrets ?

Oui. La conversion s'exécute entièrement en JavaScript dans votre navigateur. Aucune requête réseau ne transporte vos données, rien n'est stocké ou enregistré et l'outil fonctionne hors ligne. Les configurations avec les informations d'identification de la base de données, les jetons d'API ou les noms d'hôte internes ne quittent jamais votre machine.


La lisibilité de Yaml est réelle, tout comme ses arêtes vives - le format résout les types du contexte, et le contexte est exactement ce que la conversion manuelle se trompe. Un convertisseur qui connaît les règles scalaires vous donne la configuration lisible sans la corruption de type silencieuse : Convertissez votre JSON, survolez le devis qu'il a choisi et expédiez un manifeste où la Norvège est encore un pays.

Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!