JSON से XML

JSON और XML, दो प्रारूप, दो युग

XML (Extensible Markup Language) को W3C ने 10 फ़रवरी 1998 को अनुशंसा के रूप में मानकीकृत किया, W3C XML 1.0 spec, जिसे Tim Bray, Jean Paoli और C.M. Sperberg-McQueen ने संपादित किया। XML SGML (पुरानी «Standard Generalised Markup Language», ISO 8879:1986) से सबसे जटिल विशेषताओं को हटाकर और कुछ ऐसा उत्पादन करके निकला जो वेब वास्तविक रूप से उपयोग कर सके। 21वीं सदी के पहले दशक के लिए मोटे तौर पर, XML किसी भी संरचित डेटा एक्सचेंज के लिए मान्यता प्राप्त प्रारूप था, SOAP वेब सेवाएँ, RSS फ़ीड (RSS 2.0, Dave Winer, 2002), Atom (RFC 4287, 2005), Microsoft Office के Open XML प्रारूप (.docx/.xlsx/.pptx, ISO/IEC 29500:2008), Android XML लेआउट, Java property फ़ाइलें, लगभग हर सर्वर फ़्रेमवर्क में कॉन्फ़िगरेशन। XML की ताक़त namespaces, attributes, mixed content (text और child elements मिश्रित) और एक समृद्ध स्कीमा इकोसिस्टम (DTD, XML Schema 1.1, Relax NG) हैं। इसकी कमज़ोरी verbosity है, हर मान एक खुलने और बंद होने वाला टैग ले जाता है।

JSON (JavaScript Object Notation) को 2001 में Douglas Crockford ने निर्दिष्ट किया, json.org वेबसाइट और उनका मूल निबंध «JSON: The Fat-Free Alternative to XML»। JSON जानबूझकर JavaScript ऑब्जेक्ट लिटरल सिंटैक्स का एक उपसमुच्चय है: ऑब्जेक्ट्स, ऐरे, स्ट्रिंग्स, संख्याएँ, true/false/null। जुलाई 2006 में RFC 4627 के रूप में मानकीकृत, मार्च 2014 में RFC 7159 और दिसंबर 2017 में RFC 8259 (वर्तमान STD 90 मानक, ECMA द्वारा भी ECMA-404 के रूप में प्रकाशित) के रूप में परिष्कृत। JSON का वेब APIs पर XML से अधिग्रहण लगभग 2008-2014 में हुआ, समय single-page apps के उत्थान और मोबाइल API युग से मेल खाता है। आज लगभग हर सार्वजनिक API JSON के रूप में स्वयं को दस्तावेज़ करती है; XML मुख्यतः एंटरप्राइज़ इंटीग्रेशन, दस्तावेज़ प्रारूप, कॉन्फ़िगरेशन फ़ाइलें और फ़ीड प्रारूपों में जीवित है। दोनों प्रारूप सक्रिय उपयोग में बने हुए हैं क्योंकि वे अलग चीज़ें अच्छी तरह से एनकोड करते हैं: JSON सरल प्रकारों और पूर्वानुमेय आकार वाले संरचित डेटा के लिए सही है; XML मिश्रित सामग्री, attributes, namespaces और कठोर schemas वाले दस्तावेज़ों के लिए सही है।

जब आपको वास्तव में JSON को XML में बदलने की ज़रूरत होती है

