क्या JSON वैध YAML है? YAML 1.2 क्या वादा करता है और वह कहां टूटता है

JSON को YAML फ़ाइल में चिपकाना और इससे छुटकारा पाना - यह क्यों काम करता है, और एक बार ऐसा नहीं हुआ

एक साधारण JSON ऑब्जेक्ट को YAML स्रोत पक्ष में चिपकाया जा सकता है और ToolAcre के YAML 1.2 JSON स्कीमा के अंतर्गत पढ़ा जा सकता है। ब्रेसिज़, ब्रैकेट, उद्धृत कुंजियाँ, स्ट्रिंग्स, संख्याएँ, बूलियन और नल एक ही सादे JavaScript मान बन जाते हैं। यह बताता है कि क्यों सीमा अक्सर तुच्छ लगती है।

गारंटी पार्सर-विशिष्ट रहनी चाहिए। ToolAcre टैग, कैप्स उपनाम और नेस्टिंग को प्रतिबंधित करता है, और एक इनपुट सीमा लागू करता है। एक टेक्स्ट व्यापक YAML प्रोसेसर के तहत मान्य हो सकता है, फिर भी इसके JSON-दिखने वाले कोर से असंबंधित सुरक्षा या आकार कारणों से यहां इसे अस्वीकार कर दिया जाता है।

साधारण JSON इस YAML 1.2 रीडर के माध्यम से लोड होता है; असमर्थित एक्सटेंशन अलग-अलग कारणों से विफल हो जाते हैं

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

सख्त मोड के तहत, टिल्ड, खाली मान और `0o755` स्ट्रिंग बने रहें। वे YAML टोकन हैं जिनमें JSON स्वयं शामिल नहीं होंगे। कोर JSON-आकार का आउटपुट लौटाते हुए उन्हें अलग तरीके से हल करता है।

शिप किए गए स्कीमा प्रत्येक विनिर्देश किनारे को साबित किए बिना JSON-आकार वाले डेटा के साथ संरेखित होते हैं

डुप्लिकेट YAML मैपिंग कुंजियाँ अंतिम मान को चेतावनी के साथ रखती हैं; कहीं और सख्त व्याख्या उन्हें अस्वीकार कर सकती है। लीगेसी YAML 1.1 पाठक `NO` जैसे शब्दों को अलग तरीके से टाइप कर सकते हैं, जबकि यह रीडर उन्हें स्ट्रिंग के रूप में रखता है। वे अंतर व्यापक पोर्टेबिलिटी कथनों को जटिल बनाते हैं।

इंडेंटेशन के रूप में उपयोग किए गए टैब एक त्रुटि उत्पन्न करते हैं, जबकि उद्धृत JSON स्ट्रिंग्स के अंदर के टैब बच जाते हैं। बहुत गहरे या बड़े आकार के मान स्थानीय सुरक्षा सीमाओं को प्रभावित कर सकते हैं। एक सैद्धांतिक भाषा संबंध कार्यान्वयन सीमाओं को पार नहीं करता है।

डुप्लिकेट कुंजियाँ और लीगेसी-पार्सर अंतर अंतरसंचालनीयता सीमाएँ बने हुए हैं

इस मूल्य पाइपलाइन के लिए विपरीत स्पष्ट रूप से गलत है। YAML टिप्पणियों में कोई JSON प्रतिनिधित्व नहीं है, उपनाम दोहराए गए डेटा में विघटित हो जाते हैं, बहु-दस्तावेज़ धाराएँ सारणी बन जाती हैं, और असमर्थित टैग अस्वीकार कर दिए जाते हैं। ब्लॉक स्केलर स्ट्रिंग बन जाते हैं लेकिन उनकी प्रस्तुति खो जाती है।

यहां तक ​​कि एक समर्थित YAML दस्तावेज़ भी वैध JSON में परिवर्तित हो सकता है और कभी भी उसी YAML टेक्स्ट पर वापस नहीं आ सकता है। डेटा समानता सामान्य मूल्यों के लिए जीवित रह सकती है जबकि टिप्पणियाँ, एंकर, वर्तनी और स्ट्रीम पहचान नहीं।

रूपांतरण के लिए इसका क्या मतलब है - JSON से YAML एक शैली परिवर्तन है, YAML से JSON एक अनुवाद है जो जानकारी खो सकता है

