Konwerter JSON na TOML Online
Konwertuj JSON na TOML (Cargo.toml, Hugo, Netlify) bezplatnie, w Twojej przegladarce.
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
JSON do TOML dla Rust, Hugo i nowoczesnej konfiguracji
Cargo.toml dla Rust
Konwertuj zaleznosci lub konfiguracje JSON na standardowy format manifestu skrzynki Rust.
Hugo i Netlify
Front matter i konfiguracja dla witryn Hugo, netlify.toml i konfiguracja CI/CD.
pyproject.toml (PEP 518)
Migruj konfiguracje projektu Python z JSON do standardowego formatu pyproject.toml.
W 100% prywatne
Konwersja odbywa sie w Twojej przegladarce. Twoj kod i konfiguracja nigdy nie opuszczaja Twojego urzadzenia.
Jak to działa
Trzy kroki, żadnych komplikacji
Wklej lub przeslij plik JSON
Wklej zawartosc JSON do edytora lub przeslij plik .json. Bez rejestracji, bez limitow.
Automatyczna konwersja
JSON jest konwertowany do poprawnej skladni TOML w Twojej przegladarce. Bez serwerow, bez transmisji danych.
Skopiuj lub pobierz plik TOML
TOML gotowy do uzycia jako Cargo.toml, konfiguracja Hugo, netlify.toml lub pyproject.toml.
FAQ
Masz pytania?
TOML (Tom's Obvious, Minimal Language) zostal stworzony przez Toma Preston-Wernera, wspolzalozyciciela GitHub, w 2013 roku. Preston-Werner zaprojektowal go, poniewaz uznal YAML za zbyt niejednoznaczny, a JSON za zbyt gadatliwy i nieporechny do recznego edytowania jako format konfiguracyjny. TOML osiagnal wersje 1.0 w styczniu 2021 roku po latach rozwoju i przegladu. Jego celem jest bycie formatem konfiguracyjnym, ktory jest oczywisty do czytania dla ludzi i jednoznacznie latwy do parsowania dla maszyn. Dzis jest standardowym formatem konfiguracyjnym dla ekosystemu Rust (Cargo.toml), generatora stron statycznych Hugo i jest zdefiniowany jako oficjalny format metadanych pakietow Pythona w PEP 518 (pyproject.toml).
JSON jest precyzyjny i powszechny, ale nieporedni dla recznego pisania konfiguracji: nie pozwala na komentarze, wymaga cudzystowow przy wszystkich kluczach, a przecinki koncowe sa zabronione. YAML jest bardziej czytelny, ale ma notoryczna zlozona specyfikacje z wieloma sposobami wyrazania tego samego, a bledy wciec moga cicho zmieniac znaczenie pliku. TOML zajmuje srodek drogi: uzywa sekcji [tabela] i skladni klucz = wartosc znajomej kazdemu, kto edytowal pliki .ini, obsluguje komentarze #, nie zalezy od wciec jak YAML i ma kompaktowa specyfikacje. Ograniczeniem TOML jest to, ze nie nadaje sie dobrze do gleboko zagniezdonych danych lub ogolnych struktur danych.
Cargo.toml to plik manifestu dla kazdej skrzynki (pakietu) w Rust. Definiuje nazwe pakietu, wersje wedlug semver, autorow, edycje Rust i zaleznosci. Sekcja [dependencies] to miejsce, gdzie deklaruje sie zewnetrzne biblioteki z ich wersjami: na przyklad serde = { version = "1.0", features = ["derive"] }. Cargo, menedzer pakietow Rust, czyta ten plik, aby rozwiazac drzewo zaleznosci, pobrac pakiety z crates.io i skompilowac projekt. Jesli masz konfiguracje zaleznosci w JSON i musisz zmigrować ją do projektu Rust, ten konwerter generuje poprawny TOML.
Hugo, generator stron statycznych oparty na Go, obsluguje trzy formaty front matter dla stron tresci: YAML (rozdzielony przez ---), TOML (rozdzielony przez +++) i JSON (rozdzielony przez { }). Front matter TOML w Hugo wyglada tak: +++\ntitle = "Moj artykul"\ndate = 2024-01-15T10:00:00Z\ntags = ["go", "hugo"]\ndraft = false\n+++. Jesli masz front matter w JSON i chcesz zmigrować go do konwencji TOML preferowanej przez wiele motywow Hugo, ten konwerter przeprowadza transformacje w kilka sekund.
pyproject.toml to standardowy plik konfiguracyjny dla projektow Pythona, zdefiniowany w PEP 518 (2016) i rozszerzony przez PEP 517, PEP 621 i PEP 660. Zastepuje stary setup.py i setup.cfg jednym deklaratywnym plikiem. Rada sterujaca Pythona wybrala TOML po ocenie YAML, JSON i innych formatow: YAML zostal odrzucony ze wzgledu na zlozona specyfikacje i zaskakujace zachowania, JSON ze wzgledu na brak komentarzy. Sekcja [build-system] definiuje zaplecze kompilacji (setuptools, flit, hatch, poetry), [project] definiuje metadane pakietu, a sekcje [tool.ruff] lub [tool.mypy] konfiguruja narzedzia developerskie.
TOML dobrze radzi sobie z dwoma lub trzema poziomami zagniezdania przez tabele: [database.server] tworzy obiekt zagniezdony. Dla glebszego zagniezdania TOML uzywa inline tabel: { host = "localhost", port = 5432 }. Jednakze JSON z obiektami zagniezdzonymi na wiecej niz trzech lub czterech poziomach moze stac sie gadatliwy i nienaturalny w TOML. Konkretny przypadek, z ktorym TOML nie radzi sobie elegancko, to tablica obiektow z wieloma wlasciwosciami: TOML wymaga skladni [[table.array]] z powtarzanymi sekcjami. Jesli Twoj JSON ma gleboko zagniezdzone struktury przeznaczone dla danych, a nie konfiguracji, zastanow sie, czy TOML jest odpowiednim formatem docelowym, czy tez bardziej odpowiedni bylby YAML.
Konwertuj JSON na TOML: Cargo.toml, Hugo, Netlify i pyproject.toml
TOML (Tom's Obvious, Minimal Language) zostal stworzony w 2013 roku przez Toma Preston-Wernera, wspolzalozyciciela GitHub, tworce Jekylla (generatora stron statycznych, ktory napedzal GitHub Pages i spopularyzowal koncepcje JAMstack) i autora specyfikacji Semantic Versioning na semver.org. Preston-Werner zaprojektowal TOML jako bezposrednia i artykuowana odpowiedz na frustracje z istniejacymi formatami konfiguracyjnymi. YAML, pomimo swojej powierzchownej czytelnosci, ma specyfikacje ponad 80 stron zawierajaca wiele rownowaznych i czesto zaskakujacych sposobow wyrazania tych samych danych. Plik YAML z niepoprawnym wcieciem moze calkowicie zmienic swoje znaczenie bez wywolywaania bledu parsowania, co czyni go niebezpiecznym w konfiguracji infrastruktury. JSON, ze swojej strony, jest precyzyjny i powszechny, ale ma krytyczne ograniczenia dla konfiguracji pisanych i utrzymywanych przez ludzi: nie pozwala na komentarze zadnego rodzaju (ograniczenie, ktore tworca JSON Douglas Crockford przyznal jako celowe), wymaga podwojnych cudzystowow przy wszystkich kluczach nawet gdy sa prostymi identyfikatorami, zabrania przecinkow koncowych w tablicach i obiektach i nie oferuje wygodnej skladni dla reprezentowania hierarchicznych struktur sekcji. TOML rozwiazuje wszystkie te problemy: uzywa sekcji [tabela] i skladni klucz = "wartosc" znajomej kazdemu, kto edytowal pliki .ini lub .cfg, obsluguje komentarze # jak Python i wiekszosc jezykow skryptowych, nie zalezy od wciec dla znaczenia, ma jawna natywna obsluge dat i znacznikow czasu zgodnych z RFC 3339, i kompletna, jednoznaczna specyfikacje, ktora osiagnela stabilna wersje 1.0.0 w styczniu 2021 roku.
Najwiekszy i najbardziej aktywny ekosystem TOML w praktyce to Rust i jego menedzer pakietow Cargo. Cargo, oficjalny system kompilacji i menedzer pakietow Rust (czesc zestawu narzedzi od pierwszego stabilnego wydania Rust w maju 2015 roku), uzywa Cargo.toml jako formatu manifestu dla kazdej skrzynki. Typowy Cargo.toml projektu Rust zawiera: sekcje [package] z nazwa, wersja (wymagany semver), autorami, edycja (2015, 2018 lub 2021), opisem, licencja i URL-em repozytorium; sekcje [dependencies] z zaleznoscia produkcyjna ze wskazaniem wersji i opcjonalnych flag funkcji; [dev-dependencies] dla zaleznosci tylko do testow i benchmarkow; [build-dependencies] dla skryptow build.rs; [features] do definiowania opcjonalnych mozliwosci skrzynki; i [workspace] do zarzadzania monorepo z wieloma skrzynkami. Crates.io, oficjalny rejestr pakietow Rust, ma ponad 140 000 opublikowanych skrzynek, kazda z Cargo.toml jako autorytatywnym zrodlem metadanych. Netlify przyjal TOML dla swojego pliku konfiguracyjnego netlify.toml, ktory definiuje reguly kompilacji, niestandardowe naglowki HTTP wedlug wzorca sciezki, reguly przekierowania i przepisania z pelna obsluaga wyrazen regularnych, konfiguracje funkcji serverless i Edge Function oraz zmienne srodowiskowe zabezpieczone na kontekst wdrozenia.
Python przyjal TOML jako oficjalny format konfiguracji projektu przez serie PEP (Python Enhancement Proposals) obejmujaca lata od 2016 do chwili obecnej, co stanowi jedna z najwazniejszych zmian w infrastrukturze kompilacji i pakowania ekosystemu Pythona od lat. PEP 518 (maj 2016) wprowadzil pyproject.toml z sekcja [build-system] do okreslania zaplecza kompilacji i jego wlasnych zaleznosci instalacyjnych, eliminujac problem cyrkulacyjnej zaleznosci. PEP 621 (listopad 2020) ustandaryzowalo metadane pakietu w sekcji [project]: nazwa, wersja, opis, readme, licencja, autorzy i opiekunowie, klasyfikatory PyPI, slowa kluczowe, adresy URL projektu, minimalna wersja Pythona w requires-python, zaleznosci uruchomieniowe w dependencies i opcjonalne zgrupowane zaleznosci w [project.optional-dependencies]. Sekcje [tool.nazwa_narzedzia] pozwalaja kazdemu narzedziu ekosystemu przechowywac konfiguracje bez konfliktow: [tool.ruff] dla lintera i formatera Ruff, [tool.mypy] dla sprawdzacza typow mypy, [tool.pytest.ini_options] dla pytest, [tool.black] dla formatera Black. Przed pyproject.toml typowy projekt Python wymagal oddzielnych plikow konfiguracyjnych dla kazdego narzedzia — setup.py, setup.cfg, tox.ini, .flake8, mypy.ini i innych — czesto z zduplikowanymi metadanymi. pyproject.toml zunifikowal to wszystko w jeden deklaratywny, czytelny i adnotowalny plik. Konwersja programowo generowanych danych konfiguracyjnych JSON do TOML to naturalny krok, gdy konfiguracja wymaga biezacej recznej konserwacji i przegladu.