JSON validate करें

कहाँ चलता है
कुछ भी अपलोड नहीं होता, क्योंकि कोई फ़ाइल है ही नहीं — गणना इसी पन्ने में होती है।
न कतार, न खाता
यह उतनी ही तेज़ी से जवाब देता है जितनी आपकी मशीन देती है, और कभी नहीं पूछता कि आप कौन हैं।
जितनी बार चाहें
न कुछ गिना जाता है, न कोई सीमा है — दोबारा जवाब देने में हमारा कुछ ख़र्च नहीं होता।

काम कैसे करता है

वह दस्तावेज़ चिपकाइए जिसे मना किया जा रहा है।
पंक्ति और कॉलम पढ़िए, और निशान लगा हुआ टुकड़ा भी।
सुधारकर दोबारा चिपकाइए। कुछ अपलोड नहीं हुआ है।

Parser जो पंक्ति बताता है और जिस पंक्ति पर ग़लती है

JSON का parser उसी क्षण रुक जाता है जब उसे कुछ ऐसा मिलता है जो बैठता नहीं, और वह जगह अक्सर असली ग़लती से काफ़ी बाद होती है। पंक्ति 12 पर छूटा हुआ अल्पविराम पंक्ति 13 पर पकड़ में आता है, जब वहाँ अल्पविराम की जगह उद्धरण-चिह्न दिखता है; संदेश 13 की ओर इशारा करता है।

इसीलिए यहाँ सिर्फ़ एक संख्या नहीं निकलती बल्कि निशान लगा हुआ टुकड़ा भी। संदर्भ देख लेना ही «कॉलम 4» को «ऊपर वाली पंक्ति का अल्पविराम छूटा है» में बदलता है, और यही फ़र्क़ है दस सेकंड में सुधार लेने और दो सौ पंक्तियों के दस्तावेज़ को घूरते रहने के बीच।

हर ब्राउज़र त्रुटि अपने शब्दों में लिखता है

वही टूटा हुआ दस्तावेज़ Chrome, Firefox और Safari में अलग-अलग संदेश देता है, क्योंकि हर JavaScript इंजन अपने संदेश ख़ुद लिखता है। कुछ स्थिति को अक्षरों की गिनती के रूप में देते हैं, कुछ स्थिति देते ही नहीं।

यहाँ पंक्ति और कॉलम संदेश के शब्दों पर भरोसा करने के बजाय उसी गिनती से निकाले जाते हैं। इससे जवाब हर ब्राउज़र में एक जैसा रहता है, जो ऐसे औज़ार से कम से कम माँगा ही जा सकता है जिसका पूरा काम आपको यह बताना है कि कहाँ देखना है।

चार ग़लतियाँ जो लगभग सब कुछ समझा देती हैं

किसी बंद कोष्ठक से पहले एक अतिरिक्त अल्पविराम; दो तत्वों के बीच छूटा हुआ अल्पविराम; दोहरे के बजाय इकहरे उद्धरण-चिह्न; और बिना उद्धरण वाली कुंजी। मना किए गए दस्तावेज़ों का भारी बहुमत इन्हीं चार में आ जाता है, और चारों JSON को JavaScript की तरह लिखने से पैदा होते हैं।

पाँचवाँ ज़्यादा धोखेबाज़ है: दस्तावेज़ की शुरुआत में एक अदृश्य अक्षर, लगभग हमेशा वह byte order mark जिसे Excel और Windows के कुछ एडिटर सबसे आगे रख देते हैं। दस्तावेज़ बिलकुल ठीक दिखता है और parser कॉलम 1 पर विफल होता है, यानी ठीक उस जगह जहाँ कोई देखता नहीं।

वैध होने का मतलब सही होना नहीं है

किसी दस्तावेज़ का वैध JSON होना सिर्फ़ इतना कहता है कि उसका वाक्य-विन्यास ठीक है, और कुछ नहीं। जो फ़ील्ड संख्या होना चाहिए था और स्ट्रिंग बनकर आया, ऐसे रूप में लिखी तारीख़ जिसकी दूसरा पक्ष उम्मीद नहीं करता, या ऐसा object जिसमें आधी कुंजियाँ ही नहीं हैं — ये सब यह जाँच बिना अटके पार कर जाते हैं।

