Formateur & validateur YAML, gratuit

Collez du YAML pour le formater et le valider. Voyez les erreurs instantanément, corrigez l'indentation et convertissez en JSON.

Traité localement · rien n'est envoyé à un serveur
Collez du YAML pour valider

Qu'est-ce que le YAML ?

YAML (YAML Ain't Markup Language) est un format de sérialisation de données lisible par l'humain, utilisé pour les fichiers de configuration (Docker, Kubernetes, GitHub Actions, Ansible), l'échange de données, et plus encore. Il utilise l'indentation au lieu des accolades et constitue un sur-ensemble du JSON.

Questions fréquentes

Quelles erreurs le validateur détecte-t-il ?

Erreurs d'indentation, deux-points manquants, clés en double, caractères invalides, chaînes non fermées, mauvaises imbrications et autres problèmes de syntaxe YAML. Les messages d'erreur incluent les numéros de ligne.

Puis-je convertir le YAML en JSON ?

Oui ! Cliquez sur le bouton « → JSON » pour convertir votre YAML en JSON bien formaté. Pour la conversion inverse, utilisez notre Convertisseur JSON → YAML, gratuit.

Petit tour d'horizon de YAML

YAML 1.0 a été publié en 2001 par Clark Evans, Ingy döt Net et Oren Ben-Kiki ; YAML 1.1 a suivi en 2005, et la version actuelle est YAML 1.2.2, qui a corrigé plusieurs pièges historiques (notamment le « problème de la Norvège », voir plus bas) et a été conçue pour être un sur-ensemble strict de JSON. La spécification officielle se trouve à yaml.org/spec/1.2.2. Ce formateur utilise la bibliothèque open source js-yaml, qui analyse selon le schéma YAML 1.2 par défaut ; ainsi, la plupart des bizarreries héritées de la 1.1 ne s'appliquent pas au texte formaté ici, mais elles s'appliquent à la plupart des outils YAML côté serveur auxquels vous enverrez la sortie.

Où vit réellement YAML

YAML s'est imposé comme le format de configuration de l'infrastructure cloud-native. Les endroits où vous le rencontrerez le plus :

Le piège des espaces (espaces uniquement)

YAML utilise l'indentation pour marquer la structure, et la spécification est explicite : les tabulations ne sont pas autorisées pour l'indentation. Uniquement des espaces. C'est la source de bogues la plus courante en YAML écrit à la main, surtout parce que de nombreux éditeurs mélangent silencieusement tabulations et espaces selon leurs réglages. Le message d'erreur que vous obtiendrez d'un analyseur strict ressemble à « found character '\t' that cannot start any token », autrement dit : « vous avez utilisé une tabulation quelque part ». Le correctif est universel : activez « afficher les espaces » dans votre éditeur et convertissez chaque tabulation en deux ou quatre espaces.

La taille d'indentation relève de la convention plutôt que de la spécification. 2 espaces est le standard de facto pour les manifestes Kubernetes, GitHub Actions et la plupart du YAML que vous lirez sur le web moderne. 4 espaces est plus courant dans Ansible. La règle qui compte : soyez cohérent au sein d'un même fichier. Mélanger 2 et 4 espaces entre des clés sœurs, voilà ce qui fait trébucher les analyseurs, pas la taille que vous choisissez.

Le problème de la Norvège (et pourquoi vous devriez mettre entre guillemets les chaînes ambiguës)

YAML 1.1 (toujours la valeur par défaut dans PyYAML, snakeyaml et beaucoup d'autres analyseurs côté serveur) interprète une longue liste de graphies booléennes sans guillemets comme de véritables booléens : true, True, TRUE, false, False, FALSE, yes, Yes, YES, no, No, NO, y, n, on, off. Le piège célèbre : le code pays ISO de la Norvège est NO. Une configuration YAML qui liste des pays comme des chaînes sans guillemets analyse silencieusement la Norvège comme le booléen false, et le code en aval qui lit countries[0] == 'NO' échoue de façon déroutante.

YAML 1.2 (et le schéma par défaut de js-yaml) a restreint les booléens à seulement true / false, ce qui corrige le problème de la Norvège au niveau de l'analyseur. Mais de nombreux outils du monde réel utilisent encore par défaut le schéma YAML 1.1 pour la rétrocompatibilité. L'habitude défensive : mettez entre guillemets toute chaîne qui pourrait ressembler à un booléen, un nombre, une date ou une version. country: "NO", postal_code: "01234", version: "1.10", time: "10:30". Les guillemets sont le désambiguïsateur universel.

Autres pièges de coercition de type

Style bloc contre style flux

YAML prend en charge deux notations pour les mêmes données :

# Block style (the standard, indentation-based)
person:
  name: Alice
  tags:
    - admin
    - billing

# Flow style (JSON-like inline)
person: { name: Alice, tags: [admin, billing] }

Le style bloc est ce que vous verrez dans 99 % du YAML écrit à la main : c'est ce qui rend le format lisible. Le style flux est une échappatoire utile pour de courtes valeurs sur une seule ligne ou pour générer du YAML par programme quand vous préférez ne pas suivre l'indentation. Le formateur normalise vers le style bloc pour la sortie (la forme la plus lisible), quel que soit le style utilisé dans votre entrée.

Ancres et alias (l'astuce DRY)

La fonctionnalité de réutilisation de YAML : définissez une valeur une fois avec l'ancre &name, référencez-la ailleurs avec l'alias *name. Pratique pour les longs fichiers de configuration où le même bloc de valeurs apparaît plusieurs fois.

defaults: &defaults
  region: us-east-1
  log_level: info

production:
  <<: *defaults
  log_level: warn   # override

staging:
  <<: *defaults

Quelques réserves : tous les processeurs YAML ne prennent pas en charge les ancres et les alias (notamment certains anciens outils de manifestes Kubernetes et certains contextes Helm). La syntaxe de <<: « clé de fusion » montrée ci-dessus est une extension de YAML 1.1 et est officiellement dépréciée en 1.2 : js-yaml la prend en charge, mais les analyseurs purement 1.2 peuvent ne pas le faire.

Fichiers multi-documents

Un seul fichier YAML peut contenir plusieurs documents, séparés par ---. Courant dans Kubernetes : un fichier avec un Deployment, un Service et un ConfigMap, séparés par ---, appliqués avec un seul kubectl apply -f :

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc

YAML, JSON et TOML

Si vous avez le choix pour une nouvelle configuration : TOML pour la configuration plate, YAML si vous avez besoin d'une imbrication profonde et que l'écosystème s'est standardisé dessus (Kubernetes, Ansible), JSON si c'est une machine qui l'écrit. YAML est le bon format quand des humains doivent lire une configuration profondément imbriquée et écrire des commentaires pertinents en ligne.

Confidentialité

Les configurations YAML contiennent fréquemment des secrets qui ne devraient pas transiter par le serveur d'autrui : des blobs base64 de Kubernetes Secret, des mots de passe de base de données dans application.yml, des clés d'API dans les workflows CI, des noms d'hôtes internes dans les configurations de déploiement. Le formateur s'exécute entièrement dans votre navigateur via la bibliothèque open source js-yaml : le contenu collé est analysé et réémis localement, sans aucune requête / aucun téléversement / aucune journalisation. Fermer l'onglet efface tout.

Erreurs courantes

  1. Mélanger tabulations et espaces dans l'indentation. L'erreur la plus courante. Les tabulations sont interdites par la spécification ; certains éditeurs les insèrent silencieusement. Affichez les espaces dans votre éditeur.
  2. Indentation incohérente entre éléments de même niveau. Les clés sœurs doivent être alignées sur la même colonne. Une indentation mixte de 2/4 espaces casse l'analyse.
  3. Valeurs sans guillemets qui ressemblent à des booléens, des nombres, des dates ou des heures. NO, 012, 1.10, 10:30, yes : mettez-les entre guillemets.
  4. Espace manquant après les deux-points. key: value fonctionne ; key:value est invalide (analysé comme une seule chaîne).
  5. Espaces en fin de ligne. Certains analyseurs traitent les espaces de fin comme significatifs ; d'autres non. L'habitude sûre quel que soit l'outil est de supprimer les espaces en fin de ligne.
  6. Chaînes multilignes sans le bon scalaire de bloc. Les longues chaînes ont besoin de | (littéral, préserve les sauts de ligne) ou de > (replié, joint les lignes). Le texte multiligne brut sans guillemets se comporte rarement comme vous l'attendez.
  7. Ancres / alias supposés partout. Helm et certains contextes Kubernetes ne prennent pas pleinement en charge &/*. Testez dans votre véritable pipeline avant d'en dépendre.
  8. Incohérences d'encodage. Les fichiers YAML devraient être en UTF-8. Un éditeur Windows enregistrant en UTF-16 avec BOM produit des fichiers que certains analyseurs ne peuvent pas lire.

Autres questions fréquentes

Le formateur préservera-t-il mes commentaires ?

Non. La bibliothèque js-yaml analyse le YAML en une valeur JavaScript et la réémet à partir de cette valeur, ce qui signifie que les commentaires (# like this) sont supprimés : ils vivent dans le texte source, pas dans la structure analysée. Si préserver les commentaires compte (c'est généralement le cas pour les fichiers de configuration soignés à la main), utilisez une alternative qui préserve les commentaires comme eemeli/yaml via son API CST, ou faites de petites modifications à la main plutôt que de faire un aller-retour par ce formateur.

Pourquoi mon NO est-il traité comme un booléen par l'analyseur YAML de mon serveur ?

Parce que cet analyseur utilise YAML 1.1 (la valeur par défaut pour PyYAML, snakeyaml et beaucoup d'autres), qui interprète NO comme le booléen false. Ce formateur utilise YAML 1.2 par défaut (via js-yaml), il ne déclenche donc pas le bogue ici, mais dès l'instant où vous livrez le fichier dans un environnement YAML 1.1, le piège s'active. Mettez toujours entre guillemets les chaînes ambiguës : country: "NO".

Puis-je convertir le YAML en JSON ?

Oui, cliquez sur « → JSON ». La conversion est sans perte pour tout ce qui peut être représenté en JSON (chaînes, nombres, booléens, null, tableaux, objets). Ce qui ne survit pas : les commentaires (JSON n'a aucune syntaxe pour eux), les ancres et alias (JSON n'a pas d'équivalent), et les types date / horodatage de YAML (qui deviennent des chaînes en JSON). Pour la conversion inverse, utilisez l'outil JSON vers YAML dédié.

Quelque chose est-il envoyé à un serveur ?

Non. Toute l'analyse, le formatage et la conversion JSON s'exécutent dans votre navigateur via js-yaml. Le YAML collé n'est jamais transmis à aucun serveur. C'est important parce que les configurations YAML contiennent fréquemment des secrets (valeurs de Kubernetes Secret, mots de passe de base de données, clés d'API, points de terminaison internes) qui ne devraient pas être téléversés vers un service tiers.

Quelle est la limite de taille ?

Pas de limite stricte : le formateur s'exécute dans la mémoire de votre navigateur. Les manifestes Kubernetes typiques (quelques Ko) et les charts Helm (des dizaines de Ko) se formatent instantanément. Les très grands fichiers multi-documents (plusieurs Mo) peuvent être lents mais fonctionnent généralement ; si vous avez un chart Helm de 10 Mo, formatez-le localement avec un outil en ligne de commande.

Pourquoi YAML est-il si source d'erreurs ?

Trois raisons qui se cumulent : (1) l'espace significatif fait que les fautes de frappe provoquent des changements sémantiques silencieux ; (2) la coercition de type permissive de YAML 1.1 transforme des chaînes ambiguës en booléens / nombres non voulus ; (3) le format offre trop de façons d'écrire la même chose (bloc contre flux, guillemets simples contre doubles, trois variantes de chaînes multilignes). Les habitudes défensives, toujours mettre entre guillemets, toujours rester cohérent avec l'indentation, valider avant de déployer, corrigent la majeure partie de la surface d'exposition.

Outils associés

Convertisseur JSON → YAML

Convertissez entre les formats JSON et YAML.

Formateur JSON

Formatez, validez et embellissez les données JSON.

Formateur XML

Formatez, embellissez ou minifiez du XML.