YAML vers JSON et JSON vers YAML — convertisseur sans conservation des commentaires
Convertissez des configurations YAML Kubernetes, docker-compose ou GitHub Actions en JSON et inversement, dans votre navigateur. C'est une re-sérialisation, pas un aller-retour sans perte : les commentaires, les ancres et les documents multiples sont perdus, et les valeurs sans guillemets suivent les règles de typage YAML.
Ce que fait ce convertisseur — et ce qu'il perd
Les deux sens, un bouton chacun
YAML → JSON et JSON → YAML sont deux actions distinctes. Le résultat écrase l'autre éditeur et n'est jamais fusionné avec le texte existant.
Les commentaires sont toujours perdus
Les commentaires YAML sont supprimés à l'analyse, et le YAML généré n'en contient jamais. JSON n'a de toute façon pas de syntaxe de commentaire.
Les ancres sont développées, les documents multiples échouent
Les couples &anchor / *alias sont résolus en objets dupliqués. Un fichier contenant plusieurs documents --- est rejeté au lieu d'être fusionné.
Les valeurs suivent le typage YAML 1.2
1.0 sans guillemets devient 1, 2024-01-01 devient un horodatage ISO et .inf / .nan deviennent null. Mettez des guillemets pour conserver une chaîne.
Exécution locale, choix de fichier et téléchargement
Les fichiers sont lus dans le navigateur et rien n'est téléversé. Aucune limite stricte de taille, mais un fichier très volumineux fige l'onglet pendant la conversion.
FAQ sur la conversion YAML ↔ JSON
La conversion est-elle bidirectionnelle ?
Oui : un bouton pour YAML → JSON, un autre pour JSON → YAML. Chaque sens re-sérialise toutefois les données, donc les commentaires, la mise en forme et les ancres ne sont pas conservés. Le YAML généré utilise une indentation de 2 espaces et replie les longues chaînes à 80 colonnes ; aucune option d'indentation ou de tri n'est proposée.
Peut-on conserver les commentaires ?
Non. L'analyseur YAML supprime les commentaires et le YAML généré n'en ajoute pas ; JSON n'a pas de syntaxe de commentaire. Gardez le fichier commenté comme source de vérité et considérez la sortie comme des données dérivées.
Les ancres, alias et documents multiples sont-ils pris en charge ?
Les ancres et alias sont résolus et écrits comme des valeurs dupliquées. Les documents multiples (plusieurs blocs ---) sont rejetés avec « expected a single document in the stream » ; découpez-les d'abord. Cela concerne les manifestes Kubernetes regroupant plusieurs ressources dans un fichier.
Pourquoi version: 1.0 devient 1, et pourquoi yes reste une chaîne ?
Les scalaires sans guillemets sont typés par les règles YAML : 1.0 est un nombre, donc affiché comme 1. js-yaml suit YAML 1.2, où yes / no / on / off sont de simples chaînes ; la clé on: de GitHub Actions reste donc une chaîne. Ajoutez des guillemets si le type doit rester une chaîne.
Comment sont traitées les dates, les grands entiers et null ?
Une date sans guillemets comme 2024-01-01 est interprétée comme un horodatage et devient 2024-01-01T00:00:00.000Z en JSON. Les entiers au-delà de 2^53 perdent en précision, et .inf / .nan deviennent null. ~, null et les valeurs vides deviennent tous null.
Les fichiers Kubernetes, docker-compose ou GitHub Actions sont-ils pris en charge ?
Le YAML standard à un seul document fonctionne, y compris ces formats. Découpez d'abord les exports Kubernetes multi-documents, et rappelez-vous que les commentaires sont perdus : n'utilisez pas le résultat comme fichier de configuration à committer.
Qu'en est-il de la taille des fichiers et de la confidentialité ?
Tout s'exécute dans le navigateur et aucun fichier n'est téléversé. Aucune limite n'est configurée, mais la conversion est synchrone sur le thread principal : des fichiers de plusieurs MB peuvent figer la page.
