YAML और JSON के बीच अंतर क्या है?


734

विशेष रूप से निम्नलिखित बातों पर विचार करते हुए YAML और JSON के बीच क्या अंतर हैं?

  • प्रदर्शन (एनकोड / डिकोड समय)
  • मेमोरी की खपत
  • अभिव्यक्ति की स्पष्टता
  • पुस्तकालय की उपलब्धता, उपयोग में आसानी (मुझे पसंद है C)

मैं कॉन्फ़िगर फ़ाइलों को संग्रहीत करने के लिए हमारे एम्बेडेड सिस्टम में इन दोनों में से एक का उपयोग करने की योजना बना रहा था।

सम्बंधित:

क्या मुझे अपना पर्ल डेटा स्टोर करने के लिए YAML या JSON का उपयोग करना चाहिए?


26
विदित हो कि JSON को YAML का उपसमूह माना जा सकता है: en.wikipedia.org/wiki/JSON#YAML
चार्ल्स


1
YAML के (लगभग) JSON के एक सुपरसेट के बाद, प्रदर्शन के प्रश्न का उत्तर इस धारणा के बिना नहीं दिया जा सकता है कि क्या आप इस अर्थ का उपयोग करेंगे। यदि आपको इसकी आवश्यकता नहीं है: JSON पढ़ने में YAML पार्सर्स कितनी तेजी से हैं? यदि आपको इसकी आवश्यकता है: जब आप एक ही विचार के संभवतः JSON प्रतिनिधित्व के लिए अनुमति देते हैं तो JSON पार्सर कितना धीमा होता है?
पूल

@ जोकून मुझे लगता है कि "मैं एक सी लाइब्रेरी पसंद करूंगा" (उदाहरण libyaml)
dbr

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

जवाबों:


656

तकनीकी रूप से YAML JSON का सुपरसेट है। इसका मतलब यह है कि, सिद्धांत रूप में, एक YAML पार्सर JSON को समझ सकता है, लेकिन जरूरी नहीं कि इसके आसपास कोई दूसरा तरीका हो।

"YAML: JSON से संबंध" शीर्षक वाले अनुभाग में आधिकारिक चश्मा देखें ।

सामान्य तौर पर, कुछ चीजें मुझे पसंद हैं जैसे कि YAML जो JSON में उपलब्ध नहीं है।

  • जैसा @jdupont ने बताया , YAML देखने में आसान है। वास्तव में YAML मुखपृष्ठ स्वयं मान्य YAML है, फिर भी मानव के लिए पढ़ना आसान है।
  • YAML में "एन्कर्स" का उपयोग करके एक YAML फ़ाइल के भीतर अन्य वस्तुओं को संदर्भित करने की क्षमता है। इस प्रकार यह संबंधपरक जानकारी को संभाल सकता है क्योंकि एक MySQL डेटाबेस में मिल सकता है।
  • YAML फ़ाइल के भीतर JSON या XML जैसे अन्य क्रमांकन स्वरूपों को एम्बेड करने के बारे में YAML अधिक मजबूत है ।

व्यवहार में, इनमें से किसी भी अंतिम दो बिंदु आपके या मेरे द्वारा की जाने वाली चीजों के लिए संभव नहीं होंगे, लेकिन लंबे समय में, मुझे लगता है कि YAML अधिक मजबूत और व्यवहार्य डेटा क्रमांकन प्रारूप होगा।

अभी, AJAX और अन्य वेब प्रौद्योगिकियाँ JSON का उपयोग करती हैं। वर्तमान में ऑफलाइन डेटा प्रक्रियाओं के लिए YAML का अधिक उपयोग किया जा रहा है। उदाहरण के लिए, यह C- आधारित OpenCV कंप्यूटर विज़न पैकेज में डिफ़ॉल्ट रूप से शामिल है, जबकि JSON नहीं है।

आपको JSON और YAML दोनों के लिए C लाइब्रेरी मिलेगी। YAML के पुस्तकालय नए होते हैं, लेकिन मुझे अतीत में उनसे कोई परेशानी नहीं हुई। उदाहरण के लिए देखें यमल-सीपीपी


