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

यहाँ आप TOML को NDJSON में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।

कहाँ चलता है आपके ब्राउज़र में। फ़ाइल कभी अपलोड नहीं होती।
बिना नुक़सान कुछ नहीं छोड़ा जाता। TOML में जो था, NDJSON में ठीक वही रहता है।
फ़ाइल आकार की सीमा हर फ़ाइल 100 MB तक, मुफ़्त, बिना खाते के।

एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।

TOML से NDJSON

एक कॉन्फ़िग फ़ाइल, एक लाइन, और यही सही इकाई क्यों है

TOML दस्तावेज़ एक table है। TOML फ़ाइल जो शीर्ष स्तर पर सूची हो, ऐसी कोई चीज़ नहीं — स्पेसिफ़िकेशन इसकी इजाज़त नहीं देता — तो जो रिकॉर्ड सीमा newline-delimited JSON को चाहिए वह किसी एक फ़ाइल के भीतर कभी नहीं आती। पूरा दस्तावेज़ एक लाइन बन जाता है।

ज़्यादातर स्रोत के लिए यह सीमा होती। यहाँ यह समस्या की बनावट है: कोई pyproject.toml को टुकड़ों में बँटा नहीं चाहता, और जो कोई इसे NDJSON में बदलता है वह ऐसा संग्रह बना रहा है जहाँ हर फ़ाइल एक रिकॉर्ड है। फ़ॉर्मेट की इकाई और सवाल की इकाई यहाँ मेल खाती है।

किसी workspace में हर Cargo.toml की सूची बनाना

तरीक़ा है: हर फ़ाइल बदलिए, लाइन को बढ़ते हुए आउटपुट में जोड़ते जाइए। हर लाइन पूरी तरह अपने आप में एक JSON मान है और कुछ भी फ़ाइल को नहीं लपेटता — न कोई घेरने वाला ऐरे, न रिकॉर्ड के बीच कॉमा — तो जोड़ना ही पूरी मिलावट है।

इससे आपको एक ऐसा डेटासेट मिलता है जिससे सवाल पूछे जा सकते हैं। कौन-से crate किसी ख़ास dependency संस्करण को pin करते हैं, कौन-से पैकेज कोई लाइसेंस नहीं बताते — ये सब संग्रह पर एक क्वेरी बन जाते हैं, डायरेक्ट्री घूमने वाली स्क्रिप्ट की बजाय।

वह फ़ील्ड जो बदलाव आपके लिए नहीं जोड़ सकता

बिना स्रोत वाला रिकॉर्ड इन्वेंट्री में लगभग बेकार है। कन्वर्टर फ़ाइल की सामग्री पढ़ता है और कुछ नहीं — इसे पथ, रिपॉज़िटरी या कमिट नहीं पता — तो जो लाइन बनती है उसमें कोई फ़ील्ड नहीं बताता वह कहाँ से आई।

इसे ख़ुद दो में से किसी एक पल पर जोड़िए। जोड़ते समय `jq` का पास हर लाइन में path कुंजी डाल सकता है, जो TOML फ़ाइलों को अछूता रखता है। या हर TOML फ़ाइल के भीतर एक कुंजी इसका नाम रखे, जो हर भावी बदलाव में बचती है पर दूसरों की फ़ाइलें संपादित करना है।

एक लाइन में क्या है

Compact JSON: कोई इंडेंटेशन नहीं, कोलन के बाद कोई स्पेस नहीं, कुंजियाँ TOML के घोषित क्रम में, आख़िर में नई लाइन। Table नेस्टेड ऑब्जेक्ट बनते हैं और table की ऐरे ऑब्जेक्ट की ऐरे बनती हैं, तो author सूची या build target का सेट क्वेरी इंजन की उम्मीद के हिसाब से आता है।

लाइन उतनी लंबी है जितना कॉन्फ़िग। pyproject.toml कुछ किलोबाइट का है और बना lock-adjacent कॉन्फ़िग कहीं बड़ा हो सकता है, और लाइन-दर-लाइन पढ़ने वाले reader को पूरी लाइन मेमोरी में रखनी पड़ती है।

टाइप्ड मान स्ट्रीम में पार जाते समय