• JSON-केवल क्लाइंट से SOAP वेब सेवा को कॉल करना। SOAP डिज़ाइन से XML-आधारित है (SOAP envelope, WSDL सेवा विवरण, XSD schemas)। यदि आपके पास JSON रूप में डेटा है और आपको SOAP अनुरोध बॉडी बनाने की ज़रूरत है, तो JSON-से-XML सेतु है। एंटरप्राइज़ इंटीग्रेशन में आम जब आधुनिक माइक्रोसर्विसेज़ को लेगेसी SOAP एंडपॉइंट्स (बैंकिंग, सरकार, बीमा, स्वास्थ्य देखभाल इंटरचेंज सिस्टम) से बात करने की आवश्यकता होती है।
• JSON डेटा से Office Open XML दस्तावेज़ उत्पन्न करना। .docx, .xlsx और .pptx प्रारूप XML फ़ाइलों के ZIP अभिलेखागार हैं। JSON-समर्थित डेटा से Office दस्तावेज़ों को प्रोग्रामेटिक रूप से उत्पन्न या संशोधित करने के लिए, JSON-से-XML रूपांतरण आपके एप्लिकेशन की डेटा परत और दस्तावेज़ जनरेशन लाइब्रेरी के बीच की सीमा पर होता है।
• JSON सामग्री से RSS या Atom फ़ीड उत्पन्न करना। ब्लॉग, समाचार साइटें और पॉडकास्ट प्लेटफ़ॉर्म सिंडिकेशन के लिए RSS/Atom फ़ीड्स उत्सर्जित करते हैं। यदि आपका CMS लेखों को JSON के रूप में संग्रहीत करता है, तो फ़ीड-जनरेशन चरण JSON प्रविष्टियों को उस XML प्रारूप में बदलता है जिसकी फ़ीड-रीडर इकोसिस्टम अपेक्षा करता है।
• लेगेसी एप्लिकेशन के लिए XML कॉन्फ़िगरेशन फ़ाइलें उत्पन्न करना। कई पुराने एंटरप्राइज़ एप्लिकेशन (Java एप्लिकेशन सर्वर, .NET कॉन्फ़िगरेशन फ़ाइलें, Spring XML एप्लिकेशन कॉन्टेक्स्ट) अपनी कॉन्फ़िगरेशन को XML के रूप में उपयोग करते हैं। आधुनिक infrastructure-as-code टूलिंग आम तौर पर YAML या JSON में काम करती है, इसलिए एक JSON-से-XML रूपांतरण deployment pipeline में बैठता है।
• एक XSLT रूपांतरण में डेटा फ़ीड करना। XSLT (XSL Transformations, Michael Kay का स्पेसिफ़िकेशन, W3C अनुशंसा) मानक XML रूपांतरण भाषा है और XML इनपुट का उपयोग करती है। यदि आपका डेटा JSON में शुरू होता है और आपका रिपोर्टिंग इंजन XSLT-आधारित है, तो रूपांतरण इनपुट सीमा पर होता है।
• Android संसाधन फ़ाइलें उत्पन्न करना। Android की strings.xml, colors.xml, dimens.xml और लेआउट फ़ाइलें XML हैं। स्थानीयकरण पाइपलाइन्स जो संपादन की सुविधा के लिए स्ट्रिंग्स को JSON में संग्रहीत करती हैं, बिल्ड के समय XML में बदल देती हैं।

रूपांतरण मैपिंग, कहाँ जानकारी जीवित रहती है और कहाँ खो जाती है

JSON और XML की अलग संरचनात्मक प्राथमिकताएँ हैं, इसलिए किसी भी रूपांतरण को विकल्प चुनने पड़ते हैं। मानक JSON-से-XML मैपिंग जिसका अधिकांश कन्वर्टर (यह भी शामिल) पालन करते हैं:

