डेवलपर टूल · JSON फ़ॉर्मेटर और सत्यापनकर्ता
क्यों JSON लाइन्स फ़ाइल लाइन 2, कॉलम 1 पर सत्यापन विफल हो जाती है
· यह काम किस प्रकार करता है
json डेवलपर-वर्कफ़्लो मान्यकरण
एक .jsonl फ़ाइल एक नहीं बल्कि कई JSON दस्तावेज़ होती है, इसलिए एक सख्त सत्यापनकर्ता ठीक वहीं रुकता है जहां दूसरा शुरू होता है। यह पोस्ट JSON लाइन्स और NDJSON कन्वेंशन और उन्हें एक समय में एक रिकॉर्ड को मान्य करने के तरीके के बारे में बताती है।
प्रत्येक पंक्ति पर मान्य, फ़ाइल के रूप में अमान्य
प्रत्येक पंक्ति पर मान्य, फ़ाइल के रूप में अमान्य - वह निर्यात जिसे प्रत्येक डाउनस्ट्रीम टूल ख़ुशी से पढ़ता है लेकिन एक सत्यापनकर्ता दूसरी पंक्ति में अस्वीकार कर देता है। एक लॉग शिपर प्रत्येक नई लाइन को रिकॉर्ड सीमा के रूप में उपभोग कर सकता है, फिर भी एक सख्त JSON पार्सर पूरी फ़ाइल को एक इनपुट के रूप में देखता है। पहली वस्तु पूर्ण है JSON; अगला ओपनिंग ब्रेस एक अवैध दूसरा रूट मान है।
ToolAcre एक JSON टेक्स्ट को मान्य करता है, JSON पंक्तियों को नहीं। एक बार जब स्कैनर पहला रूट मान पूरा कर लेता है, तो JSON मान की समाप्ति के बाद किसी भी बाद के गैर-व्हाट्सएप वर्ण को अप्रत्याशित के रूप में रिपोर्ट किया जाता है। यह छुपे हुए फ़ॉलबैक के रूप में प्रति-पंक्ति NDJSON सत्यापन या रूपांतरण की पेशकश नहीं करता है। यह अंतर हरे परिणाम को यह बताने से रोकता है कि लाइन-ओरिएंटेड स्ट्रीम में प्रत्येक रिकॉर्ड की जाँच की गई थी।
एक पाठ, एक मान - जिसे RFC 8259 JSON पाठ के रूप में परिभाषित करता है और एक पंक्ति में दो शीर्ष-स्तरीय मान एक व्याकरण त्रुटि क्यों हैं
एक पाठ, एक मान - जिसे RFC 8259 JSON पाठ के रूप में परिभाषित करता है और एक पंक्ति में दो शीर्ष-स्तरीय मान एक व्याकरण त्रुटि क्यों हैं। JSON टेक्स्ट एक क्रमबद्ध मान है, इसलिए एक ऑब्जेक्ट, ऐरे, स्ट्रिंग, नंबर, बूलियन या नल रूट पर खड़ा हो सकता है। व्हाइटस्पेस उस मान को घेर सकता है, लेकिन यह कई जड़ों को एक बड़े वैध दस्तावेज़ में अलग नहीं कर सकता है।
उदाहरण के लिए, `{"ok":true} {"ok":false}` में दो अलग-अलग मान्य object हैं, लेकिन यह एक JSON text नहीं है। पहला object पूरा value है; पूरी string parse करने पर दूसरे `{` को reject करना चाहिए। दोनों value को सामान्य JSON में दिखाने के लिए array में रखें और array element के बीच ज़रूरी comma जोड़ें।
JSON लाइनें और NDJSON
JSON लाइनें और NDJSON - नई लाइन-सीमांकित परंपराएं, वे स्ट्रीमिंग और लॉग के लिए क्यों मौजूद हैं, और वे JSON सरणी से कैसे भिन्न हैं। प्रत्येक भौतिक रेखा में एक पूर्ण JSON मान होता है, सामान्यतः एक वस्तु, और नई पंक्ति JSON व्याकरण के बाहर फ़्रेमिंग के रूप में कार्य करती है। निर्माता रिकॉर्ड जोड़ सकते हैं और उपभोक्ता पूरा संग्रह लोड किए बिना उन्हें क्रमिक रूप से संसाधित कर सकते हैं।
इसके बजाय एक सरणी में एक प्रारंभिक ब्रैकेट, अल्पविराम से अलग किए गए तत्व और एक समापन ब्रैकेट होता है, जिससे पूरी फ़ाइल एक एकल JSON मान बन जाती है। यह APआई के लिए सुविधाजनक है जो एक सीमित संग्रह लौटाता है लेकिन अनिश्चित काल तक बढ़ती इवेंट स्ट्रीम के लिए अजीब है। एक काट-छाँट की गई JSON लाइन्स फ़ाइल पहले के सभी पूर्ण रिकॉर्ड को सुरक्षित रख सकती है; एक काटी गई सारणी आम तौर पर संलग्न मूल्य को अधूरा छोड़ देती है।
त्रुटि हमेशा लाइन 2, कॉलम 1 पर क्यों होती है
त्रुटि हमेशा लाइन 2, कॉलम 1 पर क्यों होती है - पार्सर पहला मान समाप्त करता है, इनपुट के अंत की उम्मीद करता है, और दूसरे रिकॉर्ड के पहले अक्षर को पूरा करता है। नई लाइन स्वयं कानूनी रूप से अनुगामी रिक्त स्थान है, इसलिए यह विफलता को ट्रिगर नहीं करती है। अगले रिकॉर्ड का शुरुआती ब्रेस पहला टोकन है जो पूर्ण-दस्तावेज़ स्थिति का खंडन करता है।
वह स्थान इस दावे के बजाय नैदानिक साक्ष्य है कि दूसरी वस्तु विकृत है। यदि रिपोर्ट लगातार वैध रूट के बाद पहले गैर-व्हाट्सएप वर्ण को इंगित करती है, तो विराम चिह्न संपादित करने से पहले फ़ाइल आकार का निरीक्षण करें। ब्रेस हटाने से रिकॉर्ड दूषित हो जाएगा; एक लाइन-अवेयर रीडर चुनना या रिकॉर्ड्स को एक सरणी में परिवर्तित करना वास्तविक फ़्रेमिंग बेमेल को संबोधित करता है।
कार्यान्वित उदाहरण: तीन लॉग रिकॉर्ड को मान्य करना
व्यावहारिक उदाहरण: तीन लॉग रिकॉर्ड को मान्य करना - प्रत्येक पंक्ति को स्वयं जांचना बनाम उन्हें अल्पविराम के साथ एक सरणी में लपेटना। मान लीजिए कि पंक्तियों में `{"level":"info"}`, `{"level":"warn"}` और `{"level":"error"}` हैं। एक लाइन-ओरिएंटेड सत्यापनकर्ता तीन अलग-अलग इनपुट को पार्स करता है और यदि किसी के पास कोई लापता उद्धरण या पिछला अल्पविराम है तो वह सटीक रिकॉर्ड की पहचान कर सकता है।
संपूर्ण दस्तावेज़ की सख्त जांच के लिए, नमूने को `[{"level":"info"},{"level":"warn"},{"level":"error"}]` में बदलें। कोष्ठक एक मूल स्थापित करते हैं और अल्पविराम इसके तत्वों का परिसीमन करते हैं। केवल नई पंक्तियों को अल्पविराम से न बदलें: जब तक कि आसपास की सारणी नहीं जोड़ी जाती है, तब तक विराम चिह्न द्वारा अलग की गई तीन जड़ें उत्पन्न होती हैं, और यह उन रिक्त पंक्तियों को गलत तरीके से संभाल सकती है जिन्हें स्रोत सम्मेलन मना कर सकता है या अनदेखा कर सकता है।
दो आकृतियों के बीच कन्वर्ट करना
दो आकृतियों के बीच कन्वर्ट करना - जब एक रैपिंग ऐरे उपयुक्त हो और जब यह लाइन-सीमांकित आउटपुट के बिंदु को हरा देगा। API अनुरोध, एडिटर या सख्त सत्यापनकर्ता के लिए इच्छित एक सीमित निर्यात अक्सर एक सरणी बन सकता है। रूपांतरण को पहले प्रत्येक रिकॉर्ड को पार्स करना होगा, क्योंकि पाठ्य संयोजन सुरक्षित रूप से एम्बेडेड एस्केप्ड वर्णों या अमान्य पंक्तियों का हिसाब नहीं दे सकता है।
जब रिकॉर्ड लगातार आते हैं, फ़ाइलें जोड़ी जाती हैं, या उपभोक्ताओं को सीमित मेमोरी और रिकॉर्ड-स्तरीय पुनर्प्राप्ति की आवश्यकता होती है, तो JSON लाइनें रखें। मल्टी-गीगाबाइट ईवेंट स्ट्रीम को एक सरणी में परिवर्तित करने के लिए कंटेनर स्थिति को बनाए रखने की आवश्यकता होती है और समापन ब्रैकेट आने तक पूर्ण पार्स में देरी होती है। दूसरी दिशा में, प्रत्येक सरणी तत्व को एक पंक्ति पर सघन रूप से क्रमबद्ध करें और परिभाषित करें कि क्या खाली पंक्तियों या अंतिम नई पंक्तियों की अनुमति है।
इसमें क्या शामिल नहीं है
इसमें क्या शामिल नहीं है - न्यूलाइन और रिकॉर्ड-सेपरेटर फ़्रेमिंग के बिना संयोजित JSON (RFC 7464), जिसके लिए समर्पित पार्सर की आवश्यकता होती है। सीधे एक साथ रखे गए मानों को सरल लाइन ऑपरेशन के साथ सुरक्षित रूप से विभाजित नहीं किया जा सकता है, खासकर जब जड़ें संख्याएं या स्ट्रिंग हो सकती हैं। RFC 7464 केवल दृश्यमान नई पंक्तियों पर निर्भर रहने के बजाय JSON पाठ अनुक्रमों को फ्रेम करने के लिए ASCII रिकॉर्ड-विभाजक वर्ण का उपयोग करता है।
यह record के साझा application rule भी validate नहीं करता। हर line parse करने से यह साबित नहीं होता कि timestamp क्रम में हैं, identifier unique हैं या सभी object एक schema इस्तेमाल करते हैं। ये जाँच record framing और syntax parsing के बाद होती हैं। इसी तरह string के अंदर escape sequence ` ` के रूप में newline data है, physical boundary नहीं; सही line reader को यह अंतर बचाना चाहिए।
टेकअवे: जानें कि आप कौन सा आकार धारण कर रहे हैं
टेकअवे: जानें कि आप कौन सा आकार धारण कर रहे हैं - और कैसे सत्यापनकर्ता की स्थिति आपको तुरंत बताती है कि एक फ़ाइल लाइन-सीमांकित है। पूर्ण पंक्ति-एक मान के बाद पंक्ति दो के पहले टोकन में विफलता दृढ़ता से कई फ़्रेम किए गए रिकॉर्ड को इंगित करती है, न कि पहले रिकॉर्ड में टूटे हुए सिंटैक्स को। डेटा बदलने से पहले एक्सटेंशन, निर्माता दस्तावेज़ और अपेक्षित उपभोक्ता की जाँच करें।
नई लाइन जानबूझकर होने पर रिकॉर्ड को स्वतंत्र रूप से सत्यापित करने के लिए JSON लाइन्स या NDJSON पार्सर का उपयोग करें। जब गंतव्य को एक पूर्ण JSON संग्रह की आवश्यकता हो तो एक सरणी का उपयोग करें। ToolAcre मल्टी-रूट फ़ाइल को सही ढंग से अस्वीकार करता है क्योंकि इसका अनुबंध सख्त एकल-पाठ सत्यापन है; अस्वीकृति यह दर्शाने के बजाय उस अनुबंध की रक्षा करती है कि न्यूलाइन-सीमांकित JSON स्वाभाविक रूप से दोषपूर्ण है। सत्यापनकर्ता को फ़्रेमिंग प्रारूप से मिलान करें।