अगर कोई API यहाँ वैध निकले दस्तावेज़ को फिर भी मना कर रही है, तो दिक़्क़त वाक्य-विन्यास की नहीं रही: वह schema की है। उसे JSON Schema का validator उसी API के schema के सामने जाँचता है, और वह अलग सवाल है जो ठीक वहाँ से शुरू होता है जहाँ यह पन्ना ख़त्म होता है।

Tab और वह कॉलम जो मेल नहीं खाता

बीच में tab रखकर कॉलम गिनना दुविधा भरा है: tab एक अक्षर है, पर स्क्रीन पर एडिटर की सेटिंग के हिसाब से चार या आठ जगह घेरता है। अक्षरों पर निकाला गया कॉलम-नंबर तब उस चीज़ से मेल नहीं खाता जो दिखती है।

यहाँ अक्षर गिने जाते हैं, जो parser भी करता है, और टुकड़ा tab खोलकर दिखाया जाता है ताकि निशान वहीं गिरे जहाँ आँख उसकी उम्मीद करती है। यह बहुत छोटा-सा ब्योरा है और मदद करने वाले संकेत तथा भ्रमाने वाले संकेत के बीच का पूरा फ़र्क़ है।

देवनागरी में कॉलम की गिनती अलग चलती है

JavaScript का parser स्थिति UTF-16 इकाइयों में गिनता है, और एक दिखने वाला हिंदी अक्षर आम तौर पर कई code point का होता है: «क्षि» में क, ्, ष और ि — चार। इसलिए हिंदी सामग्री वाली पंक्ति में parser का कॉलम-नंबर उस स्थान से बड़ा होता है जिसे आप आँख से गिनते हैं।

इसीलिए यहाँ निशान लगे टुकड़े पर ज़ोर है, अकेली संख्या पर नहीं। जिस पंक्ति में हिंदी टेक्स्ट हो वहाँ «कॉलम 47» अपने आप में लगभग बेकार है; निशान लगा टुकड़ा वहाँ भी उतना ही काम करता है जितना सादे ASCII में, और यही एकमात्र वजह है कि दोनों दिए जाते हैं।

वैध दस्तावेज़ से क्या पढ़ा जा सकता है

जब दस्तावेज़ पार हो जाता है तो उसका आकार भी निकलता है: ऊपरी स्तर object है या array, कितनी कुंजियाँ हैं, कितना नेस्टिंग है और आकार कितना है। ये वही आँकड़े हैं जिन्हें कोई यह तय करने से पहले देखता है कि उसे प्रोसेस कैसे करना है।

चारों में सबसे काम का नेस्टिंग की गहराई है। बहुत से parser और बहुत सी API की अपनी सीमा होती है, और अपने-आप बनने वाला दस्तावेज़ उसे बिना किसी की जानकारी के पार कर सकता है। यह वह संख्या है जिसे कोई कभी नहीं देखता, उस दिन तक जब वह किसी ऐसी त्रुटि की व्याख्या कर देती है जिसका कोई तुक नहीं बैठ रहा था।

बड़ी संख्याओं की चेतावनी अलग से मिलती है

अगर दस्तावेज़ में ऐसा पूर्णांक है जो ठीक-ठीक बना रहने के लिए बहुत बड़ा है, तो यह बताया जाता है, भले ही दस्तावेज़ पूरी तरह वैध हो। यह वाक्य-विन्यास की त्रुटि नहीं है: यह पढ़ते समय होने वाला चुपचाप नुक़सान है, और वह हर उस तंत्र में उसी तरह होता है जो JavaScript का parser इस्तेमाल करता है।

इसकी अपनी चेतावनी बनती है क्योंकि इसका निदान सबसे बुरा होता है। दस्तावेज़ ठीक भीतर जाता है, ठीक बाहर आता है, और बीच में किसी पहचान-संख्या के आख़िरी अंक बदल जाते हैं — और उसे पाने वाला तंत्र रिकॉर्ड नहीं ढूँढ़ पाता, बिना इस बात के किसी संकेत के कि क्यों।

सजी हुई झलक यहाँ क्यों नहीं है

यह पन्ना एक सवाल का जवाब देता है, दो का नहीं: कहाँ विफल होती है। दस्तावेज़ को indent के साथ देखना format वाले पन्ने का काम है, जिसके पास indent चुनने और कुंजियाँ क्रम में लगाने के वे विकल्प भी हैं जिनका यहाँ कोई मतलब नहीं।