199
json एक सबसेट नहीं है (हालाँकि यह करीब है), और जब आप उन्हें एनकाउंटर करते हैं तो असंगतताएँ उल्लंघन करती हैं। json पुस्तकालयों आमतौर पर तेजी से कर रहे हैं ... ( stackoverflow.com/questions/2451732/… )। yaml समर्थकों का कहना है कि यह एक सबसेट है। अगर पठनीयता एक चिंता का विषय है, तो yaml का उपयोग करें। यदि इंटरऑपरेबिलिटी और गति एक चिंता का विषय है, तो JSON का उपयोग करें।
एरिक एरोनिटी

6
YAML JSON सिंटैक्स के एक विशेष रूप का एक सुपरसेट है। यही है, यदि आप JSON का उपयोग इस तरह से करते हैं जो YAML के साथ संगत है, तो यह एक उचित उपसमूह है। जैसा कि पियर ने ऊपर टिप्पणी की, चश्मा [अनुकूलता की ओर लक्ष्य] (ajaxian.com/archives/json-yaml-its-getting-closer-to-truth)।
n

120
इसके अलावा YAML टिप्पणियों का समर्थन करता है जो आसान है।
डेन

59
@ErikAronesty JSON, YAML 1.1 के सबसेट के करीब था, लेकिन YAML 1.2 के बाद से अब यह एक सच्चा सबसेट है। YAML 1.2 को मुख्य रूप से दो विशिष्टताओं के बीच अंतिम कुछ असंगतियों को दूर करने के लिए जारी किया गया था।
00prometheus 19

64
से YAML 1.2 कल्पना : "इस संशोधन के प्राथमिक उद्देश्य के एक अधिकारी ने सबसेट के रूप में JSON के अनुपालन में YAML लाना है।"
रिच सी

203

अंतर:

  1. YAML, इस पर निर्भर करता है कि आप इसे कैसे उपयोग करते हैं, JSON से अधिक पठनीय हो सकता है
  2. JSON अक्सर तेज़ होता है और संभवतः अधिक सिस्टम के साथ अभी भी इंटरऑपरेबल होता है
  3. JSON पार्सर को बहुत जल्दी "अच्छा पर्याप्त" लिखना संभव है
  4. डुप्लिकेट कुंजी, जो संभावित वैध JSON हैं, निश्चित रूप से YAML अमान्य हैं।
  5. YAML में टिप्पणियों और रिलेशनल एंकरों सहित सुविधाओं की एक टन है। YAML सिंटैक्स तदनुसार काफी जटिल है, और समझने में कठिन हो सकता है।
  6. यम्ल में पुनरावर्ती संरचनाएं लिखना संभव है: {a: &b [*b]}जो कुछ कन्वर्टर्स में असीम रूप से लूप करेगा। यहां तक ​​कि परिपत्र का पता लगाने के साथ, "यमल बम" अभी भी संभव है (देखें xml बम )।
  7. क्योंकि कोई संदर्भ नहीं हैं, JSON में ऑब्जेक्ट संदर्भों के साथ जटिल संरचनाओं को क्रमबद्ध करना असंभव है। इसलिए YAML क्रमांकन अधिक कुशल हो सकता है।
  8. कुछ कोडिंग वातावरण में, YAML का उपयोग एक हमलावर को मनमाने कोड को निष्पादित करने की अनुमति दे सकता है ।

टिप्पणियों:

  1. पायथन प्रोग्रामर आमतौर पर YAML के बड़े प्रशंसक होते हैं, क्योंकि इंडेंटेशन के उपयोग के कारण, स्तर को इंगित करने के लिए ब्रैकेटेड सिंटैक्स के बजाय।
  2. कई प्रोग्रामर एक खराब विकल्प को इंडेंट करने के लिए "अर्थ" के लगाव पर विचार करते हैं।
  3. यदि डेटा प्रारूप किसी UI के भीतर पार्स किया गया, या मैसेजिंग लेयर में भेजा गया, तो एप्लिकेशन का वातावरण छोड़ रहा होगा, JSON एक बेहतर विकल्प हो सकता है।
  4. व्याकरण परिभाषाओं जैसे जटिल कार्यों के लिए, YAML का उपयोग सीधे किया जा सकता है, और अक्सर एक नई भाषा का आविष्कार करने से बेहतर विकल्प होता है।

