JSON est-il valide YAML ? Ce que YAML 1.2 promet et où il ne fonctionne pas

Coller JSON dans un fichier YAML et s'en sortir - pourquoi cela a fonctionné, et la seule fois où cela n'a pas fonctionné

Un objet JSON ordinaire peut être collé dans le côté source YAML et lu sous le schéma YAML 1.2 JSON de ToolAcre. Les accolades, les crochets, les clés entre guillemets, les chaînes, les nombres, les booléens et null deviennent la même valeur JavaScript simple. Cela explique pourquoi la frontière semble souvent insignifiante.

La garantie doit rester spécifique à l'analyseur. ToolAcre restreint les balises, limite les alias et l'imbrication, et applique une limite de saisie. Un texte peut être valide sous un processeur YAML plus large mais être refusé ici pour des raisons de sécurité ou de forme sans rapport avec son noyau d'apparence JSON.

Chargements ordinaires JSON via ce lecteur YAML 1.2 ; les extensions non prises en charge échouent pour des raisons distinctes

Les schémas sélectionnés produisent des valeurs en forme de JSON : chaînes, nombres, booléens, null, tableaux et mappages. Cet alignement permet d'analyser puis de sérialiser plutôt que de remplacer la ponctuation. Le code source n'établit pas chaque formulation ou erratum de la spécification YAML, donc l'article rapporte le comportement testé au lieu de revendiquer une conformité exhaustive.

En mode strict, tilde, valeur vide et `0o755` restent des chaînes. Ce sont des jetons YAML que JSON lui-même ne contiendrait pas. Core les résout différemment tout en renvoyant une sortie en forme de JSON.

Les schémas fournis s'alignent sur les données en forme de JSON sans prouver chaque avantage de la spécification

Les clés de mappage YAML en double conservent la dernière valeur avec un avertissement ; une interprétation stricte ailleurs pourrait les rejeter. Les anciens lecteurs YAML 1.1 peuvent saisir des mots tels que `NO` différemment, tandis que ce lecteur les conserve sous forme de chaînes. Ces différences compliquent les déclarations générales sur la portabilité.

Les tabulations utilisées comme indentation produisent une erreur, tandis que les tabulations à l'intérieur des chaînes JSON entre guillemets sont échappées. Des valeurs très élevées ou surdimensionnées peuvent atteindre les plafonds de sécurité locaux. Une relation linguistique théorique ne dépasse pas les limites de mise en œuvre.

Les clés en double et les différences entre les analyseurs existants restent des limites d'interopérabilité

L'inverse est clairement faux pour ce pipeline de valeurs. Les commentaires YAML n'ont pas de représentation JSON, les alias sont résolus en données répétées, les flux multidocuments deviennent des tableaux et les balises non prises en charge sont rejetées. Les scalaires de blocs deviennent des chaînes mais leur présentation est perdue.

Même un document YAML pris en charge peut donc être converti en JSON valide et ne jamais revenir au même texte YAML. L'égalité des données peut survivre pour les valeurs ordinaires, contrairement aux commentaires, aux ancres, à l'orthographe et à l'identité du flux.

Ce que cela signifie pour la conversion — JSON en YAML est un changement de style, YAML en JSON est une traduction qui peut perdre des informations

JSON-to-YAML est généralement un changement de style et de sérialisation pour une entrée en forme de JSON. YAML-to-JSON interprète d'abord la syntaxe spécifique à YAML, puis projette le résultat dans le modèle de valeur plus petit de JSON. Les directions ne sont pas symétriques.

ToolAcre teste les documents JSON-to-YAML-to-JSON ordinaires contenant des valeurs imbriquées, Unicode, des valeurs nulles, des tableaux et des chaînes d'apparence ambiguë. Ces appareils prouvent la classe de données couverte, pas toutes les paires de processeurs JSON ou YAML possibles.

Exemple concret : un document JSON chargé en tant que YAML — la même structure, puis une fonctionnalité YAML ajoutée uniquement pour montrer où l'outil JSON s'arrête

Collez `{"country":"NO","items":[1,null],"nested":{"ok":true}}` comme entrée YAML. Le lecteur strict renvoie le même arbre. Ajoutez un commentaire YAML et la valeur reste la même pendant que le commentaire disparaît. Remplacez un objet répété par une ancre et un alias ; le JSON contient désormais des copies plutôt qu'une syntaxe de référence.

Ajoutez `---` et un deuxième document ; le résultat devient un tableau de documents avec un avertissement. Ajoutez `!!binary` ; le lecteur restreint le refuse. Chaque étape marque une limite distincte : présentation ignorée, structure résolue, convention de flux et type non pris en charge.

Ce que cela ne couvre pas : compatibilité au niveau du schéma, où les types YAML comme les horodatages n'ont pas d'équivalent JSON

La compatibilité des schémas ne concerne pas seulement la syntaxe de surface. Core peut créer Infinity ou NaN, que JSON écrit comme null avec des avertissements. L'horodatage et les balises binaires sont refusés dans les schémas restreints plutôt que convertis. ToolAcre restreint délibérément YAML aux données sécurisées en forme de JSON.

Une autre implémentation de YAML peut prendre en charge des types supplémentaires. Cela le rend moins compatible avec les valeurs simples de JSON à ces points, pas automatiquement meilleures ou pires. Choisissez en fonction du contrat cible et des exigences de sécurité.

La compatibilité au niveau du schéma inclut les valeurs non finies et les balises temporelles que ce lecteur restreint limite ou refuse

Les données ordinaires en forme de JSON passent proprement à travers ce lecteur et graveur YAML 1.2. Des revendications plus larges concernant tous les documents ou analyseurs nécessitent des éléments couvrant les clés en double, les versions de schéma, les balises et les limites de ressources.

Utilisez des convertisseurs de syntaxe pour tester le texte réel et lire ses avertissements. Traitez « JSON is YAML » comme un raccourci utile uniquement après avoir nommé l'analyseur, le schéma et les fonctionnalités non prises en charge qui précisent la limite réelle.

Pour un test de portabilité, conservez un appareil entièrement dans le modèle de valeur de JSON et un autre qui ajoute une fonctionnalité uniquement YAML à la fois. Exécutez les deux via chaque consommateur prévu. La première mesure la revendication pratique du sous-ensemble ; la seconde identifie exactement où les commentaires, alias, flux, balises ou règles scalaires divergent. Cette méthode par étapes est plus informative que de demander si deux langages sont des sous-ensembles dans l'abstrait, car elle produit des échecs liés aux analyseurs réellement utilisés par votre système.