Eden najuporabnejših trenutkov v pretvorniku formatov je, ko ne pretvarja, da lahko vsaka struktura čisto postane vsaka druga struktura. To se zgodi, ko Converty pusti podokno TOML prazno za vhod, ki se sicer pravilno razčleni kot JSON ali YAML. Dokument je veljaven. Podatki še vedno obstajajo. Težava je ožja: TOML te strukture ne more predstaviti na način, ki ga pretvornik zahteva.
To je lahko videti kot napaka, če pretvorbo formatov razumeš kot kozmetično prebarvanje sintakse. Toda pretvorba strukturiranih podatkov je vprašanje, ali se isti osnovni model lahko pošteno serializira v drug format.
Zato Pretvornik JSON / YAML / TOML najprej razčleni vir in šele nato izriše združljive izhode. Lep JSON, minificiran JSON in YAML lahko predstavijo širok razpon oblik. TOML je bolj omejen. Če razčlenjena vrednost ne ustreza TOML-združljivemu objektu na najvišji ravni, je pravilno, da se pretvornik ustavi.
TOML je ožji, ker je zgrajen za konfiguracijo
JSON in YAML sta velikodušna formata. Predstavita lahko top-level array, močno nepravilne gnezdene zbirke in veliko oblik dokumentov za API-je, izmenjavo podatkov ter konfiguracijo. TOML je drugačen. Namenjen je urejenim, predvidljivim poimenovanim nastavitvam in razdelkom.
Zato se TOML dobro bere v potekih, za katere je namenjen. Kompromis je, da ni univerzalna tarča za vsak veljaven JSON ali YAML dokument.
V Convertyjevi implementaciji se omejitev začne pri korenu. Izhod TOML se izriše samo, ko je razčlenjeni vhod objekt na najvišji ravni. Če je vir top-level array, scalar ali druga struktura, ki se ne preslika čisto v TOML root table, pretvornik omejitev pokaže namesto da bi ustvaril zavajajoč rezultat.
Veljaven vhod ni isto kot pretvorljiv vhod
Dokument je lahko veljaven JSON ali YAML in še vedno slab kandidat za TOML. Vprašanje pretvorbe pride po razčlenjevanju, ne pred njim.
Zato je vedenje pretvornika koristno strogo. Neveljaven vir ustavi potek zgodaj, ker ni ničesar zaupanja vrednega za pretvorbo. Veljaven vir nadaljuje, TOML pa se prikaže samo, ko je struktura združljiva. Veljavnost te pripelje v potek; združljivost odloči, katere izhode lahko obdržiš.
Če JSON in YAML delujeta, TOML pa ne, težava navadno ni sintaksa. Težava je oblika podatkov.
Top-level array je najpreprostejši primer omejitve
Predstavljaj si JSON dokument, katerega korenska vrednost je seznam objektov. To je običajna oblika v API odzivih in izvozih. JSON in YAML jo zlahka predstavita. TOML, kot ga izrisuje Converty, tega seznama ne obravnava kot dokumentno root table.
To je primer, kjer mora pretvornik pokazati opombo o združljivosti, ne prisiljene pretvorbe. Čist pretvornik naj razloži, zakaj izhod manjka, ne pa tiho preoblikuje podatke v nekaj, kar je videti verjetno in spremeni pomen.
Tudi združljivi tipi vrednosti so pomembni
Tudi ko je koren objekt, lahko TOML zavrne nekatere vrednosti, ki jih JSON ali YAML lažje sprejmeta. Praktična lekcija je ista: TOML je strožji glede tega, kako naj izgleda konfiguracijski dokument.
Zato Converty pokaže opozorila, ko serializacija TOML odpove. Manjkajoči izhod je koristna informacija. Pove, da je morda treba podatke poenostaviti, preoblikovati ali pustiti v JSON oziroma YAML, ker ta formata bolje ustrezata viru.
Realističen primer predaje
Premikaš dokument med sistemi. Deploy orodje pričakuje TOML, vir pa je YAML iz dokumentacije ali JSON iz API payloada. Instinkt je ciljni format obravnavati kot zadnjo predstavitveno težavo, pravo vprašanje pa je, ali se izvorna struktura že vede kot konfiguracijski objekt.
Če se, Converty navadno izriše TOML ob JSON in YAML. Če se ne, je manjkajoči TOML izhod opozorilo, ki si ga potreboval. Težava je višje v strukturi in jo je treba prilagoditi, preden jo kdo prilepi v konfiguracijsko datoteko.
Širši začetek je Kako pretvarjati JSON, YAML in TOML brez poškodovanja podatkov. Ta članek pojasni ožji troubleshooting sloj.
Včasih je pravilen odgovor nehati pretvarjati
Manjkajoče podokno TOML se lahko zdi nedokončano delo, a pogosto te ščiti pred slabšo napako v nadaljevanju. Če je dokument bolje izražen kot JSON ali YAML, prisilno tlačenje v TOML ni disciplina, ampak popačenje.
To je pomembno v mešanih potekih, kjer podatki skačejo med API-ji, deploy konfiguracijo in uvoznimi orodji. Izbira formata naj sledi strukturi. Če je trenutna težava uvoz vrstic, Kako odpraviti težave z ločili CSV pred uvozom pokriva enakovredno lekcijo na tabelarični strani.
Če delo sčasoma sodi v skripte ali CI, Converty proti yq za predaje JSON in YAML pomaga odločiti, ali je brskalniški potek še pravi sloj.
Manjkajoči TOML izhod je koristna povratna informacija
Najboljša orodja za strukturirane podatke ne samo pretvarjajo besedila. Povedo tudi, kdaj je ciljni format napačen dom za izvorno strukturo. Prazen TOML rezultat v Convertyju pomeni prav to: vhod ni nujno pokvarjen, morda pa pripada drugemu formatnemu kontekstu.
Odpri Pretvornik JSON / YAML / TOML, uporabi pogosta vprašanja, vrni se k Kako pretvarjati JSON, YAML in TOML brez poškodovanja podatkov in nadaljuj s Converty proti yq za predaje JSON in YAML, ko naslednja odločitev ni samo kateri format kopirati, ampak ali naloga sodi v brskalnik ali ponovljiv CLI pipeline.
