YAML को JSON में कैसे बदलें: बचने वाली आम गलतियाँ
YAML और JSON एक जैसे दिखते हैं, पर असल में अलग क्यों हैं
YAML और JSON समान दिखते हैं, और उनका रिश्ता करीबी है। YAML 1.2 तो JSON का एक सुपरसेट भी है, इसलिए कोई भी मान्य JSON एक मान्य YAML भी है। यह बहुत अच्छा लगता है, है ना? यह तब तक अच्छा है जब तक आप एक वास्तविक YAML फ़ाइल को बदलते हैं और अपने पहले साइलेंट डेटा करप्शन का पता लगाते हैं। दोनों प्रारूपों के डिज़ाइन लक्ष्य बस अलग हैं। JSON मशीनों के लिए बनाया गया था: सख्त, स्पष्ट, और टिप्पणियों के लिए कोई जगह नहीं। दूसरी ओर, YAML इंसानों के लिए बनाया गया था। यह संरचना के लिए इंडेंटेशन का उपयोग करता है, बहु-पंक्ति स्ट्रिंग्स का समर्थन करता है, इनलाइन टिप्पणियों की अनुमति देता है, और इसमें एक टाइप अनुमान प्रणाली है जो आपके इरादे का अनुमान लगाने की कोशिश करती है। यह सहायक अनुमान ही वह जगह है जहाँ रूपांतरण गड़बड़ा जाता है। एक YAML पार्सर स्ट्रिंग 'yes' को पढ़ सकता है और इसे बूलियन `true` के रूप में व्याख्या कर सकता है। यह '1.0' को देख सकता है और आपके द्वारा टाइप की गई स्ट्रिंग के बजाय एक फ्लोट उत्पन्न कर सकता है। ये बग नहीं हैं; YAML स्पेक डिज़ाइन के अनुसार काम कर रहा है। समस्या तब उत्पन्न होती है जब JSON में ऐसी कोई अस्पष्टता नहीं होती है। एक बार जब आपका YAML मान पार्स किए गए डेटा में बूलियन बन जाता है, तो JSON आउटपुट `true` लिखेगा, और मूल स्ट्रिंग हमेशा के लिए खो जाएगी। जब आप Kubernetes क्लस्टर, OpenAPI स्पेक, या CI/CD पाइपलाइन के लिए कॉन्फ़िगरेशन फ़ाइलों को परिवर्तित कर रहे हों, तो ये साइलेंट टाइप परिवर्तन बिना किसी त्रुटि संदेश के डाउनस्ट्रीम सब कुछ तोड़ सकते हैं। फ़ाइलों को विश्वसनीय रूप से बदलने के लिए, आपको इन मूलभूत अंतरों को समझना होगा।
बदलने का सबसे तेज़ तरीका: CocoConvert का उपयोग करना
जब आपको बस एक फ़ाइल को बदलने की आवश्यकता होती है, तो सबसे तेज़ तरीका एक स्क्रिप्ट को एक साथ जोड़ने के बजाय एक समर्पित टूल का उपयोग करना है। CocoConvert का [YAML से JSON कनवर्टर](/convert/yaml-to-json) सभी पार्सिंग और सीरियलाइज़ेशन का प्रबंधन करता है, जिससे आपको तुरंत ठीक से स्वरूपित, UTF-8 एन्कोडेड आउटपुट मिलता है। प्रक्रिया बहुत सरल है: अपना YAML पेस्ट करें, एक .yaml या .yml फ़ाइल अपलोड करें, और कन्वर्ट पर क्लिक करें। आपका JSON आउटपुट पैनल में दिखाई देता है, जिसे कॉपी या डाउनलोड किया जा सकता है। CocoConvert आधुनिक YAML 1.2 पार्सिंग नियमों का उपयोग करता है, इसलिए आप पुरानी "नॉर्वे समस्या" से परेशान नहीं होंगे जहाँ स्ट्रिंग 'NO' को बूलियन `false` के रूप में गलत समझा जाता था। यदि आपके स्रोत YAML में इंडेंटेशन की गलती है, तो आपको चुपचाप विकृत आउटपुट के बजाय एक लाइन नंबर के साथ एक स्पष्ट पार्स त्रुटि मिलेगी। यह बहु-दस्तावेज़ YAML फ़ाइलों (जिनमें `---` विभाजक होते हैं) को भी सही ढंग से संभालता है। इन्हें एक JSON ऐरे में परिवर्तित किया जाता है, जहाँ प्रत्येक दस्तावेज़ एक ऐरे तत्व बन जाता है। यह मानक, अपेक्षित व्यवहार है, लेकिन यह याद रखना अच्छा है यदि आप अपने आउटपुट में एक अप्रत्याशित ऐरे देखते हैं क्योंकि आपकी फ़ाइल `---` से शुरू हुई थी। एक सीमा है: यह टूल YAML एंकर और एलियास का समर्थन नहीं करता है जो एक ही फ़ाइल में विभिन्न दस्तावेज़ों में नोड्स का संदर्भ देते हैं। उन जटिल मामलों के लिए जिनमें क्रॉस-डॉक्यूमेंट एंकर शामिल हैं, आपको उन्हें पहले हल करना होगा, या तो हाथ से या स्थानीय स्क्रिप्ट के साथ, रूपांतरण के लिए फ़ाइल अपलोड करने से पहले।
YAML टाइप कोअर्सन: सबसे ज़्यादा परेशान करने वाली गलतियाँ
YAML से JSON में परिवर्तित करते समय डेटा हानि का नंबर एक कारण टाइप कोअर्सन (type coercion) है। किसी भी प्रोडक्शन फ़ाइल को बदलने से पहले, आपको इन विशिष्ट गलतियों के लिए ऑडिट करना ही चाहिए। **अप्रत्याशित स्ट्रिंग्स से बूलियन बनना।** पुराने YAML 1.1 पार्सर (जैसे PyYAML संस्करण 6.0 से पहले) `yes`, `no`, `on`, और `off` को बूलियन के रूप में व्याख्या करते थे। आधुनिक YAML 1.2 केवल `true` और `false` को इस तरह मानता है, लेकिन यदि आपकी स्रोत फ़ाइल किसी पुराने टूल द्वारा बनाई गई थी, तो इसमें 'yes' हो सकता है जब इसका वास्तव में मतलब स्ट्रिंग 'yes' हो। यदि आप फ़ाइल की उत्पत्ति नहीं जानते हैं, तो आपको इन मानों की मैन्युअल रूप से जाँच करनी होगी। **ऑक्टल (अष्टक) पूर्णांक।** यह एक क्लासिक समस्या है। YAML में, `0755` जैसा मान ऑक्टल पूर्णांक 493 के रूप में पार्स किया जाता है। यह फ़ाइल अनुमतियाँ सेट करने के लिए Kubernetes मैनिफ़ेस्ट में एक कुख्यात जाल है। जब परिवर्तित किया जाता है, तो आपके JSON में संख्या `493` होगी, न कि स्ट्रिंग `'0755'`। यदि कोई डाउनस्ट्रीम प्रक्रिया उस नंबर को `chmod` कॉल में उपयोग करने का प्रयास करती है, तो अनुमतियाँ पूरी तरह से गलत होंगी, और आपको कोई त्रुटि नहीं मिलेगी। **फ्लोटिंग-पॉइंट के विशेष मामले।** YAML विशेष फ्लोट मानों जैसे `.inf`, `-.inf`, और `.nan` को समझता है। JSON ऐसा नहीं करता। CocoConvert इसे उन्हें 'Infinity', '-Infinity', और 'NaN' स्ट्रिंग्स में परिवर्तित करके संभालता है। यह एक समझदार फ़ॉलबैक है, लेकिन यदि आपका एप्लिकेशन केवल संख्याओं की अपेक्षा करता है, तो यह इन स्ट्रिंग मानों पर विफल हो सकता है, जिसके लिए पोस्ट-प्रोसेसिंग की आवश्यकता होगी। **नल (Null) का निरूपण।** YAML नल के साथ लचीला है, `null`, `~`, या यहाँ तक कि एक कुंजी के बाद एक खाली मान को भी स्वीकार करता है। ये सभी JSON में एक मानक `null` बन जाएंगे। यह आमतौर पर ठीक है, लेकिन याद रखें कि कोलन के बाद कुछ भी नहीं वाली कुंजी एक JSON `null` बन जाती है, न कि एक खाली स्ट्रिंग `""`।
बहु-पंक्ति स्ट्रिंग्स और टिप्पणियों को संभालना
YAML दो शक्तिशाली बहु-पंक्ति स्ट्रिंग सिंटैक्स प्रदान करता है जिनका JSON में कोई सीधा समकक्ष नहीं है: लिटरल ब्लॉक स्केलर (`|`) और फोल्डेड ब्लॉक स्केलर (`>`)। एक लिटरल ब्लॉक (`|`) हर एक न्यूलाइन को संरक्षित करता है। एक फोल्डेड ब्लॉक (`>`) एकल न्यूलाइन को स्पेस में बदल देता है लेकिन डबल न्यूलाइन को वास्तविक न्यूलाइन के रूप में रखता है। दोनों सिंटैक्स एक एकल JSON स्ट्रिंग का उत्पादन करते हैं, लेकिन न्यूलाइन हैंडलिंग में सूक्ष्म अंतर एम्बेडेड सामग्री जैसे शेल स्क्रिप्ट, SQL क्वेरी, या प्रमाणपत्रों के लिए महत्वपूर्ण हैं। उदाहरण के लिए, यह YAML: ```yaml script: | echo hello echo world ``` यह JSON बन जाता है: ```json {"script": "echo hello\necho world\n"} ``` ध्यान दें कि अनुगामी न्यूलाइन (`\n`) लिटरल `|` शैली के साथ डिफ़ॉल्ट रूप से संरक्षित है। इसे हटाने के लिए, आप चॉम्पिंग इंडिकेटर `|-` का उपयोग करेंगे। जिस किसी ने भी एक CI स्क्रिप्ट को डीबग किया है जो एक सूक्ष्म व्हाइटस्पेस अंतर पर विफल हो रही है, वह इस दर्द को जानता है। इसे गलत करने से स्क्रिप्ट या एपीआई टूट सकते हैं जो व्हाइटस्पेस के प्रति संवेदनशील हैं। टिप्पणियाँ एक बहुत कठिन समस्या हैं। YAML `#` का उपयोग करके टिप्पणियों का समर्थन करता है। JSON नहीं करता। बात खत्म। इसका मतलब है कि रूपांतरण के दौरान, आपकी YAML फ़ाइल में हर एक टिप्पणी स्थायी रूप से हटा दी जाती है। यह समझाने वाला सारा महत्वपूर्ण संदर्भ कि *क्यों* एक निश्चित मान सेट किया गया है—इंफ्रास्ट्रक्चर-एज़-कोड में एक आम प्रथा—JSON आउटपुट से गायब हो जाता है। JSON स्पेक के भीतर कोई समाधान नहीं है। मेरी सिफारिश सरल है: हमेशा अपनी टिप्पणी की गई YAML को सत्य का स्रोत मानें और उत्पन्न JSON को एक डिस्पोजेबल बिल्ड आर्टिफैक्ट मानें। कुछ टीमें JSONC (टिप्पणियों के साथ JSON) का उपयोग करती हैं, लेकिन यह बस संगतता की समस्या को आगे के लिए टाल देता है।
एंकर, एलियास, और मर्ज कीज़
YAML के एंकर और एलियास आपकी फ़ाइलों को DRY (डोंट रिपीट योरसेल्फ) रखने के लिए एक शानदार सुविधा हैं, लेकिन वे JSON रूपांतरण के दौरान जटिलता लाते हैं। आप `&anchor-name` के साथ एक एंकर को परिभाषित करते हैं और फिर `*anchor-name` के साथ इसका संदर्भ देते हैं। एक YAML पार्सर इन एलियास का विस्तार करता है जैसे ही वह फ़ाइल पढ़ता है, मेमोरी में अंतिम डेटा संरचना का निर्माण करता है। इसलिए, JSON आउटपुट में पूरी तरह से विस्तारित, डुप्लिकेट सामग्री होती है, जिसमें मूल एंकर का कोई निशान नहीं होता है। इस सामान्य पैटर्न पर विचार करें: ```yaml defaults: &defaults timeout: 30 retries: 3 production: <<: *defaults host: prod.example.com staging: <<: *defaults host: staging.example.com ``` `<<` सिंटैक्स एक YAML मर्ज कुंजी है। परिणामी JSON होगा: ```json { "defaults": {"timeout": 30, "retries": 3}, "production": {"timeout": 30, "retries": 3, "host": "prod.example.com"}, "staging": {"timeout": 30, "retries": 3, "host": "staging.example.com"} } ``` विस्तार सही है, लेकिन मूल YAML की संक्षिप्तता चली गई है। यदि उस डिफॉल्ट्स एंकर से 50 सेवाओं को विरासत में मिला है, तो JSON में उस डेटा की 50 प्रतियाँ होंगी। एक मशीन के लिए, यह पूरी तरह से ठीक है। एक इंसान के लिए जो फ़ाइल को पढ़ने की कोशिश कर रहा है, या उन प्रणालियों के लिए जहाँ फ़ाइल का आकार एक चिंता का विषय है, यह एक महत्वपूर्ण कमी है। ध्यान रखें कि मर्ज कुंजी समर्थन (`<<`) तकनीकी रूप से एक YAML एक्सटेंशन है, जो कोर स्पेक का हिस्सा नहीं है, इसलिए कुछ सख्त पार्सर इसे अस्वीकार कर देंगे। CocoConvert मर्ज कुंजियों को बिना किसी समस्या के संभालता है। यदि आप Python के PyYAML के साथ एक रूपांतरण स्क्रिप्ट कर रहे हैं, तो आपको `yaml.full_load()` या `yaml.safe_load()` का उपयोग करना होगा। `Loader` तर्क के बिना पुराने `yaml.load()` से बचें, क्योंकि इसे PyYAML 5.1 के बाद से बड़े सुरक्षा जोखिमों के कारण पदावनत कर दिया गया है।
प्रोग्राम द्वारा YAML को JSON में बदलना
बल्क रूपांतरण, बिल्ड पाइपलाइन एकीकरण, या किसी भी प्रकार की स्वचालित प्रसंस्करण के लिए, आपको एक कमांड-लाइन या स्क्रिप्टेड समाधान की आवश्यकता होगी। एक वेब टूल एक बार के लिए बहुत अच्छा है, लेकिन स्वचालन कोड की मांग करता है। इन्हें करने के सबसे विश्वसनीय तरीके ये हैं। **Python (सबसे पोर्टेबल विकल्प):** ```python import yaml, json, sys with open(sys.argv[1], 'r') as f: data = yaml.safe_load(f) print(json.dumps(data, indent=2, ensure_ascii=False)) ``` हमेशा `yaml.safe_load()` का उपयोग करें। पुराना `yaml.load()` एक सुरक्षा दुःस्वप्न है जो एक दुर्भावनापूर्ण YAML फ़ाइल से मनमाना कोड निष्पादित कर सकता है। `ensure_ascii=False` तर्क भी एक अच्छी आदत है, क्योंकि यह यूनिकोड वर्णों को एस्केप करने के बजाय संरक्षित करता है। **Node.js:** ```javascript const yaml = require('js-yaml'); const fs = require('fs'); const data = yaml.load(fs.readFileSync(process.argv[2], 'utf8')); console.log(JSON.stringify(data, null, 2)); ``` `js-yaml` लाइब्रेरी डिफ़ॉल्ट रूप से आधुनिक YAML 1.2 नियमों का उपयोग करती है (v4.0 से)। यदि आप किसी पुराने प्रोजेक्ट में काम कर रहे हैं, तो अपनी `package.json` को दोबारा जांचें। 4.0 से पहले के संस्करण YAML 1.1 नियमों का उपयोग करते हैं और 'yes' और 'no' जैसी स्ट्रिंग्स को गलत तरीके से बूलियन में बदल देंगे। **yq (कमांड-लाइन टूल):** ```bash yq -o=json eval '.' input.yaml > output.json ``` ईमानदारी से, `yq` कमांड लाइन पर इस काम के लिए सबसे अच्छा टूल है। यह एक उद्देश्य-निर्मित YAML प्रोसेसर है जो JSON आउटपुट के लिए एक साधारण ध्वज के साथ सब कुछ सही ढंग से संभालता है—बहु-दस्तावेज़ फ़ाइलें, एंकर, मर्ज कुंजियाँ। इसे macOS पर Homebrew के साथ स्थापित करें (`brew install yq`) या Linux/Windows के लिए GitHub से बाइनरी प्राप्त करें। बेशक, बिना कुछ स्थापित किए एक त्वरित रूपांतरण के लिए, [CocoConvert YAML से JSON टूल](/convert/yaml-to-json) अभी भी इसे पूरा करने का सबसे तेज़ तरीका है।
अपने आउटपुट का उपयोग करने से पहले उसे जाँचना
किसी फ़ाइल को बिना जाँचे परिवर्तित करना उत्पादन में सूक्ष्म बग लाने का एक नुस्खा है। एक JSON फ़ाइल वाक्यात्मक रूप से पूरी तरह से मान्य हो सकती है लेकिन इसमें शब्दार्थ की दृष्टि से गलत डेटा हो सकता है, जैसे कि हमने जिन टाइप कोअर्सन पर चर्चा की है। यहाँ भविष्य के सिरदर्द से बचाने के लिए एक व्यावहारिक चेकलिस्ट है। **सिंटैक्स सत्यापन।** कम से कम, आउटपुट को एक JSON लिंटर के माध्यम से चलाएँ। आपका कोड एडिटर (जैसे VS Code या JetBrains IDE) शायद यह स्वचालित रूप से करता है। कमांड लाइन से, Python का अंतर्निहित `json.tool` एक विश्वसनीय वर्कहॉर्स है: `python3 -m json.tool output.json > /dev/null`। यह मान्य JSON के लिए कोड 0 के साथ बाहर निकलता है और आपको बताता है कि विफलता पर यह ठीक कहाँ टूटा। **स्कीमा सत्यापन।** महत्वपूर्ण फ़ाइलों के लिए, एक स्कीमा का उपयोग करें। यदि आपके लक्ष्य प्रारूप में एक JSON स्कीमा है (OpenAPI स्पेक्स, AWS CloudFormation, और Kubernetes CRDs के लिए आम), तो उसके विरुद्ध मान्य करें। `ajv-cli` (`ajv validate -s schema.json -d output.json`) जैसा एक टूल टाइप बेमेल को पकड़ेगा जिसे एक साधारण सिंटैक्स जाँच नहीं देख सकती है। **एक ज्ञात अच्छे संस्करण के विरुद्ध अंतर देखें।** जब आपके पास एक संदर्भ JSON फ़ाइल होती है, तो अंतर देखना आवश्यक है। लेकिन पहले, शोरगुल वाले, अर्थहीन अंतरों से बचने के लिए कुंजी क्रम को सामान्य करें। `jq` टूल कुंजियों को नियतात्मक रूप से सॉर्ट कर सकता है: `jq --sort-keys . output.json > normalized.json`। याद रखें, JSON में कुंजी क्रम कोई मायने नहीं रखता, लेकिन जब आप फ़ाइलों की तुलना करने की कोशिश कर रहे हों तो यह आपको पागल कर देगा। **कोअर्सड टाइप के लिए स्पॉट-चेक करें।** यदि आपको संदेह है कि आपके YAML में '1.0' या '0755' जैसे मान थे, तो सीधे JSON आउटपुट की जाँच करें। एक त्वरित `grep -n "0755" output.json` आपको तुरंत बताएगा कि क्या आपका ऑक्टल स्ट्रिंग रूपांतरण से बच गया या एक बेकार पूर्णांक में बदल गया। सच में, एक कमिट या डिप्लॉयमेंट से पहले अपने आउटपुट को मान्य करने में पाँच मिनट लगाना हमेशा उस उत्पादन घटना को डीबग करने से तेज़ होता है जो एक बूलियन के कारण हुई थी जिसे एक स्ट्रिंग होना चाहिए था।