Aller au contenu principal
ToolsByUs

TOML vers JSON

Rien n’est envoyé : ce convertisseur analyse le TOML 1.0 dans votre navigateur et émet du JSON. Les tables deviennent des objets, les entrées [[tableau de tables]] deviennent des tableaux d’objets, les datetimes RFC 3339 sont conservées sous forme de chaînes, et les clés dupliquées génèrent une erreur numérotée au lieu d’être fusionnées silencieusement. Le JSON suit la RFC 8259.

100 % local

TOML vers JSON en clair

TOML occupe un créneau spécifique : c’est le format de configuration de Cargo.toml, pyproject.toml et une centaine de gestionnaires de paquets, choisi parce qu’un humain peut le modifier sans le casser. JSON occupe un autre — c’est ce que les programmes échangent. Tôt ou tard, un script, un fichier de test ou une API voudra votre TOML sous forme de JSON, et cette conversion pose exactement deux questions mécaniques : comment un en-tête [table] devient-il un objet JSON, et comment un en-tête [[tableau de tables]] devient-il un tableau JSON ?

Le mappage est déterministe. Un [tableau] et ses clés deviennent un objet imbriqué ; les clés pointées comme database.port deviennent également des objets imbriqués ; un [[tableau de tables]] devient un tableau avec un objet par en-tête. Les scalaires de TOML se mappent directement — les booléens restent booléens, les entiers et flottants restent des nombres, et les traits de soulignement que TOML autorise pour la lisibilité disparaissent, car 1_000_000 et 1000000 sont le même nombre. Les datetimes RFC 3339 n’ont pas de type JSON, donc elles arrivent sous forme de chaînes avec leur texte préservé exactement.

Tout s’exécute dans cet onglet de navigateur. Le texte TOML que vous collez est analysé par un moteur en page, le JSON est sérialisé depuis le document analysé, et aucun des deux ne touche au réseau — ouvrez DevTools et observez que le panneau Réseau reste silencieux pendant que vous convertissez. La Content-Security-Policy de la page interdit les connexions sortantes, donc l’affirmation sur la confidentialité est vérifiable plutôt que décorative.

Le cycle complet est le flux de travail courant — extraire la configuration d’une charge, la modifier, la remettre — et la convertir JSON en TOML page exécute ce mappage à l’envers, d’abord pour les scalaires.

Le JSON que cet outil émet est compact par défaut, donc si vous le voulez indenté pour la lecture, le formateur JSON le réimprimera avec l’espacement de votre choix.

Comment la conversion fonctionne réellement

Le moteur analyse votre TOML en un arbre de document d’abord, car chaque décision JSON découle des règles de portée propres à TOML : un en-tête [table] ouvre un objet nommé, un en-tête [[tableau de tables]] ajoute un nouvel objet à un tableau nommé, et les clés au-dessus de tout en-tête appartiennent à l’objet racine. Une fois l’arbre existant, l’émission de JSON est une simple sérialisation — les seuls jugements sont les endroits où TOML et JSON sont en désaccord, et chaque décision est prise de la même manière à chaque fois :

  • Tables : [owner] avec une clé name produit un objet owner — les en-têtes de TOML et les accolades de JSON codent la même imbrication.
  • Tableaux de tables : chaque en-tête [[servers]] ajoute un objet à un tableau servers, dans l’ordre du fichier.
  • Clés pointées : database.port = 5432 se imbrique sous database, exactement comme TOML 1.0 définit que les clés pointées se comportent.
  • Datetimes : 1979-05-27T07:32:00Z n’a pas de type JSON, donc il est émis comme la chaîne "1979-05-27T07:32:00Z", octet par octet.
  • Nombres : les traits de soulignement sont de la ponctuation TOML, pas des données — 1_000_000 est émis comme 1000000 — et inf et nan de TOML deviennent null, car JSON n’a pas de littéral pour l’un ni l’autre.

À quoi ressemble la sortie

L’exemple ci-dessous est la paire exacte que produit le bouton Charger l’exemple du convertisseur : une racine avec trois clés scalaires (dont une avec trait de soulignement), un tableau [issuer], et deux entrées [[items]]. Observez chaque forme traverser — les traits de soulignement disparaissent dans le nombre, le tableau issuer s’imbrique comme un objet, et le tableau items rassemble ses objets dans l’ordre du fichier. Les clés restent dans l’ordre déclaré par le TOML, car l’ordre du document est le seul ordre qu’un convertisseur peut garder honnêtement.

Comme le JSON est émis depuis l’arbre analysé plutôt que par découpage textuel, le formatage est également normalisé : deux styles d’espacement dans le TOML produisent un JSON cohérent, et une ligne vide isolée ne change rien. Ce qui survit est la structure et les valeurs — ce qui est exactement ce qu’un convertisseur doit promettre.

