JSON फ़ॉर्मैटिंग·वैलिडेशन·JSON Schema: फ़र्क और व्यावहारिक उपयोग

2026-04-13 को प्रकाशित 8 मिनट पढ़ें

सारांश (TL;DR)

पिछले महीने एक टीम ने feature_flags.json की एक पंक्ति बदली और डिप्लॉय किया। JSON.parse पास हो गया, CI हरी थी, staging पर चला गया — फिर flags.checkout_v2 स्ट्रिंग "true" निकली और सारी checkout शाखाएँ पुराने संस्करण में गिर गईं। “JSON देख लिया” वाक्य असल में तीन कामों का मिश्रण है — फ़ॉर्मैटिंग, सिंटैक्स वैलिडेशन और स्ट्रक्चरल वैलिडेशन — और उस दिन टीम ने केवल पहले दो किए। फ़ॉर्मैटिंग (pretty-print) व्हाइटस्पेस और लाइन ब्रेक जोड़कर सिर्फ़ दिखावट बदलता है, कुछ वैलिडेट नहीं करता। सिंटैक्स वैलिडेशन RFC 8259 के आधार पर ब्रैकेट, क्वोट, एस्केप की सही होने की जाँच करता है — JSON.parse यही काम करता है। स्ट्रक्चरल वैलिडेशन उसके बाद आता है — “क्या यह आकार मेरा कोड जो अपेक्षा करता है, वही है?” — और इसी के लिए JSON Schema बना है। तीनों को “एक बटन” में मिला देना ऐसे मूक-विफलताओं को न्योता देता है। पढ़ते समय फ़ॉर्मैटिंग, इनपुट लेते समय पार्सिंग, और API बाउंड्री, कॉन्फ़िग फ़ाइल, मैसेज बाउंड्री पर Ajv जैसे वैलिडेटर से स्कीमा तक — तीनों को अपनी-अपनी जगह रखने वाली पाइपलाइन सुरक्षित होती है।

पृष्ठभूमि

JSON को RFC 8259 (और समान ECMA-404) परिभाषित करते हैं। सिंटैक्स छोटा और सरल है। डॉक्युमेंट string, number, true, false, null, array या object में से कोई एक होता है। string डबल-क्वोट में आती है और \n, \t, \", \\, \uXXXX (यूनिकोड कोड यूनिट) जैसे एस्केप सपोर्ट करती है। number में integer और float का भेद नहीं, दशमलव सिंटैक्स है। object string-keyed सदस्यों का बिना क्रम का संग्रह है, और array क्रम वाले मानों की सूची है।

JSON जानबूझकर जो नहीं रखता, वह भी ज़रूरी है: कमेंट, trailing comma, single-quote स्ट्रिंग, hex और binary literal नहीं। गैर-ASCII अक्षर UTF-8 बाइट्स के रूप में सीधे लिखे जाते हैं या \u एस्केप से। JSON5 और HJSON अलग फ़ॉर्मैट हैं जिन्होंने कुछ नियम शिथिल किए हैं; सख़्त JSON पार्सर उन्हें नहीं लेगा।

पार्सिंग सफल होने का मतलब सिर्फ़ “सिंटैक्स ठीक है”, “अर्थ सही है” नहीं। {"user": "x", "pass": "y"} पूरी तरह वैध JSON है, पर अगर एंडपॉइंट {"username": "...", "password": "..."} अपेक्षा करता है, तो ऐप्लिकेशन की दृष्टि से यह ग़लत डेटा है। इसे पकड़ने के लिए चाहिए स्कीमा — मशीन-पठनीय “स्वीकार्य डॉक्युमेंट का आकार” का विवरण — और उसका मानक है JSON Schema (वर्तमान अनुशंसित मेटा-स्कीमा Draft 2020-12)। आवश्यक फ़ील्ड, टाइप, enum·const, रेगेक्स से स्ट्रिंग पैटर्न, संख्या रेंज, array items और यूनीकनेस, object properties·additionalProperties, और संयोजन के लिए allOf·oneOf·anyOf·$ref — सब सपोर्टेड हैं। Ajv 8.12 जैसा वैलिडेटर स्कीमा को एक बार कंपाइल करके फ़ंक्शन बना देता है, इसलिए हॉट पाथ पर लागत लगभग नगण्य है।