JSON-to-YAML आमतौर पर JSON-आकार वाले इनपुट के लिए एक शैली और क्रमांकन परिवर्तन है। YAML-to-JSON पहले YAML-विशिष्ट सिंटैक्स की व्याख्या करता है और फिर परिणाम को JSON के छोटे मान मॉडल में प्रोजेक्ट करता है। दिशाएँ सममित नहीं हैं.

ToolAcre सामान्य JSON-to-YAML-to-JSON दस्तावेज़ों का परीक्षण करता है जिनमें नेस्टेड मान, यूनिकोड, शून्य, सरणियाँ और अस्पष्ट दिखने वाले तार होते हैं। वे फिक्स्चर कवर किए गए डेटा वर्ग को साबित करते हैं, हर संभव JSON या YAML प्रोसेसर जोड़ी को नहीं।

कार्यान्वित उदाहरण: एक JSON दस्तावेज़ को YAML के रूप में लोड किया गया - समान संरचना, फिर एक YAML-केवल सुविधा यह दिखाने के लिए जोड़ी गई कि JSON टूलिंग कहाँ रुकती है

`{"country":"NO","items":[1,null],"nested":{"ok":true}}` को YAML इनपुट के रूप में चिपकाएँ। सख्त पाठक वही पेड़ लौटा देता है। एक YAML टिप्पणी जोड़ें और टिप्पणी गायब होने पर भी मान वही रहता है। किसी दोहराई गई वस्तु को एंकर और उपनाम से बदलें; JSON में अब संदर्भ सिंटैक्स के बजाय प्रतियां शामिल हैं।

`---` और दूसरा दस्तावेज़ जोड़ें; परिणाम एक चेतावनी के साथ दस्तावेज़ों की एक श्रृंखला बन जाता है। `!!binary` जोड़ें; प्रतिबंधित पाठक इसे अस्वीकार कर देता है। प्रत्येक चरण एक अलग सीमा को चिह्नित करता है: उपेक्षित प्रस्तुति, हल की गई संरचना, स्ट्रीम कन्वेंशन और असमर्थित प्रकार।

इसमें क्या शामिल नहीं है - स्कीमा-स्तरीय संगतता, जहां टाइमस्टैम्प जैसे YAML प्रकार का कोई JSON समकक्ष नहीं है

स्कीमा संगतता केवल सतह सिंटैक्स के बारे में नहीं है। कोर इन्फिनिटी या NaN बना सकता है, जिसे JSON चेतावनियों के साथ शून्य के रूप में लिखता है। टाइमस्टैम्प और बाइनरी टैग को परिवर्तित करने के बजाय प्रतिबंधित स्कीमा के तहत अस्वीकार कर दिया जाता है। ToolAcre जानबूझकर YAML को सुरक्षित JSON आकार के डेटा तक सीमित कर देता है।

एक अन्य YAML कार्यान्वयन अतिरिक्त प्रकारों का समर्थन कर सकता है। यह इसे उन बिंदुओं पर सादे JSON मानों के साथ कम संगत बनाता है, स्वचालित रूप से बेहतर या बदतर नहीं। लक्ष्य अनुबंध और सुरक्षा आवश्यकताओं के आधार पर चुनें।

स्कीमा-स्तरीय अनुकूलता में गैर-परिमित मान और अस्थायी टैग शामिल हैं जिन्हें यह प्रतिबंधित पाठक सीमित या अस्वीकार करता है

साधारण JSON-आकार का डेटा इस YAML 1.2 रीडर और लेखक से साफ़ होकर गुजरता है। सभी दस्तावेज़ों या पार्सर्स के बारे में व्यापक दावों के लिए डुप्लिकेट कुंजी, स्कीमा संस्करण, टैग और संसाधन सीमाओं को कवर करने वाले फिक्स्चर की आवश्यकता होती है।

वास्तविक पाठ का परीक्षण करने और उसकी चेतावनियाँ पढ़ने के लिए सिंटेक्स कन्वर्टर्स का उपयोग करें। पार्सर, स्कीमा और असमर्थित सुविधाओं का नामकरण करने के बाद ही "JSON YAML है" को एक उपयोगी शॉर्टहैंड के रूप में मानें जो वास्तविक सीमा को सटीक बनाते हैं।

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