XML to JSON Converter

The attribute forces the element to become a JSON object rather than a plain string, since a plain string value has nowhere to hang the attribute. The text content moves to a #text key alongside the attribute key: {"price": {"@currency": "USD", "#text": "19.99"}}. If the element had no attributes, the same tag would have simplified to a plain string value instead.

Per the XML 1.0 spec, a self-closing tag and an explicitly-closed empty tag are equivalent — there's no way to distinguish them once parsed, so both convert identically. With no attributes and no text or child content, there's nothing to populate the JSON value with, so this typically comes through as an empty string or null rather than an empty object, since there are no attribute or child keys to place inside one.

No. JSON's grammar (RFC 8259 / ECMA-404) has no comment syntax and no node type analogous to a processing instruction (<?xml-stylesheet type="text/xsl" href="style.xsl"?>), so both are stripped during conversion. Only element structure, attributes, and character data survive the conversion; anything that isn't data in the XML infoset sense is discarded.

Two separate spec gaps compound here. First, XML often contains whitespace-only text nodes between elements purely for pretty-printing indentation, which can surface as stray #text entries unless explicitly stripped. Second, the JSON grammar (ECMA-404) never mandates that object members preserve insertion order — most parsers do in practice, but it isn't a spec guarantee — so attribute order captured as @keys isn't reliably round-trippable either.

यह किसी खास टूल की गड़बड़ी नहीं, बल्कि एक अंतर्निहित अस्पष्टता (ambiguity) है। XML में कोई नेटिव न्यूमेरिक या बूलियन टाइप नहीं होता — XML 1.0 स्पेक के अनुसार, हर एलिमेंट की सामग्री character data ही होती है — इसलिए XML-से-JSON कन्वर्जन को हमेशा यह तय करना पड़ता है कि टेक्स्ट को JSON number/boolean बनाया जाए या string ही रहने दिया जाए। यह निर्णय "007" (जो एक ज़िप कोड या प्रोडक्ट कोड हो सकता है, नंबर 7 नहीं) या "1.50" (एक कीमत, जिसे नंबर में बदलने पर आखिरी शून्य चुपचाप 1.5 हो जाता है) जैसी वैल्यू के लिए वाकई जोखिमभरा है। सुरक्षित डिफ़ॉल्ट, जिसे ज़्यादातर कन्वर्जन अपनाते हैं, यह है कि सभी एलिमेंट और attribute वैल्यू को JSON strings ही रहने दिया जाए और यह तय करना उपभोग करने वाले कोड पर छोड़ दिया जाए कि कब और कैसे कास्ट किया जाए — इस तरह कोई भी जानकारी चुपचाप नष्ट नहीं होती।

ब्राउज़र और Node.js में XML के लिए JSON.parse जैसा कोई बिल्ट-इन समकक्ष नहीं है — आपको DOMParser (सिर्फ ब्राउज़र में) या किसी XML लाइब्रेरी (Node में) की ज़रूरत पड़ेगी, फिर getElementsByTagName या XPath के ज़रिए DOM ट्री से वैल्यू निकालने के लिए ट्रैवर्सल कोड खुद लिखना होगा। इसके उलट, JSON.parse एक सिंगल बिल्ट-इन कॉल है जो आपको सीधे plain objects और arrays दे देता है जिन्हें आप तुरंत destructure कर सकते हैं। यही अंतर वजह है कि लीगेसी SOAP APIs, RSS/Atom फीड्स, और sitemap.xml फ़ाइलें अक्सर JavaScript कोडबेस के छोर पर JSON में कन्वर्ट कर दी जाती हैं: बात यह नहीं कि JSON ज़्यादा शक्तिशाली है, बल्कि यह कि उसे उपभोग करने के लिए JS टूलिंग पहले से मौजूद है।

XML, JSON से करीब एक दशक पहले आया था: XML 1.0 फरवरी 1998 में W3C Recommendation बना, जो SGML से व्युत्पन्न था और एक डॉक्यूमेंट मार्कअप भाषा के रूप में डिज़ाइन किया गया था (इसीलिए इसमें attributes, mixed content, और namespaces हैं)। JSON को Douglas Crockford ने 2000 के दशक की शुरुआत में JavaScript के object-literal सिंटैक्स से निकाला, जिसे पहली बार 2006 में RFC 4627 के रूप में औपचारिक रूप दिया गया, फिर ECMA-404 (2013) और अपने वर्तमान रूप, RFC 8259 (2017) के रूप में फिर से स्पेसिफाई किया गया। JSON की सादगी — चार डेटा टाइप, कोई attribute नहीं, कोई mixed content नहीं — इस बात को दर्शाती है कि यह किसी चल रहे प्रोग्राम को डेटा स्ट्रक्चर भेजने-प्राप्त करने के लिए एक वायर फॉर्मेट के रूप में बना था, न कि दस्तावेज़ों को मार्कअप करने के लिए।

नहीं — और attributes के लिए यह टूल जिस @-प्रीफिक्स कन्वेंशन का उपयोग करता है, वह खुद इस अंतर का सबूत है। यह कन्वेंशन (attributes के लिए @key, mixed content के लिए #text) JSON स्पेसिफिकेशन का हिस्सा नहीं है; यह एक व्यापक रूप से इस्तेमाल किया जाने वाला लेकिन अनौपचारिक कन्वेंशन है, और अलग-अलग XML-से-JSON टूल एक ही इनपुट को अलग-अलग तरीके से हैंडल करते हैं — कुछ attributes को plain keys में फ़्लैट कर देते हैं, कुछ एलिमेंट कंटेंट को $ या _text key में लपेट देते हैं, कुछ BadgerFish या Parker कन्वेंशन इस्तेमाल करते हैं। JSON में attribute जैसी कोई बिल्ट-इन अवधारणा है ही नहीं, इसलिए हर XML-से-JSON टूल plain JSON objects के ऊपर अपना खुद का कन्वेंशन थोप रहा होता है, और एक कन्वर्टर का JSON आउटपुट उसी XML इनपुट के लिए दूसरे कन्वर्टर के आउटपुट से मेल नहीं खाएगा।

चूंकि यह कन्वर्टर namespace प्रीफिक्स को उनके पूरे namespace URI में रिज़ॉल्व करने के बजाय शाब्दिक रूप से key के नाम के हिस्से के तौर पर सुरक्षित रखता है, इसलिए "a:id" और "b:id" दो अलग JSON keys में कन्वर्ट होते हैं और आपस में टकराते नहीं — लेकिन यह तभी तक सही रहता है जब तक प्रीफिक्स खुद अलग-अलग हों। अगर किसी डॉक्यूमेंट के दो अलग हिस्सों में संयोग से एक ही प्रीफिक्स अलग-अलग namespace URIs के लिए इस्तेमाल हो (जो XML में कानूनी है, क्योंकि प्रीफिक्स बाइंडिंग उस एलिमेंट तक सीमित होती है जिस पर वह घोषित की गई है), या अगर कोई डाउनस्ट्रीम टूल namespace संदर्भ के बिना JSON को दोबारा पार्स करे, तो वह प्रीफिक्स-आधारित key यह भरोसेमंद ढंग से नहीं बता पाती कि वह एलिमेंट असल में किस namespace का था। जिन दस्तावेज़ों में प्रीफिक्स से ज़्यादा namespace URIs मायने रखते हैं, वहां कन्वर्जन से पहले प्रीफिक्स को नॉर्मलाइज़ करना ज़्यादा सुरक्षित है।