YAML fonctionnalités perdues dans une conversion JSON : commentaires, ancres et balises

Le fichier est revenu plus longtemps et sans un seul commentaire — une configuration YAML convertie en JSON et inversement, et tout ce qui n'a pas survécu

Un fichier YAML peut revenir de JSON plus longtemps, même après la disparition de chaque commentaire. Les ancres qui partageaient un mappage sont résolues en données d'objet répétées, de sorte que le sérialiseur écrit chaque copie indépendamment. Les valeurs peuvent toujours être d'accord, mais la structure de création et l'explication ont disparu.

C'est pourquoi un aller-retour YAML-to-JSON-to-YAML doit être considéré comme une conversion de données et non comme une préservation de la source. ToolAcre lit un graphique de valeurs restreintes et écrit un nouveau document. Il ne conserve jamais d'arbre syntaxique concret contenant des commentaires, des noms d'ancres, des choix de citations ou une présentation scalaire en blocs.

Commentaires - pourquoi JSON n'a pas de place pour eux et chaque # ligne a disparu après la conversion

Les commentaires sont ignorés par l'analyseur YAML car JSON n'a pas de nœud de commentaire. Une ligne commençant par `#` peut expliquer pourquoi un délai d'attente existe ou à qui appartient un service ; une fois supprimé, aucun algorithme ne peut déduire le libellé ou l’emplacement. La reconversion crée un YAML valide sans ce contexte opérationnel.

Conservez le fichier d'origine dans le contrôle de version et examinez les différences avant de le remplacer. Si l'objectif est uniquement d'inspecter les valeurs résolues, JSON est utile. Si l'objectif est de reformater tout en conservant les commentaires, ce convertisseur de valeur générique n'est pas la bonne représentation.

Ancres et alias – &default et *default développés en copies répétées, et comment le fichier se développe en conséquence

Les ancres et les alias sont acceptés dans les limites de sécurité, puis résolus. `base: &b {x: 1}` et `copy: *b` deviennent deux chemins d'objet contenant `x: 1`. La sortie YAML utilise `noRefs`, donc l'identité d'objet partagé ne crée pas de nouvelles ancres. La relation compacte disparaît même lorsque les valeurs répétées survivent.

Les alias récursifs sont refusés car JSON ne peut pas exprimer de cycles. L'expansion des alias est limitée par le nombre d'alias, l'imbrication et une mesure des nœuds étendus ; un court document qui se transformerait en plus d'un million de valeurs est arrêté. Cela protège l'onglet sans réclamer un support arbitraire YAML.

Fusionner les clés — la convention << : de YAML 1.1, comment les analyseurs qui la prennent en charge aplatissent le mappage fusionné et ce qui se passe dans ceux qui ne le font pas

Le plan suppose que les clés de fusion YAML 1.1 sont aplaties. ToolAcre charge uniquement le schéma JSON ou Core de js-yaml, dont aucun n'active le type de fusion. Sous ces schémas, une clé `<<` est une donnée ordinaire plutôt qu'une instruction permettant de fusionner des mappages. Présenter une fusion aplatie comme un comportement expédié serait donc faux.

Si votre source dépend de la sémantique des clés de fusion, résolvez-la dans l'application qui possède cette convention ou réécrivez explicitement les valeurs avant la conversion. Un alias utilisé comme valeur de `<<` ordinaire peut toujours se résoudre en un objet, mais la clé reste `<<` ; cela n'équivaut pas à fusionner ses membres dans le parent.

Les clés de fusion ne sont pas activées par les deux schémas restreints fournis par ce convertisseur

Les balises explicites standard reconnues par le schéma restreint peuvent choisir des types de base, tels que `!!str` ou `!!int`. Les balises personnalisées et plus riches, notamment les constructeurs binaires, d'horodatage, d'ensemble, de carte ordonnée, de fonction JavaScript et d'objet Python, sont rejetées. Ils ne sont pas stringifiés et ne sont jamais exécutés.

Un flux YAML séparé par `---` est accepté. Un document devient une valeur ; plusieurs deviennent un tableau avec un avertissement indiquant le nombre de documents. Un séparateur de fin peut créer un document final vide selon le schéma sélectionné. Aucune cible ici n'a de modèle de flux, le tableau est donc une convention déclarée.

Les balises non sécurisées sont refusées ; les flux multidocuments deviennent des tableaux

Utilisez `defaults: &d` avec les tentatives et le délai d'attente, un commentaire expliquant le délai d'attente, puis `service:` avec `inherited: *d`. JSON contient à la fois les valeurs par défaut et un objet hérité répété ; le commentaire et le nom de l'ancre sont absents. La conversion de ce JSON émet deux mappages plutôt qu'une relation d'ancrage.

Ajoutez `---` suivi d'un autre document et la racine JSON devient un tableau de documents. Ajoutez `!!binary` et la conversion s'arrête avec un indice de schéma restreint. Ces trois changements distinguent les données prises en charge résolues, la convention structurelle et la construction purement non prise en charge.

Ce que cela ne couvre pas : l'ordre des clés et le style de citation, qui survivent généralement mais ne sont garantis par aucun des deux formats.

L'ordre d'insertion des objets ordinaires reste souvent visible, mais il ne s'agit pas d'une préservation de style source, et la sélection de clés de tri le modifie délibérément. Les citations, le style de flux par rapport au style de bloc, l’orthographe scalaire et les commentaires ne survivent pas. Les clés de mappage en double conservent la dernière valeur avec un avertissement plutôt que de conserver les deux entrées invalides.

L'auteur protège les chaînes ambiguës en citant des valeurs qu'un YAML 1.1 consommateur pourrait mal lire, mais ce choix de sécurité peut différer du style original de l'auteur. L'égalité des données est le test défendable pour les valeurs ordinaires en forme de JSON ; l’égalité textuelle ne l’est pas.

L'ordre des clés peut rester, tandis que les commentaires, les ancres, l'orthographe et le style des balises ne sont pas conservés.

YAML-to-JSON entraîne une perte chaque fois que le sens vit en dehors de la valeur en forme de JSON : commentaires, alias, balises non prises en charge, limites de flux en tant que telles et style. ToolAcre rend visible plusieurs pertes et refuse les constructions dangereuses ou cycliques plutôt que de prétendre les préserver.

Convertissez un fichier représentatif avant d'adopter le flux de travail. Inspectez les avertissements, comparez les valeurs résolues et conservez le YAML créé. Le panneau est un excellent aperçu de ce que voit un analyseur, mais il ne s'agit pas d'un éditeur préservant les commentaires ni d'un transformateur de modèle d'objet YAML complet.

Pour une révision de migration, séparez les modifications de valeur des modifications de source uniquement. Une comparaison approfondie JSON peut établir si des valeurs ordinaires ont survécu, tandis qu'une différence de texte révèle des commentaires, des ancres et un style qui ont nécessairement changé. Aucun des chèques ne remplace l’autre. Appeler la comparaison de valeurs sans perte ignorerait les informations source ; appeler chaque changement textuel un échec de données ignorerait la re-sérialisation valide.