अपना JSON जांचें
सिर्फ़ वैध या अवैध नहीं — लाइन, कॉलम, कैरेक्टर, और उसके बारे में क्या करना है। कुछ भी स्टोर नहीं होता; जांच यहीं चलती है।
- कभी स्टोर नहीं होती
- न कतार, न इंतज़ार
- साइनअप नहीं, वॉटरमार्क नहीं
JSON पेस्ट करें, टाइप करते-करते उसकी जांच होती रहेगी।
यह कैसे काम करता है
अपना JSON पेस्ट करें
या फ़ाइल यहां छोड़ें। वह जहां है वहीं पढ़ी जाती है; कुछ भी कहीं नहीं भेजा जाता।
नतीजा पढ़ें
वैध, और साथ में अंदर क्या-क्या है उसकी गिनती। या अवैध, और ठीक वह जगह चिह्नित।
ठीक करें और दोबारा जांचें
वहीं एडिट करें और टाइप करते-करते जवाब अपडेट होता है।
JSON असल में किन चीज़ों की मनाही करता है
JSON का व्याकरण जान-बूझकर बहुत छोटा रखा गया है, और लगभग हर वैलिडेशन फ़ेल होना उन गिनी-चुनी चीज़ों में से एक है जो लोग JavaScript से उधार लेते हैं और जिन्हें JSON ने कभी नहीं अपनाया। आख़िरी एलिमेंट के बाद एक आख़िरी कॉमा। डबल के बजाय सिंगल कोट। बिना कोट वाली की। कमेंट — JSON में ये नहीं हैं, और कभी नहीं थे। NaN और Infinity, जो JavaScript में वैध संख्याएं हैं पर JSON में नहीं। और शुरुआत में एक बाइट ऑर्डर मार्क, जो हर एडिटर में अदृश्य रहता है, जिसे कुछ Windows टूल UTF-8 में सेव करते समय जोड़ देते हैं और जिसकी वजह से एक बिल्कुल ठीक डॉक्यूमेंट अपने पहले ही कैरेक्टर पर फ़ेल हो जाता है।
दो चीज़ें वैध हैं और फिर भी आपको परेशानी देंगी, इसीलिए “वैध” और “सही” एक बात नहीं है। स्पेसिफ़िकेशन में डुप्लिकेट की मना नहीं हैं — और हर पार्सर उन्हें अलग तरह से सुलझाता है, ज़्यादातर आख़िरी वाली लेते हैं, इसलिए दोहराई गई की वाला डॉक्यूमेंट यहां वैध निकलता है और अलग-अलग भाषाओं में अलग-अलग मतलब रखता है। और JSON में संख्याओं की सटीकता की कोई तय सीमा नहीं है, जबकि ज़्यादातर पार्सर उन्हें फ़्लोटिंग पॉइंट के रूप में पढ़ते हैं: लगभग नौ क्वाड्रिलियन से बड़ा पूर्णांक चुपचाप राउंड हो जाता है, इसीलिए बड़े आइडेंटिफ़ायर अक्सर स्ट्रिंग के रूप में रखे जाते हैं।
आपको ठीक वह लाइन, कॉलम और कैरेक्टर वापस मिलता है जहां पार्सिंग रुकी, जो आमतौर पर ख़ुद मैसेज से ज़्यादा काम का होता है। पार्सर वह जगह बताता है जहां डॉक्यूमेंट का मतलब बनना बंद हुआ, वह नहीं जहां ग़लती हुई — छूटा हुआ बंद ब्रेस फ़ाइल के आख़िर में बताया जाता है, और छूटा हुआ कॉमा उसके बाद वाले टोकन पर। बताई गई जगह से ठीक पहले देखने की आदत सबसे ज़्यादा समय बचाती है।
सही तरह से बना होना और सही होना एक बात नहीं है, और यह फ़र्क़ मायने रखता है। यह पुष्टि करता है कि सिंटैक्स पार्स होता है। डॉक्यूमेंट में वे फ़ील्ड हैं या नहीं जो आपकी API मांगती है, कोई मान सीमा के अंदर है या नहीं, कोई तारीख़ सच में तारीख़ है या नहीं — इनमें से कोई भी JSON का सवाल नहीं है। वह स्कीमा वैलिडेशन है, उसके लिए स्कीमा चाहिए, और कोई डॉक्यूमेंट यहां बेदाग़ होकर भी उस सर्विस द्वारा तुरंत अस्वीकार किया जा सकता है जिसे आप उसे भेज रहे हैं।
जब आपको कुछ और चाहिए
व्याकरण के बजाय स्कीमा के मुक़ाबले डॉक्यूमेंट जांचने के लिए JSON Schema स्टैंडर्ड है और ajv उसका सबसे तेज़ इम्प्लीमेंटेशन — यह बताएगा कि कोई ज़रूरी फ़ील्ड ग़ायब है या कोई मान सीमा से बाहर है, और आमतौर पर असली सवाल यही होता है। check-jsonschema यही जांच कमांड लाइन और CI में चलाता है।
कमांड लाइन पर किसी भी काम के लिए jq रखने लायक टूल है: jq empty file.json वैलिडेट करता है और सफल होने पर कुछ नहीं दिखाता, जो स्क्रिप्ट के लिए बिल्कुल सही है, और jq . फ़ॉर्मैट करता है। मेमोरी में न समा सकने वाली बड़ी फ़ाइलों के लिए jq --stream और Python का ijson टुकड़ों में पार्स करते हैं, जो पूरा डॉक्यूमेंट लोड करने वाला कोई पेज नहीं कर सकता।
अक्सर पूछे जाने वाले सवाल
क्या मेरा JSON कहीं स्टोर होता है?
नहीं। कोई सर्वर कॉल नहीं, कोई लॉगिंग नहीं, और कुछ भी स्टोर नहीं होता। पेज लोड होने के बाद आप इंटरनेट बंद कर सकते हैं और यह काम करता रहता है। यहां यह जितना दिखता है उससे ज़्यादा मायने रखता है: लोग ऑनलाइन फ़ॉर्मैटर में जो चीज़ें पेस्ट करते हैं वे API रिस्पॉन्स, कॉन्फ़िग फ़ाइलें और एरर पेलोड होती हैं, और उनमें अक्सर टोकन, ग्राहकों के रिकॉर्ड और इंटरनल होस्टनेम होते हैं।
JSON टूटा होने पर यह मुझे क्या बताता है?
लाइन, कॉलम, वह लाइन जिसमें ठीक उस कैरेक्टर के नीचे एक निशान (^) होता है, और वहां क्या अपेक्षित था। ज़्यादातर JSON चार में से किसी एक वजह से टूटता है — आख़िरी कॉमा, डबल के बजाय सिंगल कोट, बिना कोट वाली की, या स्ट्रिंग के अंदर असली नई लाइन — और इनमें से हर एक का नाम लेकर बताया जाता है, उसे आम सिंटैक्स एरर कहकर नहीं टाला जाता।
वैध किसे माना जाता है?
RFC 8259, सख़्ती से। यानी डबल कोट वाली की, कोई आख़िरी कॉमा नहीं, कोई कमेंट नहीं, और संख्याओं में शुरुआती शून्य या हेक्स नहीं। सख़्त होना ही वैलिडेटर का मक़सद है: अगर यह वह स्वीकार कर लेता जिसे आपका पार्सर अस्वीकार करेगा, तो इसने आपको कुछ नहीं बताया होता।
क्या यह मेरे JSON को किसी स्कीमा के मुक़ाबले जांचता है?
नहीं — यह सिंटैक्स जांचता है, जो एक अलग सवाल है। सिंटैक्स यह है कि टेक्स्ट JSON है भी या नहीं। स्कीमा यह है कि डेटा में सही फ़ील्ड और टाइप हैं या नहीं। यह पेज पहले सवाल का जवाब देता है; यह बताएगा कि फ़ाइल पार्स होती है, और उसे मिला ढांचा दिखाएगा, पर इसे नहीं पता कि आपके फ़ील्ड क्या होने चाहिए।
यह वैध क्यों कहता है, जबकि मेरी API अब भी उसे अस्वीकार करती है?
क्योंकि वैध JSON और आपकी API को चाहिए JSON अलग चीज़ें हैं। सिंटैक्स के हिसाब से बिल्कुल सही डॉक्यूमेंट में भी कोई ज़रूरी फ़ील्ड ग़ायब हो सकता है, संख्या की जगह स्ट्रिंग हो सकती है, या चीज़ें एंडपॉइंट की उम्मीद से अलग तरह नेस्ट हो सकती हैं। यह पेज जो ढांचे का सारांश दिखाता है उसे API के डॉक्यूमेंटेशन से मिलाकर पढ़ें — बेमेल आमतौर पर तुरंत दिख जाता है।
क्या बड़ी संख्याएं ठीक से जांची जाती हैं?
हां, अंक-दर-अंक — ज़्यादातर वैलिडेटर उन्हें चुपचाप बिगाड़ देते हैं। JavaScript की संख्या 64-बिट फ़्लोट होती है, इसलिए वह सिर्फ़ 9,007,199,254,740,991 तक के पूर्णांक ही सटीक रख सकती है। इससे बड़ी कोई भी चीज़ — Twitter/X पोस्ट ID, Discord snowflake, बैंक खाता नंबर, 64-बिट डेटाबेस की — `JSON.parse` से गुज़रते ही अपने आख़िरी अंक खो देती है। संख्या फिर भी सही-सी दिखती है, और यही उसे ख़तरनाक बनाता है: 7205759403792793600 चुपचाप 7205759403792793000 बन जाती है। यह पेज आपके पेस्ट किए अंक बिल्कुल वैसे ही रखता है, और बताता है कि उसे कितनी संख्याएं बचानी पड़ीं।
क्या साइज़ की कोई सीमा है?
उपलब्ध मेमोरी, न कि हमारी लगाई कोई सीमा। कुछ मेगाबाइट के डॉक्यूमेंट तुरंत फ़ॉर्मैट हो जाते हैं; बहुत बड़े डॉक्यूमेंट की सीमा यह है कि एक साथ कितना रखा जा सकता है, हमारी तरफ़ की कोई चीज़ नहीं।
ध्यान दें: यह जांचता है कि JSON सही तरह से बना है, यह नहीं कि उसका कोई मतलब है। कोई डॉक्यूमेंट पूरी तरह वैध होकर भी उन फ़ील्ड से ख़ाली हो सकता है जिनकी आपकी API को उम्मीद है — वह स्कीमा वैलिडेशन है, जिसके लिए स्कीमा चाहिए। यहां आपको ठीक वह लाइन, कॉलम और कैरेक्टर मिलता है जहां पार्सिंग रुकी।
यह टूल अपनी वेबसाइट पर लगाएं
किसी भी ब्लॉग, क्लास पेज या हेल्प आर्टिकल के लिए मुफ़्त। एक स्निपेट पेस्ट करें और आपके विज़िटर इसे सीधे आपके पेज पर इस्तेमाल कर सकेंगे।