JSON ↔ YAML कनवर्टर
JSONJSON और YAML 1.2 के बीच द्विदिशात्मक रूपांतरण, लाइव सत्यापन और त्रुटि पंक्ति/स्तंभ स्थान के साथ।
दूरस्थ URL लाए नहीं जाते; अपना JSON सीधे पेस्ट करें।
इस पृष्ठ पर
YAML / JSON कन्वर्टर क्या है?#
YAML और JSON एक ही तरह के डेटा लिखने के दो तरीके हैं — नेस्टेड मैप्स, सूचियाँ, स्ट्रिंग्स, नंबर्स, बूलियन्स, और null। JSON सख्त और विरामचिह्न-भारी है (हर स्ट्रिंग डबल कोट्स में, हर जगह ब्रैकेट); YAML उन कोट्स और ब्रेस की जगह इंडेंटेशन और डैश लेता है, जो इसे इतना पढ़ने योग्य बनाता है कि लोग इसे हाथ से कॉन्फ़िग फ़ाइलों, CI पाइपलाइनों, और कंटेनर मेनिफेस्ट्स के लिए लिखते हैं।
आपको बार-बार दोनों के बीच आना-जाना पड़ता है क्योंकि अलग-अलग औज़ार अलग-अलग फ़ॉर्मेट पसंद करते हैं। एक Kubernetes चार्ट YAML में लिखा जाता है पर API JSON बोलता है। एक CI कॉन्फ़िग YAML है; वह लिंटर जिसे आप उसे खिलाना चाहते हैं JSON अपेक्षा करता है। कोई साथी चैट में एक YAML ढेर चिपकाता है; आपकी स्क्रिप्ट JSON.parse चाहती है। यह हाथ से करना — पुनः-इंडेंट, पुनः-कोट, ब्रैकेट की जगह डैश — ठीक वही छोटे-छोटे काम है जो एक अतिरिक्त कॉमा या एक गलत संरेखित स्पेस घुसा देता है, और फिर कुछ भी पार्स नहीं होता।
यह पेज आपके ब्राउज़र में दोनों दिशाओं में कन्वर्ट करता है। YAML से JSON जब आपको मशीन-अनुकूल कठोरता चाहिए; JSON से YAML जब आप एक ऐसी कॉन्फ़िग फ़ाइल चाहते हैं जिसे इंसान वास्तव में पढ़ सके। यह YAML 1.2 कोर स्कीमा (कोई जोखिम भरा ऑब्जेक्ट इंस्टैंशिएशन नहीं) के साथ पार्स करता है, त्रुटियों को सटीक पंक्ति और स्तंभ पर टाँकता है, और लंबी पंक्तियों को तह करने से इनकार करता है ताकि आउटपुट डिफ़-अनुकूल रहे।
इसका उपयोग कैसे करें#
- टूलबार के ऊपर-बाईं ओर दो-बटन टॉगल से कोई दिशा चुनें:
- YAML → JSON (डिफ़ॉल्ट): बाईं ओर YAML चिपकाएँ, दाईं ओर सख्त JSON पाएँ।
- JSON → YAML: बाईं ओर JSON चिपकाएँ, दाईं ओर इंडेंट किया हुआ YAML पाएँ।
- इंडेंट चुनें — 2 या 4 स्पेस। यह दोनों ओर आउटपुट की नेस्टिंग गहराई नियंत्रित करता है।
- अपना डेटा चिपकाने से पहले व्यवहार देखना चाहते हैं तो नमूना पर क्लिक करें, या दोनों पैनलों को मिटाने के लिए साफ़ करें।
- दायाँ पैनल कन्वर्सन चलते ही अपडेट होता है। नीचे की स्थिति पट्टी तीन में से एक बताती है: आउटपुट बाइट आकार के साथ एक सफलता पंक्ति, एक खाली-इनपुट संकेत, या सटीक दोषपूर्ण टोकन की ओर इशारा करती 1-आधारित पंक्ति और स्तंभ के साथ एक पार्स त्रुटि।
- परिणाम लेने के लिए आउटपुट हेडर पर कॉपी पर क्लिक करें।
कन्वर्सन इनपुट पार्स होते ही चलता है। क्लिक करने के लिए कोई उत्पन्न बटन नहीं है — इनपुट ठीक करें और आउटपुट रिफ़्रेश हो जाता है।
प्रमुख विशेषताएँ#
- दो-तरफ़ा, एक पैनल जोड़ी। वही इनपुट/आउटपुट लेआउट दोनों दिशाएँ संभालता है; टॉगल तय करता है कि कौन सा पार्सर चले।
- YAML 1.2 कोर स्कीमा।
null,true/false, पूर्णांक, फ़्लोट, और कोटेड स्ट्रिंग्स ठीक वैसे ही हल होते हैं जैसे एक मानक-अनुपालक पार्सर करता है — न कि एक ढीले ह्यूरिस्टिक के रूप में। - लाइन फ़ोल्डिंग अक्षम। लंबी आउटपुट पंक्तियाँ कभी नहीं लपेटी या छोड़ी जातीं, इसलिए किसी चेक-इन फ़ाइल के विरुद्ध डिफ़ केवल वास्तविक बदलाव दिखाता है।
- सटीक त्रुटि स्थान। एक गलत संरेखित इंडेंट या एक अतिरिक्त
:कोrow:colके रूप में रिपोर्ट किया जाता है, न कि एक सामान्य “could not parse” के रूप में। - गहराई-संरक्षित। गहराई से नेस्टेड इनपुट (क्लासिक “YAML billion-laughs” विस्तार) सीमित है, इसलिए कोई दुर्भावनापूर्ण या आकस्मिक रूप से पुनरावर्ती फ़ाइल टैब को फ़्रीज़ नहीं कर सकती।
- केवल स्थानीय। आपकी कॉन्फ़िग कभी पेज से बाहर नहीं जाती — इसे भेजने के लिए कोई बैकएंड है ही नहीं। एक मेगाबाइट से ऊपर, भारी पार्स एक बैकग्राउंड वर्कर को सौंपा जाता है ताकि UI प्रतिक्रियाशील रहे।
कार्य उदाहरण#
एक आम वास्तविक काम: YAML में लिखी एक सर्विस कॉन्फ़िग को एक JSON रिक्वेस्ट बॉडी में जाना है। इसे YAML → JSON और 2 इंडेंट चुनकर बाईं पैनल में चिपकाएँ:
name: api-gateway
port: 8080
replicas: 3
targets:
- host: example.com
port: 443
- host: cdn.example.com
port: 8443
features:
retries: true
timeout_ms: 2500
दायाँ पैनल सख्त, पार्स-तैयार JSON बनाता है:
{
"name": "api-gateway",
"port": 8080,
"replicas": 3,
"targets": [
{
"host": "example.com",
"port": 443
},
{
"host": "cdn.example.com",
"port": 8443
}
],
"features": {
"retries": true,
"timeout_ms": 2500
}
}
ध्यान दें कि बिना कोट वाले YAML मान 8080, true, और 3 क्रमशः JSON नंबर, बूलियन, और नंबर बन गए — कोर स्कीमा ने उन्हें टाइप किया, आपको नहीं करना पड़ा। दिशा पलटें (JSON → YAML) और JSON को वापस चिपकाएँ: आपको वही नेस्टेड संरचना सूची आइटमों के लिए डैश के साथ पुनः-इंडेंट मिलती है, जो वह रूप है जिसे आप एक कॉन्फ़िग रिपॉज़िटरी में चेक इन करते।
अक्सर पूछे जाने वाले प्रश्न#
क्या मेरी YAML टिप्पणियाँ राउंड ट्रिप के दौरान सुरक्षित रहती हैं?#
नहीं। JSON में कोई टिप्पणी सिंटैक्स ही नहीं है, इसलिए आपकी YAML में कोई भी # comment पढ़ा तो जाता है पर JSON की राह पर गिरा दिया जाता है — रखने की कोई जगह ही नहीं। टिप्पणियाँ इनपुट पर बर्दाश्त की जाती हैं (वे कभी त्रुटि नहीं करतीं), पर वे इस पार कोण को पार नहीं कर सकतीं। यदि टिप्पणियाँ मायने रखती हैं, तो YAML को सत्य का स्रोत मानें और हर बार उससे JSON जनरेट करें।
क्या यह मल्टी-डॉक्यूमेंट YAML (--- से अलग फ़ाइलें) संभालता है?#
यह डॉक्यूमेंट स्ट्रीम प्रोसेस करता है और अग्रणी दस्तावेज़ लौटाता है। अधिकांश कॉन्फ़िग और मेनिफेस्ट फ़ाइलें सिंगल-डॉक्यूमेंट होती हैं, इसलिए यह शायद ही कभी मुद्दा हो; यदि आपके पास मल्टी-डॉक्यूमेंट स्ट्रीम है, तो उसे --- सेपरेटर पर विभाजित करें और हर हिस्से को कन्वर्ट करें।
मेरी कॉन्फ़िग फ़ाइल के लिए YAML या JSON — मैं क्या चुनूँ?#
YAML का उपयोग करें जब कोई इंसान इसे हाथ से संपादित करता है और आपको एंकर और इंडेंट द्वारा नेस्टिंग के साथ टिप्पणी जैसी पठनीयता चाहिए। JSON का उपयोग करें जब कोई मशीन इसे बनाती है और कोई पार्सर इसका उपभोग करता है, या जब कठोरता मायने रखती है (JSON में हर वैल्यू लिखने का ठीक एक क़ानूनी तरीका है, इसलिए डिबग करने के लिए कोई अस्पष्टता नहीं)। यह औज़ार इसलिए है ताकि आपको केवल एक पर ही सीमित रहना न पड़े।
त्रुटि “row 4, col 5” कहती है पर वह पंक्ति ठीक दिखती है। क्या गलत है?#
लगभग हमेशा इंडेंटेशन। YAML संरचना अग्रणी स्पेसेस से तय करता है, इसलिए एक चाइल्ल जो एक स्पेस बहुत बाईं या दाईं ओर है — या मिश्रित टैब और स्पेस — असली गलती वाली पंक्ति के बाद वाली पंक्ति पर त्रुटि के रूप में सामने आता है, क्योंकि पार्सर असंगतता केवल तभी नोटिस करता है जब वह अगला टोकन पढ़ता है। पहले बताई गई पंक्ति के ऊपर वाली पंक्ति का इंडेंट जाँचें।