JSON को TOML में बदलें

JSON में कोई comment नहीं है। यह specification में लिखा है, कोई चूक नहीं, और यही वजह है JSON में लिखी ज़्यादातर configuration बनाए रखने में असुविधाजनक होती है। TOML, जो जनवरी 2021 में 1.0 पर पहुँचा और अब Cargo, pyproject.toml और Hugo की config फ़ॉर्मेट है, comments रखता है।

दूसरी वजह flatness है। तीन-level गहरी JSON config braces की तीन परतें हैं; TOML में वही चीज़ एक header line है — [server.tls.client] — और उसके नीचे keys की एक छोटी सूची।

TOML दस्तावेज़ एक table है। यह किसी array से शुरू नहीं हो सकता जैसा JSON दस्तावेज़ कर सकता है। रूपांतरण असफल होने की बजाय इसे संभालता है — जो value object नहीं है वह items नाम की key के भीतर लपेट दी जाती है।

फ़ाइल तब valid रहती है, और यह जवाब नहीं, placeholder है। कोई converter नहीं जान सकता कि फ़ाइल पढ़ने वाला टूल उस list को dependencies कहलाना चाहता है या servers।

यह हर बार जाँचने लायक़ विफलता है। TOML के पास कोई null literal नहीं है, और writer एक नहीं गढ़ता — जिस key का JSON value null था वह बस लिखी नहीं जाती। {"a": null} बदलिए तो आउटपुट ख़ाली फ़ाइल है।

यह मायने रखता है या नहीं यह पूरी तरह उस टूल पर निर्भर करता है जो नतीजा पढ़ेगा। कई config parser अनुपस्थित key और null key को एक जैसा मानते हैं — दोनों के लिए डिफ़ॉल्ट पर वापस जाते हैं।

यह वह हिस्सा है जो अक्सर उन्हें चौंकाता है जो सोचते हैं TOML JSON से कमज़ोर फ़ॉर्मेट है। Records की सूची उसी table header को दोहराकर व्यक्त की जाती है — [[servers]] तीन बार लिखने से तीन servers मिलते हैं।

सदस्यों को एक जैसा मेल खाना ज़रूरी नहीं। पहला object जिसमें id और name है और दूसरा जो region जोड़ता है, बिना शिकायत के convert होता है, और TOML valid रहती है।

TOML table header उसके नीचे लिखी हर चीज़ का मालिक होता है जब तक अगला header न आए। तो [server] के बाद रखी सादी key server की मानी जाएगी। इसलिए writer हर शीर्ष scalar को पहले table header से ऊपर उठाता है।

आउटपुट इसलिए आपकी JSON के क्रम में नहीं है, और यह हो भी नहीं सकता। यह इकलौता reordering है जो अर्थ बचाता है; कोई और reordering किसी key को ग़लत table में डाल देगा।

JSON की चार levels एक ही header line बनती हैं — {"a":{"b":{"c":{"d":1}}}} [a.b.c] बनकर convert होता है, नीचे d = 1 के साथ। TOML गहराई header में व्यक्त करता है, indentation में नहीं।

इसकी एक सीमा भी है जो validity का नहीं, ruचि का सवाल है — [build.targets.linux.arm64.flags] जैसा header legal है और पढ़ने में कोई मज़ा नहीं। अगर बदली फ़ाइल में इतने लंबे headers हों, यह एक संकेत है।

आउटपुट में कोई comment नहीं है, क्योंकि input के पास रखने को कहीं जगह नहीं थी। यह converter की कमी नहीं — यही वजह है JSON रखना पहले सार्थक था।

जो इसे रूपांतरण के बाद पहले पाँच मिनट सबसे क़ीमती बनाता है। TOML फ़ाइल इस configuration के बारे में institutional knowledge रख सकती है — कौन-सी values बदलना सुरक्षित है, यह लिखने का यही एक पल है जो कुछ नहीं खर्चता।

TOML के पास चार date और time types हैं। JSON के पास कोई नहीं — RFC 8259 आपको strings, numbers, booleans, null, arrays और objects देता है, और हर timestamp पहले प्रकार का है।

तो "2024-01-01T00:00:00Z" जैसी JSON value quoted TOML string के रूप में लिखी जाती है, जो सही है और वह नहीं जो फ़ॉर्मेट व्यक्त कर सकता था। अगर पढ़ने वाले टूल को असली date-time चाहिए, उन लाइनों से हाथ से quotation marks हटा दीजिए।

सबसे सस्ती जाँच है round trip — TOML को वापस JSON में बदलिए और शुरुआती फ़ाइल से तुलना कीजिए। जिन keys में null था वे गायब होंगी और और कुछ अलग नहीं होना चाहिए।

दूसरी जाँच है टूल ख़ुद। Cargo, Hugo और ज़्यादातर Python packaging tools तुरंत बता देंगे कि दस्तावेज़ parse होता है या नहीं।

इसी ब्राउज़र टैब में, आपके अपने processor पर। कोई request फ़ाइल कहीं नहीं ले जाता, कोई अकाउंट नहीं, कोई कतार नहीं, और मुफ़्त तह 100 MB तक की फ़ाइलें स्वीकार करती है।

यह config के लिए सामान्य से ज़्यादा मायने रखता है। एक JSON configuration फ़ाइल ठीक वही चीज़ है जो internal hostnames, bucket names, service accounts रखती है।