• JSON ऑब्जेक्ट्स XML तत्व बन जाते हैं। प्रत्येक कुंजी टैग नाम के रूप में कुंजी के साथ एक चाइल्ड तत्व बन जाती है। {"name": "Alice"} <name>Alice</name> बन जाता है।
• JSON ऐरे दोहराए गए चाइल्ड तत्व बन जाते हैं। {"items": [1, 2, 3]} <items> रैपर के अंदर तीन <item>1</item><item>2</item><item>3</item> चाइल्ड बन जाता है। (विभिन्न कन्वर्टर ऐरे-तत्व नाम के लिए विभिन्न परंपराओं का उपयोग करते हैं; कुछ माता-पिता का नाम एकवचन में उपयोग करते हैं, कुछ एक स्थिर <item> का उपयोग करते हैं।)
• स्ट्रिंग्स, संख्याएँ, बूलियन तत्व की पाठ्य सामग्री बन जाते हैं। प्रकार जानकारी संरक्षित नहीं होती, XML सभी पाठ को वर्ण डेटा के रूप में मानता है, इसलिए एक राउंडट्रिप XML → parse → JSON पर वापस serialise संख्याओं को उद्धृत स्ट्रिंग्स के रूप में उत्सर्जित करेगा जब तक कि उपभोक्ता प्रकार अनुमान लागू न करे।
• null एक स्व-बंद होने वाला रिक्त तत्व बन जाता है। {"middle_name": null} <middle_name/> बन जाता है। कुछ कन्वर्टर इसके बजाय xsi:nil="true" का उपयोग करते हैं।
• रूट तत्व सब कुछ लपेटता है। JSON शीर्ष-स्तरीय ऐरे या स्केलर की अनुमति देता है; XML बिल्कुल एक रूट तत्व की मांग करता है। <root> रैपर (यहाँ कॉन्फ़िगरेबल) पारंपरिक समाधान है।

रूपांतरण में खोई जानकारी: संख्याओं और स्ट्रिंग्स के बीच JSON का भेद, true/false और "true"/"false" स्ट्रिंग्स के बीच JSON का भेद, JSON का ऐरे बनाम ऑब्जेक्ट भेद (जब एक ऐरे दोहराए गए तत्व बन जाता है तो आप केवल XML से नहीं बता सकते कि स्रोत में एक-तत्व ऐरे था या एकल मान)। संभावित रूप से प्राप्त लेकिन साधारण कन्वर्टर्स द्वारा उपयोग नहीं की गई जानकारी: XML attributes (एक JSON ऑब्जेक्ट चाइल्ड तत्वों के बजाय कुंजियों को attributes में मैप कर सकता है), XML namespaces (JSON के पास इसके बराबर कुछ नहीं है), CDATA सेक्शन (XML विशेष वर्णों वाले पाठ को एम्बेड करने के लिए)। एक राउंडट्रिप-सुरक्षित JSON-से-XML रूपांतरण के लिए जो प्रकार जानकारी को संरक्षित करता है, BadgerFish परंपरा या Parker परंपरा JSON प्रकारों को namespaced XML attributes के रूप में एनकोड करते हैं, यह उपकरण राउंडट्रिप-सुरक्षित रूप के बजाय सरल, अधिक पठनीय रूप उत्पन्न करता है।

XML टैग-नाम बाधाएँ जो JSON कुंजियों के पास नहीं हैं

JSON ऑब्जेक्ट कुंजियाँ मनमानी स्ट्रिंग्स हैं, कोई भी Unicode अनुमति है। XML तत्व नाम बहुत अधिक प्रतिबंधित हैं: उन्हें एक अक्षर या अंडरस्कोर से शुरू होना चाहिए (न कि अंक, हाइफ़न या बिंदु), अक्षर, अंक, हाइफ़न, अंडरस्कोर और बिंदु शामिल कर सकते हैं (कोई स्पेस नहीं, न ही अधिकांश विराम चिह्न), केस-संवेदी हैं, और किसी भी केस संयोजन में आरक्षित उपसर्ग xml से शुरू नहीं हो सकते। स्पेस वाली JSON कुंजियाँ ("first name": "Alice"), अंकों से शुरू होने वाली कुंजियाँ ("3rd_choice"), या विशेष वर्णों वाली कुंजियाँ ("@type", "$value") सीधे XML तत्व नामों के रूप में उपयोग नहीं की जा सकतीं। अधिकांश कन्वर्टर (यह शामिल) मौन रूप से अमान्य वर्णों को विकृत करते हैं, स्पेस को अंडरस्कोर से बदलते हैं, अंकों से शुरू होने वाली कुंजियों के सामने एक अंडरस्कोर लगाते हैं, अधिकांश विराम चिह्न हटाते हैं। राउंडट्रिप करते समय इसके बारे में जागरूक रहें: गैर-XML-सुरक्षित कुंजियों वाला JSON दस्तावेज़ XML के माध्यम से समान रूप से राउंडट्रिप नहीं करेगा।

