Convertisseur JSON vers TOML

Convertit un objet JSON en document conforme à TOML 1.0 via @iarna/toml. Les objets imbriqués deviennent des en-têtes `[section]` ; les tableaux d'objets deviennent des blocs tableau-de-tables `[[items]]` ; chaînes, nombres, booléens et chaînes date-heure ISO 8601 mappent vers des primitives TOML. La sortie est triée vers un ordre canonique — les clés apparaissent avant les sous-tables pour la compatibilité avec les parsers TOML stricts.

Exemple

Entrée JSON :

{
  "name": "Ada",
  "active": true,
  "address": {
    "city": "London"
  }
}

Sortie TOML :

name = "Ada"
active = true

[address]
city = "London"

Pièges courants JSON vers TOML

TOML a des règles de niveau supérieur plus strictes que JSON. Les motifs ci-dessous expliquent pourquoi une valeur JSON qui « devrait fonctionner » peut échouer.

• Tableau au niveau supérieur. TOML ne peut pas représenter un tableau JSON de niveau supérieur. Encadrez-le : `{"items": [...]}`. Le résultat devient un tableau-de-tables TOML sous `[[items]]`.
• Scalaire au niveau supérieur. Un document JSON nu `42` ou `"hello"` n'a pas de clé à laquelle se rattacher en TOML. Encadrez-le dans un objet : `{"value": 42}`.
• Valeurs null. TOML n'a pas de type null. Le sérialiseur omet entièrement les clés dont la valeur JSON est null. Si vous devez représenter « explicitement rien », utilisez une chaîne vide `""` ou une valeur sentinelle, selon votre code aval.
• Tableaux à types mixtes. TOML 1.0 permet `[1, "two"]`, mais pas les parsers legacy 0.5. Si votre TOML doit faire un aller-retour via du tooling 0.5, gardez les tableaux homogènes dans le JSON avant la conversion.
• Clés avec des points dans la sortie TOML. Une clé JSON comme `"my.key"` devient un chemin de "clé pointée" TOML, que les parsers TOML interpréteront comme imbriqué. Pour préserver un point littéral dans le nom de clé, le sérialiseur le guillemète : `"my.key" = ...` — mais les consommateurs peuvent encore le parser comme chemin.
• NaN / Infinity. TOML 1.0 supporte les littéraux `nan`, `inf`, `-inf`. JSON ne les représente pas — ils arrivent typiquement comme les chaînes `"NaN"`, `"Infinity"`, etc. Convertissez manuellement si vous avez besoin des vrais spéciaux float TOML.

Comment les dates sont-elles représentées ?

Les dates JSON sont des chaînes ISO 8601, p. ex. `"2026-04-26T12:00:00Z"`. Le sérialiseur les conserve comme chaînes en TOML — pas comme types datetime natifs. Pour obtenir un datetime TOML natif, il faudrait pré-traiter et émettre la valeur avec le bon marqueur de type côté JavaScript.

Les objets profondément imbriqués sont-ils aplatis ?

Non — ils deviennent des en-têtes imbriqués `[a.b.c]`. Chaque niveau d'imbrication devient un chemin d'en-tête joint par des points. Pour des structures très profondes, la sortie peut avoir de longues lignes d'en-tête ; c'est juste comment TOML exprime la profondeur.

L'ordre des clés sera-t-il préservé ?

Principalement. Le sérialiseur canonicalise l'ordre pour que les primitives viennent avant les sous-tables (règle TOML). Au sein de chaque niveau, l'ordre d'insertion JSON est préservé.

Comment obtenir une table inline TOML en sortie ?

Vous ne pouvez pas — le sérialiseur utilise toujours des en-têtes de bloc `[section]`, jamais des tables inline. Si vous avez besoin d'une sortie inline, post-traitez le résultat. Les tables inline sont une caractéristique de lisibilité TOML, pas une forme de données différente.

Mon JSON est-il téléchargé ?

Non. Tout s'exécute dans votre navigateur — votre entrée est parsée et sérialisée par JavaScript sur cette page et n'est jamais envoyée à un serveur.

Puis-je faire un aller-retour JSON → TOML → JSON ?

Pour les types supportés (chaîne, nombre, booléen, objet imbriqué, tableau d'objets), oui. Les aller-retours perdent les valeurs null (TOML n'a pas de null) et peuvent normaliser l'ordre des clés.