तुलना और डेटा

पहलूफ़ॉर्मैटिंगसिंटैक्स वैलिडेशनJSON Schema वैलिडेशन
उद्देश्यपठनीयता के लिए स्पेस संरेखणस्ट्रिंग पार्स होती है या नहींपार्स्ड मान अपेक्षित आकार में है या नहीं
पकड़ता हैकुछ नहीं (केवल व्हाइटस्पेस)ब्रैकेट मिसमैच, क्वोट ग़लती, ख़राब एस्केप, trailing commaआवश्यक फ़ील्ड गायब, टाइप ग़लत, रेंज बाहर, अज्ञात key
नहीं पकड़तासंरचना·अर्थ दोषअपेक्षित आकार·बिज़नेस नियमस्कीमा में न लिखे नियम, फ़ील्डों के बीच संबंध
आम टूलJSON.stringify(obj, null, 2), jq, IDE फ़ॉर्मैटरJSON.parse, jq -e, भाषाओं के पार्सरAjv 8.x, python-jsonschema, OpenAPI वैलिडेटर
लागू होता हैडेव टूल·लॉगहर पार्सिंग बाउंड्री (परोक्ष)API रिक्वेस्ट/रिस्पॉन्स, कॉन्फ़िग लोड, मैसेज बाउंड्री

तीनों कॉलम “एक चुनो” नहीं, बल्कि क्रमिक परतें हैं। 12 MB की package-lock.json को एक लाइन में देखने की बजाय इंडेंट करके देखना फ़ॉर्मैटिंग है, और जैसे ही इसका नाम “वैलिडेशन” रख देते हैं, असली दुर्घटना शुरू होती है।

वास्तविक परिदृश्य

परिदृश्य 1 — API रिस्पॉन्स डीबगिंग। एक बाहरी पेमेंट गेटवे 600 पंक्तियों की JSON एक ही पंक्ति में लौटाता है। Network पैनल, कोई लोकल फ़ॉर्मैटर, या curl ... | jq . — कुछ भी इसे देखने योग्य आकार में बदल देता है। यहाँ वैलिडेशन नहीं हो रहा, लक्ष्य सिर्फ़ “क्या अजीब है” आँख से ढूँढना है — इस चरण को “वैलिडेट कर लिया” कहना ग़लत होगा।

परिदृश्य 2 — कॉन्फ़िग फ़ाइल लोडिंग। मान लें सर्विस स्टार्टअप पर config.json पढ़ती है। सख़्त JSON पार्सर trailing comma जैसी सिंटैक्स ग़लती पकड़कर बूट रोक देगा — यह सही व्यवहार है। पर शुरुआत वाले सिनारियो की तरह, retries: 3 की जगह retries: "three" हो तो भी पार्सिंग ठीक है, और समस्या तब सामने आती है जब कोड स्ट्रिंग को संख्या से तुलना करता है। मैंने एक टीम को जो पैटर्न सुझाया था वह यह था — स्टार्टअप की पहली पंक्ति में Ajv compile(schema) से बने वैलिडेशन फ़ंक्शन को कॉल करें, उल्लंघन पर process.exit(1)। पाँच मिनट के बदलाव ने दो-दो दिन के staging इंसिडेंट बचाए।

परिदृश्य 3 — OpenAPI कॉन्ट्रैक्ट वैलिडेशन। एक टीम OpenAPI 3.1 डॉक्युमेंट में एंडपॉइंट, रिक्वेस्ट बॉडी और रिस्पॉन्स आकार को components.schemas में लिखती है। कॉन्ट्रैक्ट टेस्ट उसी स्कीमा से नमूना पेलोड वैलिडेट करते हैं, और सर्वर इम्प्लीमेंटेशन का “स्ट्रिंग की जगह इंटीजर” वाला ड्रिफ़्ट क्लाइंट के टूटने से पहले ही पकड़ा जाता है।

आम ग़लतफ़हमियाँ

“बस JSON.parse ही काफ़ी वैलिडेशन है।” यह सिंटैक्स देखता है, आकार नहीं। आधा-खाली ऑब्जेक्ट भी वापस मिल सकता है। JSON.parse को “टूटी स्ट्रिंग रोकने” की परत रखें, और विश्वास की सीमा पर स्कीमा जाँच अलग से लगाएँ।

