Aller au contenu principal
ToolsByUs

JSON vers TOML

Ce convertit émet du TOML 1.0 à partir de JSON entièrement dans votre navigateur. Les clés scalaires sont écrites en premier, puis les [tables], puis les [[tableaux de tables]], afin que chaque définition précède les en-têtes qu’elle doit précéder. Les clés incompatibles avec TOML sont signalées, les nulls sont refusés avec un chemin nommé, et un tableau de niveau supérieur ne peut pas être converti — TOML n’a pas de racine anonyme.

100 % local

JSON vers TOML en clair

Le sens de la conversion est important : JSON est généralement généré par un programme — une charge utile d’API, un document stocké, l’état d’un outil de build — tandis que TOML est généralement lu par un humain qui configure quelque chose. Convertir JSON en TOML signifie donc repasser dans un format avec des règles de placement réelles, et la plus importante est invisible jusqu’à ce qu’elle cause des problèmes : dans TOML, la position d’une clé dans le fichier décide à quelle table elle appartient. Écrire retries = 3 après une en-tête [servers] fait qu’elle devient silencieusement une clé de servers, et non de la racine.

Ce convertit émet les clés scalaires en premier, puis les [tables], puis les [[tableaux de tables]], afin que chaque paire clé/valeur soit écrite sous l’en-tête qui lui correspond et que chaque table soit entièrement définie avant que l’en-tête suivant ne s’ouvre. Les objets JSON deviennent des tables, les tableaux d’objets deviennent des tableaux de tables, les tableaux de scalaires restent sous forme de tableaux en ligne, et chaque valeur est émise avec le type TOML 1.0 qu’elle a déjà — il n’y a pas d’étape d’inférence qui puisse être erronée.

Tout se passe dans cet onglet de navigateur. Le JSON que vous collez est analysé avec le JSON.parse du navigateur, le TOML est construit à partir de ce document en mémoire, et rien ne traverse le réseau — le panneau Réseau dans DevTools reste vide pendant que vous travaillez, et la Content-Security-Policy de la page maintient cet état.

La conversion inverse est plus courante — lire un Cargo.toml dans un script — et la convertir TOML en JSON page la gère, en conservant les datetimes comme chaînes de caractères, tout comme celle-ci les reçoit.

Si le JSON provient d’un script plutôt que d’un formateur, passez-le par le Validateur JSON d’abord — un document qui n’y parvient pas échouera ici aussi, avec le même message.

Pourquoi les scalaires viennent en premier, puis les tables, puis les tableaux

La règle de placement de TOML est la raison pour laquelle la sortie est ordonnée de cette manière. Les clés écrites après une en-tête [table] appartiennent à cette table, et les clés écrites après une en-tête [[tableau de tables]] appartiennent à sa dernière entrée — un émetteur qui entrelacerait des scalaires et des en-têtes produirait un fichier qui se analyse avec succès dans une structure erronée. Émettre les paires clé/valeur d’un niveau d’abord, puis ses sous-tables, puis ses tableaux de tables, est le seul ordre qui permet un aller-retour, et la même règle s’applique récursivement à l’intérieur de chaque table imbriquée.

Les chaînes de caractères ont leur propre règle : tout est émis comme une chaîne de base TOML entre guillemets doubles, avec les barres obliques, les guillemets et les caractères de contrôle échappés comme le définit TOML 1.0. Le convertit ne passe pas en chaînes littérales pour économiser la ponctuation, car décider quand une barre oblique est littérale est précisément la supposition qu’un convertit ne doit pas faire. Les clés suivent la même discipline, donc une clé comme port : 8080 arrive entre guillemets et sans ambiguïté.

Le mappage de JSON vers TOML

Chaque forme gérée par le convertit, et sa destination TOML 1.0 :

JSONTOML en sortie
ObjetEn-tête [table], clés en dessous
Tableau d’objetsEntrées de [[tableau de tables]], une par objet
Tableau de scalairesTableau en ligne : ["rapide", "sûr"]
Chaîne de caractèresChaîne de base avec échappements standards
Clé avec un point ou un espaceClé entre guillemets : "app.name" = 1
nullRefusé — TOML 1.0 n’a pas de null

À quoi ressemble la sortie

