डेवलपर टूल · सिंटेक्स कन्वर्टर्स
XML से JSON मैपिंग: विशेषताएँ, टेक्स्ट नोड्स और एक-बनाम-अनेक समस्या
· यह काम किस प्रकार करता है
एक्सएमएल json डेटा-प्रारूप
XML को JSON में बदलने का कोई एक सही तरीका नहीं है, क्योंकि XML में विशेषताएँ, मिश्रित सामग्री और ऑर्डर किए गए बच्चे हैं जिनमें JSON का अभाव है। यह पोस्ट सामान्य मानचित्रण परंपराओं और प्रत्येक में मौजूद जालों के बारे में बताती है।
क्यों एक <item> एक ऑब्जेक्ट बन गया और दो एक ऐरे बन गए - XML फ़ीड जिसका JSON आकार इस पर निर्भर करता है कि इसमें कितनी प्रविष्टियाँ हैं
`<item>one</item>` वाला फ़ीड `"item": "one"` उत्पन्न करता है; दूसरे भाई-बहन को जोड़ने से वह संपत्ति `"item": ["one", "two"]` में बदल जाती है। पार्सर यह अनुमान नहीं लगा सकता कि एक आइटम वैचारिक रूप से एक की सूची थी क्योंकि दोनों अर्थों में समान XML वाक्यविन्यास है। इसलिए केवल पहले नमूने के विरुद्ध बनाया गया कोड विफल हो सकता है जब उत्पादन दूसरा भेजता है।
ToolAcre इस अस्थिरता को हमेशा-सरणी विकल्प के पीछे नहीं छिपाता है। यह एक नाम को एक बार एक मान के रूप में और बार-बार आने वाले भाई-बहनों को एक सरणी के रूप में रिकॉर्ड करता है। प्रत्यक्ष मानचित्रण का निरीक्षण करना आसान है, लेकिन स्थिर संग्रह आकार की आवश्यकता वाले उपभोक्ताओं को स्कीमा ज्ञान का उपयोग करना चाहिए या रूपांतरण के बाद परिणाम को स्वयं सामान्य करना चाहिए।
XML में क्या है जो JSON में नहीं है - विशेषताएँ, तत्वों के साथ मिश्रित पाठ, क्रमबद्ध भाई-बहन, नामस्थान, टिप्पणियाँ और प्रसंस्करण निर्देश
XML विशेषताओं को चाइल्ड तत्वों से अलग करता है, सहोदर क्रम को संरक्षित करता है, तत्वों के बीच पाठ की अनुमति देता है, नेमस्पेस उपसर्ग रखता है, और इसमें टिप्पणियाँ और प्रसंस्करण निर्देश शामिल हो सकते हैं। JSON ऑब्जेक्ट और सरणियाँ प्रदान करता है लेकिन उन नोड कैटेगरी के लिए कोई अंतर्निहित समकक्ष नहीं है। कोई भी XML-to-JSON परिणाम परिणामस्वरूप एक चुना हुआ प्रक्षेपण है, सार्वभौमिक अनुवाद नहीं।
यह पाठक घोषणा, टिप्पणियाँ और प्रसंस्करण निर्देश छोड़ देता है। नेमस्पेस उपसर्ग हल होने के बजाय शब्दशः बने रहते हैं: `<ns:item>` कुंजी `ns:item` बन जाती है, जबकि `xmlns:ns` `@xmlns:ns` बन जाती है। मिश्रित पाठ को एक कुंजी के तहत जोड़ा जाता है, इसलिए बाल तत्वों के आसपास इसकी मूल स्थिति खो जाती है और एक चेतावनी कहती है कि रूपांतरण राउंड-ट्रिप नहीं हो सकता है।
विशेषता परंपराएँ - @ या $ जैसे उपसर्ग, वे क्यों मौजूद हैं, और एक ही नाम के साथ एक विशेषता और एक बच्चा तत्व कैसे टकराते हैं
विशेषताएँ `@` उपसर्ग का उपयोग करती हैं। `<user id="7"><id>other</id></user>` `@id` के साथ `"7"` के बराबर और बच्चे `id` के साथ `"other"` के बराबर एक ऑब्जेक्ट बन जाता है। उपसर्ग दो अलग-अलग XML निर्माणों को एक ही ऑब्जेक्ट प्रॉपर्टी में टकराने से रोकता है। जब JSON को XML पर वापस लिखा जाता है तो यह कन्वर्टर के अनुबंध का भी हिस्सा बन जाता है।
अन्य लाइब्रेरीज़ `$`, एक विशेषता ऑब्जेक्ट या अन्य कन्वेंशन का उपयोग कर सकती हैं। ToolAcre केवल दृश्यमान `@` मैपिंग का समर्थन करता है। लेखक को बदले बिना एप्लिकेशन कोड में उस उपसर्ग को बदलने से विशेषताएँ तत्वों में बदल जाएंगी, इसलिए परिवर्तित मूल्य को मध्यवर्ती निरीक्षण फॉर्म के रूप में उपयोग करते समय इसे संरक्षित करें।
टेक्स्ट नोड कन्वेंशन - तत्व सामग्री के लिए # टेक्स्ट या _, और क्या होता है जब किसी तत्व में टेक्स्ट और बच्चे दोनों होते हैं
केवल पाठ वाला तत्व उस स्ट्रिंग में ढह जाता है। जब विशेषताएँ या बच्चे भी मौजूद होते हैं, तो पाठ `#text` के अंतर्गत रहता है; CDATA को `#cdata` के अंतर्गत अलग से रखा गया है। एक स्व-समापन टैग एक खाली स्ट्रिंग बन जाता है। ये आरक्षित कुंजियाँ लेखक को सामान्य बच्चों के नामों को उन सामग्री कैटेगरी से अलग करने देती हैं जिन्हें JSON स्वयं परिभाषित नहीं करता है।
मिश्रित सामग्री हानिप्रद रहती है। `<p>before<b>bold</b>after</p>` में, बच्चे के सापेक्ष "पहले" और "बाद" की स्थिति को सम्मिलित `#text` संपत्ति से पुनर्निर्मित नहीं किया जा सकता है। टूल उस संरचनात्मक पैटर्न का पता लगाता है और चेतावनी देता है। जब दस्तावेज़ क्रम अर्थ का हिस्सा हो तो नोड-संरक्षित XML API का उपयोग करें।
एक-बनाम-अनेक समस्या - बार-बार दोहराए जाने पर ही तत्व सरणी बन जाते हैं, और उपभोक्ताओं को रक्षात्मक रूप से कोड क्यों करना चाहिए
दोहराए गए भाई-बहन पुनरावृत्ति देखने के बाद ही सरणी में बदल जाते हैं। एक `<book>` एक वस्तु है; दो पुस्तकें वस्तुओं की एक श्रृंखला हैं। इसे कभी-कभी एक-बनाम-अनेक समस्या कहा जाता है, लेकिन यह पार्सर दोष नहीं है। स्रोत दस्तावेज़ में इसकी घटनाओं से स्वतंत्र कोई सूची घोषणा शामिल नहीं है।
रक्षात्मक उपभोक्ता स्कीमा ज्ञान के साथ ज्ञात पथों को सामान्य कर सकते हैं: `catalogue.book` लपेटें जब यह पहले से ही एक सरणी नहीं है। उस नियम को हर संपत्ति पर लागू न करें, क्योंकि एक साधारण अदिश को केवल समरूपता के लिए एक सूची नहीं बनना चाहिए। कन्वर्टर जानबूझकर ऐसी डोमेन जानकारी का आविष्कार करने से बचता है।
व्यावहारिक उदाहरण: एक छोटे RSS-शैली दस्तावेज़ को परिवर्तित करना - विशेषताएँ, एक दोहराया तत्व और एक नामस्थान, जिसके परिणामस्वरूप JSON एनोटेट किया गया है
कन्वर्ट करें `<feed xmlns:m="https://example.invalid/meta"><item id="1"><m:title>One</m:title></item><item id="2"><m:title><![CDATA[Two & More]]></m:title></item></feed>`. जड़ `feed` है; `@xmlns:m` नेमस्पेस घोषणा को बरकरार रखता है; `item` एक सरणी है; प्रत्येक `@id` टेक्स्ट है; और दूसरे शीर्षक में `#cdata` शामिल है।
प्रकार का अनुमान डिफ़ॉल्ट रूप से बंद है, इसलिए `id="2"` भी स्ट्रिंग `"2"` ही रहती है। अनुमान को सक्षम करने से पार्सर संख्यात्मक और बूलियन पाठ को उन JavaScript प्रकारों के रूप में पढ़ सकता है, लेकिन XML ने उस इरादे की घोषणा नहीं की। विकल्प उपयोगकर्ता द्वारा नियंत्रित एक अनुमान है, दस्तावेज़ द्वारा प्रदान किया गया साक्ष्य नहीं।
इसमें क्या शामिल नहीं है - स्कीमा-संचालित रूपांतरण जो किसी तत्व को जानता है वह हमेशा एक सूची होती है, जिसके लिए XSD या मैन्युअल मैपिंग की आवश्यकता होती है
कोई XSD लोड नहीं किया गया है, और कोई स्कीमा-संचालित सूची जानकारी उपलब्ध नहीं है। कन्वर्टर यह नहीं जान सकता कि एक तत्व दोहराने योग्य है जब केवल एक ही दिखाई देता है, आवश्यक बच्चों को मान्य करता है, नेमस्पेस यूआरआई को एप्लिकेशन प्रकारों में हल करता है या एक टाइप किया गया क्लाइंट उत्पन्न करता है। एक सफल पार्स केवल कॉन्फ़िगर रीडर द्वारा स्वीकृत अच्छी तरह से गठित XML स्थापित करता है।
DOCTYPE घोषणाओं को पार्सिंग से पहले अस्वीकार कर दिया जाता है, जिसमें हानिरहित घोषणाएँ भी शामिल हैं। वह सीमा बाहरी इकाई अनुरोधों, स्थानीय फ़ाइल पढ़ने और इकाई विस्तार को रोकती है। DOCTYPE को हटाने से उन घोषणाओं को भी हटाया जा सकता है जिन पर दस्तावेज़ निर्भर था, इसलिए ऐसा तभी करें जब आपके पास डेटा हो और आप परिणामों को समझें।
टेकअवे: XML से JSON एक मैपिंग है, अनुवाद नहीं - और सिंटेक्स कन्वर्टर्स पैनल आपको अपने ब्राउज़र में उस मैपिंग का निरीक्षण करने की सुविधा कैसे देता है
परिणाम को ToolAcre की दस्तावेज़ीकृत मैपिंग के रूप में मानें: विशेषताओं के लिए `@`, मिश्रित तत्व पाठ के लिए `#text`, CDATA के लिए `#cdata`, बार-बार भाई-बहनों के बाद सरणियाँ और शाब्दिक नामस्थान उपसर्ग। वे नियम XML और JSON को एक डेटा मॉडल साझा करने का दिखावा किए बिना आउटपुट को पूर्वानुमानित बनाते हैं।
निरीक्षण के लिए, यह प्रक्षेपण तेज़ और पठनीय है। टिकाऊ एकीकरण के लिए, एक और कई घटनाओं, बच्चों के साथ नाम साझा करने की विशेषताओं, खाली तत्वों, मिश्रित सामग्री और नामस्थान का परीक्षण करें। यदि तत्व क्रम या स्कीमा बाधाएँ मायने रखती हैं, तो सामान्य रूपांतरित आकार पर निर्भर होने के बजाय उस अनुबंध के विरुद्ध XML को पार्स करें।
कच्चे XML फिक्स्चर को सामान्यीकृत अपेक्षा के बगल में रखें। यदि कोई निर्भरता अपग्रेड सरणी हैंडलिंग, व्हाइटस्पेस ट्रिमिंग या इकाई डिकोडिंग को बदलता है तो वह जोड़ी सबूत सुरक्षित रखती है। यह समीक्षकों को उन भेदों को देखने की जगह भी देता है जिन्हें JSON दृश्य प्रदर्शित नहीं कर सकता। एक परिवर्तित वस्तु अकेले यह साबित नहीं कर सकती है कि क्या एक खाली स्ट्रिंग स्व-समापन तत्व, युग्मित टैग या स्रोत में किसी अन्य सम्मेलन से आई है।