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

यही पूरा वाक्य पूरा रूपांतरण है। INI फ़ाइल sections की सूची है, हर एक flat key-value लाइनें रखते हुए, और section के भीतर section की कोई सुविधा नहीं। इसका कोई specification नहीं — यह 1985 से है।

JSON बिना किसी सीमा के nest करता है। तो रूपांतरण को एक tree को दो levels पर projection करना है, और असली सवाल यह नहीं कि यह काम करता है या नहीं, बल्कि यह कि तीसरे level और उससे नीचे के साथ क्या होता है।

हर वह ऊपरी key जिसका value object है, section बनती है — server, logging और database objects रखने वाली JSON फ़ाइल [server], [logging] और [database] बनाती है। जो settings किसी इंसान ने पहले लिखी थीं, उनके लिए यह अक्सर एक सटीक मेल है।

सादा value रखने वाली ऊपरी keys पहले section header से पहले लिखी जाती हैं, बाद में नहीं। यह style का चुनाव नहीं — कोई INI section उसके बाद हर लाइन का मालिक होता है जब तक अगला header न आए।

तीसरा nesting level dotted key बनकर लिखा जाता है। अगर server में tls object हो जिसमें cert path हो, आउटपुट [server] section बनकर उसके नीचे tls.cert line रखता है।

कुछ parsers इस परंपरा को समझते हैं और nesting दोबारा बनाते हैं; ज़्यादातर नहीं समझते। कोई भी setting पढ़ने के लिए दोनों तरीक़े ठीक हैं। जो यह नहीं है वह round-trippable होना — dot रखने वाली असली JSON key nesting के एक level से अलग नहीं की जा सकती।

Key बचती है, value नहीं — null equals sign के बाद कुछ भी नहीं लिखता। यह unset value के सबसे नज़दीक है जो INI के पास है, क्योंकि फ़ॉर्मेट के पास न null है, न इसे व्यक्त करने का कोई तरीक़ा।

आपका parser इससे क्या करता है यह अलग-अलग होता है, और दस सेकंड में जान लेना बेहतर है। Python configparser इसे ख़ाली string लौटाता है। कुछ readers key पूरी तरह छोड़ देते हैं।

INI के पास कोई list नहीं। तीन allowed hosts वाला array 0, 1 और 2 keyed तीन लाइनें बनता है, जो हर value रखता है पर लगभग किसी parser convention से नहीं मिलता।

यह वह हिस्सा है जिसे INI बनने के बाद बदलने की बजाय JSON में पहले बदलना बेहतर है। Array को एक string में जोड़ दीजिए जिस separator को application उम्मीद करता है, फिर बदलिए।

शीर्ष-level वाला JSON array array positions के नाम पर sections बनाता है — [0], [1], [2], हर एक record की keys रखते हुए। फ़ाइल syntax के हिसाब से valid INI है और इसे पढ़ने वाला कोई समझदार program नहीं होगा।

यह आउटपुट विफलता नहीं, संकेत है। INI एक configuration फ़ॉर्मेट है — एक application के लिए named settings का सेट — और records की सूची डेटा है। CSV या स्प्रेडशीट लक्ष्य है अगर कोई इंसान इसे पढ़ेगा।

लगभग हर value वैसे ही लिखी जाती है — path, hostname, port, flag — जिससे फ़ाइल हाथ से टाइप की गई जैसी दिखती है। तीन प्रकार की values ऐसी नहीं हैं — जिसमें line break हो, जो पहले से quote से शुरू और ख़त्म होती हो।

यह escape हाल का है और एक असली दोष की जगह लेता है — अगस्त 2026 से पहले newline वाली JSON string सीधे लाइन break के रूप में लिखी जाती थी, जिससे अगला section अनजाने में बन सकता था।

INI हर चीज़ को टेक्स्ट के रूप में स्टोर करता है। JSON का true, true लिखा जाता है, JSON का 8080, 8080, और आगे इनका मतलब वही तय करता है जो फ़ाइल पढ़ता है।

अंदाज़ा किस दिशा में जाता है यह जानना ज़रूरी है इससे पहले किसी value पर भरोसा करें। लीडिंग zeros वाला version string नंबर मान लिए जाने पर वे zeros खो देता है।

आउटपुट में कोई comment नहीं है, क्योंकि JSON के पास कोई देने को नहीं था। INI comments सँभालता है — semicolon या hash से शुरू होने वाली लाइन — और यह converter दोनों को दूसरी दिशा में पढ़ते वक़्त मानता है।

चूँकि settings को INI में ले जाने का मक़सद ही अक्सर यह है कि कोई इंसान उन्हें edit करेगा, comment लाइनें तुरंत जोड़ने लायक़ हैं — कौन-सी values environment-specific हैं।

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

Privacy बात यहाँ सजावट नहीं है। Settings फ़ाइल database connection strings, API endpoints, internal hostnames रखती है — और, कोई भी माने या नहीं, कभी-कभी एक password जो environment variable होना चाहिए था।