9
यह है। यमल १.२ का पूरा उद्देश्य JSON को एक सबसेट बनाने के लिए कुछ अनुकूलता अंतरों को हल करना था। यदि आपको लगता है कि युक्ति ने अपना उद्देश्य प्राप्त नहीं किया है, तो एरिक, कृपया मान्य JSON के कहीं एक उदाहरण की ओर संकेत करें जो YAML युक्ति का उल्लंघन करता है और / या एक सत्यापित 1.2-अनुपालन YAML पार्सर को तोड़ता है।
SFEley

32
@SFEley YAML कल्पना का कहना है कि संभावित वैध JSON फाइलें हैं जो अमान्य YAML होंगी। लेकिन यह वास्तविक उपयोग में होने की संभावना नहीं है। "JSON के RFC4627 के लिए यह आवश्यक है कि मैपिंग कीज़ केवल" SHOULD "हों, जो अद्वितीय हों, जबकि YAML उनका कहना है कि" MUST "होना चाहिए। तकनीकी रूप से, YAML इसलिए JSON युक्ति का अनुपालन करता है, डुप्लिकेट को एक त्रुटि के रूप में चुनने के लिए। व्यवहार में, JSON JSON पर चुप है। इस तरह के डुप्लिकेट के शब्दार्थ, केवल पोर्टेबल JSON फाइलें हैं जो अद्वितीय कुंजी के साथ हैं, जो इसलिए मान्य YAML फाइलें हैं। " - yaml.org/spec/1.2/spec.html#id2759572
डेविड सी। बिशप

9
इंडेंट के उपयोग पर टिप्पणी करने के लिए; ठीक है, मेरा मानना ​​है कि इसका उपयोग करने की आवश्यकता हो सकती है और हर कोई इसे पसंद नहीं करेगा। उदाहरण के लिए, मैं एक .NET लड़का हूं। मैं एक travis.yml फ़ाइल देख रहा था और सोच रहा था कि कोई समस्या क्यों है। मुझे पता चला कि मेरे पास एक टैब है जहां यह नहीं होना चाहिए। हर कोई अंतरिक्ष / टैब / नई लाइनों की वरीयताओं के कारण उड़ने वाली चीजों के लिए उपयोग नहीं किया जाता है।
फिल 15

10
टैब को केवल इंडेंटेशन वर्ण के रूप में अनुमति नहीं है। IMHO, कि सभी भाषाओं में अच्छी कोडिंग शैली है - सिंटैक्टिक इंडेंटेशन के साथ या बिना।
00prometheus

6
@Wyrmwood मैं व्यक्तिगत रूप से अजगर और YAML को पसंद करता हूं और सचमुच हर दिन उनका उपयोग करता हूं। मैं सामान का उपयोग करने के लिए YAML का उपयोग अक्सर करता हूं और सामान के लिए JSON को ऐसे लोगों के लिए संपादित करना पड़ता है जिन्हें लोगों को "देखने" की आवश्यकता हो सकती है। मुझे सी ++ देवों द्वारा मान्य आलोचना के अधीन किया गया है, जो भ्रामक होने के लिए इंडेंटेशन का पता लगाते हैं .... खासकर अगर कई स्तर या लंबे फ़ंक्शन ब्लॉक हैं। बेशक ... अच्छा परीक्षण योग्य कोड उन चीजों में नहीं होता है, इसलिए यह आमतौर पर एक मुद्दा नहीं है। यह मेरा व्यक्तिगत अवलोकन है, लेकिन किसी भी आकस्मिक Google खोज से कई परिणाम मिलेंगे ...।
Erik Aronesty

88

गूढ़ सिद्धांत को दरकिनार