Clés dupliquées et autres échecs honnêtes

Un convertisseur honnête refuse les entrées qu’il ne peut représenter fidèlement, et TOML 1.0 est assez strict pour que ces refus soient rares et univoques. Trois entrées sont rejetées avec un message spécifique, numéroté par ligne, au lieu d’être remodelées silencieusement :

  • Clés dupliquées — TOML 1.0 interdit de définir une clé plus d’une fois, donc l’analyseur s’arrête à la ligne problématique au lieu de laisser la dernière écraser silencieusement votre configuration.
  • Chaînes multilignes — le sous-ensemble pris en charge par cet analyseur couvre les chaînes de base et littérales sur une seule ligne ; un bloc """ est refusé avec un message qui le dit exactement, au lieu d’une tentative déformée.
  • Constructeurs non fermés — un en-tête [table] ou une chaîne entre guillemets qui ne se termine jamais signale la ligne où l’analyseur a abandonné, pas une erreur syntaxique générique.

Le mappage en un coup d’œil

Chaque constructeur que ce convertisseur prend en charge, et où il atterrit dans le JSON :

TOML 1.0JSON en sortie
[owner] tableObjet "owner" imbriqué
[[items]] en-têteTableau "items" d’objets
clé pointée database.portObjet "database" imbriqué
1979-05-27T07:32:00ZChaîne, texte RFC 3339 préservé
1_000_000Nombre 1000000
'chaîne littérale'Chaîne, antislashes intacts

Questions fréquentes

La conversion de TOML en JSON envoie-elle mon fichier quelque part ?

Non. L’analyse et la sérialisation s’exécutent toutes les deux dans cet onglet de navigateur avec du JavaScript qui s’est chargé quand la page a ouvert. Il n’y a pas de route API pour envoyer des données, et la Content-Security-Policy bloque les connexions sortantes. Vous pouvez vérifier les deux affirmations en quelques secondes : ouvrez DevTools, observez le panneau Réseau pendant que vous convertissez, et voyez qu’aucune requête n’est envoyée.

Que devient les datetimes TOML dans la sortie JSON ?

Elles deviennent des chaînes. JSON (RFC 8259) n’a aucun type date ou datetime — seulement chaîne, nombre, booléen, null, objet et tableau — donc 1979-05-27T07:32:00Z est émis comme la chaîne exacte "1979-05-27T07:32:00Z". Rien n’est reformatté ou décalé dans le fuseau horaire ; le texte survit octet par octet, et votre code en aval le parse quand il a besoin d’une vraie date.

Comment [[tableau de tables]] diffère-t-il de [table] ?

Les crochets doubles ajoutent, les crochets simples définissent. [servers] crée un objet nommé servers ; un deuxième en-tête [servers] serait une erreur de clé dupliquée. [[servers]] crée un tableau et ajoute un objet par en-tête, donc trois blocs [[servers]] deviennent un tableau à trois éléments. La distinction simple/double est toute la différence, c’est pourquoi ce convertisseur la préserve aussi dans la direction inverse.

Pourquoi une clé dupliquée est-elle une erreur au lieu d’un écrasement ?

Parce que TOML 1.0 déclare que définir une clé plusieurs fois est invalide, et un convertisseur qui résoudrait le conflit certifierait un fichier que sa propre spécification rejette. L’erreur cite le numéro de ligne de la deuxième définition, qui est généralement la faute de frappe ou la mauvaise fusion dont vous aviez besoin de trouver de toute façon.

Mon TOML utilise des chaînes multilignes entre guillemets triples — pourquoi l’erreur ?

Cet analyseur prend en charge un sous-ensemble documenté de TOML 1.0 : chaînes de base sur une ligne, chaînes littérales sur une ligne, entiers, flottants, booléens, datetimes, tables, tableaux de tables et clés pointées. Les chaînes multilignes sont en dehors du sous-ensemble et sont rejetées avec un message clair nommé plutôt qu’analysées partiellement. Divisez la valeur en une chaîne sur une ligne avec des échappements \n et elle se convertit proprement.

Que sont devenus mes valeurs inf et nan ?

TOML autorise les flottants inf et nan, mais JSON n’a de littéral pour aucun des deux — JSON.parse ne peut pas les produire et JSON.stringify écrit null. Le convertisseur émet null pour ces deux valeurs et les signale dans l’aperçu, car transformer silencieusement l’infini en un nombre fini apparent est le genre de mensonge qui coûte des heures à retracer.

Équipe ToolsByUs · Comment nous vérifions nos outils