Konwerter TOML na JSON Online
Konwertuj TOML na JSON bezplatnie, w Twojej przegladarce, bez przesylania plikow.
{
"title": "My Project",
"version": "1.0.0",
"features": [
"async",
"json"
],
"dependencies": {
"serde": "1.0",
"tokio": "1.28"
},
"authors": [
{
"name": "John",
"email": "john@example.com"
}
]
}Zastosowania
TOML do JSON dla narzedzi, walidacji i API
Walidacja JSON Schema
Waliduj Cargo.toml, pyproject.toml lub dowolny konfig TOML za pomoca JSON Schema i ajv.
Dostep programowy
Czytaj konfiguracje TOML z Pythona, Node.js lub dowolnego narzedzia, ktore obsluguje JSON.
Debugowanie TOML
Wizualizuj zlozona strukture pliku TOML jako rownowazne drzewo obiektow JSON.
W 100% prywatne
Konwersja odbywa sie w Twojej przegladarce. Twoja konfiguracja i kod nigdy nie opuszczaja Twojego urzadzenia.
Jak to działa
Trzy kroki, żadnych komplikacji
Wklej lub przeslij plik TOML
Wklej zawartosc Cargo.toml, pyproject.toml lub dowolnego pliku TOML. Bez rejestracji.
Konwersja i walidacja
TOML jest parsowany i walidowany, a nastepnie konwertowany do sformatowanego JSON w Twojej przegladarce.
Skopiuj lub pobierz JSON
JSON gotowy dla API, narzedzi, walidacji JSON Schema lub programowego przetwarzania.
FAQ
Masz pytania?
TOML doskonale nadaje sie do recznego pisania konfiguracji, ale ekosystem narzedzi programistycznych — API, skrypty, walidatory, edytory — glownie mowi jezykiem JSON. Konwersja TOML na JSON pozwala Ci: walidowac strukture pliku konfiguracyjnego za pomoca JSON Schema (narzedzia takie jak ajv lub jsonschema), czytac Cargo.toml lub pyproject.toml ze skryptow Python lub Node.js za pomoca JSON.parse, integrować dane konfiguracyjne TOML w potoki konsumujace JSON, migrowac konfiguracje z systemu opartego na TOML na system oparty na JSON oraz debugowac zlozona strukture pliku TOML przez ogladanie rownowaznej reprezentacji obiektu.
Tabele TOML sa mapowane bezposrednio na obiekty JSON. Sekcja [database] z klucz = wartosc staje sie obiektem JSON { "database": { "key": "value" } }. Notacja kropkowa [database.server] tworzy zagniezdanie: { "database": { "server": {} } }. Inline tabele { key = "value" } rowniez konwertuja sie na obiekty. Typy danych TOML maja bezposrednie odpowiedniki JSON: lancuchy znakow na lancuchy znakow, liczby calkowite na liczby, liczby zmiennoprzecinkowe na liczby, wartosci logiczne na wartosci logiczne, tablice na tablice. Daty i znaczniki czasu TOML (RFC 3339) nie maja natywnego odpowiednika JSON i sa konwertowane na lancuchy ISO 8601.
Tablica tabel to najbardziej specyficzna konstrukcja TOML bez bezposredniego odpowiednika JSON. Skladnia [[products]] z wieloma wpisami tworzy tablice obiektow. W JSON staje sie to tablica pod odpowiadajacym kluczem: { "products": [ { "name": "A" }, { "name": "B" } ] }. To dokladnie wzorzec, ktory Cargo.toml uzywa dla [[bin]] (wiele binariow w przestrzeni roboczej), [[example]] i [[test]]. Jesli Twoj Cargo.toml ma wiele wpisow [[bin]], konwersja JSON produkuje tablice obiektow pod kluczem bin.
W Pythonie standardowa biblioteka zawiera tomllib od Pythona 3.11 (PEP 680): import tomllib; with open('pyproject.toml', 'rb') as f: data = tomllib.load(f). Dla wczesniejszych wersji uzyj tomli (pip install tomli). W Node.js nie ma natywnego parsera TOML, ale @iarna/toml i smol-toml sa popularne: const toml = require('@iarna/toml'); const data = toml.parse(fs.readFileSync('config.toml', 'utf8')). Jesli Twoj potok CI/CD musi czytac wartosci z pliku TOML, a parser nie jest dostepny, konwersja na JSON pozwala uzyc jq, JSON.parse lub dowolnego standardowego narzedzia.
JSON Schema to najszerzej uzywany standard do walidacji struktury danych (Draft 7, Draft 2019-09, Draft 2020-12, okreslony przez json-schema.org). TOML nie ma rownowaznego natywnego systemu walidacji. Jednak konwertujac TOML na JSON, mozesz go walidowac za pomoca dowolnej implementacji JSON Schema: ajv (JavaScript), jsonschema (Python), networknt/json-schema-validator (Java) i innych. Jest to szczegolnie przydatne do walidowania Cargo.toml lub pyproject.toml w potokach CI, sprawdzania, czy pliki konfiguracyjne aplikacji pasuja do oczekiwanego schematu przed wdrozeniem, lub dokumentowania oczekiwanej struktury niestandardowego formatu konfiguracyjnego.
Komentarze TOML (wiersze zaczynajace sie od # lub tekst po # w wierszu danych) nie maja reprezentacji w JSON. JSON nie obsluguje komentarzy zadnego rodzaju — to byl jeden z glownych powodow, dla ktorych Python wybrall TOML zamiast JSON dla pyproject.toml. Przy konwersji TOML na JSON wszystkie komentarze sa odrzucane. Jesli komentarze w Twoim pliku konfiguracyjnym zawieraja wazne informacje (takie jak uzasadnienie dla wersji zaleznosci lub notatki migracyjne), nalezy je udokumentowac gdzies indziej przed konwersja, poniewaz nie moga byc odtworzone z wynikowego JSON.
Konwertuj TOML na JSON: Cargo.toml, pyproject.toml i walidacja JSON Schema
TOML (Tom's Obvious, Minimal Language, wersja 1.0.0 opublikowana w styczniu 2021 roku przez Toma Preston-Wernera, wspolzalozyciciela GitHub) to format konfiguracyjny preferowany przez ludzi w kilku krytycznych ekosystemach technologicznych, ale jego adopcja w zautomatyzowanych narzedziacih — REST API, potokach CI/CD, walidatorach schematow, edytorach z intellisense — jest znacznie nizsza niz JSON. Ta asymetria miedzy popularnoscia przy recznym tworzeniu a wsparciem narzedzi tworzy powtarzajaca sie, dobrze udokumentowana potrzebe praktyczna: czytanie, transformowanie, walidowanie lub migrowanie plikow TOML za pomoca standardowych narzedzi ekosystemu JSON. Cargo.toml, plik manifestu ekosystemu Rust, jest prawdopodobnie najczesciej czytanym plikiem TOML na swiecie: kazda z ponad 140 000 skrzynek opublikowanych na crates.io ma go jako obowiazkowy wymog, a kazdy projekt Rust ma co najmniej jeden Cargo.toml w swoim glownym katalogu. Programowy dostep do metadanych Cargo.toml jest czestym wymogiem w potokach automatyzacji: wydobycie wersji skrzynki w skrypcie wydania (aby stworzyc tag git lub opublikowac na crates.io z cargo publish), generowanie automatycznej dokumentacji zaleznosci dla projektu, weryfikowanie, czy wersje zaleznosci sa zgodne z polityki bezpieczenstwa organizacji. Wszystkie te operacje sa znacznie prostsze, gdy plik zrodlowy jest w JSON i moze byc przetwarzany za pomoca dowolnego z setek narzedzi i bibliotek JSON dostepnych w kazdym jezyku programowania.
pyproject.toml, standardowy plik konfiguracyjny projektu Python wprowadzony przez PEP 518 w maju 2016 roku i rozszerzony przez PEP 517, PEP 621 i PEP 660, zawiera ustrukturyzowane informacje krytyczne dla narzedzi ekosystemu Pythona: zaplecze kompilacji w sekcji [build-system] (setuptools, flit, hatch, poetry, meson-python), kompletne metadane pakietu w [project] w tym nazwe, wersje, opis, autorow, licencje, klasyfikatory PyPI, slowa kluczowe, adresy URL projektu, wymagana wersje Pythona, zaleznosci uruchomieniowe i opcjonalne zaleznosci przez extra w [project.optional-dependencies]. Sekcje [tool.X] przechowuja konfiguracje dla kazdego narzedzia ekosystemu: [tool.ruff] dla regul lintera i formatera Ruff, [tool.mypy] dla sprawdzacza typow mypy, [tool.pytest.ini_options] dla konfiguracji pytest, [tool.black] dla formatera Black. Narzedzia takie jak pip, build, twine, ruff, mypy, pytest, black i isort czytaja pyproject.toml bezposrednio. Jednak jesli musisz napisac niestandardowy skrypt Python lub JavaScript, ktory czyta i przetwarza wiele plikow pyproject.toml — na przyklad aby skontrolowac wersje zaleznosci w monorepo z setkami mikroserwisow — konwersja ich na JSON pozwala uzyc json.load() w Pythonie 3 lub JSON.parse() w Node.js bez dodawania zaleznosci TOML do skryptu. Walidacja strukturalna rowniez znacznie korzysta z konwersji JSON: JSON Schema to najdojrzalszy i najszerzej obslugiwany standard do opisywania i walidowania struktury danych, z wysokiej jakosci implementacjami we wszystkich glownych jezykach, podczas gdy TOML Schema nie istnieje jeszcze jako formalny standard uznany przez jakies cialo standaryzacyjne.
Hugo, generator stron statycznych oparty na Go opracowany przez Steve'a Francii w 2013 roku i obecnie jeden z najpopularniejszych w ekosystemie JAMstack, intensywnie uzywa TOML zarowno dla globalnej konfiguracji witryny (w pliku hugo.toml lub config.toml w glownym katalogu projektu), jak i dla front matter poszczegolnych stron i wpisow (rozdzielonych przez +++ na poczatku i koncu plikow Markdown). Jesli musisz zmigrować witryne Hugo do innego systemu zarzadzania trescia — Contentful, Strapi, Sanity.io lub niestandardowego CMS-a headless — konwersja plikow konfiguracyjnych TOML i front matter na JSON jest niezbednym pierwszym krokiem do programowego przetwarzania i transformacji danych. Netlify, najpopularniejsza platforma hostingowa i CI/CD dla witryn statycznych i aplikacji Jamstack, uzywa netlify.toml do deklaratywnego definiowania: polecenia kompilacji i katalogu publikacji wedlug kontekstu wdrozenia, niestandardowych naglowkow HTTP wedlug sciezki, regul przekierowania i przepisania z obsluaga wyrazen regularnych i dowolnych kodow statusu HTTP, konfiguracji funkcji serverless i Edge Function oraz bezpiecznych zmiennych srodowiskowych na kontekst. Narzedzia DevOps i platformy orkiestracji, ktore przetwarzaja konfiguracje wdrozenia (Terraform, Pulumi, skrypty automatyzacji), generalnie preferuja JSON lub YAML jako format wejsciowy, co sprawia, ze konwersja netlify.toml na JSON jest uzyteczna dla integracji z infrastruktura jako kod. Na koniec konwersja TOML na JSON sluzy jako narzedzie debugowania i analizy: ogladanie zlozonego pliku TOML jako drzewa obiektow JSON ze standardowym wciecia i jawnymi typami pozwala natychmiast zidentyfikowac bledy strukturalne, takie jak nieprawidlowe zagniezdanie tabel, wartosci zlego typu, zduplikowane sekcje lub znieksztalcone tablice tabel — zanim te problemy spowoduja nieoczekiwane zachowanie w produkcji.