JSON त्रुटि संदेश खोज: त्रुटि पाठ से सीधे समाधान तक

सार: जब JSON.parse की त्रुटि आए, तो पहले स्थान और token पकड़ें; स्थान 0 का अर्थ है HTML रिस्पॉन्स, BOM या गलत प्रकार जाँचें, और "Expected" संदेश का अर्थ है पिछला अक्षर देखें — बताए गए स्थान से पंक्ति-दर-पंक्ति दोबारा न पढ़ें।

त्रुटि पाठ शोर नहीं है — वह उत्तर है। Parser आपको बताता है कि वह किस अक्षर पर पहुँचा, उसे क्या अपेक्षित था, और वास्तव में क्या मिला। त्रुटि संदेश से खोजना पूरे दस्तावेज़ को हाथ से दोबारा लिखने से बेहतर है।

हर JSON.parse() त्रुटि के तीन भाग होते हैं: स्थान (अक्षर offset, या पंक्ति/स्तंभ), अपेक्षा (Expected...), और वास्तविकता (Unexpected token X, या xxx is not valid JSON)। इंजन इन्हें अलग-अलग शब्दों में कहते हैं — Chrome और Node (V8) कहते हैं Expected ',' or '}' after property value in JSON at position 25, Firefox कहता है JSON.parse: expected ',' or '}' after property value in object at line 3 column 1, Safari कहता है JSON Parse error: Expected ',' or '}' — पर तीनों एक ही सिंटैक्स टूटन की ओर इशारा करते हैं। त्रुटि खोजते समय शब्दों को छोड़ें और तीन तथ्य पकड़ें: कौन सा अक्षर, क्या अपेक्षित था, क्या आया।

1. 12 त्रुटियों की खोज तालिका

बायाँ स्तंभ आपके console से सबसे पहचाने जाने योग्य अंश है (V8 का शब्दांकन)। Firefox/Safari के रूप कोष्ठक में हैं।

पहली दो पर गहराई से नज़र डालनी चाहिए, क्योंकि उनमें से कोई भी "आपका JSON गलत है" नहीं कहती — वे कहती हैं "जो आपको मिला, वह वह नहीं है जो आप सोच रहे हैं"।

2. स्थान-0 त्रुटि के तीन सामान्य स्रोत

स्थान 0 का अर्थ है कि सबसे पहला अक्षर ही अवैध है। अगर कुछ भी संदिग्ध न लगे, तो अक्षर संभवतः अदृश्य है। तीन सामान्य संदिग्ध:

पहला: <, यानी HTML। यह उत्पादन में सबसे आम पार्स त्रुटि है। गलत URL, gateway द्वारा रीडायरेक्ट किया गया expired session, या सर्वर त्रुटि टेम्पलेट — body <!DOCTYPE html> से शुरू होती है और parser पहले ही अक्षर पर रुक जाता है। सही कदम यह है कि Network panel खोलकर कच्चा रिस्पॉन्स पढ़ें, फिर API कॉल ठीक करें, JSON नहीं।

दूसरा: BOM या शून्य-चौड़ाई वाले अक्षर। Windows Notepad से सहेजी गई फ़ाइलें अक्सर UTF-8 BOM (\uFEFF) से शुरू होती हैं, और वेब पृष्ठों या चैट ऐप से कॉपी किया गया पाठ शून्य-चौड़ाई स्पेस (\u200B–\u200D) लिए हो सकता है। आपको अदृश्य, parser को स्पष्ट:

复制// Strip BOM and zero-width characters before parsing
const cleaned = raw.replace(/^\uFEFF/, '').replace(/[\u200B-\u200D]/g, '');
const data = JSON.parse(cleaned);

तीसरा: गलत प्रकार। JSON.parse(undefined) रिपोर्ट करता है "undefined" is not valid JSON; JSON.parse(someObject) रिपोर्ट करता है Unexpected token o (object "[object Object]" में बदल गया, और o स्थान 1 पर अवैध है)। दोनों का अर्थ है "डेटा पहले ही पार्स हो चुका है" या "डेटा कभी था ही नहीं"। व्याकरण नहीं, प्रकार जाँचें:

复制let data = text;
if (typeof data === 'string') {
  data = JSON.parse(data); // Parse only when it really is a string
}

3. स्थान आगे की ओर इशारा करता है; कारण पीछे है