“JSON Schema सिर्फ़ सर्वर के लिए है।” ब्राउज़र में रिक्वेस्ट भेजने से पहले वैलिडेशन से यूज़र को तुरंत फ़ीडबैक मिलता है और सर्वर पर लोड घटता है। Ajv समेत कई वैलिडेटर ब्राउज़र में अच्छी तरह चलते हैं। सर्वर वैलिडेशन फिर भी ज़रूरी है — क्लाइंट पर भरोसा मत करें — पर क्लाइंट-साइड वैलिडेशन UX सुधारती है और सुरक्षा मॉडल कमज़ोर नहीं करती।

“JSON5 बस कमेंट्स वाला JSON है।” JSON5 कमेंट, अनक्वोटेड key, trailing comma, hex literal जोड़ता है। यूज़र-एडिटेड कॉन्फ़िग फ़ॉर्मैट के रूप में यह मित्रवत है (सबसे प्रसिद्ध उदाहरण tsconfig.json वास्तव में JSONC नामक एक और ग़ैर-मानक सुपरसेट है), लेकिन RFC 8259 का सख़्ती से पालन करने वाले उपभोक्ता इसे स्वीकार नहीं करेंगे। नेटवर्क पर जाए या किसी स्वतंत्र पार्सर से गुज़रे, तो सख़्त JSON ही भेजें।

“YAML इंडेंटेशन वाला JSON है।” हर वैध JSON वैध YAML है, लेकिन YAML में anchor·alias, tag type, एक फ़ाइल में कई डॉक्युमेंट, block·fold scalar, indentation-sensitive पार्सिंग जैसी सुविधाएँ हैं जो JSON में नहीं। प्रसिद्ध “नॉर्वे समस्या” — YAML 1.1 में बिना क्वोट के NO बूलियन false बन जाता है — इसका उदाहरण है।

चेकलिस्ट

  1. बस पढ़ना ही है? फ़ॉर्मैटिंग करें। इसे “वैलिडेट कर लिया” मत कहें।
  2. क्या डेटा विश्वास की सीमा पार कर रहा है (HTTP रिक्वेस्ट, मैसेज क्यू, कॉन्फ़िग फ़ाइल)? पार्सिंग के साथ-साथ JSON Schema भी लागू करें।
  3. अज्ञात फ़ील्ड स्वीकार करने हैं या नहीं? स्कीमा में additionalProperties: false सेट करें और अस्वीकृति/हटाने की नीति तय करें।
  4. एरर मैसेज क्रियान्वयन-योग्य हैं? Ajv के allErrors: true जैसी सेटिंग से सारी त्रुटियाँ एक साथ दिखाएँ।
  5. क्या स्कीमा असली कोड के पास रहती है? स्पेसिफ़िकेशन और इम्प्लीमेंटेशन के बीच ड्रिफ़्ट तब कम होता है जब स्कीमा दोनों का सिंगल सोर्स ऑफ़ ट्रुथ हो।
  6. क्या फ़ॉर्मैट सचमुच JSON के लिए उपयुक्त है? मनुष्य-संपादित कॉन्फ़िग है और पार्सर ख़ुद चुन सकते हैं, तो JSON5/JSONC या TOML ज़्यादा क्षमाशील हैं। मशीन-टू-मशीन के लिए सख़्त JSON रखें।

संबंधित टूल

Patrache Studio का JSON फ़ॉर्मैटर ब्राउज़र में चलता है, इसलिए पेस्ट किया गया पेलोड डिवाइस से बाहर नहीं जाता। JSON पेलोड अकेला नहीं चलता — अगर उसमें बाइनरी एन्कोड है तो Base64 और URL एन्कोडिंग: क्यों ज़रूरी और कब ग़लत इस्तेमाल बताता है साइज़ क्यों बढ़ता है। ID शामिल हो तो UUID v1·v4·v7 तुलना और DB प्राइमरी-की डिज़ाइन यह दर्शाता है कि सर्वर कौन-सा वर्ज़न जारी करता है, इसका असर इंडेक्सिंग·सॉर्टिंग·कैश पर क्यों पड़ता है।

संदर्भ

संबंधित टूल

devtools.patrache.studio/json/formatter/