YAML et JSON : préserver les données, pas l’apparence
Une configuration YAML peut devoir devenir JSON pour être échangée avec un service. Une ressemblance de structure ne signifie pas que chaque élément possède un équivalent.
Le type compte davantage que l’apparence
La chaîne "003" n’est pas le nombre 3, et "false" entre guillemets n’est pas le booléen false. Gardez les identifiants en texte si les zéros ou leur écriture exacte importent.
Le convertisseur traite les données YAML 1.2 Core compatibles JSON. Ne transposez pas automatiquement les attentes d’un ancien système : certains mots changent d’interprétation selon la version.
Références: YAML 1.2.2 — Core types and comments as presentation
Les commentaires ne sont pas des valeurs
Les commentaires YAML facilitent la maintenance, sans appartenir aux données. Ils ne passent pas en JSON ici et ne réapparaissent pas lors du retour.
Gardez la source annotée et considérez le résultat comme un export de données. La coloration syntaxique et un ordre familier ne prouvent pas que les types sont préservés.
Références: YAML 1.2.2 — Core types and comments as presentation
Refuser évite les pertes silencieuses
Le flux accepte un document à clés textuelles. Il refuse clés dupliquées, alias, ancres, balises personnalisées et fonctions hors du modèle pris en charge.
Les nombres hors de la plage représentable sont refusés plutôt qu’arrondis discrètement. Utilisez du texte pour les longs identifiants. La conversion n’exécute pas la configuration et ne prouve pas son acceptation par le destinataire.
Exemple : trois valeurs, trois types
code: "003", enabled: false et retries: 3 produisent la chaîne "003", le booléen false et le nombre 3. Les zéros restent parce que le code est textuel, pas grâce à une déduction.
Ajouter # staging avant ces lignes ne crée aucune propriété JSON. Au retour en YAML, guillemets et forme peuvent changer sans altérer valeurs et types ; le commentaire original ne revient pas.