यह शीर्षक का जवाब देता है, न कि विवरण जैसा कि मेरे जैसे Google पर खोज परिणाम से शीर्षक को सबसे अधिक पढ़ा जाता है इसलिए मुझे लगा कि वेब डेवलपर के दृष्टिकोण से व्याख्या करना आवश्यक है

  1. YAML अंतरिक्ष इंडेंटेशन का उपयोग करता है, जो पायथन डेवलपर्स के लिए परिचित क्षेत्र है।
  2. जावास्क्रिप्ट डेवलपर्स JSON से प्यार करते हैं क्योंकि यह जावास्क्रिप्ट का एक सबसेट है और इसे सीधे जावास्क्रिप्ट के साथ व्याख्या और लिखा जा सकता है, साथ ही JSON को घोषित करने के लिए शॉर्टहैंड तरीके का उपयोग करते हुए, बिना रिक्त स्थान के विशिष्ट चर नामों का उपयोग करते समय कुंजी में कोई दोहरे उद्धरण की आवश्यकता नहीं होती है।
  3. पार्सलर्स के ढेर सारे हैं जो सभी भाषाओं में बहुत अच्छी तरह से काम करते हैं, दोनों के लिए YAML और JSON।
  4. कई मामलों में देखने के लिए YAML का अंतरिक्ष प्रारूप बहुत आसान हो सकता है क्योंकि प्रारूपण के लिए अधिक मानव-पठनीय दृष्टिकोण की आवश्यकता होती है।
  5. यदि आप अपने संपादक में दिखाई देने वाली जगह का प्रारूपण नहीं करते हैं, तो अधिक संक्षिप्त और देखने में आसान होने के कारण YAML का फ़ॉर्म भ्रामक रूप से संपादित करना मुश्किल हो सकता है। टैब रिक्त स्थान नहीं हैं, ताकि यदि आप अपने कीस्ट्रोक्स को अंतरिक्ष में व्याख्या करने के लिए संपादक नहीं रखते हैं तो आगे भ्रमित हो जाते हैं।
  6. JSON को अनुक्रमित करने के लिए बहुत तेज़ है और यह जांचने के लिए YAML की तुलना में काफी कम विशेषताओं के कारण है, जो JSON को संसाधित करने के लिए छोटे और हल्के कोड को सक्षम करता है।
  7. एक आम गलत धारणा यह है कि YAML को कम विराम चिह्न की आवश्यकता है और JSON की तुलना में अधिक कॉम्पैक्ट है लेकिन यह पूरी तरह से गलत है। व्हॉट्सएप अदृश्य है इसलिए ऐसा लगता है कि कम वर्ण हैं, लेकिन यदि आप वास्तविक व्हाट्सएप की गिनती करते हैं जो आवश्यक है कि मिक्सएल को उचित इंडेंटेशन के साथ-साथ अच्छी तरह से व्याख्या करने के लिए हो, तो आप पाएंगे कि एचसीएल को वास्तव में JSON के लिए अधिक वर्णों की आवश्यकता होती है। JSON पदानुक्रम या समूह का प्रतिनिधित्व करने के लिए व्हाट्सएप का उपयोग नहीं करता है और अधिक कॉम्पैक्ट परिवहन के लिए हटाए गए अनावश्यक व्हाट्सएप के साथ आसानी से चपटा हो सकता है।

कमरे में हाथी: इंटरनेट ही

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

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


10
मैं असहमत हूं कि अजगर डेवलपर्स YAML को पसंद करते हैं। अजगर तानाशाह आधारभूत JSON है, dicts की सूची भी मूल रूप से JSON है। पायसन ने json lib में बिल्ड किया है। एक ओर ध्यान दें कि मैं एक अजगर डेवलपर हूं और मुझे JSON पसंद है (अधिकांश अजगर डेवलपर्स जिन्हें मैं जानता हूं कि JSON पसंद करते हैं)।
कर्णावन

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

6
@JasonSebring। आपको लगभग आश्चर्य होगा कि YAML रिक्त स्थान के साथ क्यों गया। YAML का मेरा पहला 'डुबकी' एक टूटी हुई एप्लिकेशन के लिए नेतृत्व किया ... सभी रिक्त स्थान के कारण। आपने सोचा होगा कि शायद नॉन-प्रिंटिंग चार्ट का उपयोग न करने के लिए इंडेंटेशन का उपयोग करना बहुत अधिक समझ में आता है! (यही कारण है कि, पृथ्वी पर उन्होंने '' के बजाय '' का चयन क्यों नहीं किया?) YAML को समझने के लिए आपको ऐनक पर जाना होगा। समझने के लिए JSON की आवश्यकता नहीं है। (मैं पूर्व में रहा हूँ, और बाद कभी नहीं)। यह मेरे लिए एक प्रारूप इंगित करता है जो वास्तव में 'मानव पठनीय' नहीं है
cmroanirgo

