आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
यहाँ आप TOML को JSON में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
TOML से JSON
TOML बरसों से Python और Rust पैकेजिंग का मानक रहा है, और किसी रिपॉज़िटरी के आस-पास का टूलिंग अक्सर उतना आगे नहीं पहुँचा। jq वाला CI चरण और कुछ नहीं, कोई Node स्क्रिप्ट जिसे Cargo.toml से वर्शन पढ़ना है, दो सौ रिपॉज़िटरी में निर्भरताएँ गिनने वाला डैशबोर्ड — ये सब JSON पढ़ सकते हैं, TOML बिना नई निर्भरता के नहीं पढ़ सकते।
यही वह मामला है जिसे यह कन्वर्ज़न सँभालता है, और यह साफ़ चलता है क्योंकि दोनों डेटा-मॉडल लगभग पूरी तरह मिलते हैं। TOML नेस्टिंग और सरणी वाली की-वैल्यू टेबल है, जो नेस्टिंग और सरणी वाली JSON ऑब्जेक्ट ही है। दिलचस्प हिस्सा वे चार जगहें हैं जहाँ TOML कुछ जानती है जो JSON नहीं जानती।
कोई ब्रैकेट वाला हेडर नेस्टेड ऑब्जेक्ट बनता है, और बिंदु-वाला हेडर कई परत नीचे नेस्टिंग बनाता है — किसी tool के लिए और उसके नीचे किसी linter के लिए लिखा हेडर एक ऑब्जेक्ट के भीतर दूसरी ऑब्जेक्ट बनाता है, तो JSON पथ हेडर से ठीक मेल खाता है।
दो-ब्रैकेट वाला हेडर टेबलों की सरणी है, और यह हर बार आने पर एक प्रविष्टि वाली JSON सरणी बन जाता है — जो Python पैकेज के authors, Rust क्रेट के binaries और किसी build के targets रखता है। यही वह संरचना है जिसकी सबसे ज़्यादा चिंता होती है और सबसे कम करनी चाहिए।
TOML इस परिवार का इकलौता फ़ॉर्मेट है जिसके पास असली कालिक प्रकार हैं: offset datetime, local datetime, local date और local time स्पेसिफ़िकेशन में हैं, और पार्सर उन्हें तारीख़ों के रूप में लौटाता है। JSON के पास कोई तारीख़-प्रकार नहीं, इसलिए हर एक स्ट्रिंग बनता है।
मान एक झुर्री के साथ बचे रहते हैं। offset datetime अपना offset रखता है, UTC पर सामान्य किए बिना। local date जैसे लिखा गया वैसा ही आता है। local time एक मिलीसेकंड हिस्सा पा लेता है जो उसके पास नहीं था।
TOML 1.0 को 64-बिट signed पूर्णांक चाहिए। JSON संख्याएँ IEEE double हैं और लगभग नौ क्वाड्रिलियन तक ही सटीक हैं। इस सीमा से ऊपर पूर्णांक रखने वाली TOML फ़ाइल पूरी तरह वैध है, और यहाँ का पार्सर ग़लत संख्या वाली JSON बनाने की बजाय एक त्रुटि के साथ रुक जाता है।
इनकार करना सही फ़ैसला है और अंधाधुंध टालने लायक़ नहीं। चुपचाप गोल किया कोई पहचानकर्ता हफ़्तों बाद किसी जॉइन में गड़बड़ी बनकर सामने आता है जो कहीं मेल नहीं खाता। ऐसा बड़ा मान हो तो स्रोत में उसे स्ट्रिंग के रूप में कोट कर दीजिए।
TOML के float में inf और nan शामिल हैं। JSON के पास दोनों नहीं, इसलिए serializer दोनों के लिए null लिखता है। यह मानक JavaScript बर्ताव है और यह उस तरह नुक़सान करता है जिसे कुछ भी रिपोर्ट नहीं करता — तय की गई अनंत ऊपरी सीमा और अनसेट ऊपरी सीमा JSON में एक ही चीज़ बन जाती हैं।
बारीक़ नुक़सान है टाइपिंग का। TOML किसी पूर्णांक और किसी float में फ़र्क़ करता है, इसलिए 1 और 1.0 अलग प्रकार के अलग मान हैं। JSON के पास एक ही संख्या-प्रकार है, और 1.0 को 1 के रूप में लिखा जाता है।
टेबल और कीज़ उसी क्रम में आती हैं जिस क्रम में TOML ने उन्हें घोषित किया, जो बदली गई फ़ाइल को पढ़ने लायक़ बनाए रखता है। आउटपुट दो-स्पेस इंडेंट के साथ है और एक नई-लाइन पर ख़त्म होता है।
अपवाद संख्यात्मक कीज़ हैं। कोई कोट की गई TOML की जो एक संख्या है — साल या पोर्ट से इंडेक्स करने वाले कॉन्फ़िग में मिलती है — अपने ऑब्जेक्ट की बाक़ी हर की से पहले, बढ़ते क्रम में लाई जाती है, क्योंकि JavaScript पूर्णांक-जैसी की को इसी तरह क्रम में रखता है।
नतीजा साधारी JSON है, इसलिए jq बिना किसी फ़्लैग के पढ़ लेता है: प्रोजेक्ट-वर्शन निकालना, निर्भरता-नाम गिनाना या किसी tool सेक्शन की जाँच करना — सब एक-लाइन एक्सप्रेशन हैं। यह आमतौर पर पूरी यात्रा की वजह है, और यह उस शेल स्क्रिप्ट को बदल देता है जो TOML फ़ाइल पर grep करने वाली थी।
यह वैलिडेशन का रास्ता भी खोलता है। JSON Schema परिपक्व और व्यापक रूप से लागू है, और TOML के स्पेसिफ़िकेशन में कोई स्कीमा-भाषा नहीं, इसलिए बदलकर फिर वैलिडेट करना कई रिपॉज़िटरी में घर के नियम लागू करने का असली तरीक़ा है।
TOML टिप्पणियों का समर्थन करता है और उन्हें भरपूर इस्तेमाल करता है: कोई निर्भरता क्यों पिन की गई, किसी वर्कअराउंड के पास टिकट-नंबर, कौन-सा वातावरण किस सेटिंग पर लागू होता है। RFC 8259 के तहत JSON में कोई टिप्पणी-सिंटैक्स नहीं, इसलिए कुछ भी नहीं पहुँचता।
यही रिश्ते की दिशा तय कर देता है। TOML वह फ़ाइल है जिसे लोग संपादित और रिव्यू करते हैं, और JSON उससे जब भी किसी को पढ़ना हो तब बनाई जाती है। रिपॉज़िटरी में JSON को TOML के साथ चेक-इन करना सच की दो प्रतियाँ बनाता है जो बहक जाएँगी।
अगर पढ़ना किसी build चरण की बजाय किसी ऐप्लिकेशन के भीतर हो रहा है, तो पार्सर इस्तेमाल कीजिए। हर बड़ी भाषा के पास एक है — Python के पास कई वर्शन से tomllib मानक लाइब्रेरी में है, Rust, Go और JavaScript के पास अच्छे से बनाए रखे विकल्प हैं। फ़ाइल सीधे पढ़ना वे कालिक प्रकार और पूर्णांक-दशमलव फ़र्क़ रखता है जो यह कन्वर्ज़न सपाट कर देती है।
यह कन्वर्टर सीमा पर अपनी जगह कमाता है: एक बार की जाँच, कोई CI चरण जहाँ निर्भरता जोड़ना ज़्यादा झंझट है, या कोई पाइपलाइन जिसके अगले चरण को सिर्फ़ JSON चाहिए। सब कुछ ब्राउज़र में चलता है, तो किसी क्रेडेंशियल वाले निजी कॉन्फ़िग को यहाँ छोड़ना सुरक्षित है।
| TOML | JSON | |
|---|---|---|
| पूरा नाम | Tom's Obvious Minimal Language | JavaScript Object Notation |
| फ़ाइल एक्सटेंशन | .toml | .json |
| मीडिया टाइप | application/toml | application/json |
| पहली बार प्रकाशित | 2013 | 2001 |
| विनिर्देश | TOML 1.0 | RFC 8259 |
| लाइसेंस | खुला मानक | खुला मानक |
| आज की स्थिति | मौजूदा | मौजूदा |
| ब्राउज़र में खुलता है | कोई ब्राउज़र नहीं | हर ब्राउज़र |
| इसकी जगह विचारणीय | YAML, INI | XML, YAML, NDJSON |
टिप्पणियाँ साथ नहीं जातीं। TOML में फ़ाइल के साथ समझाइश लिखी जा सकती है और JSON में उसके लिए कोई वाक्य-रचना ही नहीं, इसलिए हर समझाने वाली पंक्ति छूट जाती है — और चोट ठीक उन्हीं फ़ाइलों पर पड़ती है जिन पर टिप्पणियाँ लिखी जाती हैं: वह कॉन्फ़िगरेशन जिसे किसी और को सँभालना है।
कुछ नहीं खोता। TOML और JSON — दोनों अपनी सामग्री बिना नुक़सान सँभालते हैं: यह कन्वर्ज़न पैकिंग बदलता है, गुणवत्ता नहीं, और आप इसे दोहरा सकते हैं बिना इस डर के कि नुक़सान जमा होता जाएगा।
JSON को हर मौजूदा ब्राउज़र खोल लेता है। TOML को इतने भी नहीं। अगर फ़ाइल किसी वेब पेज या किसी फ़ॉर्म तक जा रही है, तो आम तौर पर इस कन्वर्ज़न की पूरी वजह यही है।
Visual Studio Code TOML और JSON — दोनों पढ़ लेता है, इसलिए आप नतीजे को असली फ़ाइल के बग़ल में रखकर देख सकते हैं, बिना दूसरा प्रोग्राम खोले।
दोनों का निशाना अलग काम है: TOML का एडिटिंग पर, JSON का प्रोग्रामों के बीच डेटा ले जाना और वेब पर। इस पर सोचना बनता है, क्योंकि जिस वजह से एक मौजूद है, आम तौर पर उसी वजह से दूसरा असुविधाजनक होता है।
TOML 2013 में आया। यह TOML 1.0 में तय किया गया है, और अगर फ़ाइल को उस औज़ार से ज़्यादा जीना है जिसने उसे लिखा, तो यह बात क़ीमती है।
JSON 2001 से चला आ रहा है, और RFC 8259 में तय किया गया है। Visual Studio Code, jq और Postman इस फ़ॉर्मेट को पढ़ लेते है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100।
नहीं। JSON वही सामग्री बिना कुछ फेंके सँभालता है: नतीजा गुणवत्ता में असली फ़ाइल जैसा ही होता है।
कुछ नहीं खोता। TOML और JSON — दोनों अपनी सामग्री बिना नुक़सान सँभालते हैं: यह कन्वर्ज़न पैकिंग बदलता है, गुणवत्ता नहीं, और आप इसे दोहरा सकते हैं बिना इस डर के कि नुक़सान जमा होता जाएगा।
टिप्पणियाँ साथ नहीं जातीं। TOML में फ़ाइल के साथ समझाइश लिखी जा सकती है और JSON में उसके लिए कोई वाक्य-रचना ही नहीं, इसलिए हर समझाने वाली पंक्ति छूट जाती है — और चोट ठीक उन्हीं फ़ाइलों पर पड़ती है जिन पर टिप्पणियाँ लिखी जाती हैं: वह कॉन्फ़िगरेशन जिसे किसी और को सँभालना है।