डेवलपर टूल · JSON फ़ॉर्मेटर और सत्यापनकर्ता
JSON सत्यापनकर्ता किसी त्रुटि की सटीक पंक्ति और कॉलम कैसे ढूंढता है
· यह काम किस प्रकार करता है
json मान्यकरण डेवलपर-वर्कफ़्लो
ब्राउज़र इंजन JSON.parse विफलताओं की अलग-अलग रिपोर्ट करते हैं, और कुछ केवल एक कैरेक्टर ऑफसेट देते हैं। यह पोस्ट बताती है कि कैसे एक सत्यापनकर्ता इसे एक पंक्ति और कॉलम में बदल देता है, और स्थिति यह क्यों चिह्नित करती है कि पार्सिंग कहाँ रुकी है बजाय इसके कि आपने कहाँ गलती की है।
त्रुटि संदेश जो आपको कुछ नहीं बताता - क्यों 'JSON स्थिति 1432 में अप्रत्याशित टोकन' 400-लाइन फ़ाइल में बेकार है
"अप्रत्याशित टोकन" जैसी त्रुटि लंबे कॉन्फ़िगरेशन में निराशाजनक है क्योंकि यह कोई स्थान प्रदान नहीं करती है जिसे आप अपने एडिटर में खोल सकते हैं। JSON.parse ब्राउज़र का आधिकारिक पार्सर है, लेकिन इसका डायग्नोस्टिक टेक्स्ट JavaScript इंजन और संस्करणों के बीच भिन्न है। ToolAcre अस्थिर अंग्रेजी त्रुटि स्ट्रिंग से मिलान करके स्थान का अनुमान नहीं लगाता है। यदि JSON.parse विफल रहता है, तो एक अलग सख्त स्कैनर पहले अक्षर की पहचान करने के लिए मूल पाठ पर चलता है जिसे JSON व्याकरण स्वीकार नहीं कर सकता है।
JSON पार्सर वास्तव में क्या करता है जैसे वह पढ़ता है - टोकनिंग और पुनरावर्ती-वंश व्याकरण के माध्यम से चलना जो एक समय में एक मान का उपभोग करता है
JSON में छह संरचनात्मक वर्ण हैं - ब्रेसिज़, ब्रैकेट, कोलन और अल्पविराम - और मान जो स्ट्रिंग, संख्या, सरणियाँ, ऑब्जेक्ट, सही, गलत या शून्य हो सकते हैं। अल्पविराम को विभाजक कहने से पहले स्कैनर को यह जानना आवश्यक है कि क्या यह उद्धृत स्ट्रिंग के अंदर है: {"note":"A,B"} का मान एक है, दो नहीं। यह किसी मान या ऑब्जेक्ट सदस्य के माध्यम से कदम उठाता है और जांचता है कि कानूनी तौर पर आगे क्या हो सकता है। RFC 8259 इस व्याकरण को परिभाषित करता है, और JavaScript ऑब्जेक्ट शाब्दिक के विपरीत यह टिप्पणियों या अनुवर्ती अल्पविरामों की अनुमति नहीं देता है।
कैरेक्टर ऑफसेट से लाइन और कॉलम तक - विफलता ऑफसेट तक नई लाइनों की गिनती, और क्यों CRLF अंत और मल्टी-बाइट कैरेक्टर गिनती को जटिल बनाते हैं
एक स्कैनर आमतौर पर मूल JavaScript स्ट्रिंग में शून्य-आधारित ऑफसेट से शुरू होता है। इसे उपयोगी बनाने के लिए, ऑफसेट से पहले लाइन ब्रेक की गणना करें और पता लगाएं कि विफलता अंतिम ब्रेक से कितनी दूर है। CRLF को एक दृश्य रेखा के अंत के रूप में माना जाना चाहिए, न कि दो पंक्तियों के रूप में; JavaScript स्ट्रिंग्स में स्थितियाँ UTF-16 कोड इकाइयों की गणना करती हैं, डिस्क पर UTF-8 बाइट्स की नहीं। एक गैर-BMP इमोजी एक एडिटर में दो कोड इकाइयों पर कब्जा कर सकता है जो दृश्य रूप से एक ग्लिफ़ दिखाता है। UI एक पंक्ति, कॉलम और अंश की रिपोर्ट करता है ताकि आप अपने द्वारा चिपकाई गई फ़ाइल के विरुद्ध कैरेट की जांच कर सकें।
जहां पार्सिंग रुकती है वह वह जगह नहीं है जहां गलती है - अगली कुंजी पर एक लापता अल्पविराम की सूचना दी जाती है, और एक भटका हुआ उद्धरण त्रुटि को कई पंक्तियों में नीचे धकेल सकता है
पहला असंभव टोकन अक्सर मूल गलती के बाद होता है। किसी ऑब्जेक्ट में, सत्य के बाद अल्पविराम को भूलने से अगली संपत्ति की शुरुआत का उद्धरण अवैध हो जाता है: पार्सर अल्पविराम या समापन ब्रेस की अपेक्षा कर रहा था। एक समाप्त न की गई स्ट्रिंग के कारण बाद में लाइन ब्रेक या इनपुट के अंत में त्रुटि दिखाई दे सकती है। लापता सीमांकक को खोजने के लिए रिपोर्ट किए गए बिंदु से पीछे की ओर पढ़ें; यह न मानें कि कैरेट के अंतर्गत वर्ण हटा दिया जाना चाहिए।
कार्यान्वित उदाहरण: एक लापता अल्पविराम के साथ एक कॉन्फ़िगरेशन - रिपोर्ट की गई स्थिति, आसपास के टोकन, और वास्तविक कारण तक पीछे की ओर कैसे चलना है
शाब्दिक तीन-पंक्ति वाले दस्तावेज़ {"name":"demo" को आज़माएं, उसके बाद पंक्ति दो पर "enabled":true और पंक्ति तीन पर "port":8080}, सत्य के बाद कोई अल्पविराम न लगाएं। ToolAcre रिपोर्ट लाइन 3, कॉलम 1, ऑफसेट 31: यह पिछली संपत्ति के बाद अल्पविराम या } की अपेक्षा करता है, और यह "पोर्ट" के पहले उद्धरण के तहत एक कैरेट दिखाता है। पंक्ति दो के अंत में अल्पविराम लगाएं, फिर दोबारा सत्यापित करें। यह पहली वाक्यविन्यास बाधा का निदान है, न कि यह निर्णय कि "पोर्ट" शब्द गलत है।
ब्राउज़र इंजन कैसे भिन्न होते हैं - V8, स्पाइडरमंकी और JavaScriptCore एक ही विफलता को अलग-अलग तरीके से व्यक्त करते हैं, यही कारण है कि एक सुसंगत लाइन-और-कॉलम रिपोर्ट मदद करती है
V8, स्पाइडरमंकी और JavaScriptCore ने एक ही JSON.parse विफलता के लिए अलग-अलग शब्दों और कभी-कभी अलग-अलग प्रासंगिक स्निपेट का उपयोग किया है। जब मूल पार्सर मान को अस्वीकार कर देता है तो ToolAcre का स्कैनर अपना स्वयं का संरचनात्मक कारण और स्थान प्रदान करता है। यदि स्कैनर कभी भी JSON.parse से असहमत होता है, तो टूल स्थिति बनाने के बजाय इंजन त्रुटि लौटाता है। किसी अनुमानित चरित्र की ओर आत्मविश्वास से इशारा करने की तुलना में वह फ़ॉलबैक अधिक सुरक्षित है।
इसमें क्या शामिल नहीं है - गलत प्रकार, लापता फ़ील्ड या स्कीमा उल्लंघन जैसी अर्थ संबंधी समस्याएं, जिन्हें एक सिंटैक्स सत्यापनकर्ता कभी चिह्नित नहीं करेगा
आपके एप्लिकेशन के लिए वाक्यात्मक रूप से मान्य ऑब्जेक्ट अभी भी गलत हो सकता है: एक गायब आवश्यक फ़ील्ड, टेक्स्ट के रूप में लिखी गई उम्र, दो डुप्लिकेट कुंजियाँ या किसी गैर-मौजूद फ़ाइल का संदर्भ स्वचालित रूप से अमान्य नहीं हैं JSON। RFC 8259 का कहना है कि अंतरसंचालनीयता के लिए सदस्य नाम अद्वितीय होने चाहिए, लेकिन मात्र पार्सिंग आपके API स्कीमा को लागू नहीं करता है। यहां सिंटैक्स को मान्य करें और दस्तावेज़ का उपभोग करने वाले प्रोग्राम में सिमेंटिक बाधाओं को मान्य करें।
टेकअवे: स्थिति को 'पहला टोकन जिसे व्याकरण स्वीकार नहीं कर सका' के रूप में पढ़ें - और JSON फ़ॉर्मेटर और सत्यापनकर्ता पाठ को अपलोड किए बिना उस पंक्ति और कॉलम की रिपोर्ट कैसे करते हैं
रिपोर्ट की गई स्थिति को "पहला टोकन जिसे यह व्याकरण स्वीकार नहीं कर सका" के रूप में मानें। कारण की ओर पीछे की ओर काम करें, एक समस्या को ठीक करें और फिर से चलाएँ। JSON फ़ॉर्मेटर और सत्यापनकर्ता पेस्ट किए गए कॉन्फ़िगरेशन को अपलोड किए बिना इसे स्थानीय रूप से करता है। यदि कोई ऑफ़लाइन एडिटर फ़ाइल का निदान कर सकता है तो किसी भी सार्वजनिक वेबसाइट पर वास्तविक उत्पादन क्रेडेंशियल पेस्ट न करें।