Convertir TOML vers JSON

Que fait le convertisseur TOML vers JSON ?

Le convertisseur lit TOML 1.0 et sort trois formats cibles — JSON, JSON5 ou YAML — selon pour quoi le résultat doit être réutilisé. Contrairement aux convertisseurs typiques qui poussent toutes les valeurs TOML dans un flux JSON plat, ce convertisseur conserve les informations structurelles qui distinguent TOML de JSON : quatre types datetime, commentaires et hiérarchie compréhensible.

Pure-client. Toute entrée reste dans votre navigateur. Pas d’inscription, pas de téléversement serveur, pas de tracking — vous pouvez le vérifier vous-même dans les DevTools onglet réseau.

Trois propriétés le distinguent des convertisseurs standard :

• Sidecar datetime. Les quatre types datetime TOML (avec/sans fuseau, juste date, juste heure) sont préservés via un wrapper {$type, value} — au retour JSON → TOML, le bon format est restauré.
• Préservation des commentaires. Qui choisit JSON5 comme sortie et active le toggle commentaires obtient les commentaires TOML # rendus comme lignes // aux bonnes positions JSON5.
• Indications Cargo/pyproject. Si votre TOML est un manifeste Cargo ou pyproject.toml, le convertisseur affiche des indications de sanity — champs obligatoires, clés inconnues — sans bloquer le fichier.

Comment fonctionne la fidélité datetime ?

TOML 1.0 distingue quatre types datetime, JSON ne connaît que des strings. Exemple : 2026-05-17 en TOML est un LocalDate, donc « ce jour, sans contexte de fuseau ». 2026-05-17T14:30:00+02:00 est une OffsetDateTime, donc « ce moment en heure d’été parisienne ». 14:30:00 est une LocalTime, donc « cette heure, sans date ». Si vous convertissez ces quatre types en JSON sans mesures spéciales, ils ne sont plus que des strings — la différence est perdue, le retour n’est plus univoque.

Le toggle sidecar datetime résout cela. S’il est actif, chaque valeur datetime est emballée dans un petit objet wrapper : {"$type":"toml/local-date","value":"2026-05-17"}. Les consommateurs JSON peuvent lire le wrapper s’ils veulent, ou simplement extraire .value. Au retour JSON → TOML, le convertisseur reconnaît le champ $type et restaure la syntaxe TOML correcte.

Qui n’a pas besoin du sidecar — par exemple parce que le JSON est lu à la main ou que les données vont en base de données qui accepte des strings ISO — désactive le toggle.

JSON, JSON5 ou YAML — quel format convient ?

JSON est le standard et le défaut. Pour la communication machine-à-machine, REST APIs et pipelines de données c’est le bon choix. La sortie est bytes-clean, conforme à la spec JSON et lisible par tout parser.

JSON5 est une extension pratique de la syntaxe JSON qui permet commentaires, virgules trailing et clés d’objet non quotées. Beaucoup d’outils de build (tsconfig.json TypeScript, config Babel, config Webpack) lisent JSON5 nativement. Si vous convertissez TOML en JSON5 et activez le toggle commentaires, vous obtenez un fichier au même contenu structurel que le TOML original, plus tous les commentaires # comme //.

YAML est l’alternative la plus populaire à TOML pour fichiers de configuration. Qui veut migrer de TOML à YAML (Kubernetes-configs, Ansible-playbooks, workflows GitHub-Actions) choisit YAML comme sortie. Le convertisseur strippe automatiquement les sidecars datetime, car YAML ne différencie pas les quatre types de timestamp — vous obtenez des strings ISO plains dans la sortie YAML.

Comment aident les indications Cargo.toml et pyproject.toml ?

Si le convertisseur reconnaît un bloc [package] (Rust) ou un bloc [project] (PEP 621), il affiche une bannière d’indication. La bannière est non bloquante — elle ne vous prescrit pas à quoi le manifeste doit ressembler, elle pointe juste sur des anomalies.

Indications Cargo (selon Cargo Manifest Reference) :

• name ou version manquants dans le bloc [package] — les deux sont obligatoires.
• edition mal typé — devrait être une string comme "2021", pas un entier.
• Clés top-level inconnues hors des tables standard Cargo ([dependencies], [dev-dependencies], [build-dependencies], [features], [workspace], [bin], [lib], [profile], [patch], [badges]).

Indications pyproject (selon PEP 621) :

• name manquant dans le bloc [project] — obligatoire.
• version manquante sans entrée dynamic = ['version'] — l’une des deux est nécessaire.
• requires-python manquant — recommandé mais pas obligatoire.
• Clés top-level inconnues hors de [project], [build-system], [tool], [dependency-groups].

L’idée : sanity-check rapide à l’écriture ou édition de manifestes, sans devoir appeler cargo check ou python -m build --dry-run localement.

Comment l’arbre de hiérarchie visualise-t-il la structure TOML ?

La plus grande faiblesse UX de TOML est la lisibilité des tables imbriquées. [server.database.replica] se lit au premier abord comme trois tables séparées mais est une seule hiérarchie profondément imbriquée. Avec beaucoup d’entrées [[products]], on perd vite la vue d’ensemble.

L’arbre de hiérarchie dans le panneau latéral résout cela. Dès que le TOML est parsé, l’arbre montre la structure complète comme arbre repliable avec badges de type : str, int, float, bool, table, aot[] pour Array-of-Tables, dt+offset / dt / date / time pour les quatre types datetime. Pour aot[], les éléments individuels apparaissent comme products[0], products[1] — vous voyez immédiatement quel élément porte quelle propriété.

Pour les longs strings, un preview est tronqué ("Lorem ipsum..." → "Lorem ipsum dolor sit am…").

Qu’est-ce qui n’est volontairement pas construit ?

• Pas de validation TOML contre des schémas complets. Les indications Cargo et pyproject sont des heuristiques — pas une validation complète. Qui en a besoin utilise cargo check ou validate-pyproject localement.
• Pas d’auto-fix de format TOML. Tri de clés, regroupement de tables, reformatage whitespace — tâches qu’un formatter dédié résout mieux.
• Pas de mode backwards-compat v0.5. TOML 0.5 avait des quirks (tableaux homogènes, autre syntaxe datetime). Nous parsons strict v1.0.
• Pas de pipeline server-side big-file. Pure-client signifie que le fichier est traité localement. Jusqu’à env. 10 Mo c’est sans souci dans tout navigateur moderne.
• Pas d’UI d’édition AST préservant la syntaxe. Qui change TOML programmatiquement et veut garder exactement le formatage original utilise un éditeur TOML comme Taplo localement.

Où trouver plus de détails ?

• Spec TOML 1.0 — la spécification officielle
• TOML sur Wikipédia — histoire et propriétés
• Spécification JSON5 — l’extension JSON avec commentaires
• Cargo Manifest Reference — manifeste Rust
• PEP 621 — standard pyproject.toml
• validate-pyproject — validation PEP 621 complète