TOML के पास असली समय-संबंधी टाइप हैं और JSON के पास नहीं, तो हर date और datetime स्ट्रिंग बन जाती है। Offset बचते हैं, UTC में सामान्य नहीं होते, local date जैसे लिखे थे वैसे ही आते हैं, और local time को एक मिलीसेकंड हिस्सा मिल जाता है जो स्रोत में नहीं था।

दो float लिटरल ऐसे तरीक़े से लॉसी हैं जो कोई नहीं बताता: inf और nan वैध TOML हैं और JSON में null बन जाते हैं, तो तय की गई अनंत सीमा और तय न की गई सीमा डेटासेट में एक जैसी दिखती हैं। पूर्णांक-float का फ़र्क़ भी चला जाता है, क्योंकि 1.0, 1 के तौर पर serialise होता है।

वह TOML फ़ाइल जो बदलाव रोक देती है

TOML 1.0 को 64-बिट signed पूर्णांक चाहिए और JSON नंबर IEEE double हैं, तो क़रीब नौ क्वाड्रिलियन से ऊपर का मान सटीक तौर पर नहीं दिखाया जा सकता। Parser लाइन का नाम लेती त्रुटि के साथ रुक जाता है, आपके डेटासेट में गोल संख्या लिखने की बजाय।

किसी इन्वेंट्री के लिए यही सही व्यवहार है, जहाँ ग़लत संख्या दस हज़ार रिकॉर्ड में सही से अलग नहीं दिखेगी। ऐसा हो, तो स्रोत फ़ाइल में उस मान को स्ट्रिंग के तौर पर quote कर दीजिए — यह हर असली मामले में मात्रा नहीं, पहचानकर्ता होता है।

रिकॉर्ड जो एक जैसी कुंजी साझा नहीं करते

अलग-अलग प्रोजेक्ट के कॉन्फ़िग एक जैसे सेक्शन नहीं रखेंगे। एक तीन linter वाला tool table घोषित करता है, अगला कोई नहीं, तीसरा ऐसी कुंजी इस्तेमाल करता है जो कोई और नहीं करता। हर लाइन सिर्फ़ उतनी कुंजी रखती है जितनी उसकी फ़ाइल में थीं, जो उसी संग्रह को टेबल में समेटकर कॉलम को हर चीज़ का मिलन बनाने से बेहतर है।

गंतव्य तय करता है इसकी क़ीमत कितनी है। Schema-on-read स्टोर बिखरे रिकॉर्ड को सहज संभालता है। तय स्कीमा वाला loader बाहरी को नकारेगा या फ़ील्ड छोड़ देगा। लक्ष्य तय करने से पहले संग्रह की सबसे चौड़ी और सबसे सँकरी फ़ाइल का सैंपल लीजिए।

टिप्पणियाँ, और डेटासेट में जो छूट रहा है

TOML टिप्पणियाँ कॉन्फ़िग की तर्कशीलता हैं: कोई dependency क्यों pin है, कोई workaround किस टिकट से जुड़ा है, कोई जादुई संख्या क्या मतलब रखती है। NDJSON प्रति-लाइन JSON है और JSON में टिप्पणी वाक्य-रचना नहीं, तो यह सब डेटासेट से ग़ायब है।

यह इन्वेंट्री के लिए स्वीकार्य है, माइग्रेशन के लिए नहीं। कौन-से पैकेज संस्करण pin करते हैं यह पूछने वाले को आसपास का गद्य नहीं चाहिए; TOML फ़ाइलों को इस डेटा से बनी किसी चीज़ से बदलने वाला उसे फेंक रहा होगा। स्ट्रीम को कॉन्फ़िग के बारे में सवाल पूछने के लिए इस्तेमाल कीजिए।

एक JSON फ़ाइल कब बेहतर जवाब है

अगर आपको सिर्फ़ एक कॉन्फ़िग पढ़नी है, इसे JSON में बदलिए। इंडेंट JSON पढ़ने लायक़ है, jq इसे वैसे ही संभालता है, और एक-लाइन फ़ाइल जोड़ने के अलावा हर मक़सद के लिए बुरी है। NDJSON वहाँ अपनी जगह कमाता है जहाँ कई फ़ाइलें हों और वे किसी चीज़ में जा रही हों।