यह वही फ़ैसला है जो इस पूरे हिस्से में encode को decode से अलग रखता है। जो यहाँ आता है उसके पास कुछ टूटा हुआ है और उसे जगह चाहिए; जो वहाँ जाता है उसके पास कुछ अपठनीय है और उसे देखना है। जोड़ने पर ऐसा पन्ना बनता जिसका आधा हिस्सा दोनों में से हर एक के लिए फ़ालतू होता।

NaN, Infinity और वे कुंजियाँ जो चुपचाप ग़ायब हो जाती हैं

JSON में `NaN`, `Infinity` और `undefined` जैसा कुछ है ही नहीं। JavaScript में ये तीनों बनते हैं, इसलिए किसी गणना का नतीजा सीधे किसी दस्तावेज़ में लिखे जाने पर या तो उसे अवैध बना देता है या — और यह ज़्यादा बुरा है — चुपचाप बदल जाता है।

`JSON.stringify` `NaN` और `Infinity` को `null` लिख देता है, और `undefined` वाली कुंजी को पूरी तरह छोड़ देता है। दस्तावेज़ वैध निकलता है, यह पन्ना उसे पार कर देता है, और दूसरी तरफ़ किसी फ़ील्ड में `null` बैठा है या वह फ़ील्ड है ही नहीं। अगर कोई कुंजी बिना किसी वजह के ग़ायब हो रही है, तो उसे बनाने वाली गणना पहली जगह है जहाँ देखना चाहिए।

DPDP Act के लिहाज़ से इसका क्या मतलब है

जिस दस्तावेज़ को कोई चीज़ मना कर रही है वह आम तौर पर असली दस्तावेज़ होता है: कोई ऑर्डर, कोई ग्राहक-रिकॉर्ड, नाम-पते वाला किसी webhook का शरीर। चूँकि जाँच पन्ने पर ही होती है, उसमें से कुछ भी हम तक नहीं पहुँचता और न हमारे किसी रिक्वेस्ट लॉग में रहता है।

यह ठीक वही हालत है जिसे कोई आंतरिक नीति रोकना चाहती है — debug करने के लिए निजी डेटा किसी तीसरे पक्ष की सेवा में चिपका देना — और यहाँ वह बनती ही नहीं, क्योंकि पाने वाला कोई तीसरा पक्ष है ही नहीं। नेटवर्क पैनल इस्तेमाल के दौरान यह दिखा देता है।

JSON validate करें: आम सवाल

यह पंक्ति 13 बताता है और ग़लती 12 पर लगती है, ऐसा क्यों?

यह सामान्य है: parser वहाँ रुकता है जहाँ चीज़ें बैठना बंद करती हैं, वहाँ नहीं जहाँ कारण है। 12 पर छूटा अल्पविराम 13 पर पकड़ा जाता है। इसीलिए यहाँ सिर्फ़ संख्या नहीं, निशान लगा टुकड़ा भी मिलता है।

दस्तावेज़ वैध है और मेरी API उसे फिर भी मना कर रही है, क्यों?

तब दिक़्क़त वाक्य-विन्यास की नहीं, schema की है: किसी फ़ील्ड का प्रकार ग़लत, तारीख़ किसी और रूप में, कोई कुंजी ग़ायब। उसे उसी API के schema के सामने JSON Schema का validator जाँचता है।

यह कॉलम 1 पर विफल होता है और मुझे कुछ अजीब दिखता नहीं, क्यों?

लगभग तय है कि दस्तावेज़ से पहले एक अदृश्य byte order mark पड़ा है, जिसे Excel या Windows का कोई एडिटर लगा देता है। फ़ाइल को दोबारा UTF-8 में, BOM के बिना सहेज लीजिए।

दस्तावेज़ वैध है तो यह किसी संख्या की चेतावनी क्यों देता है?

क्योंकि उसमें ऐसा पूर्णांक है जो पढ़े जाते समय ठीक-ठीक बना रहने के लिए बहुत बड़ा है। वह वैध है और फिर भी अंक खोता है, यहाँ भी और JavaScript का parser इस्तेमाल करने वाले हर तंत्र में भी। ऐसे मान को स्ट्रिंग के रूप में चलना चाहिए।

क्या दस्तावेज़ मेरे डिवाइस से बाहर जाता है?

नहीं। जाँच इसी पन्ने पर होती है। यह मायने रखता है, क्योंकि जिस दस्तावेज़ को कोई चीज़ मना कर रही होती है वह आम तौर पर असली होता है, भीतर लोगों के डेटा के साथ।

नतीजा