आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
यहाँ आप NDJSON को INI में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
NDJSON से INI
यह बेमेल पूरा है, और सबसे पहले बताना ज़रूरी है। INI फ़ाइल नामित सेक्शन का सेट है, हर एक सपाट की-वैल्यू पंक्तियाँ रखता है — एक चीज़ का वर्णन, आमतौर पर एक ऐप्लिकेशन का कॉन्फ़िगरेशन। NDJSON बिना नाम, बिना मायने वाले क्रम की रिकॉर्ड श्रृंखला है।
कोई प्रतिनिधित्व दोनों को संतुष्ट नहीं करता। बदलाव सूची के रिकॉर्ड को उसका इकलौता नाम देता है — उसकी पोज़िशन: पहली पंक्ति [0] बनती है, दूसरी [1]। यह ईमानदार है, कुछ नहीं खोता, पर सेक्शन नाम में कोई मतलब नहीं होता।
अगर रिकॉर्ड असल में कई कॉन्फ़िगरेशन हैं — हर होस्ट के लिए एक — तो [0] और [1] का नाम असली नामों से बदलना पूरा काम कर देता है। नीचे की की पहले से सही हैं।
अगर रिकॉर्ड डेटा हैं, कॉन्फ़िगरेशन नहीं, तो नाम बदलने से मदद नहीं मिलती। सौ सेक्शन जो पोज़िशन के नाम पर हैं, कॉन्फ़िग फ़ाइल नहीं — ग़लत नोटेशन में लिखा टेबल है। CSV, JSON या डेटाबेस वही चाहते हैं।
यह लोगों को फँसाता है, इसलिए साफ़ कहना ज़रूरी है। ठीक एक पंक्ति वाली फ़ाइल भी एक की सूची है, और नतीजा [0] सेक्शन होता है जिसमें उस रिकॉर्ड की हर फ़ील्ड है।
उपाय स्रोत फ़ॉर्मैट बदलना है। उस पंक्ति को .json एक्सटेंशन से सेव कीजिए और JSON को INI में बदलिए — वहाँ रिकॉर्ड की टॉप-लेवल की सीधे सेक्शन हेडर बनती हैं।
INI सेक्शन को सपोर्ट करता है और सेक्शन के भीतर कुछ नहीं। यहाँ वह इकलौता स्तर रिकॉर्ड इंडेक्स के लिए इस्तेमाल हो चुका है, तो रिकॉर्ड की हर नेस्टिंग को की-नाम में ही रहना पड़ता है।
server ऑब्जेक्ट के अंदर port वाला रिकॉर्ड server.port नाम की एक पंक्ति बनाता है, नंबर वाले सेक्शन के भीतर। कुछ नहीं खोता, पर दो रिकॉर्ड जिनकी एक जैसी नेस्टिंग है वे संरचनात्मक रूप से कुछ साझा नहीं करते।
अनुमत होस्ट की सूची रखने वाला रिकॉर्ड hosts.0, hosts.1, hosts.2 नाम की की बनाता है। नंबर वाले सेक्शन के साथ मिलकर, नतीजा [2] सेक्शन के अंदर hosts.0 जैसी पंक्ति दे सकता है — पढ़ने लायक़ पर बदसूरत।
जो INI पार्सर सूची सपोर्ट करते हैं, वे आमतौर पर कॉमा-सेपरेटेड मान वाली एक पंक्ति चाहते हैं। अगर ऐप्लिकेशन का कोई नियम है, बदलने से पहले सोर्स में ऐरे जोड़ लीजिए।
JSON का true वैसे ही true लिखा जाता है, संख्या अपने अंकों में, null की के बाद कुछ न लिखकर, और स्ट्रिंग जस की तस। लाइन-ब्रेक वाली वैल्यू में बैकस्लैश-n लिखा जाता है, असली टूटन नहीं — यही अगली पंक्ति को टूटने से बचाता है।
सर्टिफ़िकेट, चाबियाँ और एम्बेडेड स्क्रिप्ट आमतौर पर इसकी वजह हैं, और बड़े आकार की वैल्यू फिर भी अपनी अलग फ़ाइल में रहना चाहिए जिसे INI सिर्फ़ पथ से इशारा करे।
INI टिप्पणियों को सपोर्ट करता है, JSON नहीं करता — तो बदली गई फ़ाइल बिना किसी टिप्पणी के आती है। चूँकि INI बनाने की वजह लगभग हमेशा यह होती है कि कोई इंसान उसे पढ़ने या बदलने वाला है, ये पंक्तियाँ लिखना पहला उपयोगी संपादन है।
कौन-सा सेक्शन पर्यावरण-विशिष्ट है, कौन-सी वैल्यू कहीं और से मेल खानी चाहिए — यह सब स्रोत नहीं रख सकता था और मंज़िल फ़ॉर्मैट इसी के लिए है।
ईमानदार नियम यह है — अगर नतीजे में कई नंबर वाले सेक्शन हैं और हर एक को असली नाम नहीं दिया जा सकता, बदलाव ने अलग सवाल का जवाब दिया है। INI एक चीज़ बताता है; रिकॉर्ड की सूची एक चीज़ नहीं है।
वही फ़ाइल से विकल्प एक क्लिक दूर हैं — CSV या वर्कबुक अगर इंसान देखेगा, SQL या Parquet अगर मशीन क्वेरी करेगी, TOML अगर असल में रिकॉर्ड की सूची कॉन्फ़िगरेशन फ़ाइल में चाहिए थी।
| NDJSON | INI | |
|---|---|---|
| पूरा नाम | Newline-Delimited JSON | INI कॉन्फ़िगरेशन |
| फ़ाइल एक्सटेंशन | .ndjson, .jsonl | .ini, .cfg, .conf |
| मीडिया टाइप | application/x-ndjson | text/plain |
| पहली बार प्रकाशित | 2013 | 1985 |
| लाइसेंस | खुला मानक | खुला मानक |
| आज की स्थिति | मौजूदा | पुराना, फिर भी हर जगह पढ़ा जाता है |
| ब्राउज़र में खुलता है | कोई ब्राउज़र नहीं | कोई ब्राउज़र नहीं |
| इसकी जगह विचारणीय | JSON, CSV | TOML, YAML |
दोनों तरफ़ के प्रोग्राम अलग हैं: NDJSON फ़ाइल jq और pandas में खुलती है और INI फ़ाइल Notepad और Visual Studio Code में — यानी नतीजा जिसके पास जाएगा, उसे दूसरी सूची में से कोई प्रोग्राम चाहिए होगा।
दोनों का निशाना अलग काम है: NDJSON का प्रोग्रामों के बीच डेटा ले जाना और स्ट्रीमिंग पर, INI का एडिटिंग पर। इस पर सोचना बनता है, क्योंकि जिस वजह से एक मौजूद है, आम तौर पर उसी वजह से दूसरा असुविधाजनक होता है।
INI 1985 से चला आ रहा है। Notepad और Visual Studio Code इस फ़ॉर्मेट को पढ़ लेते है।
INI 1985 में आया और NDJSON 2013 में। किसी को सौंपने के लिए आम तौर पर पुराना वाला ज़्यादा सुरक्षित रहता है; नया वाला वही काम कम बाइट में कर देता है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100।
NDJSON और INI सामग्री का वर्णन बुनियादी तौर पर अलग-अलग तरीक़ों से करते हैं। इसलिए यह कन्वर्ज़न नक़ल नहीं, पुनर्निर्माण है: ईमानदार, पर बाइट-दर-बाइट एक जैसा नहीं। INI में एक के अंदर एक होता ही नहीं। एक स्तर से गहरी संरचनाएँ चपटी होकर बिंदु वाली कुंजियाँ बन जाती हैं।
कन्वर्ज़न के लिए नहीं: वह उसी ब्राउज़र में होता है जो आपने पहले से खोल रखा है। नतीजा खोलने के लिए उसके बाद वही प्रोग्राम चाहिए जिससे आपका डिवाइस INI Configuration आम तौर पर दिखाता है।