दूसरी सीमा है दोहराव। अगर इन्वेंट्री को समय-सारिणी पर दोबारा बनाना है, यह काम ऐसी स्क्रिप्ट में जाना चाहिए जो पेड़ घूमकर, असली TOML लाइब्रेरी से हर फ़ाइल पार्स करके, पथ के साथ लाइन बनाए। यह कन्वर्टर पहली बार डेटासेट बनाने और यह तय करने के लिए है कि इसके जवाब स्वचालित करने लायक़ हैं या नहीं।

TOML को NDJSON में ऐसे बदलें

अपनी TOML फ़ाइल इस पेज पर छोड़ें, या चुनने के लिए दबाएँ।
लक्ष्य के रूप में NDJSON चुनें। कन्वर्ज़न आपके ब्राउज़र में होता है और फ़ाइल अपलोड नहीं होती।
तैयार NDJSON फ़ाइल डाउनलोड कर लें।

TOML या NDJSON: क्या बदलता है

TOML और NDJSON की तुलना
	TOML	NDJSON
पूरा नाम	Tom's Obvious Minimal Language	Newline-Delimited JSON
फ़ाइल एक्सटेंशन	.toml	.ndjson, .jsonl
मीडिया टाइप	application/toml	application/x-ndjson
पहली बार प्रकाशित	2013	2013
विनिर्देश	TOML 1.0	—
लाइसेंस	खुला मानक	खुला मानक
आज की स्थिति	मौजूदा	मौजूदा
ब्राउज़र में खुलता है	कोई ब्राउज़र नहीं	कोई ब्राउज़र नहीं
इसकी जगह विचारणीय	YAML, JSON, INI	JSON, CSV

क्या खो जाता है

टिप्पणियाँ साथ नहीं जातीं। TOML में फ़ाइल के साथ समझाइश लिखी जा सकती है और NDJSON में उसके लिए कोई वाक्य-रचना ही नहीं, इसलिए हर समझाने वाली पंक्ति छूट जाती है — और चोट ठीक उन्हीं फ़ाइलों पर पड़ती है जिन पर टिप्पणियाँ लिखी जाती हैं: वह कॉन्फ़िगरेशन जिसे किसी और को सँभालना है।

क्या बचा रहता है

कुछ नहीं खोता। TOML और NDJSON — दोनों अपनी सामग्री बिना नुक़सान सँभालते हैं: यह कन्वर्ज़न पैकिंग बदलता है, गुणवत्ता नहीं, और आप इसे दोहरा सकते हैं बिना इस डर के कि नुक़सान जमा होता जाएगा।

नतीजा खोलना

दोनों तरफ़ के प्रोग्राम अलग हैं: TOML फ़ाइल Visual Studio Code में खुलती है और NDJSON फ़ाइल jq और pandas में — यानी नतीजा जिसके पास जाएगा, उसे दूसरी सूची में से कोई प्रोग्राम चाहिए होगा।

कौन-सा फ़ॉर्मेट किस काम के लिए है

दोनों का निशाना अलग काम है: TOML का एडिटिंग पर, NDJSON का प्रोग्रामों के बीच डेटा ले जाना और स्ट्रीमिंग पर। इस पर सोचना बनता है, क्योंकि जिस वजह से एक मौजूद है, आम तौर पर उसी वजह से दूसरा असुविधाजनक होता है।

TOML 2013 में आया। यह TOML 1.0 में तय किया गया है, और अगर फ़ाइल को उस औज़ार से ज़्यादा जीना है जिसने उसे लिखा, तो यह बात क़ीमती है।

NDJSON 2013 से चला आ रहा है। jq और pandas इस फ़ॉर्मेट को पढ़ लेते है।

TOML से NDJSON: आम सवाल

क्या मेरी TOML फ़ाइल कहीं अपलोड होती है?

नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो।

क्या TOML को NDJSON में बदलना मुफ़्त है?

हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100।

TOML को NDJSON में बदलने पर क्या गुणवत्ता जाती है?

नहीं। NDJSON वही सामग्री बिना कुछ फेंके सँभालता है: नतीजा गुणवत्ता में असली फ़ाइल जैसा ही होता है।

क्या TOML से NDJSON बिना नुक़सान का है?