JSON को XML में बदलें

XML दस्तावेज़ में एक ही सबसे बाहरी एलिमेंट होता है। JSON दस्तावेज़ पंद्रह कुंजी वाला ऑब्जेक्ट हो सकता है, या ऐरे, या सादी संख्या, और इनमें से किसी के पास कंटेनर के लिए नाम नहीं होता। तो बदलाव का एक नियम है: ठीक एक कुंजी वाला ऑब्जेक्ट उस कुंजी को रूट बनाता है, बाक़ी सब root नाम के एलिमेंट में लिपट जाता है। अपवाद जानना ज़रूरी है क्योंकि यह सबसे आम शक्ल पकड़ता है — अगर वह इकलौती कुंजी ऐरे रखती है, {"items": [1, 2]}, तो उसे रूट बनाने पर <items> दो बार लिखा जाता और कोई सबसे बाहरी एलिमेंट न बचता, इसलिए जोड़े के चारों ओर <root> लपेट दिया जाता है।

पहली हालत ही लक्ष्य है, और अगर आपके पास JSON पर नियंत्रण है तो यह एक छोटा संपादन है। अपने पेलोड को उसके नाम की एक कुंजी में लपेटना — invoice, order, shipment — का मतलब है XML वह एलिमेंट नाम लेकर आता है जो लेने वाला सिस्टम चाहता है, सामान्य रैपर की बजाय जिसे आपको बाद में नतीजे में बदलना पड़े।

XML में ऐरे टाइप नहीं और कभी चाहिए भी नहीं: सूची मतलब वही टैग उसी पैरेंट में कई बार लिखा जाना। तो तीन tags रखने वाला ऑब्जेक्ट लगातार तीन <tags> एलिमेंट बनाता है, जो हर XML कंज़्यूमर पहले से संभाल लेता है।

यह इकलौती जगह है जहाँ XML, JSON के लिए टेबल फ़ॉर्मेट से बेहतर बैठता है। वही ऐरे CSV में बदलने पर अतिरिक्त कॉलम, जुड़ी हुई स्ट्रिंग या अतिरिक्त पंक्ति के बीच चुनाव मजबूर करता है, और इनमें से हर एक किसी न किसी के लिए ग़लत है। XML में दोहराव सहज है, तो पाँच लाइन आइटम वाला ऑर्डर बिना आपकी तरफ़ से कोई फ़ैसला लिए बदल जाता है।

XML में किसी एलिमेंट से मान जोड़ने के दो तरीक़े हैं — टैग के भीतर एक attribute या एक चाइल्ड एलिमेंट — और स्कीमा इस बात को बहुत गंभीरता से लेती है कि कौन-सा। JSON के पास एक ही तरीक़ा है। यहाँ का रिवाज़ इसे जोड़ता है: @ से शुरू होने वाली कुंजी attribute के तौर पर लिखी जाती है, और #text नाम की कुंजी एलिमेंट का अपना टेक्स्ट अपने चाइल्ड के साथ देती है।

यह रिवाज़ मनमाना नहीं; यह वही है जो इस साइट का XML रीडर उल्टी दिशा में बनाता है। किसी दस्तावेज़ को JSON में बदलना, संपादित करना और वापस बदलना attribute को attribute के तौर पर ही लौटाता है, एलिमेंट में बदले बिना। अगर लेने वाला सिस्टम id को attribute की तरह चाहता है और आपकी JSON में यह सादी कुंजी है, तो बदलने से पहले उसे @id कर देना ही पूरा हल है।

JSON कुंजी कोई भी स्ट्रिंग हो सकती है: स्पेस, स्लैश, इमोजी, शुरुआत में अंक, ख़ाली स्ट्रिंग भी। XML एलिमेंट नाम नहीं हो सकते। Writer असफल होने की बजाय दोबारा लिखता है, और यह जान-बूझकर एक सँकरी सूची के हिसाब से करता है — A-Z, a-z, 0-9, underscore, dot और hyphen बचते हैं, बाक़ी सब underscore बनता है, और अंक से शुरू होने वाला नाम आगे एक अंडरस्कोर पाता है। तो "2024 report" <_2024_report> बनकर आता है।

यह सूची XML 1.0 से भी सँकरी है, और यही सबसे ज़्यादा पकड़ में आने वाला मामला है: XML एलिमेंट नाम में स्वरचिह्न वाले अक्षर, ग्रीक, सिरिलिक, देवनागरी और CJK आ सकते हैं, और यह writer इनमें से कुछ नहीं रखता। café कुंजी <caf_> बनकर आती है और 名前 <__> बनकर। फ़ाइल सही ढंग से बनी होती है और नाम वे नहीं जो आपकी स्कीमा बताती है। बदलने से पहले JSON में ऐसी कुंजियों के नाम बदल दीजिए।