जहाँ XML 2026 में अभी भी राज करता है

XML 2026 में पीछे नहीं हट रहा, यह बस विशिष्ट niches में बस गया है। दस्तावेज़ प्रारूप: Office Open XML (Microsoft Office), OpenDocument (LibreOffice), EPUB ebooks, SVG (W3C अनुशंसा 4 सितंबर 2001), MathML, XHTML। कॉन्फ़िगरेशन: Java एप्लिकेशन सर्वर, Spring XML कॉन्टेक्स्ट, Maven POMs, Android XML संसाधन, .NET app.config और web.config फ़ाइलें। फ़ीड्स: RSS 2.0, Atom 1.0 (RFC 4287), पॉडकास्ट फ़ीड (iTunes RSS एक्सटेंशन)। स्वास्थ्य देखभाल और सरकारी इंटरचेंज: HL7 v3, FHIR (जो अब विकल्प के रूप में JSON प्रदान करता है लेकिन XML रूप भारी उपयोग में बना हुआ है), DocBook, NewsML, बैंकिंग ISO 20022। मानक निकाय: लगभग हर IETF और W3C स्पेसिफ़िकेशन उदाहरण XML का उपयोग करता है। उन डोमेनों में XML की verbosity एक विशेषता है: यह स्व-वर्णनात्मक है, स्कीमा के विरुद्ध सत्यापित करना अच्छी तरह स्थापित है, और XML डायलेक्ट्स के बीच XSLT रूपांतरण एक परिपक्व टूलकिट है। प्रारूप कहीं नहीं जा रहा; JSON-से-XML रूपांतरण आधुनिक डेटा टूलिंग और इन स्थापित XML-नेटिव सिस्टम्स के बीच का सेतु है।

गोपनीयता: केवल ब्राउज़र-में रूपांतरण

एक कन्वर्टर में पेस्ट किया गया JSON अक्सर वास्तविक प्रोडक्शन डेटा होता है, उपयोगकर्ता पहचानकर्ताओं वाली API प्रतिक्रियाएँ, आंतरिक एंटिटी ID जो व्यवसाय वर्गीकरण प्रकट करते हैं, कॉन्फ़िगरेशन मान जिनमें एंडपॉइंट URL और फ़ीचर फ़्लैग शामिल हैं, टोकन, अभी तक प्रकाशित नहीं किया गया मसौदा सामग्री। सर्वर-साइड कन्वर्टर हर इनपुट की एक प्रति अपने लॉग्स में लेते हैं। यह कन्वर्टर ब्राउज़र के अंतर्निहित JSON.parse() के साथ आपका JSON पार्स करता है, परिणामी ऑब्जेक्ट ट्री को JavaScript में चलता है, और XML को एक स्ट्रिंग के रूप में उत्सर्जित करता है, सब आपके ब्राउज़र टैब के अंदर। DevTools के नेटवर्क टैब में सत्यापित करें जब आप Convert पर क्लिक करते हैं (कोई अनुरोध फ़ायर नहीं होता), या लोड होने के बाद पृष्ठ को ऑफ़लाइन (हवाई जहाज मोड) करें और कन्वर्टर अभी भी काम करता है। प्रोडक्शन API प्रतिक्रियाओं, आंतरिक कॉन्फ़िग, मसौदा सामग्री, या किसी भी JSON के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी होते नहीं देखना चाहेंगे।

अक्सर पूछे जाने वाले प्रश्न

JSON ऐरे कैसे रूपांतरित होते हैं?

