YAML
2 टूल्स
डेटा सीरियलाइज़ेशन फ़ॉर्मेट
डेटा सीरियलाइज़ेशन वह प्रक्रिया है जिसमें structured data को ऐसे format में बदला जाता है जिसे store या transfer किया जा सके और बाद में reconstruct किया जा सके। अलग-अलग formats human readability, machine parseability, expressiveness और file size के बीच अलग-अलग trade-offs करते हैं।
JSON, YAML, TOML और XML — ये software development में इस्तेमाल होने वाले चार मुख्य text-based सीरियलाइज़ेशन फ़ॉर्मेट हैं। हर एक में ऐसी खूबियाँ हैं जो उसे कुछ खास situations के लिए बेहतर बनाती हैं — इन trade-offs को समझने से आप हर काम के लिए सही format चुन सकते हैं।
JSON और YAML की तुलना
JSON और YAML एक ही डेटा मॉडल को व्यक्त करते हैं। YAML, JSON का एक कठोर सुपरसेट है — कोई भी वैध JSON दस्तावेज़ YAML में भी वैध होता है। नीचे एक ही कॉन्फ़िगरेशन को दोनों प्रारूपों में दिखाया गया है:
{
"server": {
"host": "localhost",
"port": 8080,
"debug": true
},
"database": {
"url": "postgres://localhost/mydb",
"pool": 10
}
}server: host: localhost port: 8080 debug: true database: url: postgres://localhost/mydb pool: 10
YAML ब्रेसेज़ ({ }) और brackets ([ ]) की जगह indentation इस्तेमाल करता है और ज़्यादातर string values से quotes हटा देता है। इससे manually edit होने वाली files के लिए यह ज़्यादा clean और readable बनता है, लेकिन indentation की गलती पर यह तुरंत टूट जाता है।
प्रारूप तुलना
| प्रारूप | पठनीयता | टिप्पणियाँ | ऐरे | सर्वोत्तम उपयोग |
|---|---|---|---|---|
| JSON | ★★★☆☆ | टिप्पणी नहीं | मूल समर्थन | API, डेटा आदान-प्रदान |
| YAML | ★★★★★ | हाँ (#) | मूल समर्थन | कॉन्फ़िग फ़ाइलें, IaC |
| TOML | ★★★★☆ | हाँ (#) | मूल समर्थन | ऐप कॉन्फ़िग (Rust, Python) |
| XML | ★★☆☆☆ | हाँ (<!-- -->) | दोहराए गए तत्व | दस्तावेज़, SOAP, SVG |
YAML की सामान्य समस्याएँ
YAML शक्तिशाली है, लेकिन इसमें कुछ जाने-माने विशेष मामले हैं जो डेवलपर्स को अचंभित कर देते हैं। ये सबसे सामान्य समस्याएँ हैं:
YAML 1.1 में 'NO' का सीधा मान बूलियन false के रूप में व्याख्यायित किया जाता है। NO (नॉर्वे), OFF, FALSE, N जैसे देश कोड — सभी false के रूप में पार्स होते हैं। YAML 1.2 में यह ठीक किया गया है, परंतु अनेक पार्सर अभी भी 1.1 नियमों का उपयोग करते हैं। संदिग्ध string values को सदैव quotes में रखें।
YAML संरचना परिभाषित करने के लिए इंडेंटेशन का उपयोग करता है। एक अतिरिक्त space या tab character किसी दस्तावेज़ का अर्थ पूरी तरह बदल सकता है। YAML में इंडेंटेशन के लिए tab allowed नहीं है — केवल space allowed है।
जो सीधे मान संख्या, बूलियन या null जैसे दिखते हैं, वे स्वतः रूपांतरित हो जाते हैं। '1.0' फ्लोट बन जाता है, '2024-01-01' कुछ पार्सर में दिनांक ऑब्जेक्ट बन जाता है। जिन values को आप string के रूप में रखना चाहते हैं, उन्हें quotes में रखें।
YAML विनिर्देश इंडेंटेशन के लिए टैब वर्णों को स्पष्ट रूप से वर्जित करता है। जो संपादक रिक्त स्थानों को स्वतः टैब में बदलते हैं, वे आपकी YAML फ़ाइल को चुपचाप तोड़ देंगे। अपने संपादक को YAML फ़ाइलों में रिक्त स्थानों का उपयोग करने के लिए कॉन्फ़िगर करें।
YAML में दो बहु-पंक्ति स्ट्रिंग संकेतक हैं: | (शाब्दिक ब्लॉक, नई पंक्तियाँ यथावत रखता है) और > (मोड़ा हुआ ब्लॉक, नई पंक्तियों को रिक्त स्थान में बदलता है)। इन्हें आपस में बदलने से चुपचाप गलत आउटपुट उत्पन्न होता है।
YAML एंकर (&) और उपनाम (*) नोड का पुनः उपयोग करने की सुविधा देते हैं, जो शक्तिशाली है, लेकिन सरल पार्सर में अनंत लूप या मेमोरी की अत्यधिक खपत का कारण बन सकते हैं। अविश्वसनीय स्रोतों से प्राप्त एंकर-युक्त YAML को सत्यापित करें।
YAML की विशिष्ट विशेषताएँ
टिप्पणियाँ
YAML, # वर्ण के साथ टिप्पणियों का समर्थन करता है। कॉन्फ़िगरेशन फ़ाइलों के लिए JSON की तुलना में यह सबसे बड़े व्यावहारिक लाभों में से एक है — आप अपनी सेटिंग्स को सीधे उसी स्थान पर प्रलेखित कर सकते हैं। टिप्पणियाँ अपनी पंक्ति पर या किसी मान के बाद दिखाई दे सकती हैं।
एंकर और उपनाम
YAML आपको एक नोड को &anchor-name के साथ एक बार परिभाषित करने और उसे *anchor-name के साथ कहीं भी पुनः उपयोग करने की सुविधा देता है। इससे जटिल कॉन्फ़िग में दोहराव समाप्त होता है। Kubernetes और Docker Compose साझा सेवा परिभाषाओं के लिए एंकर का व्यापक उपयोग करते हैं।
बहु-पंक्ति स्ट्रिंग
YAML दो मोड के साथ ब्लॉक स्केलर का समर्थन करता है: शाब्दिक ब्लॉक (|) नई पंक्तियों को यथावत रखता है, जो स्क्रिप्ट और टेम्पलेट के लिए उपयोगी है। मोड़ा हुआ ब्लॉक (>) लंबी स्ट्रिंग को एकल पंक्ति में समेटता है, जो लंबे विवरणात्मक पाठ के लिए उपयोगी है।
रूपांतरण की आवश्यकता कब होती है
GitHub Actions, GitLab CI और CircleCI मूल रूप से YAML का उपयोग करते हैं। जब पाइपलाइन कॉन्फ़िग को प्रोग्राम के माध्यम से उत्पन्न किया जाता है, तो अक्सर JSON ऑब्जेक्ट बनाना और अंतिम आउटपुट के लिए YAML में रूपांतरित करना अधिक सरल होता है।
Kubernetes संसाधान YAML में परिभाषित होते हैं, लेकिन Helm चार्ट टेम्पलेटिंग और कुछ टूल JSON आउटपुट देते हैं। प्रारूपों के बीच रूपांतरण से API प्रतिक्रियाएँ देखना और मानक JSON टूल का उपयोग करना संभव होता है।
REST API, JSON लौटाती हैं। जब उस डेटा को YAML-आधारित कॉन्फ़िग प्रणालियों (Ansible, Salt, Kubernetes) में उपयोग किया जाता है, तो एक रूपांतरक उपकरण बिना मैन्युअल पुनः-प्रारूपण के अंतर को पाट देता है।
एक tool से दूसरे में जाने का मतलब अक्सर उसका config format बदलना होता है। JSON और YAML के बीच convert करने से आप अलग-अलग ecosystems के बीच (Node.js → Python, Docker → Kubernetes) आसानी से जा सकते हैं।
JSON Schema tooling, YAML Schema की तुलना में ज़्यादा mature है। एक common pattern यह है — config को readability के लिए YAML में लिखें, schema validation के लिए JSON में convert करें, फिर deployment के लिए वापस YAML में लाएँ।
आंतरिक टूलिंग YAML कॉन्फ़िग का उपयोग कर सकती है जबकि बाह्य API को JSON की आवश्यकता होती है। बिल्ड पाइपलाइन में एक रूपांतरक, बिना डुप्लिकेट फ़ाइलें रखे दोनों प्रतिनिधित्वों को समन्वय में रखता है।
अक्सर पूछे जाने वाले प्रश्न
हाँ। YAML 1.2, JSON का कठोर सुपरसेट है — कोई भी वैध JSON दस्तावेज़ YAML में भी वैध होता है। हालाँकि, YAML 1.1 (जो अभी भी अनेक पार्सर में उपयोग होता है) में कुछ विशेष मामले हैं जहाँ वैध JSON, वैध YAML 1.1 नहीं होता।
YAML टिप्पणियों का समर्थन करता है, जो JSON नहीं करता। गहरी नेस्टेड संरचनाओं के लिए YAML अधिक संक्षिप्त भी है। ये दो विशेषताएँ इसे मानव द्वारा संपादित कॉन्फ़िगरेशन फ़ाइलों (Docker, Kubernetes, GitHub Actions) के लिए पसंदीदा विकल्प बनाती हैं।
TOML (Tom's Obvious Minimal Language) config files के लिए बनाया गया है। इसका syntax साफ़ और INI जैसा है — types explicit हैं और कोई ambiguity नहीं है। यह Rust (Cargo.toml) और Python (pyproject.toml) projects के लिए standard है।
शायद ही कभी, लेकिन मुमकिन है। ज़्यादातर parsers में JSON key order बना रहता है (हालाँकि spec कहता है यह unordered है)। YAML में anchors और tags होते हैं जिनका JSON में कोई equivalent नहीं है। दोनों दिशाओं में accuracy के लिए, common subset तक सीमित रहें।
JSON.stringify, ऐरे में undefined मानों को null में बदलता है और ऑब्जेक्ट से उन्हें हटा देता है। यदि आपको JSON आउटपुट में अप्रत्याशित null या अनुपस्थित कुंजियाँ दिखती हैं, तो स्रोत JavaScript ऑब्जेक्ट में संभवतः undefined गुण थे।
हाँ। चूँकि YAML, JSON का सुपरसेट है, आप किसी YAML दस्तावेज़ के भीतर JSON वाक्य-विन्यास सीधे समाहित कर सकते हैं। यह कभी-कभी जटिल नेस्टेड संरचनाओं के लिए किया जाता है जहाँ YAML का इंडेंटेशन भ्रमित करने वाला हो सकता है।