YAML, JSON के डेटा मॉडल का एक सुपरसेट है: हर मान्य JSON डॉक्यूमेंट शब्द दर शब्द मान्य YAML भी है। अंतर यह नहीं है कि हर फॉर्मेट क्या दर्शा सकता है, बल्कि यह कि हर एक कैसे लिखा जाता है और हर एक हाथ से लिखते समय कितना आरामदायक है।
वही डेटा, दो तरीके
{
"name": "web-app",
"version": "1.0.0",
"scripts": { "build": "vite build", "test": "vitest" },
"dependencies": ["react", "vite"]
}name: web-app
version: 1.0.0
scripts:
build: vite build
test: vitest
dependencies:
- react
- viteवही डॉक्यूमेंट, एनालाइज़ करने पर वही डेटा। YAML कर्ली ब्रेसेज़, ब्रैकेट्स, प्लेन स्ट्रिंग्स के चारों ओर के कोटेशंस और ज़्यादातर कॉम्स को हटा देता है, और नेस्टिंग दिखाने के लिए इन्डेंटेशन का उपयोग करता है।
असली अंतर कहां हैं
कमेंट्स। YAML में होते हैं, # ऐसे। JSON में डिज़ाइन के हिसाब से बिल्कुल
नहीं होते; किसी .json कॉन्फ़िग फ़ाइल में किसी सेटिंग के बगल में कोई
स्पष्टीकरण रखने के लिए उसे कहीं और रखना होगा, आमतौर पर README में, क्योंकि
पार्सर // या # वाली लाइन को सीधे रिजेक्ट कर देगा। यही एक कारण है कि
हाथ से मेंटेन की जाने वाली कॉन्फ़िग (CI पाइपलाइंस, Docker Compose, Kubernetes
मैनिफेस्ट) में डिफ़ॉल्ट YAML होता है: एक साल बाद इसे एडिट करने वाले व्यक्ति
को यह जानना होगा कि कोई सेटिंग क्यों वैसी है जैसी है, और कमेंट ही एकमात्र
जगह है जो वैल्यू के बगल में बची रहती है।
व्हाइटस्पेस संवेदनशीलता। YAML का इन्डेंटेशन स्ट्रक्चरल है, ठीक Python की तरह। दो स्पेस की जगह चार, या जहां स्पेस चाहिए वहां एक टैब आ जाए तो डॉक्यूमेंट का मतलब बदल जाता है या टूट जाता है, और खराब इन्डेंटेशन का एरर मैसेज अक्सर JSON पार्सर के “अनएक्सपेक्टेड टोकन लाइन 4, कॉलम 12” से कम स्पेसिफिक होता है। JSON की कर्ली ब्रेसेज़ और ब्रैकेट्स एक्सप्लिसिट होते हैं, इसलिए इन्डेंटेशन सिर्फ कॉस्मेटिक है, और यही JSON के मशीन-जेनरेटेड फॉर्मेट होने की एक वजह है: स्क्रिप्ट को पठनीयता से कोई फर्क नहीं पड़ता और वह स्पष्ट डिलिमिटर पसंद करता है।
एक ही वैल्यू लिखने के अलग-अलग तरीके। YAML में प्लेन स्केलर, एकल कोटेड
स्ट्रिंग, डबल कोटेड स्ट्रिंग, मल्टी-लाइन टेक्स्ट के लिए ब्लॉक स्केलर,
रिफरेंस द्वारा वैल्यू दोहराने के लिए एंकर्स और एलियास, और कुछ इम्प्लिसिट
टाइप कन्वर्ज़न्स हैं (yes और no YAML 1.1 में बूलियन के रूप में पार्स
होते थे, जो ठीक वह सरप्राइज़ है जिसने “नॉर्वे प्रॉब्लम” को जन्म दिया,
एक कंट्री कोड NO का फ़ॉल्स बूलियन पढ़ा जाना, एक जाना-पहचाना YAML गोट्चा
बन गया)। JSON में स्ट्रिंग लिखने का एक तरीका, नंबर लिखने का एक तरीका,
और कोई इम्प्लिसिट कन्वर्ज़न नहीं है। एक ही चीज़ लिखने के कम तरीके मतलब
गलत लिखने के कम तरीके, और यही मशीन-टू-मशीन पेलोड में JSON का असली
तर्क है।
वर्बॉसिटी और कमेंट्स को छोड़कर, साइज़। व्हाइटस्पेस हटाने के बाद JSON और YAML एक ही डेटा के लिए लगभग तुलनीय साइज़ तक कम्प्रेस हो जाते हैं; YAML का फायदा पठनीयता है जब कोई व्यक्ति इसे एडिट कर रहा हो, न कि कच्चा बाइट काउंट।
कब किसका उपयोग करें
- JSON उस सब के लिए जो एक प्रोग्राम जेनरेट करता है और दूसरा प्रोग्राम कंज़्यूम करता है बिना बीच में किसी व्यक्ति के पढ़े: API पेलोड्स, डेटा इंटरचेंज, कोई भी चीज़ जो एक ही रिक्वेस्ट-रिस्पॉन्स साइकिल में सीरियलाइज़ और डीसीरियलाइज़ होती है।
- YAML उस सब के लिए जो कोई व्यक्ति नियमित रूप से हाथ से एडिट करता है और उसे मेंटेनेबल रखने के लिए कमेंट्स या मल्टी-लाइन स्ट्रिंग्स की ज़रूरत होती है: CI कॉन्फ़िग, Kubernetes मैनिफेस्ट, एप्लीकेशन कॉन्फ़िग फ़ाइलें जो इनलाइन डॉक्यूमेंटेशन के साथ आती हैं।
कई टूल्स दोनों स्वीकार करते हैं और इंटरनली कन्वर्ट करते हैं, जो आमतौर पर कोई स्थायी पक्ष चुनने से ज़्यादा उपयोगी है: कॉन्फ़िग उस फॉर्मेट में लिखें जो उसे मेंटेन करने वाले लोग पसंद करते हैं, और जहां कोई और चीज़ उसे प्रोग्रामेटिकली कंज़्यूम करने की ज़रूरत हो वहां JSON में कन्वर्ट करें।
एक से दूसरे में कन्वर्ट करना
JSON से YAML कन्वर्टर दोनों दिशाओं में काम करता है: यह
एंकर्स, एलियास और मल्टी-डॉक्यूमेंट स्ट्रीम्स को सही तरीके से लिखता है
न कि सबको प्लेन स्केलर्स में फ्लैट करता है, और YAML को वापस पढ़ते समय
उन चीज़ों को कोट करता है जो अपने ओरिजिनल टाइप के रूप में राउंड ट्रिप
नहीं करेंगी (जैसे "1.0.0" वर्ज़न स्ट्रिंग स्ट्रिंग ही रहती है, नंबर 1
नहीं बनती)। जो भी आप कन्वर्ट करते हैं वह अपलोड नहीं होता; कन्वर्ज़न
आपके ब्राउज़र में चलती है, ठीक इस साइट की हर टूल की तरह।