हर ऐरे तत्व एक अलग चाइल्ड तत्व बन जाता है। {"colors": ["red", "blue"]} <colors><item>red</item><item>blue</item></colors> बन जाता है। नाम रहित ऐरे प्रविष्टियों के लिए पारंपरिक तत्व नाम <item> है। यदि आपका डाउनस्ट्रीम उपभोक्ता एक भिन्न परंपरा की अपेक्षा करता है (उदा., माता-पिता के नाम का एकवचन रूप जैसे <color>), तो आपको XML को पोस्ट-प्रोसेस करना होगा या एक भिन्न कन्वर्टर का उपयोग करना होगा जो कस्टम ऐरे-तत्व नामकरण का समर्थन करता है।

क्या यह बड़ी JSON फ़ाइलों के साथ काम करता है?

हाँ, चूँकि सब कुछ आपके ब्राउज़र में चलता है, व्यावहारिक छत आपके डिवाइस की उपलब्ध मेमोरी है। आधुनिक लैपटॉप पर हज़ारों लाइनें JSON एक सेकंड से बहुत कम में परिवर्तित होती हैं। बहुत बड़े इनपुट (multi-MB) पार्सर के पेड़ पर चलने के दौरान टैब को संक्षेप में फ़्रीज़ कर सकते हैं। बड़े डेटासेट के बैच रूपांतरण के लिए, सर्वर-साइड कन्वर्टर (Node में xml2js, Python में dicttoxml) का उपयोग करने वाला एक स्क्रिप्ट अधिक उपयुक्त है।

क्या मेरा JSON किसी सर्वर पर अपलोड किया जाता है?

नहीं। रूपांतरण पूरी तरह से आपके ब्राउज़र में चलता है, पेस्ट किया गया JSON कभी आपका डिवाइस नहीं छोड़ता। DevTools के नेटवर्क टैब में सत्यापित करें जब आप Convert पर क्लिक करते हैं (कोई अनुरोध फ़ायर नहीं होता), या लोड होने के बाद पृष्ठ को ऑफ़लाइन (हवाई जहाज मोड) करें। प्रोडक्शन API प्रतिक्रियाओं, आंतरिक कॉन्फ़िगरेशन, या किसी भी डेटा के लिए सुरक्षित जिसे आप बाहरी रूप से साझा नहीं करना चाहेंगे।

क्या मैं कुछ JSON कुंजियों को चाइल्ड तत्वों के बजाय XML attributes बना सकता हूँ?

यह कन्वर्टर सभी JSON कुंजियों को चाइल्ड तत्वों के रूप में उत्सर्जित करता है, attributes के रूप में नहीं। कुछ कन्वर्टर्स द्वारा उपयोग की गई परंपरा (@ उपसर्ग वाली कुंजियाँ attributes बन जाती हैं ("@id": 5 → माता-पिता पर id="5")) BadgerFish परंपरा है। यदि आपका डाउनस्ट्रीम उपभोक्ता विशिष्ट मानों को attributes के रूप में आवश्यक करता है, तो आपको एक कस्टम कन्वर्टर की आवश्यकता होगी जो परंपरा को समझता है, या परिणामी XML को हाथ से संपादित करना होगा।

जिन JSON कुंजियों में स्पेस या अमान्य XML वर्ण होते हैं उनका क्या होता है?

XML तत्व नामों में JSON कुंजियों की तुलना में अधिक सख़्त नियम हैं: उन्हें एक अक्षर या अंडरस्कोर से शुरू होना चाहिए, स्पेस नहीं हो सकती, और अधिकांश विराम चिह्न अनुमत नहीं हैं। अमान्य वर्णों वाली कुंजियाँ साफ़ की जाती हैं, स्पेस अंडरस्कोर बन जाते हैं, अग्रणी अंकों को एक अंडरस्कोर उपसर्ग मिलता है, विशेष वर्ण हटा दिए जाते हैं। इसका मतलब है कि एक राउंडट्रिप JSON → XML → JSON मूल कुंजी नामों को बिल्कुल नहीं उत्पन्न कर सकता। यदि आपके डेटा में असामान्य कुंजियाँ हैं, तो आउटपुट का निरीक्षण करें यह सुनिश्चित करने के लिए कि विकृति ने कुछ महत्वपूर्ण नहीं तोड़ा।

संबंधित टूल