7
@cmroanirgo yah यह मेरा अनुभव था। मेरे बॉस ने हमें JSON पर YAML का उपयोग करने के लिए मजबूर किया और इसने अनावश्यक रूप से चीजों को संपादित और निगलना के लिए भद्दा बना दिया। मैंने इसे इस वजह से लिखा था कि उम्मीद है कि वोट मुझे लुभाएंगे।
जेसन सीब्रिंग

3
YAML में टैब के साथ परेशानी का अर्थ है (ए) त्रुटि संदेश नहीं पढ़ना, और (बी) एक संपादक है जो टैब को उजागर नहीं करता है। दोनों समस्याएं आसानी से ठीक हो जाती हैं, इसलिए मैं शिकायतों को नहीं समझता।
टूलबार

38

यह सवाल 6 साल पुराना है, लेकिन अजीब बात है, कोई भी उत्तर वास्तव में सभी चार बिंदुओं (गति, स्मृति, अभिव्यंजना, पोर्टेबिलिटी) को संबोधित नहीं करता है।

गति

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

हालाँकि, यह देखते हुए कि एक YAML फ़ाइल अपने JSON समकक्ष (कम "और ,पात्रों के कारण ) से थोड़ी छोटी हो सकती है , यह संभव है कि एक अत्यधिक अनुकूलित YAML पार्सर असाधारण परिस्थितियों में तेज हो सकता है।

याद

मूल रूप से एक ही तर्क लागू होता है। यह देखने के लिए मुश्किल है कि एक जेसीएल पार्सर की तुलना में एक YAML पार्सर कभी भी अधिक मेमोरी कुशल क्यों होगा, यदि वे एक ही डेटा संरचना का प्रतिनिधित्व कर रहे हैं।

अभिव्यक्ति

जैसा कि अन्य लोगों ने बताया है कि पायथन प्रोग्रामर YAML को प्राथमिकता देते हैं, जावास्क्रिप्ट प्रोग्रामर JSON की ओर। मैं ये अवलोकन करूँगा:

  • JSON के पूरे सिंटैक्स को याद रखना आसान है, और इसलिए किसी भी JSON फ़ाइल के अर्थ को समझने के बारे में बहुत आश्वस्त होना चाहिए। YAML वास्तव में किसी भी मानव द्वारा समझने योग्य नहीं है। सूक्ष्मता और किनारे के मामलों की संख्या चरम है।
  • चूँकि कुछ पार्सर संपूर्ण कल्पना को कार्यान्वित करते हैं, इसलिए किसी दिए गए संदर्भ में दिए गए अभिव्यक्ति के अर्थ के बारे में निश्चित होना कठिन है।
  • JSON में टिप्पणियों की कमी, व्यवहार में, एक वास्तविक दर्द है।

पोर्टेबिलिटी

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

सारांश

JSON प्रदर्शन के लिए विजेता है (यदि प्रासंगिक है) और इंटरऑपरेबिलिटी। YAML मानव-रखरखाव फ़ाइलों के लिए बेहतर है। HJSON एक सभ्य समझौता है, हालांकि बहुत कम पोर्टेबिलिटी के साथ। JSON5 एक अधिक उचित समझौता है, जिसमें अच्छी तरह से परिभाषित वाक्यविन्यास है।


3
मैंने वास्तव में सोचा था कि मिचेल अदृश्य पात्रों के कारण छोटा था जो मुझे इस तरह बेवकूफ बनाते थे। अदृश्य => वहाँ नहीं, वास्तव में नहीं। यदि आप अदृश्य पात्रों को गिनते हैं, तो विशेष रूप से YAML को बड़े घोंसले मिलते हैं, यह जल्दी से JSON से आगे निकल जाता है। मुझे लगा कि मानव-पठनीय भाग के रूप में यह बहुत दिलचस्प है, हम में से अधिकांश को उस धारणा में मूर्ख बनाते हैं जब तक कि मैंने वास्तव में इसके बारे में नहीं सोचा था क्योंकि आप JSON और YAML को समतल कर सकते हैं, इतना नहीं। मैंने यह भी पाया कि YAML को संपादित करना बहुत मुश्किल है, पढ़ा नहीं जा रहा है, बस संपादित करें जैसा कि आपको जरूरत है संपादक गाइड को चालू करने की, आसानी से कई बार नेस्टेड आइटमों को गलत करने की।
जेसन सेब्रिंग

1
मुझे लगता है कि यहां कोई भी उत्तर स्पष्ट रूप से नहीं दिया गया है: "सेटिंग्स / कॉन्फिग फाइलों के लिए, YAML बेहतर है (हर किसी के ऊपर बताए गए कारणों के लिए)। मशीन / मशीन इंटरोप के लिए JSON का उपयोग करें"। दूसरे शब्दों में: यदि आपके लक्षित दर्शक एक मानव हैं, तो YAML बेहतर है। यदि लक्ष्य एक अन्य कार्यक्रम है (लेकिन आप अभी भी डेटा को मानव पठनीय बनाना चाहते हैं), JSON का उपयोग करें।
फ्लोरिन टी।

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

29

GIT और YAML

अन्य उत्तर अच्छे हैं। पहले उन पढ़ें। लेकिन मैं कभी-कभी YAML का उपयोग करने के लिए एक और कारण जोड़ूंगा: गिट

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

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

व्यक्तिगत रूप से, मैं आम तौर पर सिस्टम-टू-सिस्टम इंटरैक्शन के लिए JSON का उपयोग करता हूं। मैं अक्सर कॉन्फ़िगर फ़ाइलों, स्थिर फ़ाइलों और ट्रैक की गई फ़ाइलों के लिए YAML का उपयोग करता हूं। (मैं भी आम तौर पर YAML संबंधपरक एंकरों को जोड़ने से बचता हूं। लूप का शिकार करने के लिए जीवन बहुत छोटा है।)

इसके अलावा, अगर गति और स्थान वास्तव में एक चिंता का विषय है, तो मैं भी उपयोग नहीं करता हूं। आप BSON को देखना चाहते हैं।


22

मुझे पता है कि आँखों पर कम: कोष्ठक, "" आदि के लिए YAML लगता है। हालांकि, YAML में टैब की झुंझलाहट है ... लेकिन किसी को भी यह लटका हुआ मिलता है।

प्रदर्शन / संसाधनों के मामले में, मैं दोनों के बीच बड़े अंतर की उम्मीद नहीं करूंगा।

Futhermore, हम कॉन्फ़िगरेशन फ़ाइलों के बारे में बात कर रहे हैं और इसलिए मैं एनकोड / डिकोड गतिविधि की उच्च आवृत्ति की उम्मीद नहीं करूंगा, नहीं?


22
मैंने सोचा कि टैब की झुंझलाहट से आपका क्या मतलब है । मेरा मानना ​​है कि बात यह है कि टैब वर्णों को यमल में अनुमति नहीं है , जो व्यक्तिगत रूप से मुझे लगता है कि किसी भी स्रोत फ़ाइल में एक अच्छा विचार है
पूली

6
@pool: jldupont की संभावना है कि YAML में वाक्यविन्यास महत्वपूर्ण अग्रणी व्हाट्सएप हो।
n

10
ठीक है, लेकिन वे टैब नहीं हैं।
पूली

20

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


3
किस तरह से YAML अधिक जटिल है?
Accatyyc

18
उदाहरण के लिए, YAML एंकर का समर्थन करता है, जैसा कि एक अन्य उत्तर में नोट किया गया है। अन्य विशेषताएं हैं, जैसे एक्सटेंसिबल डेटा प्रकार। यह इसे पार्स करने के लिए और अधिक जटिल बनाता है, और बताता है कि क्यों YAML में बड़ी कल्पना है। यह पार्सर कार्यान्वयन के आधार पर प्रदर्शन को नुकसान पहुंचा सकता है (इस प्रश्न पर एक नज़र डालें: stackoverflow.com/questions/2451732/… )।
एंटोन स्ट्रोगनॉफ

5
जटिलता सरलता से बेहतर है यदि वह जटिलता आपको अधिक से अधिक सरलता प्राप्त करने के लिए शक्ति खरीदती है। यह निश्चित रूप से आपके डेटा मॉडल की जटिलता के आधार पर सही है।
जोनाथन न्यूफेल्ड

3
मुझे यहाँ थोड़ी देर हो सकती है लेकिन YAML टिप्पणियों में जोड़ सकता है जबकि JSON नहीं कर सकता। मेरे लिए यह एक बड़ी मदद है जब विशिष्टताओं के दस्तावेज़ीकरण की बात आती है
मूसा लियाओ जीजेड

@Accatyyc। मुझे लगता है कि लोग यहां अंतर के बारे में सवाल पूछ रहे हैं, यह एक निश्चित संकेत है कि हर कोई आसान नहीं है। मैंने JSON के बारे में कभी कोई प्रश्न नहीं पूछा ("मुझे इसमें टिप्पणी क्यों नहीं मिल सकती?")
cmroanirgo

15

तकनीकी रूप से YAML JSON की तुलना में बहुत अधिक प्रदान करता है (YAML v1.2 JSON का सुपरसेट है))

  • टिप्पणियाँ
  • एंकर और विरासत - 3 समान वस्तुओं का उदाहरण:

    item1: &anchor_name
      name: Test
      title: Test title
    item2: *anchor_name
    item3:
      <<: *anchor_name
      # You may add extra stuff.
  • ...

