Konwerter YAML na TOML Online
Konwertuj konfiguracje YAML do TOML. Bezpłatnie, w przeglądarce.
title = "My Project" version = "1.0.0" [server] host = "localhost" port = 8080 [database] host = "db.example.com" name = "myapp"
Przypadki użycia
Z Docker i GitHub Actions do Rust i Hugo
Migracja Jekyll→Hugo
Konwertuj front matter YAML z Jekyll do TOML w celu migracji treści do Hugo.
Nowoczesny Python
Wyodrębniaj konfigurację z YAML, aby dostosować ją do pyproject.toml zgodnie z PEP 621.
100% prywatne
Twój YAML nigdy nie opuszcza przeglądarki. Bez serwerów, bez rejestracji.
W czasie rzeczywistym
Konwersja na żywo z natychmiastowym wykrywaniem błędów składniowych YAML.
Jak to działa
Trzy kroki, żadnych komplikacji
Wklej swój YAML
Wklej YAML do edytora. Obsługuje docker-compose.yml, przepływy pracy GitHub Actions, playbooki Ansible i dowolny prawidłowy YAML 1.2.
Konwersja do TOML
Konwerter przekształca mapy i listy YAML w sekcje i tablice TOML. Wszystko odbywa się w Twojej przeglądarce — żadne dane nie są przesyłane.
Skopiuj lub pobierz plik TOML
Otrzymaj TOML gotowy do użycia w Cargo.toml, pyproject.toml, Pipfile, hugo.toml lub dowolnym narzędziu akceptującym TOML v1.0.
FAQ
Masz pytania?
Najczęstsze scenariusze to: migracja projektów Python z requirements.txt + setup.cfg (format legacy) do pyproject.toml (nowoczesny standard zdefiniowany przez PEP 517/518/621), gdzie część konfiguracji może istnieć w YAML (np. przepływy pracy CI/CD) i chcesz znormalizować sekcje konfiguracyjne do TOML. Powszechna jest też migracja witryn Jekyll (front matter YAML) do Hugo (preferowany front matter TOML). Wreszcie zespoły adoptujące Rust często mają konfiguracje CI/CD w YAML (GitHub Actions), które muszą być odzwierciedlone w pliku Cargo.toml do zarządzania funkcjami lub członkami przestrzeni roboczej.
Plik docker-compose.yml definiuje usługi, sieci i wolumeny w YAML. Choć nie istnieje natywny odpowiednik TOML dla Docker Compose (Docker akceptuje tylko YAML dla swojego formatu Compose), konwersja docker-compose.yml do TOML może być przydatna jako reprezentacja pośrednia: niektóre projekty Rust używają TOML jako własnej konfiguracji infrastruktury (np. konfiguracje serwerów z tokio, actix-web lub tauri), a posiadanie tej samej struktury usług w TOML ułatwia integrację. Konwersja generuje prawidłowy TOML z sekcjami [[services]] dla tablic obiektów.
Przepływy pracy GitHub Actions (.github/workflows/*.yml) mają specyficzną strukturę (on, jobs, steps), która nie odpowiada bezpośrednio strukturze pyproject.toml ([project], [tool.X], [build-system]). Jednak często zachodzi potrzeba wyodrębnienia części przepływu pracy — takich jak macierz wersji Pythona, zależności testowe lub konfiguracja narzędzi — w celu włączenia do pyproject.toml. To narzędzie konwertuje pełny YAML do strukturalnego TOML; z wynikowego TOML możesz wybrać i dostosować odpowiednie sekcje, aby dodać je do swojego pliku pyproject.toml.
Odwrotny proces do Hugo→Jekyll: front matter YAML w Jekyll jest ograniczony przez --- na początku i końcu pliku Markdown. Aby migrować do Hugo z front matter TOML, wyodrębnij blok YAML między ---, przekonwertuj go do TOML za pomocą tego narzędzia i zamień ograniczniki --- na +++. Wspólne pola (title, date, tags, categories, draft) są tłumaczone bezpośrednio. Linki trwałe i układy specyficzne dla Jekyll mogą wymagać ręcznego mapowania do odpowiedników Hugo (url, type, layout).
Niektóre funkcje YAML nie mają bezpośredniego mapowania do TOML. Kotwice i aliasy YAML (&anchor i *alias) są rozwiązywane przed konwersją, więc wynikowy TOML zawiera rozwinięte wartości, a nie referencje. Wiele dokumentów YAML (oddzielonych przez ---) nie ma odpowiednika TOML, ponieważ TOML jest zawsze jednym dokumentem. Klucze ze specjalnymi typami (daty jako klucze mapy, klucze ze znakami specjalnymi) mogą wymagać cudzysłowów w TOML. Wartości null YAML (~ lub null) są reprezentowane jako puste ciągi tekstowe lub pomijane w TOML, ponieważ TOML nie ma natywnego typu null (TOML 1.0 nie zawiera wartości null).
Wygenerowany TOML jest syntaktycznie prawidłowy zgodnie ze specyfikacją TOML 1.0 i może być parsowany przez toml-rs (parser Rust używany przez Cargo) lub inne standardowe biblioteki TOML. Jednak semantyczna zgodność z Cargo.toml zależy od tego, czy wejściowy YAML poprawnie modeluje strukturę manifestu Cargo: [package], [dependencies], [dev-dependencies], [[bin]], [[lib]] i tak dalej. Jeśli Twój YAML już modeluje tę strukturę, wynikowy TOML będzie prawidłowym plikiem Cargo.toml. Jeśli pochodzi z innego źródła (np. docker-compose.yml), wynikowy TOML będzie wymagał ręcznej adaptacji.
Konwertuj YAML do TOML: migracja Docker i GitHub Actions do ekosystemu Rust i Hugo
Konwersja YAML do TOML jest rzadszym kierunkiem niż odwrotny, ale ma dobrze zdefiniowane przypadki użycia we współczesnym ekosystemie programistycznym. Najistotniejszym jest adopcja TOML jako standardu konfiguracji w Pythonie: plik pyproject.toml, zdefiniowany przez PEP 518 w 2016 roku i rozszerzony przez PEP 517 (system budowania), PEP 621 (metadane projektu, 2021) i PEP 660 (edytowalne buildy), stopniowo zastąpił setup.py, setup.cfg i requirements.txt jako centralna konfiguracja nowoczesnych projektów Python. Narzędzia takie jak Poetry, Hatch, Flit i PDM używają pyproject.toml jako źródła prawdy. Jeśli istniejący projekt Python ma część swojej konfiguracji w YAML — na przykład obsługiwane wersje Pythona zdefiniowane w przepływie pracy GitHub Actions lub konfigurację tox w YAML — konwersja jej do TOML w celu centralizacji w pyproject.toml jest usprawnieniem w zakresie utrzymywalności.
W ekosystemie Rust plik Cargo.toml jest sercem projektu: definiuje nazwę crate, wersję (zgodnie z Semantic Versioning), autorów, edycję Rust (2015, 2018, 2021, 2024), zależności z wersjami semver, opcjonalne funkcje crate, cele (binaria, biblioteki, przykłady, testy, benchmarki) i konfigurację przestrzeni roboczej dla projektów monorepo. Gdy zespół adoptuje Rust dla nowej usługi w infrastrukturze już intensywnie korzystającej z YAML (docker-compose.yml do lokalnego tworzenia, manifesty Kubernetes dla produkcji, GitHub Actions dla CI/CD), może być konieczne wyodrębnienie części tej konfiguracji YAML w celu włączenia do Cargo.toml. Najbardziej praktyczny przykład: przepływ pracy GitHub Actions definiuje macierz wersji Rust do testowania (stable, beta, nightly); te informacje mogą być odzwierciedlone w Cargo.toml przestrzeni roboczej.
Migracja treści między generatorami stron statycznych jest najbardziej konkretnym scenariuszem dla YAML→TOML. Jekyll, stworzony przez Toma Prestona-Wernera w 2008 roku i będący silnikiem GitHub Pages, spopularyzował koncepcję front matter YAML ograniczonego przez --- w plikach Markdown. Hugo, najszybszy generator stron statycznych (napisany w Go, z typowymi czasami budowania rzędu milisekund dla tysięcy stron), przyjął TOML jako preferowany format front matter we wczesnych wersjach, choć obsługuje też YAML i JSON. Migracja witryny z Jekyll do Hugo — popularna wśród programistów szukających lepszej wydajności dla dużych witryn — wymaga konwersji front matter YAML każdego pliku Markdown do formatu TOML z ogranicznikami +++. Dla witryny z setkami wpisów jest to automatyzowane skryptami Python (PyYAML + toml) lub Node.js (js-yaml + @iarna/toml), przy użyciu tego narzędzia do walidacji konwersji dla poszczególnych przypadków.