YAML to TOML Converter

No. Both formats support `#` line comments, but comments are trivia attached to the source text, not to the data model. The converter parses YAML into mappings, sequences, and scalars, then re-serializes that structure as TOML — any `#` comments in the original YAML are discarded in the process and won't appear in the TOML output.

YAML lets you write a mapping or sequence inline, like `{host: localhost, port: 5432}` or `[web, production]`, as an alternative to multi-line block style. TOML has a direct equivalent — inline tables (`{ host = "localhost", port = 5432 }`) and inline arrays (`["web", "production"]`). Since flow and block YAML parse to the identical data structure, the converter treats them the same way regardless of which style the source file used.

Yes. TOML's spec doesn't require any particular key order for two documents to be considered equivalent, but the converter still emits keys in the order they appeared in the YAML source, since standard parsers (PyYAML, js-yaml, ruamel.yaml) retain document order by default — this keeps diffs against the original file predictable.

TOML restricts unquoted ("bare") keys to ASCII letters, digits, underscores, and dashes. A YAML key like `first name` (a space) or `api.version` (a literal dot, which TOML would otherwise read as nested-table notation) doesn't fit that grammar, so the converter wraps it in quotes instead — producing `"first name" = "Jane"` — which TOML's spec defines as an equally valid alternative to a bare key.

Oui, mais ce qui se perd, c'est la relation, pas la donnée. Les ancres YAML (`&nom`) marquent un bloc comme réutilisable, et les alias (`*nom`) copient ce contenu ailleurs dans le même document — un usage courant pour des valeurs par défaut partagées, par exemple une ancre `&defaults` fusionnée dans plusieurs configurations d'environnement via `<<: *defaults`. TOML n'a aucune notion d'ancre, d'alias ou de clé de fusion, donc avant d'émettre le TOML, le convertisseur résout chaque alias vers sa valeur littérale développée. Le résultat est équivalent en données — chaque champ conserve la même valeur — mais la « source unique de vérité » disparaît : si le bloc ancré changeait, vous le mettiez auparavant à jour une seule fois en YAML, alors qu'en TOML vous devez désormais modifier plusieurs tables indépendantes à la main. Les fichiers YAML multi-documents (plusieurs documents séparés par `---`) se heurtent au même mur pour une raison différente : un fichier TOML ne représente qu'un seul document, donc seul un document YAML survit à la conversion.

Généralement parce qu'une chaîne d'outils spécifique exige TOML et n'accepte pas YAML comme substitut. Cargo, l'outil de Rust, lit `Cargo.toml` ; Poetry, Hatch et PDM, en Python, lisent `pyproject.toml` ; Hugo accepte le front matter en TOML dans ses fichiers de contenu ; et tout outil construit sur la crate `toml` de Rust ou la bibliothèque BurntSushi/toml de Go attend spécifiquement du TOML. Les équipes qui gèrent déjà leur infrastructure ou leur configuration CI en YAML — playbooks Ansible, workflows GitHub Actions, manifestes Kubernetes — ont parfois besoin d'extraire certaines valeurs (noms de services, ports, versions figées) de ces fichiers pour les intégrer dans un projet ou un manifeste de package basé sur TOML, sans retaper chaque champ à la main ni revérifier guillemets et types. Faire passer le fragment YAML source par un convertisseur est plus rapide et moins sujet aux erreurs que de retranscrire manuellement des clés imbriquées en tables TOML entre crochets, surtout pour des blocs de configuration volumineux comportant plusieurs niveaux d'imbrication.

YAML est le format le plus ancien, de plus d'une décennie : la version 1.0 a été publiée en 2004 par Clark Evans, Ingy döt Net et Oren Ben-Kiki, et la révision actuelle, YAML 1.2.2, a été finalisée en 2021 et définit YAML comme un sur-ensemble strict de JSON. TOML est plus récent et a été créé en 2013 par Tom Preston-Werner, cofondateur de GitHub, spécifiquement pour offrir un format de configuration minimal et non ambigu — une alternative à la fois à la complexité de YAML et au manque de standardisation d'INI. Cargo, le gestionnaire de paquets de Rust, en a été l'un des premiers adoptants influents, ce qui a contribué à établir TOML comme choix par défaut pour Rust puis pour les manifestes de packaging Python. TOML a atteint sa première version stable, la v1.0.0, en 2021, la même année que la dernière révision de YAML — les deux spécifications que vous convertissez aujourd'hui sont donc toutes deux dans leur version stable la plus récente.

Non — malgré des similitudes ponctuelles, les deux formats ont été conçus indépendamment, et la syntaxe de TOML se rapproche davantage des fichiers INI (en-têtes `[section]`, lignes `clé = valeur`) que du style bloc de YAML fondé sur l'indentation. TOML n'a volontairement aucune notion de style en ligne versus style bloc, aucune ancre ni alias, aucun tag de type personnalisé, et aucun fichier multi-document — il vise une seule et unique façon d'écrire une structure donnée, ce qui est précisément ce qui permet à ce convertisseur de transformer les mappings imbriqués de YAML en tables TOML de manière déterministe. La relation ne fonctionne proprement que dans un sens : tout document TOML valide peut être réexprimé en YAML sans aucune perte, mais l'inverse n'est pas vrai, puisque l'ensemble des fonctionnalités de YAML est un sur-ensemble strict de ce que la grammaire de TOML est capable d'exprimer.

Proprement, car les deux formats les traitent comme des types natifs plutôt que comme de simples chaînes de caractères. Le schéma central de YAML reconnaît les scalaires d'horodatage comme `2024-01-15` ou `2024-01-15T10:30:00Z` et les étiquette comme des dates plutôt que du texte ; TOML v1.0.0 définit quatre types de date/heure distincts — date-heure avec décalage, date-heure locale, date locale et heure locale — chacun avec sa propre grammaire. Le convertisseur associe un horodatage YAML à celui des quatre types TOML qui correspond aux éléments réellement présents : une simple `2024-01-15` devient une date locale TOML, tandis qu'un horodatage avec un décalage `Z` ou `+00:00` devient une date-heure avec décalage. Les deux formats suivent le format RFC 3339 pour ces valeurs, donc aucun reformatage de la chaîne de date elle-même n'est nécessaire — seule la classification du type change côté TOML.