YAML in TOML konvertieren Online
YAML-Konfiguration in TOML umwandeln. Kostenlos, im Browser.
title = "My Project" version = "1.0.0" [server] host = "localhost" port = 8080 [database] host = "db.example.com" name = "myapp"
Anwendungsfälle
Von Docker und GitHub Actions zu Rust und Hugo
Jekyll→Hugo-Migration
Wandle Jekylls YAML-Front-Matter in TOML um, um Inhalte zu Hugo zu migrieren.
Modernes Python
Extrahiere Konfiguration aus YAML, um sie gemäß PEP 621 an pyproject.toml anzupassen.
100 % privat
Dein YAML verlässt nie deinen Browser. Keine Server, keine Anmeldung.
Echtzeit
Live-Konvertierung mit sofortiger YAML-Syntaxfehler-Erkennung.
So funktioniert es
Drei Schritte, kein Aufwand
Dein YAML einfügen
Füge YAML in den Editor ein. Unterstützt docker-compose.yml, GitHub-Actions-Workflows, Ansible-Playbooks und jedes gültige YAML 1.2.
Umwandlung in TOML
Der Konverter transformiert YAML-Maps und Listen in TOML-Abschnitte und Arrays. Alles läuft in deinem Browser – nichts wird hochgeladen.
TOML kopieren oder herunterladen
Erhalte TOML, das direkt für Cargo.toml, pyproject.toml, Pipfile, hugo.toml oder jedes Tool bereit ist, das TOML v1.0 akzeptiert.
FAQ
Noch Fragen?
Die häufigsten Szenarien sind: Migration von Python-Projekten von requirements.txt + setup.cfg (veraltetes Format) zu pyproject.toml (der moderne Standard nach PEP 517/518/621), wobei einige Konfigurationen möglicherweise in YAML vorliegen (wie CI/CD-Workflows) und du Konfigurationsabschnitte in TOML normalisieren möchtest. Ebenfalls häufig bei der Migration von Jekyll-Websites (YAML-Front-Matter) zu Hugo (bevorzugtes TOML-Front-Matter). Schließlich haben Teams, die Rust einführen, oft CI/CD-Konfigurationen in YAML (GitHub Actions), die in Cargo.toml für die Verwaltung von Features oder Workspace-Mitgliedern widergespiegelt werden müssen.
docker-compose.yml definiert Services, Netzwerke und Volumes in YAML. Obwohl es kein natives TOML-Äquivalent für Docker Compose gibt (Docker akzeptiert nur YAML für sein Compose-Format), kann die Umwandlung von docker-compose.yml in TOML als Zwischendarstellung nützlich sein: Einige Rust-Projekte verwenden TOML als eigene Infrastrukturkonfiguration (z. B. Server-Konfigurationen mit tokio, actix-web oder tauri), und die gleiche Service-Struktur in TOML erleichtert die Integration. Die Umwandlung erzeugt gültiges TOML mit [[services]]-Abschnitten für Arrays von Objekten.
GitHub-Actions-Workflows (.github/workflows/*.yml) haben eine spezifische Struktur (on, jobs, steps), die nicht direkt der Struktur von pyproject.toml ([project], [tool.X], [build-system]) entspricht. Es ist jedoch üblich, Teile des Workflows extrahieren zu wollen – wie die Python-Versionsmatrix, Test-Abhängigkeiten oder Tool-Konfiguration – um sie in pyproject.toml einzubinden. Dieses Tool konvertiert das vollständige YAML in strukturelles TOML; aus dem resultierenden TOML kannst du die relevanten Abschnitte auswählen und anpassen, um sie in deine pyproject.toml aufzunehmen.
Der umgekehrte Prozess von Hugo→Jekyll: Jekylls YAML-Front-Matter ist am Anfang und Ende der Markdown-Datei durch --- begrenzt. Um zu Hugo mit TOML-Front-Matter zu migrieren, extrahiere den YAML-Block zwischen den ---, wandle ihn mit diesem Tool in TOML um und ersetze die ---Begrenzungszeichen durch +++. Häufige Felder (title, date, tags, categories, draft) werden direkt übertragen. Jekyll-spezifische Permalinks und Layouts müssen möglicherweise manuell auf Hugo-Äquivalente (url, type, layout) abgebildet werden.
Einige YAML-Funktionen lassen sich nicht direkt auf TOML abbilden. YAML-Anchors und Aliases (&anchor und *alias) werden vor der Konvertierung aufgelöst, sodass das resultierende TOML die erweiterten Werte enthält, keine Referenzen. Mehrere YAML-Dokumente (getrennt durch ---) haben kein TOML-Äquivalent, da TOML immer ein einzelnes Dokument ist. Schlüssel mit speziellen Typen (Daten als Map-Schlüssel, Schlüssel mit Sonderzeichen) müssen in TOML möglicherweise in Anführungszeichen gesetzt werden. YAML-Null-Werte (~ oder null) werden in TOML als leere Zeichenketten dargestellt oder weggelassen, da TOML keinen nativen Null-Typ hat (TOML 1.0 enthält kein null).
Das generierte TOML ist gemäß der TOML-1.0-Spezifikation syntaktisch gültig und kann von toml-rs (dem von Cargo verwendeten Rust-Parser) oder anderen Standard-TOML-Bibliotheken geparst werden. Die semantische Kompatibilität mit Cargo.toml hängt jedoch davon ab, ob das eingegebene YAML die Struktur eines Cargo-Manifests korrekt modelliert: [package], [dependencies], [dev-dependencies], [[bin]], [[lib]] und so weiter. Wenn dein YAML diese Struktur bereits modelliert, ist das resultierende TOML ein gültiges Cargo.toml. Kommt es aus einer anderen Quelle (wie docker-compose.yml), benötigt das resultierende TOML manuelle Anpassungen.
YAML zu TOML konvertieren: Docker und GitHub Actions in das Rust- und Hugo-Ökosystem migrieren
Die Konvertierung von YAML in TOML ist ein weniger häufiger Vorgang als die umgekehrte Richtung, hat aber klar definierte Anwendungsfälle im modernen Entwicklungsökosystem. Der relevanteste ist die Übernahme von TOML als Konfigurationsstandard in Python: pyproject.toml, definiert durch PEP 518 im Jahr 2016 und erweitert durch PEP 517 (Build-System), PEP 621 (Projekt-Metadaten, 2021) und PEP 660 (editierbare Builds), hat setup.py, setup.cfg und requirements.txt als zentrale Konfiguration für moderne Python-Projekte schrittweise abgelöst. Tools wie Poetry, Hatch, Flit und PDM verwenden pyproject.toml als ihre Wahrheitsquelle. Wenn ein bestehendes Python-Projekt einen Teil seiner Konfiguration in YAML hat – zum Beispiel unterstützte Python-Versionen, die in einem GitHub-Actions-Workflow definiert sind, oder tox-Konfiguration in YAML –, ist die Umwandlung in TOML zur Zentralisierung in pyproject.toml eine Verbesserung der Wartbarkeit.
Im Rust-Ökosystem ist Cargo.toml das Herzstück des Projekts: Es definiert den Crate-Namen, die Version (gemäß Semantic Versioning), Autoren, die Rust-Edition (2015, 2018, 2021, 2024), Abhängigkeiten mit Semver-Versionen, optionale Crate-Features, Targets (Binaries, Libraries, Examples, Tests, Benchmarks) und Workspace-Konfiguration für Monorepo-Projekte. Wenn ein Team Rust für einen neuen Dienst in einer Infrastruktur einführt, die bereits YAML extensiv nutzt (docker-compose.yml für die lokale Entwicklung, Kubernetes-Manifests für die Produktion, GitHub Actions für CI/CD), müssen möglicherweise Teile dieser YAML-Konfiguration extrahiert werden, um sie in Cargo.toml aufzunehmen. Das praktischste Beispiel: Der GitHub-Actions-Workflow definiert die Rust-Versionsmatrix für Tests (stable, beta, nightly); diese Information soll möglicherweise im Cargo.toml des Workspaces widergespiegelt werden.
Die Inhaltsmigration zwischen Static-Site-Generatoren ist das konkreteste Szenario für YAML→TOML. Jekyll, 2008 von Tom Preston-Werner erstellt und die Engine hinter GitHub Pages, popularisierte das Konzept des durch --- begrenzten YAML-Front-Matters in Markdown-Dateien. Hugo, der schnellste Static-Site-Generator (geschrieben in Go, mit typischen Build-Zeiten von Millisekunden für Tausende von Seiten), übernahm TOML als bevorzugtes Front-Matter-Format in frühen Versionen, unterstützt aber auch YAML und JSON. Die Migration einer Website von Jekyll zu Hugo – eine beliebte Migration unter Entwicklern, die bessere Performance für große Websites suchen – erfordert die Konvertierung des YAML-Front-Matters jeder Markdown-Datei in das TOML-Format mit +++-Begrenzungszeichen. Für eine Website mit Hunderten von Beiträgen wird dies mit Python-Skripten (PyYAML + toml) oder Node.js (js-yaml + @iarna/toml) automatisiert, wobei dieses Tool zur Validierung der Konvertierung für einzelne Fälle verwendet wird.