लगभग हर JSON त्रुटि जिससे आप मिलेंगे वह नौ में से एक होती है। पार्सर का संदेश शायद ही कभी बताता है कि कौन सी है, क्योंकि अधिकांश पार्सर उस टोकन की रिपोर्ट करते हैं जिस पर वे अटके, न कि आपकी गलती की, और ये दोनों अलग-अलग होते हैं। नीचे प्रत्येक त्रुटि, आपके द्वारा देखे जाने वाला संदेश, और उसे ठीक करने वाला संपादन दिया गया है।
यदि आप साथ चलना चाहते हैं, तो इनमें से किसी को भी JSON वैलिडेटर में पेस्ट करें। यह गलती का नाम बताता है और पंक्ति चिह्नित करता है।
1. अंतिम कॉमा
{
"name": "ana",
"role": "admin",
}आखिरी प्रॉपर्टी के बाद की कॉमा JavaScript में वैध है और JSON में गैरकानूनी। अधिकांश पार्सर इसे क्लोजिंग ब्रेस पर रिपोर्ट करते हैं, वास्तविक कॉमा से एक पंक्ति नीचे, इसीलिए लोग ब्रेस को घूरते हैं और उसमें कुछ गलत नहीं देखते।
कॉमा हटा दें। यदि आप यह समस्या बार-बार सामने आते हैं क्योंकि आप कॉन्फ़िगरेशन फ़ाइलें हाथ से संपादित करते हैं, तो JSON रिपेयर टूल उन्हें हटा देता है और हर हटाई गई कॉमा दिखाता है।
2. सिंगल कोट्स
{ 'name': 'ana' }JSON में स्ट्रिंग की एक ही सिंटैक्स है और वह डबल कोट्स का उपयोग करती है। सिंगल कोट्स एक JavaScript की आदत है। समाधान यांत्रिक है, और यदि दस्तावेज़ बड़ा है तो हाथ से करने से बेहतर है किसी टूल से करना, क्योंकि स्ट्रिंग के अंदर एक कोट्स को बदलने के बजाय एस्केप करना पड़ता है।
3. बिना कोट्स वाली keys
{ name: "ana" }ऑब्जेक्ट की keys स्ट्रिंग होती हैं, और स्ट्रिंग्स कोट्स में होती हैं। JavaScript ऑब्जेक्ट लिटरल्स में आप कोट्स हटा सकते हैं, और यहीं से यह त्रुटि हमेशा आती है: किसी ने किसी सोर्स फ़ाइल से ऑब्जेक्ट कॉपी किया और उम्मीद की कि यह JSON होगा। यह JSON नहीं है।
4. कमेंट्स
{
// the account owner
"name": "ana"
}JSON में कमेंट्स नहीं होते। Douglas Crockford ने उन्हें जानबूझकर हटाया, क्योंकि
लोग उनका उपयोग पार्सिंग निर्देश ले जाने के लिए कर रहे थे। // और /* */ दोनों
त्रुटियाँ हैं। यदि कमेंट्स महत्वपूर्ण हैं, तो उन्हें सोर्स फ़ाइल में रखें और उससे JSON
जनरेट करें, या नोट को "_comment" जैसे वास्तविक फ़ील्ड में स्थानांतरित करें।
5. NaN, Infinity और undefined
{ "score": NaN, "limit": Infinity }इनमें से कोई भी JSON में मौजूद नहीं है। उनके लिए कोई सिंटैक्स ही नहीं है, इसीलिए
त्रुटि आमतौर पर एक अप्रत्याशित नंगे शब्द के रूप में दिखाई देती है। Python बिना सावधानी के
फ़्लोट्स निकालने पर NaN और Infinity लिखता है, और JavaScript गायब
प्रॉपर्टी से undefined उत्पन्न करता है।
आपको तय करना होगा कि इन्हें क्या बनाना है, क्योंकि कोई बिना नुकसान वाला
उत्तर नहीं है। null सबसे सामान्य विकल्प है, "NaN" जैसी स्ट्रिंग दूसरा विकल्प है। रिपेयर
टूल null चुनता है और पंक्तिचिह्न सुधारों से अलग परिवर्तन सूचीबद्ध करता है,
क्योंकि यह आपके डेटा को बदलता है, न कि उसकी वर्तनी।
6. गलत केस के कीवर्ड
{ "active": True, "deleted": NULL }JSON के कीवर्ड लोअर केस में होते हैं: true, false, null। True और None
Python के हैं, NULL SQL और C का है। जो पार्सर “unexpected token T” कहता है वह
सबसे कम उपयोगी तरीके से सच बता रहा है।
7. स्ट्रिंग के अंदर न्यूलाइन
{ "note": "first line
second line" }JSON स्ट्रिंग कई पंक्तियों में नहीं फैल सकती। लाइन ब्रेक को स्ट्रिंग के अंदर \n के
रूप में लिखना पड़ता है। यह तब आम है जब कोई बहु-पंक्ति टेक्स्ट हाथ से कॉन्फ़िग में
पेस्ट करता है, और परिणामी त्रुटि अक्सर अगली पंक्ति की ओर इशारा करती है, खुली छूटी गई
स्ट्रिंग की ओर नहीं।
8. JSON द्वारा अनुमत नहीं किए गए नंबर
{ "a": .5, "b": +1, "c": 007, "d": 1_000 }चार अलग-अलग नियम। एक नंबर में दशमलव बिंदु से पहले एक अंक होना चाहिए, इसलिए .5 का मतलब है
0.5। शुरू में प्लस साइन की अनुमति नहीं है। शुरू में ज़ीरो की अनुमति नहीं है, जो
007 को अस्वीकार करता है। डिजिट सेपरेटर्स भाषा की विशेषता हैं, JSON की नहीं।
9. अनक्लोज़्ड ब्रैकेट
{
"user": {
"name": "ana"
}पार्सर फ़ाइल के अंत में पहुँचता है और वहाँ रिपोर्ट करता है, इसलिए संदेश 200 पंक्तियों वाले दस्तावेज़ की पंक्ति 200 के बारे में कुछ कहता है जबकि गायब ब्रेस पंक्ति 2 पर है। यह त्रुटि एक अच्छे टूल के लिए महत्वपूर्ण है: इस साइट का वैलिडेटर खुले और बंद न किए गए ब्रैकेट की स्थिति रिपोर्ट करता है, न कि इनपुट के अंत की।
दो त्रुटियाँ जो सिंटैक्स त्रुटियाँ नहीं हैं
दो दस्तावेज़ बिल्कुल वैध हो सकते हैं और फिर भी गलत हो सकते हैं।
एक डुप्लिकेट key बिना किसी समस्या के पार्स होती है। विनिर्देश इसकी अनुमति देता है, और आप जो भी पार्सर उपयोग करेंगे वह आखिरी मान रखता है और पहले वाले को चुपचाप हटा देता है, इसलिए डेटा बिना किसी त्रुटि के कहीं भी गायब हो जाता है:
{ "region": "eu-west-1", "retries": 3, "region": "us-east-1" }वैलिडेटर डुप्लिकेट को दोनों पंक्ति नंबरों के साथ चेतावनी के रूप में रिपोर्ट करता है, और फिर भी दस्तावेज़ को वैध कहता है, क्योंकि विनिर्देश यही कहता है।
एक लंबा पूर्णांक भी बिना किसी समस्या के पार्स होता है, और फिर जैसे ही कुछ इसे डबल में पढ़ता है सटीकता खो देता है:
{ "id": 12345678901234567890 }इसे एक सामान्य JSON लाइब्रेरी से पढ़ने पर आपको 1234567890123567000 मिलता है। इस साइट
के टूल JavaScript मान में पार्स करने के बजाय टोकन स्ट्रीम पर काम करते हैं,
इसलिए नंबर फ़ॉर्मेटिंग, मिनिफिकेशन और तुलना में बिना बदले रहता है। यही कारण है कि
diff टूल बीस अंकों वाले दो पूर्णांकों को सिर्फ इसलिए बराबर नहीं कहेगा
क्योंकि वे उसी फ़्लोटिंग पॉइंट मान पर गिरते हैं।
त्रुटि संदेश को सही ढंग से पढ़ना
दो आदतें लोगों का अधिकांश समय बचाती हैं।
पहले, रिपोर्ट की गई स्थिति को उस बिंदु के रूप में मानें जहाँ पार्सर ने हार मान ली, न कि जहाँ आपने गलती की। गायब कॉमा अगले टोकन पर रिपोर्ट होती है, अनक्लोज़्ड ब्रैकेट फ़ाइल के अंत पर, और अंतिम कॉमा क्लोजिंग ब्रेस पर।
दूसरे, रिपोर्ट की गई स्थिति से पहले वाला अक्षर जाँचें। अधिकांश मामलों में वास्तविक गलती शिकायत से एक टोकन पहले होती है।
यदि आप ये दोनों नहीं करना चाहते, तो दस्तावेज़ को वैलिडेटर में पेस्ट करें और संदेश पढ़ें, जो गलत कंस्ट्रक्ट का नाम बताता है बजाय उस टोकन के जिसे पार्स नहीं किया जा सका।