JSON के अलावा भी संरचित डेटा के कई फ़ॉर्मैट रोज़मर्रा के काम में आते हैं — YAML, CSV, XML और TOML हर एक अलग ज़रूरत से जन्मे हैं, और इनके बीच बदलाव करना एक आम व्यावहारिक काम है, खासकर जब कोई पुराना XML-आधारित सिस्टम किसी नए JSON API से जुड़ना हो।
हर फ़ॉर्मैट किस काम के लिए है
- YAML — कोष्ठकों की जगह इंडेंटेशन, CI/CD, Kubernetes और Docker Compose की कॉन्फ़िग फ़ाइलों का मानक।
- CSV — सपाट और टेबल जैसा, स्प्रेडशीट और डेटा विश्लेषण टूल के लिए सबसे सामान्य फ़ॉर्मैट।
- XML — पुराना, एट्रिब्यूट और नेमस्पेस के साथ, आज भी SOAP सेवाओं और सरकारी/बैंकिंग सिस्टम में इस्तेमाल होता है — जैसे भारत के कई पुराने e-Governance पोर्टल जो XML आधारित थे, उसके बाद JSON आधारित UPI और India Stack APIs में बदलाव आया।
- TOML — हाथ से लिखने में आसान और स्पष्ट, Rust के
Cargo.tomlसे मशहूर।
कन्वर्ज़न में क्या खो सकता है
हर कन्वर्ज़न बराबर सुरक्षित नहीं होता। JSON → CSV नेस्टिंग को खो देता है: गहरे ऑब्जेक्ट और बदलती लंबाई के array किसी आयताकार टेबल में ठीक से फ़िट नहीं होते, इसलिए उन्हें flatten या सरल करना पड़ता है। JSON ↔ YAML और JSON ↔ TOML लगभग हमेशा बिना नुकसान के होते हैं, क्योंकि दोनों फ़ॉर्मैट JSON जैसी ही नेस्टेड संरचना सपोर्ट करते हैं।
YAML में ऑटो-टाइपिंग का जाल
YAML पार्सर बिना कोट्स वाले मान का टाइप खुद अंदाज़ा लगाता है: version: 1.20 नंबर 1.2 बन सकता है, आख़िरी शून्य खोकर, और NO जैसा टेक्स्ट YAML 1.1 के नियमों के तहत बूलियन false बन जाता है, क्योंकि yes/no को बूलियन लिटरल माना जाता था। JSON में बदलने से पहले जो मान टेक्स्ट ही रहने चाहिए, उन्हें कोट्स में रखना ज़रूरी है।
यह किस काम आता है
- एक टूल जो YAML चाहता है और दूसरा जो JSON, उनके बीच कॉन्फ़िगरेशन ले जाना।
- API से मिले डेटा को CSV में एक्सपोर्ट करके स्प्रेडशीट में देखना।
- पुराने XML/SOAP सिस्टम को आधुनिक JSON API के साथ जोड़ना।