Convertir JSON en TOML en Ligne
Convertis du JSON en TOML (Cargo.toml, Hugo, Netlify) gratuitement, dans ton navigateur.
title = "My Project" version = "1.0.0" features = ["async", "json"] [dependencies] serde = "1.0" tokio = "1.28" [[authors]] name = "John" email = "john@example.com"
Cas d'usage
JSON vers TOML pour Rust, Hugo et la configuration moderne
Cargo.toml pour Rust
Convertis les dependances ou la configuration JSON au format de manifeste de crate standard de Rust.
Hugo et Netlify
Front matter et configuration pour les sites Hugo, netlify.toml et les configurations CI/CD.
pyproject.toml (PEP 518)
Migre la configuration de projets Python de JSON vers le format pyproject.toml standard.
100% prive
La conversion s'effectue dans ton navigateur. Ton code et ta configuration ne quittent jamais ton appareil.
Comment ça marche
Trois étapes, sans complications
Colle ou charge ton JSON
Colle le contenu JSON dans l'editeur ou charge le fichier .json. Sans inscription, sans limites.
Conversion automatique
Le JSON est converti en syntaxe TOML valide dans ton navigateur. Aucun serveur, aucune transmission de donnees.
Copie ou telecharge le TOML
TOML pret a utiliser comme Cargo.toml, configuration Hugo, netlify.toml ou pyproject.toml.
FAQ
Des questions ?
TOML (Tom's Obvious, Minimal Language) a ete cree par Tom Preston-Werner, cofondateur de GitHub, en 2013. Preston-Werner l'a concu car il trouvait YAML trop ambigu et JSON trop verbeux et delicat a editer a la main comme format de configuration. TOML a atteint la version 1.0 en janvier 2021 apres des annees de developpement et de revisions. Son objectif est d'etre un format de configuration evident a lire pour les humains et sans ambiguite pour les machines. Aujourd'hui c'est le format de configuration standard de l'ecosysteme Rust (Cargo.toml), du generateur de sites statiques Hugo, et il est defini comme format officiel pour les metadonnees de paquets Python dans PEP 518 (pyproject.toml).
JSON est precis et universel mais peu pratique pour la configuration ecrite a la main : il n'autorise pas les commentaires, exige des guillemets sur toutes les cles et interdit les virgules finales. YAML est plus lisible mais a une specification notoirement complexe avec plusieurs facons d'exprimer la meme chose, et des erreurs d'indentation peuvent silencieusement changer le sens du fichier. TOML occupe le juste milieu : il utilise une syntaxe de sections [table] et cle = valeur familiere a quiconque a edite des fichiers .ini, prend en charge les commentaires avec #, ne depend pas de l'indentation comme YAML, et a une specification compacte (la version 1.0 fait moins de 5000 mots). La limitation de TOML est qu'il n'est pas adapte aux donnees profondement imbriquees ou aux structures de donnees polyvalentes.
Cargo.toml est le fichier manifeste de chaque crate (paquet) en Rust. Il definit le nom du paquet, la version suivant semver, les auteurs, l'edition Rust et les dependances. La section [dependencies] est l'endroit ou les bibliotheques externes sont declarees avec leurs versions : par exemple, serde = { version = '1.0', features = ['derive'] }. Cargo, le gestionnaire de paquets de Rust, lit ce fichier pour resoudre l'arbre de dependances, telecharger les paquets depuis crates.io et compiler le projet. Si tu as une configuration de dependances en JSON et dois la migrer vers un projet Rust, ce convertisseur genere le TOML correct.
Hugo, le generateur de sites statiques base sur Go, prend en charge trois formats de front matter pour les pages de contenu : YAML (delimite par ---), TOML (delimite par +++) et JSON (delimite par { }). Le front matter TOML dans Hugo ressemble a : +++\ntitle = 'Mon article'\ndate = 2024-01-15T10:00:00Z\ntags = ['go', 'hugo']\ndraft = false\n+++. Si tu as du front matter en JSON et veux le migrer vers la convention TOML preferee par de nombreux themes Hugo, ce convertisseur gere la transformation en quelques secondes.
pyproject.toml est le fichier de configuration standard pour les projets Python, defini dans PEP 518 (2016) et etendu par PEP 517, PEP 621 et PEP 660. Il remplace l'ancien setup.py et setup.cfg par un seul fichier declaratif. Le comite directeur Python a choisi TOML apres avoir evalue YAML, JSON et d'autres formats : YAML a ete rejete pour sa specification complexe et ses comportements surprenants, JSON pour l'absence de commentaires. La section [build-system] definit le backend de build (setuptools, flit, hatch, poetry), [project] definit les metadonnees du paquet, et les sections [tool.ruff] ou [tool.mypy] configurent les outils de developpement.
TOML gere bien deux ou trois niveaux d'imbrication via les tables : [database.server] cree un objet imbrique. Pour une imbrication plus profonde, TOML utilise les tables en ligne : { host = 'localhost', port = 5432 }. Cependant, du JSON avec des objets imbriques sur plus de trois ou quatre niveaux peut devenir verbeux et peu naturel en TOML. Le cas specifique que TOML ne gere pas elegamment est un tableau d'objets avec plusieurs proprietes : TOML necessite la syntaxe [[table.array]] avec des sections repetees. Si ton JSON a des structures profondement imbriquees pensees pour des donnees plutot que de la configuration, demande-toi si TOML est le bon format cible ou si YAML serait plus approprie.
Convertir JSON en TOML : Cargo.toml, Hugo, Netlify et pyproject.toml
TOML (Tom's Obvious, Minimal Language) a ete cree en 2013 par Tom Preston-Werner, cofondateur de GitHub, createur de Jekyll (le generateur de sites statiques qui a propulse GitHub Pages et popularise le concept JAMstack avant qu'il porte ce nom), et auteur de la specification Semantic Versioning sur semver.org. Preston-Werner a concu TOML comme une reponse directe et articulee aux frustrations vis-a-vis des formats de configuration existants. YAML, malgre sa lisibilite superficielle, a une specification de plus de 80 pages incluant de multiples facons equivalentes et souvent surprenantes d'exprimer la meme donnee. Un fichier YAML mal indente peut changer completement de sens sans generer aucune erreur d'analyse, ce qui le rend dangereux pour les configurations d'infrastructure. JSON, quant a lui, est precis et universel mais presente des limitations critiques pour les configurations ecrites et maintenues par des humains : il n'autorise aucun commentaire, exige des guillemets doubles sur toutes les cles, interdit les virgules finales dans les tableaux et objets, et n'offre pas de syntaxe pratique pour les structures de sections hierarchiques. TOML resout tous ces problemes avec une syntaxe de sections [table] et cle = valeur familiere, le support des commentaires avec #, aucune dependance a l'indentation, un support natif explicite pour les dates et horodatages conforme a RFC 3339, et une specification complete arrivee a sa version stable 1.0.0 en janvier 2021 apres huit annees de developpement iteratif.
L'ecosysteme le plus important et le plus actif de TOML en pratique est Rust et son gestionnaire de paquets Cargo. Cargo, le systeme de build et gestionnaire de paquets officiel de Rust (present dans le toolchain depuis la premiere version stable de Rust en mai 2015), utilise Cargo.toml comme format de manifeste pour chaque crate. Un Cargo.toml typique contient : la section [package] avec le nom, la version (semver obligatoire), les auteurs, l'edition (2015, 2018 ou 2021), la description, la licence et l'URL du depot ; la section [dependencies] avec les dependances de production specifiant les contraintes de version et les feature flags optionnels ; [dev-dependencies] pour les dependances de tests uniquement ; [build-dependencies] pour les scripts build.rs ; [features] pour les capacites optionnelles du crate. Crates.io, le registre officiel de paquets Rust, compte plus de 140 000 crates publies. Netlify a adopte TOML pour son fichier netlify.toml qui definit les regles de build, les en-tetes HTTP personnalises par chemin, les regles de redirection et de reecriture avec support regex, la configuration des fonctions serverless et des Edge Functions, ainsi que les variables d'environnement par contexte de deploiement.
Python a adopte TOML comme format officiel de configuration de projets a travers une serie de PEPs allant de 2016 a aujourd'hui. PEP 518 (mai 2016) a introduit pyproject.toml avec la section [build-system]. PEP 517 (septembre 2017) a formalise l'interface standard entre les frontends d'installation (pip, build) et les backends de build (setuptools, flit, hatch, poetry). PEP 621 (novembre 2020) a standardise les metadonnees du paquet dans la section [project]. Les sections [tool.nom_outil] permettent a chaque outil de l'ecosysteme de stocker sa configuration sans conflits : [tool.ruff] pour le linter et formateur Ruff (le plus rapide de l'ecosysteme, ecrit en Rust), [tool.mypy] pour le verificateur de types mypy, [tool.pytest.ini_options] pour pytest, [tool.black] pour le formateur Black. Avant pyproject.toml, la configuration d'un projet Python typique etait fragmentee entre setup.py, setup.cfg, tox.ini, .flake8, mypy.ini et d'autres fichiers independants. pyproject.toml a tout unifie dans un seul fichier declaratif, lisible et annotable avec des commentaires. Convertir des donnees de configuration JSON en TOML est l'etape naturelle quand ces configurations necessitent une maintenance humaine continue.