L’exemple ci-dessous est la paire exacte que produit le bouton Charger l’exemple du convertit : un objet racine avec deux scalaires et un tableau de tags en ligne, un objet owner imbriqué, et un tableau servers contenant deux objets. Notez l’ordre — les paires clé/valeur simples de la racine, y compris tags, apparaissent toutes avant [owner], et les deux entrées servers se retrouvent sous une famille d’en-têtes [[servers]] dans l’ordre du tableau. Cet ordre n’est pas cosmétique ; c’est ce qui permet au fichier de se réanalyser dans la même structure.

La même normalisation s’applique que partout ailleurs dans cette famille : la sortie est générée à partir du document analysé, donc les particularités d’indentation du JSON source sont préservées en sens et en ordre des clés, mais sont réimprimées dans un style TOML cohérent qu’un réviseur peut comparer.

Cas limités que ce convertit refuse plutôt que d’altérer

Certaines entrées n’ont pas de représentation fidèle en TOML 1.0, et faire semblir le contraire vous donnerait un fichier de configuration qui ment :

  • Un tableau ou scalaire de niveau supérieur — les documents TOML sont toujours une table racine de paires clé/valeur, donc un fichier JSON dont le niveau supérieur n’est pas un objet est refusé avec un message clair.
  • Tout null, n’importe où — TOML 1.0 n’a pas de null, donc le convertit le refuse et nomme le chemin exact, vous laissant supprimer la clé ou choisir une valeur délibérément.
  • Clés qui semblent avoir des points — une clé nue a.b se analyserait comme une clé avec point et atterrirait dans une table imbriquée, donc de telles clés sont émises comme des chaînes de base entre guillemets, et l’aperçu les signale pour que vous puissiez repérer les noms qui étaient probablement destinés à être imbriqués.

Questions fréquentes

Mon JSON est-il envoyé à un serveur pendant la conversion ?

Non. La conversion s’exécute entièrement dans cet onglet de navigateur : JSON.parse et l’écrivain TOML sont du JavaScript local à la page, chargé une fois à l’ouverture. Il n’y a pas de point d’envoi, et la Content-Security-Policy interdit à la page d’ouvrir des connexions. DevTools le prouve — observez le panneau Réseau rester vide quel que soit le nombre de conversions.

Pourquoi les scalaires doivent-ils être écrits avant les en-têtes [table] ?

Dans TOML, chaque clé après une en-tête [servers] appartient à servers, donc entrelacer des scalaires et des en-têtes changerait la signification du fichier tout en continuant à se analyser correctement. Écrire les paires clé/valeur d’un niveau d’abord, puis ses sous-tables et tableaux de tables, est le seul ordre qui se réanalyse dans la structure de départ — c’est une question de correction, pas de style.

Que fait le convertit avec les JSON null ?

Il les refuse. TOML 1.0 n’a pas de valeur null — le langage n’offre aucune orthographe pour cela — donc aucune émission fidèle n’est possible. Le convertit signale le chemin exact de la clé problématique, comme owner.middle, et s’arrête. Supprimer la clé, ou la remplacer par une chaîne sentinelle, est votre décision plutôt qu’une supposition silencieuse intégrée dans la sortie.

Les tableaux sont-ils convertis ?

Selon leur contenu. Un tableau dont chaque élément est un objet devient un [[tableau de tables]], une entrée par objet. Un tableau de scalaires ou de valeurs mixtes devient un tableau en ligne TOML sur une seule ligne, et un tableau vide est émis comme []. Rien n’est aplati ou remodelé — le convertit rend la structure qui lui a été donnée, ce qui rend le résultat prévisible.

Que devient-il des clés avec des points, des espaces ou des deux-points ?

Les clés nues TOML n’autorisent que les lettres, les chiffres, les traits de soulignement et les traits d’union, donc tout le reste doit être une clé entre guillemets. Ce convertit émet de telles clés comme des chaînes de base — "app.name" = 1 — ce que TOML 1.0 définit comme une seule clé, et non un chemin avec points. L’aperçu signale les clés entre guillemets pour que vous puissiez voir quels noms étaient probablement destinés à être imbriqués et les renommer manuellement.

Puis-je obtenir de vraies datetimes TOML à partir d’une chaîne JSON ?

Pas par conversion, et honnêtement ainsi. JSON n’a pas de type date, donc le convertit ne peut pas savoir si "1979-05-27T07:32:00Z" est un timestamp ou une phrase qui ressemble à un timestamp ; chaque chaîne est émise comme une chaîne de base entre guillemets. Si vous voulez une datetime TOML nue, supprimez les guillemets dans la sortie manuellement — le texte est déjà du RFC 3339 valide.

Équipe ToolsByUs · Comment nous vérifions nos outils