XML नेमस्पेस, XSD स्कीमा, DTD, प्रोसेसिंग निर्देश, CDATA सेक्शन और डिजिटल हस्ताक्षर लाता है — रजिस्ट्री हस्ताक्षर सहारे को इसके गुणों में गिनती है, और यही वजह है यह फ़ॉर्मेट अब भी बैंकिंग और सरकारी लेन-देन की रीढ़ है। इनमें से कुछ भी किसी JSON फ़ाइल से निकाला नहीं जा सकता, क्योंकि उसमें इनमें से कुछ भी दर्ज नहीं होता।

व्यावहारिक तौर पर इसका मतलब: नतीजा सही ढंग से बना दस्तावेज़ है, वैध नहीं। अगर लेने वाला सिस्टम XSD के ख़िलाफ़ जाँचता है, तो रूट एलिमेंट पर नेमस्पेस डिक्लेरेशन जोड़ने और शायद एलिमेंट का क्रम बदलने की उम्मीद रखिए, क्योंकि XSD क्रम-संवेदनशील है और JSON ऑब्जेक्ट का क्रम मायने नहीं रखता।

किसी मान में ऐम्परसैंड, कोणीय कोष्ठक और दोहरे उद्धरण चिह्न बाहर लिखते समय escape होते हैं, जो "Tom & Jerry <special>" वाले उत्पाद विवरण को दस्तावेज़ बीच में ख़त्म करने से रोकता है। बाक़ी सब, apostrophe और हर ग़ैर-ASCII अक्षर समेत, UTF-8 में वैसे ही लिखा जाता है।

JSON का null ख़ाली एलिमेंट बनता है: टैग मौजूद रहता है, बीच में कुछ नहीं। यह जान-बूझकर लिया गया फ़ैसला है और इकलौता विकल्प नहीं — XML में इसी के लिए xsi:nil भी है, और कुछ स्कीमा उसी की माँग करती हैं। अगर आपकी करती है, तो ख़ाली एलिमेंट को खोजकर बदलना एक क़दम दूर है।

दस्तावेज़ दो-स्पेस इंडेंटेशन और प्रति-लाइन एक एलिमेंट के साथ लिखा जाता है, जो इसे पढ़ने लायक़ और दो पेलोड के बीच diff को समझने लायक़ बनाता है। यह <?xml version="1.0"?> लाइन से शुरू नहीं होता। XML 1.0 इस डिक्लेरेशन को वैकल्पिक बनाता है और UTF-8 को डिफ़ॉल्ट एन्कोडिंग तय करता है, तो फ़ाइल इसके बिना भी सही ढंग से बनी होती है।

कई पुराने सिस्टम इससे असहमत हैं, और उनमें से कुछ लाइन ग़ायब होने पर बेकार संदेश के साथ फ़ेल होते हैं। यह ऊपर जोड़ने के लिए एक लाइन भर है। पहली बार भेजने से पहले जान लेना अच्छा है, क्योंकि middleware कतार का "फ़ाइल अवैध है" शायद ही बताए बीस मुमकिन वजहों में से कौन-सी है।

हर मान एक शुरुआती और एक बंद टैग में लिपटता है, तो फ़ील्ड नाम प्रति रिकॉर्ड दो बार आता है, एक की बजाय। लंबे फ़ील्ड नाम वाले छोटे मान के पेलोड के लिए दस्तावेज़ आई JSON से दो-तीन गुना बड़ा हो सकता है, और इंडेंटेशन उसमें और जोड़ता है।

किसी संदेश-आकार सीमा वाली कतार के लिए यह असली क़ीमत है और फ़ाइल ट्रांसफ़र के लिए बिल्कुल नहीं, जहाँ ज़्यादातर ऐसी डिलीवरी असल में जाती हैं। जहाँ यह मायने रखता है, हल पुनर्गठन नहीं, कंप्रेशन है — XML बेहद दोहराव वाला टेक्स्ट है और gzip में बहुत अच्छे से सिमटता है।

दो जाँच, क्रम में। पहले well-formedness: कोई भी XML एडिटर, ब्राउज़र या कमांड-लाइन पार्सर एक सेकंड में बता देगा कि दस्तावेज़ पार्स होता है या नहीं, और यहाँ यह हमेशा पास होना चाहिए।

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

यह बदलाव इसी टैब में JavaScript है: ब्राउज़र JSON पार्स करता है, एक छोटा writer XML बनाता है, और कोई रिक्वेस्ट दस्तावेज़ कहीं नहीं ले जाती। कोई साइन-अप नहीं, कोई कतार नहीं, कोई रोज़ाना सीमा नहीं, और मुफ़्त स्तर 100 MB तक स्वीकार करता है।

इस पाठक के लिए यह अक्सर तय करने वाली बात है, सिर्फ़ अच्छी बात नहीं। जो पेलोड XML बनने हैं वे भुगतान, दावे, फ़ाइलिंग और मरीज़ या ग्राहक रिकॉर्ड होते हैं — ठीक वही श्रेणियाँ जहाँ किसी अनजान वेब सेवा में फ़ाइल पेस्ट करना रिपोर्ट करने लायक़ घटना है। यहाँ कुछ भेजा नहीं जाता, तो रिपोर्ट करने को कुछ नहीं।