अधिकांश समय लोग उन अतिरिक्त सुविधाओं का उपयोग नहीं करेंगे और मुख्य अंतर यह है कि YAML इंडेंटेशन का उपयोग करता है जबकि JSON कोष्ठक का उपयोग करता है । यह YAML को अधिक संक्षिप्त और पठनीय (प्रशिक्षित आंख के लिए) बनाता है ।

कौन सा चुनना है?

  • YAML अतिरिक्त विशेषताएं और संक्षिप्त संकेतन इसे विन्यास फाइल (गैर-उपयोगकर्ता प्रदान की गई फाइल) के लिए एक अच्छा विकल्प बनाता है ।
  • JSON सीमित सुविधाएँ, व्यापक समर्थन और तेज़ पार्सिंग इसे इंटरऑपरेबिलिटी और उपयोगकर्ता द्वारा प्रदान किए गए डेटा के लिए एक बढ़िया विकल्प बनाता है ।

4

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


मैं JSON का उपयोग नहीं करता, मैं JSON को कॉल किए बिना JSON के सटीक समकक्ष का उपयोग करता हूं। मैं इसे PS-OFF कहता हूं। आप मुझे उपयोग करने के लिए मुकदमा करने जा रहे हैं { "": #, [] }???
एंड्रयू

4

कभी-कभी आपको एक दूसरे के लिए निर्णय लेने की जरूरत नहीं होती है।

उदाहरण के लिए, आप एक ही समय में दोनों हो सकते हैं:

type Person struct {
    Name string `json:"name" yaml:"name"`
    Age int `json:"age" yaml:"age"`
}

3

प्रेषक: अरनौद लौरत बुक "वेब एपीआई का डिजाइन।" :

JSON डेटा प्रारूप

JSON एक टेक्स्ट डेटा प्रारूप है, जो इस बात पर आधारित है कि जावास्क्रिप्ट प्रोग्रामिंग भाषा डेटा का वर्णन कैसे करती है, लेकिन इसके नाम के बावजूद, पूरी तरह से भाषा-स्वतंत्र है (देखें https://www.json.org/ )। JSON का उपयोग करते हुए , आप वस्तुओं का वर्णन कर सकते हैं जिसमें बिना नाम / मूल्य जोड़े और आदेश दिए गए मानों वाली सरणियाँ या सूचियाँ शामिल हैं, जैसा कि इस आंकड़े में दिखाया गया है।

यहां छवि विवरण दर्ज करें

एक वस्तु को कर्ली ब्रेसिज़ ({}) द्वारा सीमांकित किया जाता है। एक नाम एक उद्धृत स्ट्रिंग ("नाम") है और एक बृहदान्त्र (:) द्वारा इसके मान से sep- उत्पन्न होता है। एक मान "मान", 1.23 की संख्या, एक बूलियन (सच या गलत), शून्य मान शून्य, एक वस्तु या एक सरणी की तरह एक स्ट्रिंग हो सकता है। एक सरणी कोष्ठक ([]) द्वारा सीमांकित किया गया है, और इसके मानों को अल्पविराम (,) से अलग किया गया है। JSON प्रारूप आसानी से किसी भी प्रोग्रामिंग भाषा के उपयोग पार्स किया गया है। यह पढ़ना और लिखना अपेक्षाकृत आसान है। यह कई उपयोगों के लिए व्यापक रूप से अपनाया जाता है जैसे डेटाबेस, configura- tion फ़ाइलें, और, निश्चित रूप से, APIs।

YAML

YAML (YAML Ain't Markup Language) एक मानव-अनुकूल, डेटा क्रमांकन प्रारूप है। JSON की तरह, YAML ( http://yaml.org ) एक कुंजी / मान डेटा प्रारूप है। आंकड़ा दो की तुलना दिखाता है।

यहां छवि विवरण दर्ज करें

निम्नलिखित बातों पर ध्यान दें:

  • YAML में संपत्ति के नाम और मूल्यों के आसपास कोई दोहरे उद्धरण ("") नहीं हैं ।

  • JSON के संरचनात्मक घुंघराले ब्रेसिज़ ({}) और अल्पविराम (,) को यमलोक में नई कहानियों और इंडेंटेशन द्वारा प्रतिस्थापित किया जाता है ।

  • ऐरे कोष्ठक ([]) और अल्पविराम (,) को डैश (-) और यमस्ल में नए सिरे से प्रतिस्थापित किया जाता है ।

  • JSON के विपरीत , YAML एक हैश मार्क (#) के साथ शुरुआत करने की अनुमति देता है। उन स्वरूपों में से एक को दूसरे में बदलना अपेक्षाकृत आसान है। हालांकि, जब आप किसी टिप्पणी को किसी JSON के लिए YAML दस्तावेज़ में परिवर्तित करते हैं, तो आप पहले से ही सूचित हो जाएंगे ।


0

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

अंत में, यह ईमानदारी से कोई फर्क नहीं पड़ता। JSON और YAML दोनों किसी भी अनुभवी प्रोग्रामर द्वारा आसानी से पढ़े जाते हैं।


-1
  • JSON yml की तुलना में बड़े डेटा को संभाल नहीं सकता है

  • विभिन्न मल्टीमीडिया स्वरूपों को संभालने के लिए उपयुक्त नहीं है।

  • JSON में 'टिप्पणियों' का समर्थन करने की सुविधा नहीं है। इसे अकेले एक अतिरिक्त विशेषता के रूप में शामिल किया जा सकता है।

  • YAML के JSON पर कुछ फायदे हैं जैसे आत्म-संदर्भ, जटिल डेटाटाइप्स के लिए समर्थन, एम्बेडेड ब्लॉक शाब्दिक, टिप्पणियां और बहुत कुछ।

  • JSON केवल पठनीय है जबकि YAML पठनीय और साथ ही संपादन योग्य हो सकता है।
  • JSON, YAML का सबसेट है, ताकि YAML पार्सर्स JSON को पार्स करने में सक्षम हो सके।
  • YAML किसी भी अतिरिक्त सीमांकक का उपयोग नहीं करता है, इसलिए यह XML और JSON की तुलना में अधिक हल्का है।

"बड़े डेटा" और "केवल पठनीय" बिंदुओं पर आपका क्या मतलब है? JSON एक डेटा प्रारूप है, एक अमूर्त अवधारणा की इन दो सीमाओं में क्या हो सकता है?
जोओ फेरीज

4
@ JoãoFarias मान लीजिए कि आपके पास 1GB JSON फ़ाइल और 1GB CSV फ़ाइल है और आपके पास 256MB मेमोरी है। आप CSV फ़ाइल लाइन को लाइन से संसाधित कर सकते हैं, JSON के साथ यह आसानी से संभव नहीं है। यह संभव है कि जैसन कभी भी पार्सिंग की तुलना में YAML फाइल लाइन को पार्स करना आसान हो।
NeverEndingQueue
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.