आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
यहाँ आप XML को JSON में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
XML से JSON
XML जानकारी तीन जगह रखता है — एलिमेंट नाम, एट्रिब्यूट और टेक्स्ट — और JSON के पास सिर्फ़ की और वैल्यू है। हर एलिमेंट एक की बनता है जिसकी वैल्यू उसके बच्चों का ऑब्जेक्ट है, हर एट्रिब्यूट @ से शुरू होने वाली की बनता है।
सिर्फ़ टेक्स्ट वाला एलिमेंट सादी स्ट्रिंग बन जाता है, बिना किसी रैपर ऑब्जेक्ट के। यह असंगति टालने लायक़ नहीं — किसी पथ की वैल्यू कभी स्ट्रिंग होती है, कभी ऑब्जेक्ट, इस पर निर्भर कि मूल एलिमेंट में एट्रिब्यूट था या नहीं।
यही सबसे महँगी बात है बदली हुई XML इस्तेमाल करने में। XML यह नहीं बताता कि कौन-सा एलिमेंट दोहराता है — सिर्फ़ स्कीमा बताती है, और पार्सर स्कीमा नहीं पढ़ रहा। तो एक item वाला चैनल ऑब्जेक्ट बनाता है, दो item वाला ऐरे।
पूरे RSS फ़ीड के लिए लिखा कोड उस दिन टूटता है जब फ़ीड में सिर्फ़ एक एंट्री हो। हर संग्रह को कोड की शुरुआत में ऐरे में बदल दीजिए, इससे पहले कि कुछ और उसे छुए।
कोई SOAP envelope अपने प्रीफ़िक्स सहित आता है — soap:Envelope ठीक "soap:Envelope" नाम की की बनता है, और xmlns घोषणाएँ "@xmlns:soap" जैसी एट्रिब्यूट बनती हैं। कुछ हल नहीं होता, कुछ हटाया नहीं जाता।
यह ईमानदार है और नाज़ुक भी, क्योंकि प्रीफ़िक्स मनमाना है। अगर आप कंज़्यूमर कंट्रोल करते हैं, कोलन के बाद वाले स्थानीय नाम पर मैच कीजिए, पूरी की पर नहीं।
वर्शन और एन्कोडिंग डिक्लेरेशन से शुरू होने वाला दस्तावेज़ "?xml" नाम की टॉप-लेवल की बनाता है, रूट एलिमेंट की के साथ बैठकर। यह दस्तावेज़ की सामग्री का हिस्सा नहीं और फिर भी आपके JSON में है।
इसे नज़रअंदाज़ या मिटाकर संभालिए, पर यह मत मान लीजिए कि रूट एलिमेंट इकलौती टॉप-लेवल की है। जो कोड पहली की को रूट मानकर पढ़ता है, वह डिक्लेरेशन वाली किसी भी फ़ाइल पर ग़लत पड़ेगा।
संख्या जैसी दिखने वाली वैल्यू JSON संख्या बन जाती है, एट्रिब्यूट और एलिमेंट टेक्स्ट दोनों में। version="1.0" 1 बन जाता है, id="007" बनता है 7।
यह किसी गिनती के लिए सुविधाजनक है और किसी अपारदर्शी टोकन के लिए नुक़सानदायक — ऑर्डर नंबर, प्रोडक्ट कोड, पोस्टकोड सब इसी तरह टूटते हैं, बिना कोई एरर दिए।
कमेंट बिना निशान के छूट जाते हैं। CDATA अनरैप होता है — भीतर जो था वह सादी स्ट्रिंग बन जाता है, तो HTML फ़्रैगमेंट एंगल-ब्रैकेट वाले टेक्स्ट की तरह आता है।
टेक्स्ट-फिर-चाइल्ड-फिर-टेक्स्ट वाला मिश्रित कंटेंट सबसे मुश्किल मामला है — दोनों टेक्स्ट #text में जुड़ जाते हैं, बीच में कहाँ चाइल्ड था इसका कोई निशान नहीं बचता।
सेल्फ़-क्लोज़िंग एलिमेंट और ख़ाली बॉडी वाला एलिमेंट दोनों ख़ाली स्ट्रिंग बनते हैं। JSON के पास null उपलब्ध है और इस्तेमाल नहीं होता — ख़ाली एलिमेंट "" है, null नहीं।
जो फ़र्क़ ग़ायब होता है वह है ग़ायब एलिमेंट और मौजूद-पर-ख़ाली एलिमेंट के बीच का। जहाँ यह मायने रखे, वैल्यू के बजाय की की मौजूदगी जाँचिए।
मिलाकर देखें तो SOAP जवाब नेस्टेड की के तौर पर पढ़ता है — envelope की, उसके अंदर body, फिर ऑपरेशन का जवाब, फिर पेलोड। हर स्तर अपना प्रीफ़िक्स रखता है।
फ़ॉल्ट पहले टेस्ट करने लायक़ मामला है — SOAP फ़ॉल्ट सफल जवाब से बिल्कुल अलग एलिमेंट संरचना रखते हैं, तो एरर का JSON बिलकुल अलग दिखता है।
आउटपुट दो-स्पेस इंडेंट के साथ आता है, तो यह रिव्यू में अच्छा पढ़ा जाता है और सीधे टेस्ट फ़िक्सचर में चिपकता है। एक असली जवाब बदलकर रिपॉज़िटरी में चेक-इन कर देना कंज़्यूमर को कुछ ईमानदार टेस्ट करने लायक़ देता है।
तीन आदतें लगभग हर मुश्किल को ढक लेती हैं — जो दोहरा सकता है उसे ऐरे में बदलिए, पहचानकर्ता को स्ट्रिंग की तरह तुलनिए, नेमस्पेस वाली की को उसके स्थानीय हिस्से पर मैच कीजिए।
| XML | JSON | |
|---|---|---|
| पूरा नाम | Extensible Markup Language | JavaScript Object Notation |
| फ़ाइल एक्सटेंशन | .xml | .json |
| मीडिया टाइप | application/xml | application/json |
| पहली बार प्रकाशित | 1998 | 2001 |
| प्रकाशक | W3C | — |
| विनिर्देश | XML 1.0 | RFC 8259 |
| लाइसेंस | खुला मानक | खुला मानक |
| आज की स्थिति | मौजूदा | मौजूदा |
| ब्राउज़र में खुलता है | हर ब्राउज़र | हर ब्राउज़र |
| इसकी जगह विचारणीय | YAML | YAML, NDJSON |
टिप्पणियाँ साथ नहीं जातीं। XML में फ़ाइल के साथ समझाइश लिखी जा सकती है और JSON में उसके लिए कोई वाक्य-रचना ही नहीं, इसलिए हर समझाने वाली पंक्ति छूट जाती है — और चोट ठीक उन्हीं फ़ाइलों पर पड़ती है जिन पर टिप्पणियाँ लिखी जाती हैं: वह कॉन्फ़िगरेशन जिसे किसी और को सँभालना है।
Visual Studio Code XML और JSON — दोनों पढ़ लेता है, इसलिए आप नतीजे को असली फ़ाइल के बग़ल में रखकर देख सकते हैं, बिना दूसरा प्रोग्राम खोले।
XML W3C का फ़ॉर्मेट है, जो 1998 में आया। यह XML 1.0 में तय किया गया है, और अगर फ़ाइल को उस औज़ार से ज़्यादा जीना है जिसने उसे लिखा, तो यह बात क़ीमती है।
JSON 2001 से चला आ रहा है, और RFC 8259 में तय किया गया है। Visual Studio Code, jq और Postman इस फ़ॉर्मेट को पढ़ लेते है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100।
XML और JSON सामग्री का वर्णन बुनियादी तौर पर अलग-अलग तरीक़ों से करते हैं। इसलिए यह कन्वर्ज़न नक़ल नहीं, पुनर्निर्माण है: ईमानदार, पर बाइट-दर-बाइट एक जैसा नहीं। XML के गुण और लिखावट वाली गाँठें — दोनों कुंजी बन जाते हैं, और यह फ़ैसला कन्वर्टर आपकी जगह ख़ुद करता है।
टिप्पणियाँ साथ नहीं जातीं। XML में फ़ाइल के साथ समझाइश लिखी जा सकती है और JSON में उसके लिए कोई वाक्य-रचना ही नहीं, इसलिए हर समझाने वाली पंक्ति छूट जाती है — और चोट ठीक उन्हीं फ़ाइलों पर पड़ती है जिन पर टिप्पणियाँ लिखी जाती हैं: वह कॉन्फ़िगरेशन जिसे किसी और को सँभालना है।
यह पेज एक को दूसरे में बदलता है। अगर आप बदल नहीं रहे बल्कि चुन रहे हैं, तो XML vs JSON बताता है कि किसे कब लेना है और कौन किस काम में कमज़ोर है।