दो त्रुटियाँ स्थान के बारे में भ्रम पैदा करती हैं, और तालिका में यही दो सबसे अधिक गलत पढ़ी जाने वाली प्रविष्टियाँ हैं:

• गायब comma: {"a": 1 "b": 2} रिपोर्ट करता है Expected ',' or '}' after property value "b" पंक्ति पर। रिपोर्ट सही है, पर सुधार पिछली पंक्ति के अंत में करना है।
• गायब बंद कोष्ठक: गहरे nesting में एक } या ] छूटने पर parser इनपुट के अंत तक सब निगल जाता है और रिपोर्ट करता है Unexpected end of JSON input। स्थान फ़ाइल का अंत है; असली अंतराल बहुत पहले हो सकता है। सबसे हाल ही के बंद न हुए { या [ के लिए पीछे खोजें — जोड़े गिनना आँख से देखने से बेहतर है।

सामान्य तकनीक द्विभाजन (bisection) है: बताए गए स्थान से पहले का पाठ काटकर अलग पार्स करें। यदि वह पार्स हो जाए, तो समस्या बताए गए स्थान के पास है; यदि न हो, तो और पीछे द्विभाजित करें। पहले असफल टुकड़े की सीमा ही असली त्रुटि स्थल है। बड़ी फ़ाइलों के लिए पहले दस्तावेज़ को प्रारूपित करें — इंडेंटेशन संरेखित होने पर गायब स्तर एक नज़र में दिख जाता है (ऑनलाइन JSON formatter इसके लिए ठीक काम करता है)।

4. चार "झूठी स्वस्थ" स्थितियाँ जो पार्स हो जाती हैं पर गलत व्यवहार करती हैं

त्रुटि से बुरा है त्रुटि न होना और डेटा गलत होना। इन चारों में JSON वैध है और parser खुश है — समस्या डेटा की बनावट में है:

1. दोहरी एन्कोडिंग: पूरे दस्तावेज़ पर JSON.stringify दो बार लगाया गया, इसलिए पार्स करने पर object नहीं, स्ट्रिंग मिलती है। अगर typeof result === 'string' है, तो दोबारा पार्स करें — पर दोहरी serialization को स्रोत पर खोजें और ठीक करें।
2. दोहराई गई key चुपचाप पिछली को ढक देती है: {"name": "Tom", "name": "Jerry"} वैध JSON है, अधिकांश parser शिकायत नहीं करते, और दूसरा मान जीत जाता है। यह कई स्रोतों से डेटा मिलाते समय काटता है; इससे पहले कि काटे, किसी सख्त JSON validator से इसे सामने लाएँ।
3. NDJSON को एक दस्तावेज़ मानना: स्ट्रीमिंग API हर पंक्ति में एक object देते हैं; पूरे पाठ को पार्स करना Unexpected non-whitespace character after JSON से विफल होता है। \n पर बाँटें और हर पंक्ति अलग पार्स करें।
4. संख्या परिशुद्धता का चुपचाप खोना: 2^53 - 1 से बड़े पूर्णांक (snowflake ID) अंतिम अंकों के शून्य होकर वापस आते हैं, बिना किसी त्रुटि के। ID को स्ट्रिंग के रूप में भेजें।

सामान्य सूत्र: parser मान लेता है कि सब ठीक है। इसलिए जब API डेटा गलत लगे, तो पहले कच्चे पाठ के पहले 80 अक्षर और उसका typeof छापें — सामग्री पर चर्चा से पहले बनावट की पुष्टि करें।

5. लिखते समय त्रुटियों को असंभव बनाएँ

खोज तालिका बाद की चीज़ है; रोकथाम पहले की। चार आदतें ज़्यादातर त्रुटियों को होने से पहले रोक लेती हैं:

复制// 1. Two checks before parsing any response
const response = await fetch('/api/users');
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: the API returned no data`);
}
const contentType = response.headers.get('content-type') ?? '';
if (!contentType.includes('application/json')) {
  throw new Error(`Expected JSON, got ${contentType}`);
}
const data = await response.json(); // 2. json() already parses — do not parse again

• उत्पन्न करने के लिए serialize करें, कभी जोड़ें नहीं: JSON.stringify() उद्धरण, newline और नियंत्रण अक्षरों को ठीक संभालता है; हाथ से बनी स्ट्रिंग Bad control character और Unterminated string का सबसे बड़ा स्रोत हैं।
• हमेशा catch करें: फेंकी गई JSON.parse त्रुटि तब तक समकालिक crash है जब तक कोई उसे न पकड़े। असुरक्षित इनपुट — localStorage, बाहरी फ़ाइलें — के लिए catch ब्लॉक में डिफ़ॉल्ट मान या स्पष्ट त्रुटि रिपोर्टिंग चाहिए।
• संरचना को Schema के हवाले करें: व्याकरण सही होना संरचना सही होना नहीं है। गायब फ़ील्ड और गलत प्रकार सीमा पर JSON Schema सत्यापन के विषय हैं; देखें JSON Schema क्या हल करता है।

6. त्वरित निर्णय पथ

पूरे लेख को एक निर्णय क्रम में समेटें। त्रुटि देखते ही पहले स्थान और token पकड़ें:

1. स्थान 0 → तीन स्रोत जाँचें: < (HTML), BOM, गलत प्रकार;
2. end of input → खाली या कटी हुई body जाँचें, फिर बंद न हुए कोष्ठकों के लिए पीछे खोजें;
3. Expected ... → पिछला अक्षर देखें; आमतौर पर गायब comma या उद्धरण होता है;
4. after JSON data → कई दस्तावेज़ जोड़ दिए गए हैं; पंक्ति से बाँटें;
5. पार्स हो जाता है पर डेटा गलत लगता है → चारों "झूठी स्वस्थ" जाँचें चलाएँ।

JSON parse त्रुटियाँ कैसे ठीक करें में दिए चरण-दर-चरण निदान के साथ मिलाकर, 90% पार्स समस्याएँ पाँच मिनट में हल हो जाती हैं। त्रुटि पाठ को ही bookmark रखें — यह वह डिबगिंग लॉग है जो parser ने आपके लिए लिखा है, इसका शब्दांकन हर तीन साल में एक बार बदलता है, और एक बार खोजना साल भर का काम बचा देता है।

"Unexpected token in JSON" का क्या अर्थ है?

Parser उस अक्षर पर पहुँचा जो JSON व्याकरण में उस स्थान पर अवैध है। token वही अस्वीकृत अक्षर है: < आमतौर पर अर्थ है कि API ने HTML लौटाया, ' अर्थ है single quote, / अर्थ है टिप्पणी, और साधारण अक्षर आमतौर पर बिना उद्धरण वाली key या undefined या NaN जैसे केवल-JavaScript शाब्दिक रूप को दर्शाता है। पहले token पढ़ें, फिर स्थान, और कारण एक तक सिकुड़ जाता है।

"Unexpected end of JSON input" कैसे ठीक करूँ?

दो स्रोत: खाली इनपुट (खाली रिस्पॉन्स body, या localStorage में खाली स्ट्रिंग) या कटा हुआ इनपुट (बीच में रुका डाउनलोड, अंतिम पंक्ति छूटी कॉपी, आकार सीमा)। खाली मामला if (!text) return से संभालें; फिर पूर्णता सत्यापित करें और सबसे हाल ही के बंद न हुए {, [ या " को बंद करें। ध्यान रखें कि यह त्रुटि गहरे में गायब ब्रैकेट से भी आ सकती है — स्थान संयोग से फ़ाइल का अंत होता है।

Chrome, Firefox और Safari त्रुटियाँ अलग-अलग क्यों बताते हैं?

तीनों ब्राउज़र अलग JS इंजन (V8, SpiderMonkey, JavaScriptCore) लाते हैं, और हर एक अपनी त्रुटियाँ अपने ढंग से लिखता है; MDN सभी आधिकारिक रूपों का दस्तावेज़ीकरण करता है। पर तीनों त्रुटियों में वही तीन तत्व होते हैं — स्थान, अपेक्षा, वास्तविकता — एक-से-एक शब्दार्थ के साथ। उन्हें V8 के शब्दांकन में बदलें और इस तालिका को जैसी है वैसी इस्तेमाल करें।

त्रुटि का स्थान ऐसी जगह दिखाता है जो ठीक लगती है — अब क्या?

असली त्रुटि पहले है। सामान्य मामले: गायब comma (अगली पंक्ति पर रिपोर्ट) और गायब बंद कोष्ठक (फ़ाइल के अंत में रिपोर्ट)। बताए गए स्थान से token-दर-token पीछे चलें, या द्विभाजन करें: पहला आधा अलग पार्स करें, और पहले असफल टुकड़े की सीमा ही वास्तविक त्रुटि स्थल है।