YamlBox

Article du guide · 6 min de lecture

YAML vs JSON : quand utiliser lequel

YAML vs JSON est un choix entre deux formats de sérialisation construits sur la même idée de base : imbriquer des paires clé-valeur et des listes. Les différences qui comptent dans la pratique concernent qui lit le fichier : les humains ou les machines.

Mis à jour

YAML vs JSON : la version courte

JSON est un format d'échange de données : strict, sans ambiguïté, et chaque langage peut l'analyser nativement. YAML est un format de configuration : il accepte les commentaires et les chaînes multilignes, et il est conçu pour être modifié par des personnes dans le cadre de requêtes pull. Utilisez JSON sur le réseau, YAML dans les fichiers que les humains conservent — et convertissez-les entre eux lorsqu'une frontière l'exige.

Ce qui diffère réellement

Commentaires

YAML a des commentaires ; JSON ne le fait pas. Dans les fichiers de configuration, cela est décisif : la raison pour laquelle vous savez pourquoi un délai d'attente est défini sur 3000 est généralement le commentaire situé au-dessus. Lorsque vous convertissez YAML en JSON, les commentaires sont supprimés, c'est pourquoi JSON est souvent traité comme un artefact de construction, et non comme la source de vérité.

Syntaxe et bruit

                # YAML
service:
  name: checkout
  replicas: 3
  ports: [8080, 9090]

// JSON — same data
{
  "service": {
    "name": "checkout",
    "replicas": 3,
    "ports": [8080, 9090]
  }
}

YAML supprime les accolades, les guillemets et les virgules en échange de la sensibilité à l'indentation. C'est le métier que tout utilisateur YAML connaît : moins de caractères, plus de façons de se tromper subtilement sur les espaces.

Types et pièges

  • JSON a un type numérique ; YAML distingue les entiers, les flottants et plus encore — et YAML 1.1 analyse le code de pays NO comme le booléen faux, et 1.10 comme un nombre qui perd son zéro final sauf s'il est cité.
  • YAML prend en charge les ancres et les alias (&defaults / *defaults) pour la réutilisation ; JSON n'a pas d'équivalent, les blocs partagés doivent donc être dupliqués ou générés.
  • YAML prend en charge les fichiers multi-documents (--- séparateurs) ; JSON est un document par fichier. Les convertisseurs transforment généralement les documents en tableau.
  • JSON nécessite des clés et des chaînes entre guillemets ; YAML n'est cité que lorsque cela est nécessaire, ce qui signifie qu'une chaîne imprudente peut silencieusement devenir un nombre ou un booléen.

Où chaque format gagne

  • API et formats de fils : JSON. Analyseurs universels, ambiguïté prévisible, adaptés au streaming (JSON Lines).
  • Kubernetes, CI/CD, Docker Compose, Ansible, Helm : YAML, car ces écosystèmes se sont standardisés dessus et prennent en charge les commentaires.
  • Configuration du fournisseur que vous générez par programme : JSON — les algorithmes la produisent sans anxiété d'indentation.
  • Documents qu'un coéquipier junior éditera à la main : YAML, avec des commentaires expliquant le pourquoi.

Conversion en toute sécurité

  1. Connaissez vos fichiers multi-documents. Un ensemble de manifestes k8s séparé par --- doit devenir un tableau JSON, pas seulement le premier document. Utilisez un convertisseur qui indique le nombre de documents trouvés.
  2. Citez les nombres qui sont des identifiants. « 1.10 » est une version ; 1,10 est un flotteur. Activez les guillemets forcés lors de la conversion en YAML si les valeurs sont des chaînes qui semblent numériques.
  3. Regardez les commentaires disparaître. La conversion en JSON entraîne par définition une perte ; si les commentaires sont importants, conservez YAML comme source et générez JSON uniquement au moment de la construction.
  4. Validez avec des erreurs précises. Les erreurs d'indentation produisent des messages trompeurs dans certains outils ; assurez-vous que le vôtre affiche une ligne et une colonne.

Essayez-le : collez n'importe quel YAML dans le convertisseur YAML en JSON — la prise en charge de plusieurs documents et des lignes d'erreur précises sont intégrées, et rien n'est téléchargé.

Questions courantes

YAML est-il un surensemble de JSON ?

YAML 1.2 est conçu comme un sur-ensemble — un JSON valide est généralement un YAML valide. Mais YAML 1.1 (toujours disponible) diffère dans certains cas extrêmes, et les onglets, les clés en double et certaines chaînes sont analysées différemment selon les moteurs. Considérez « c'est techniquement valable YAML » comme un fait amusant et non comme une stratégie de migration.

Qu’est-ce qui est le plus rapide à analyser ?

Les analyseurs JSON sont généralement plus rapides et plus simples car la grammaire est plus petite ; l’analyse native JSON existe dans chaque environnement d’exécution. Pour les fichiers de configuration, la différence n'a pas d'importance : vous analysez une fois au démarrage.