डेवलपर टूल · सिंटेक्स कन्वर्टर्स
JSON रूपांतरण में YAML सुविधाएँ खो गईं: टिप्पणियाँ, एंकर और टैग
· यह काम किस प्रकार करता है
yaml json डेटा-प्रारूप
YAML में टिप्पणियाँ, एंकर, उपनाम, मर्ज कुंजियाँ, टैग और बहु-दस्तावेज़ स्ट्रीम हैं; JSON के पास इनमें से कुछ भी नहीं है। यह पोस्ट बताती है कि एक कन्वर्टर प्रत्येक के साथ क्या करता है और वापस परिवर्तित करने से मूल फ़ाइल कभी भी पुनर्स्थापित क्यों नहीं होती है।
फ़ाइल लंबे समय तक और एक भी टिप्पणी के बिना वापस आई - एक YAML कॉन्फ़िगरेशन को JSON में परिवर्तित किया गया और वापस, और वह सब कुछ जो जीवित नहीं रहा
एक YAML फ़ाइल प्रत्येक टिप्पणी के गायब होने के बाद भी JSON से अधिक समय तक वापस आ सकती है। एक मैपिंग साझा करने वाले एंकर को बार-बार ऑब्जेक्ट डेटा में हल किया जाता है, इसलिए सीरिएलाइज़र प्रत्येक प्रतिलिपि को स्वतंत्र रूप से लिखता है। मान अभी भी सहमत हो सकते हैं, फिर भी लेखकीय संरचना और स्पष्टीकरण ख़त्म हो गए हैं।
इसीलिए YAML-to-JSON-to-YAML राउंड ट्रिप को डेटा रूपांतरण के रूप में आंका जाना चाहिए, न कि स्रोत संरक्षण के रूप में। ToolAcre एक प्रतिबंधित मान ग्राफ़ पढ़ता है और एक नया दस्तावेज़ लिखता है। यह कभी भी टिप्पणियों, एंकर नाम, उद्धरण विकल्प या ब्लॉक-स्केलर प्रस्तुति वाले एक ठोस वाक्यविन्यास वृक्ष को बरकरार नहीं रखता है।
टिप्पणियाँ - क्यों JSON में उनके लिए कोई जगह नहीं है और रूपांतरण के बाद प्रत्येक # पंक्ति गायब हो गई है
टिप्पणियाँ YAML पार्सर द्वारा खारिज कर दी जाती हैं क्योंकि JSON में कोई टिप्पणी नोड नहीं है। `#` से शुरू होने वाली एक पंक्ति यह बता सकती है कि टाइमआउट क्यों मौजूद है या सेवा का मालिक कौन है; एक बार हटा दिए जाने के बाद, कोई भी एल्गोरिदम शब्दों या प्लेसमेंट का अनुमान नहीं लगा सकता है। वापस परिवर्तित करने से उस परिचालन संदर्भ के बिना वैध YAML बनता है।
मूल फ़ाइल को संस्करण नियंत्रण में सुरक्षित रखें और उसे बदलने से पहले उसकी समीक्षा करें। यदि लक्ष्य केवल हल किए गए मानों का निरीक्षण करना है, तो JSON उपयोगी है। यदि लक्ष्य कमेंटरी को बरकरार रखते हुए पुन: स्वरूपित करना है, तो यह सामान्य मूल्य कन्वर्टर गलत प्रतिनिधित्व है।
एंकर और उपनाम - &default और *default को बार-बार प्रतियों में विस्तारित किया गया, और परिणामस्वरूप फ़ाइल कैसे बढ़ती है
एंकर और उपनामों को सुरक्षा सीमा के भीतर स्वीकार किया जाता है, फिर उनका समाधान किया जाता है। `base: &b {x: 1}` और `copy: *b` `x: 1` युक्त दो ऑब्जेक्ट पथ बन जाते हैं। आउटपुट YAML `noRefs` का उपयोग करता है, इसलिए साझा ऑब्जेक्ट पहचान नए एंकर नहीं बनाती है। जब दोहराए गए मूल्य जीवित रहते हैं तब भी सघन संबंध समाप्त हो जाता है।
पुनरावर्ती उपनामों को अस्वीकार कर दिया गया है क्योंकि JSON चक्रों को व्यक्त नहीं कर सकता है। उपनाम विस्तार को उपनाम गणना, नेस्टिंग और एक विस्तारित-नोड माप द्वारा सीमित किया गया है; एक छोटा दस्तावेज़ जो दस लाख से अधिक मानों में स्ट्रिंग होगा, रोक दिया गया है। यह मनमाने ढंग से YAML समर्थन का दावा किए बिना टैब की सुरक्षा करता है।
मर्ज कुंजियाँ - <<: YAML 1.1 से कन्वेंशन, कैसे इसका समर्थन करने वाले पार्सर मर्ज किए गए मैपिंग को समतल करते हैं, और जो नहीं करते हैं उनमें क्या होता है
रूपरेखा मानती है कि YAML 1.1 मर्ज कुंजियाँ चपटी हैं। ToolAcre केवल js-yaml के JSON या कोर स्कीमा को लोड करता है, इनमें से कोई भी मर्ज प्रकार को सक्षम नहीं करता है। इन स्कीमाओं के अंतर्गत, `<<` कुंजी मैपिंग को मर्ज करने के निर्देश के बजाय सामान्य डेटा है। इसलिए एक चपटे मर्ज को शिप किए गए व्यवहार के रूप में प्रस्तुत करना गलत होगा।
यदि आपका स्रोत मर्ज-कुंजी शब्दार्थ पर निर्भर करता है, तो इसे उस एप्लिकेशन में हल करें जो उस सम्मेलन का मालिक है या रूपांतरण से पहले मूल्यों को स्पष्ट रूप से फिर से लिखें। साधारण `<<` के मान के रूप में उपयोग किया जाने वाला उपनाम अभी भी किसी ऑब्जेक्ट को हल कर सकता है, लेकिन कुंजी `<<` बनी रहती है; यह अपने सदस्यों को मूल में विलय करने के बराबर नहीं है।
मर्ज कुंजी इस कन्वर्टर जहाजों के दो प्रतिबंधित स्कीमा द्वारा सक्षम नहीं हैं
प्रतिबंधित स्कीमा द्वारा मान्यता प्राप्त मानक स्पष्ट टैग मूल प्रकार चुन सकते हैं, जैसे `!!str` या `!!int`। कस्टम और समृद्ध टैग-जिनमें बाइनरी, टाइमस्टैम्प, सेट, ऑर्डर किया गया मैप, JavaScript फ़ंक्शन और पायथन ऑब्जेक्ट कंस्ट्रक्टर शामिल हैं-अस्वीकृत कर दिए जाते हैं। उन्हें कठोर नहीं बनाया जाता और कभी निष्पादित नहीं किया जाता।
`---` द्वारा अलग की गई YAML स्ट्रीम स्वीकार की जाती है। एक दस्तावेज़ एक मूल्य बन जाता है; कई दस्तावेज़ संख्या को नामित करने वाली चेतावनी के साथ एक सरणी बन जाते हैं। एक अनुगामी विभाजक चयनित स्कीमा के अनुसार एक खाली अंतिम दस्तावेज़ बना सकता है। यहां किसी भी लक्ष्य में स्ट्रीम मॉडल नहीं है, इसलिए सरणी एक घोषित सम्मेलन है।
असुरक्षित टैग अस्वीकार कर दिए जाते हैं; बहु-दस्तावेज़ धाराएँ सारणी बन जाती हैं
पुनर्प्रयासों और टाइमआउट के साथ `defaults: &d` का उपयोग करें, टाइमआउट की व्याख्या करने वाली एक टिप्पणी, फिर `inherited: *d` के साथ `service:` का उपयोग करें। JSON में डिफ़ॉल्ट और बार-बार विरासत में मिली वस्तु दोनों शामिल हैं; टिप्पणी और एंकर का नाम अनुपस्थित है। उस JSON को वापस परिवर्तित करने से एंकर संबंध के बजाय दो मैपिंग उत्सर्जित होती हैं।
`---` के बाद एक अन्य दस्तावेज़ जोड़ें और JSON रूट दस्तावेज़ों की एक श्रृंखला बन जाता है। `!!binary` जोड़ें और प्रतिबंधित-स्कीमा संकेत के साथ रूपांतरण रुक जाता है। ये तीन परिवर्तन हल किए गए समर्थित डेटा, संरचनात्मक सम्मेलन और पूर्णतः असमर्थित निर्माण को अलग करते हैं।
इसमें क्या शामिल नहीं है - मुख्य आदेश और उद्धरण शैली, जो आम तौर पर जीवित रहती है लेकिन किसी भी प्रारूप द्वारा गारंटी नहीं दी जाती है
सामान्य ऑब्जेक्ट प्रविष्टि क्रम अक्सर दृश्यमान रहता है, लेकिन यह स्रोत-शैली संरक्षण नहीं है, और सॉर्ट कुंजियों का चयन जानबूझकर इसे बदल देता है। उद्धरण, प्रवाह बनाम ब्लॉक शैली, अदिश वर्तनी और टिप्पणियाँ जीवित नहीं रहती हैं। डुप्लिकेट मैपिंग कुंजियाँ दोनों अमान्य प्रविष्टियों को संरक्षित करने के बजाय अंतिम मान को चेतावनी के साथ रखती हैं।
लेखक YAML 1.1 मानों को उद्धृत करके अस्पष्ट स्ट्रिंग्स की रक्षा करता है जिसे उपभोक्ता गलत तरीके से पढ़ सकता है, लेकिन वह सुरक्षा विकल्प लेखक की मूल शैली से भिन्न हो सकता है। डेटा समानता सामान्य JSON-आकार वाले मानों के लिए रक्षात्मक परीक्षण है; पाठ्य समानता नहीं है.
मुख्य क्रम बना रह सकता है, जबकि टिप्पणियाँ, एंकर, टैग वर्तनी और शैली संरक्षित नहीं हैं
YAML-to-JSON जब भी अर्थ JSON-आकार वाले मान के बाहर रहता है तो हानिप्रद होता है: टिप्पणियाँ, उपनाम, असमर्थित टैग, स्ट्रीम सीमाएँ, और शैली। ToolAcre कई नुकसानों को दृश्यमान बनाता है और उन्हें संरक्षित करने का दिखावा करने के बजाय खतरनाक या चक्रीय निर्माणों से इनकार करता है।
वर्कफ़्लो अपनाने से पहले एक प्रतिनिधि फ़ाइल परिवर्तित करें। चेतावनियों का निरीक्षण करें, अलग-अलग हल किए गए मानों का निरीक्षण करें और लिखित YAML को रखें। एक पार्सर जो देखता है उस पर पैनल एक उत्कृष्ट लेंस है, लेकिन यह एक टिप्पणी-संरक्षित एडिटर या पूर्ण YAML ऑब्जेक्ट-मॉडल ट्रांसफार्मर नहीं है।
माइग्रेशन समीक्षा के लिए, केवल-स्रोत परिवर्तनों से अलग मूल्य परिवर्तन करें। एक JSON गहरी तुलना यह स्थापित कर सकती है कि क्या सामान्य मूल्य बचे हैं, जबकि एक पाठ अंतर से टिप्पणियों, एंकरों और शैली का पता चलता है जो आवश्यक रूप से बदल गए हैं। कोई भी चेक दूसरे की जगह नहीं लेता. मूल्य तुलना को दोषरहित कहने से स्रोत जानकारी की अनदेखी हो जाएगी; प्रत्येक पाठ्य परिवर्तन को डेटा विफलता कहने से वैध पुनः क्रमांकन की अनदेखी हो जाएगी।