डेवलपर टूल · JSON फ़ॉर्मेटर और सत्यापनकर्ता
JSON में डुप्लिकेट कुंजियाँ: RFC 8259 क्या अनुमति देता है और पार्सर क्या करते हैं
· पेजभूमि
json मानकों मान्यकरण
JSON का व्याकरण एक ही कुंजी को दो बार अनुमति देता है, विशिष्टता केवल यह कहती है कि नाम 'अद्वितीय' होने चाहिए, और पार्सर्स इस बात पर असहमत हैं कि कौन सा मान जीतता है। यह पोस्ट बताती है कि शुद्धता और सुरक्षा के लिए यह क्यों मायने रखता है।
सर्वर ने कौन सी 'भूमिका' पढ़ी?
`{"role":"viewer","role":"editor"}` पर विचार करें. दोनों सदस्य व्याकरणिक रूप से पूर्ण हैं, इसलिए ToolAcre रिपोर्ट मान्य JSON है। जब पाठ `JSON.parse` तक पहुंचता है, तो परिणामी ऑब्जेक्ट में एक `role` गुण होता है जिसका मान `"editor"` होता है। पहले वाले सदस्य को छिपे हुए इतिहास के रूप में नहीं रखा जाता है। इसलिए एक सफल सिंटैक्स जांच इस बारे में कुछ भी उत्तर नहीं देती है कि ऑब्जेक्ट नाम एक से अधिक बार दिखाई दिए हैं या नहीं।
फ़ॉर्मेटिंग से हानि घटित होने के बाद ही दिखाई देती है: आउटपुट में चुने गए लेआउट में `{"role":"editor"}` होता है। यह छोड़े गए `viewer` सदस्य को पुन: उत्पन्न नहीं कर सकता क्योंकि क्रमांकन पार्स किए गए ऑब्जेक्ट को प्राप्त करता है, मूल सदस्य अनुक्रम को नहीं। यदि दोहराए गए नाम समीक्षा के लिए मायने रखते हैं, तो सामान्यीकृत परिणाम पर भरोसा करने के बजाय फ़ॉर्मेट दबाने से पहले स्रोत पाठ को संरक्षित और निरीक्षण करें।
व्याकरण इसकी अनुमति देता है, विशिष्टता इसे हतोत्साहित करती है
RFC 8259 का कहना है कि किसी वस्तु के नाम अद्वितीय होने चाहिए। वह "चाहिए" विशिष्टता को मूल वस्तु व्याकरण का हिस्सा बनाए बिना इंटरऑपरेबल आउटपुट को बढ़ावा देता है। दोहराए गए नाम में अभी भी सही अल्पविराम से अलग स्थिति में एक वैध स्ट्रिंग, कोलन और मान शामिल हैं। नतीजतन, एक व्याकरण सत्यापनकर्ता दस्तावेज़ को स्वीकार कर सकता है जबकि एक आवेदन नीति इसे अस्वीकार कर देती है।
इस अंतर को नज़रअंदाज करना आसान है क्योंकि कई त्रुटियां अनिवार्य सिंटैक्स विफलताएं हैं: एक लापता कोलन या पिछला अल्पविराम JSON ऑब्जेक्ट बिल्कुल नहीं बना सकता है। डुप्लिकेट अलग हैं. पार्सर द्वारा प्रत्येक टोकन को पहचानने के बाद वे एक अंतरसंचालनीयता प्रश्न बनाते हैं। ToolAcre जानबूझकर सिंटैक्स पर रुकता है और डुप्लिकेट-नाम नियम नहीं जोड़ता है, इसलिए इसके वैध परिणाम को विशिष्टता की गारंटी के रूप में नहीं पढ़ा जाना चाहिए।
JSON.parse और ToolAcre क्या करते हैं
`JSON.parse` ऑब्जेक्ट नाम दोहराए जाने पर बाद की घटना का उपयोग करता है। ToolAcre को वह व्यवहार विरासत में मिलता है क्योंकि यह फ़ॉर्मेटिंग से पहले पार्स करता है। `{"limit":10,"limit":25,"unit":"items"}` के लिए, सत्यापन सफल होता है, पार्स की गई सीमा 25 है, और स्वरूपित आउटपुट में एक `limit` होता है। वैकल्पिक कुंजी सॉर्टिंग उस जीवित संपत्ति को पुनर्स्थापित कर सकती है लेकिन अधिलेखित घटना को उजागर नहीं कर सकती है।
प्रत्येक पार्सर या कॉन्फ़िगरेशन के लिए उस परिणाम को सामान्यीकृत न करें। कुछ सिस्टम डुप्लिकेट को अस्वीकार कर सकते हैं, और अन्य प्रोसेसिंग स्टैक एक अलग नीति लागू कर सकते हैं या किसी ऑब्जेक्ट के निर्माण से पहले टोकन का निरीक्षण कर सकते हैं। सुरक्षित क्रॉस-सिस्टम स्टेटमेंट संकीर्ण है: दोहराए गए नाम विश्वसनीय रूप से इंटरऑपरेबल नहीं हैं। भाषा-व्यापी दावे पर भरोसा करने के बजाय, जब अंतर मायने रखता है तो प्रत्येक सीमा पर उपयोग किए गए वास्तविक पार्सर मोड की जांच करें।
जब पार्सर असहमति एक जोखिम बन जाती है
डुप्लिकेट केवल एक ठोस मल्टी-स्टेज पथ में सुरक्षा चिंता बन जाते हैं जहां घटक एक ही पाठ की अलग-अलग व्याख्या करते हैं। उदाहरण के लिए, एक अनुरोध फ़िल्टर एक घटना का निरीक्षण कर सकता है जबकि एप्लिकेशन दूसरी घटना का उपभोग करता है। ऐसा हो सकता है या नहीं यह सटीक पार्सर्स, विकल्पों, अग्रेषण व्यवहार और फ़ील्ड उपयोग पर निर्भर करता है। अकेले डुप्लिकेट सिंटैक्स एक शोषक बाईपास साबित नहीं होता है।
रक्षात्मक नियंत्रण ट्रस्ट सीमा पर एक नीति स्थापित करना और वास्तविक स्टैक का परीक्षण करना है। अस्पष्टता अस्वीकार्य होने पर हानिपूर्ण ऑब्जेक्ट निर्माण से पहले डुप्लिकेट नामों को अस्वीकार करें, या सुनिश्चित करें कि प्रत्येक घटक को पहले से ही पार्स किए गए समान प्रतिनिधित्व प्राप्त हो। ToolAcre अपने स्वयं के अंतिम-जीत स्वरूपण व्यवहार को प्रदर्शित कर सकता है, लेकिन यह गेटवे, फ्रेमवर्क या सेवाओं का ऑडिट नहीं कर सकता है जो ब्राउज़र टूल का हिस्सा नहीं हैं।
कार्यान्वित उदाहरण: दोहराई गई कुंजी वाला एक दस्तावेज़
`{"theme":"light","prefs":{"density":"roomy","density":"compact"},"theme":"dark"}` चिपकाएँ. ToolAcre पाठ को स्वीकार करता है क्योंकि प्रत्येक सदस्य वाक्यात्मक रूप से मान्य है। पार्सिंग में मूल थीम को `dark` और नेस्टेड घनत्व को `compact` के रूप में छोड़ दिया जाता है। फ़ॉर्मेटिंग से प्रत्येक नाम की एक प्रति निकलती है, इसलिए पहले के दोनों मान प्रदर्शित दस्तावेज़ से गायब हो जाते हैं।
वह उदाहरण यह भी दिखाता है कि स्वरूपित परिणाम खोजने में बहुत देर क्यों हो जाती है। प्रत्येक ऑब्जेक्ट की गहराई पर, मूल टोकन स्ट्रीम को पढ़ते समय डुप्लिकेट डिटेक्शन को सदस्य नामों का निरीक्षण करना चाहिए। सरणियों को डुप्लिकेट-नाम नियम की आवश्यकता नहीं है, हालांकि अलग-अलग एप्लिकेशन नियम दोहराए गए तत्व मानों की परवाह कर सकते हैं। स्रोत को अपरिवर्तित रखें, इसके विरुद्ध डुप्लिकेट-अवेयर पार्सर या लिंटर चलाएँ, और तय करें कि नीति चेतावनी है या अस्वीकृति।
जानबूझकर डुप्लिकेट का पता लगाना
ऐसे टूल का उपयोग करें जो स्पष्ट रूप से स्रोत JSON पर डुप्लिकेट-नाम का पता लगाने का वादा करता है। उपयुक्त तरीकों में एक पार्सर मोड शामिल है जो दोहराव पर विफल हो जाता है, एक स्ट्रीमिंग टोकन हैंडलर जो प्रत्येक खुली वस्तु के लिए नाम ट्रैक करता है, या एक दस्तावेज़ीकृत डुप्लिकेट-कुंजी नियम के साथ एक लिंटर। नेस्टेड ऑब्जेक्ट और बचे हुए नामों को सत्यापित करें: `"name"` और `"name"` एक ही सदस्य नाम पर डिकोड करें, भले ही उनकी स्रोत वर्तनी भिन्न हो।
JSON सामान्य पार्सिंग द्वारा पहले की घटनाओं को खारिज करने के बाद स्कीमा कोई विकल्प नहीं है। एक स्कीमा सत्यापनकर्ता आमतौर पर निर्मित मूल्य प्राप्त करता है और एक संपत्ति देखता है, डुप्लिकेट टोकन इतिहास नहीं। पार्सिंग से पहले या उसके दौरान विशिष्टता जाँच चलाएँ, फिर स्पष्ट मान पर स्कीमा जाँच लागू करें। ToolAcre न तो डुप्लिकेट डिटेक्शन और न ही स्कीमा सत्यापन करता है, इसलिए दोनों को एक अलग, उद्देश्य-निर्मित चरण की आवश्यकता होती है।
इसमें क्या शामिल नहीं है
दोहराए गए ऑब्जेक्ट नाम रिकॉर्ड में दोहराए गए मानों के समान नहीं हैं। `[ {"id":7}, {"id":7} ]` में दो अलग-अलग ऑब्जेक्ट हैं, प्रत्येक में एक `id` है; डुप्लिकेट पहचानकर्ता का पता लगाने के लिए एक डेटासेट नियम है। इसी तरह, एक ही स्ट्रिंग वाले दो सरणी तत्व दो जानबूझकर स्थितियाँ बने रहते हैं जब तक कि कोई एप्लिकेशन अनुबंध यह नहीं कहता कि सरणी एक सेट का प्रतिनिधित्व करती है।
यह लेख व्यापक भाषा पारिस्थितिकी तंत्र के लिए सार्वभौमिक प्रथम-जीत, अंतिम-जीत या अस्वीकार नीति का दावा नहीं करता है। यह ToolAcre के अवलोकन योग्य `JSON.parse` व्यवहार को रिकॉर्ड करता है और बताता है कि किसी अन्य घटक को सीधे क्यों जांचा जाना चाहिए। यह अकेले डुप्लिकेट से शोषण क्षमता का निर्धारण नहीं करता है। सुरक्षा प्रभाव के लिए साक्ष्य की आवश्यकता होती है कि अलग-अलग व्याख्याएँ प्रासंगिक प्राधिकरण, रूटिंग या सत्यापन सीमा को पार करती हैं।
टेकअवे: वैध JSON हमेशा स्पष्ट नहीं होता है JSON
ToolAcre वैध परिणाम का मतलब है कि टोकन अनुक्रम सख्त है JSON; इसका मतलब यह नहीं है कि प्रत्येक वस्तु का नाम अद्वितीय है। `JSON.parse` दोहराए गए नाम के लिए अंतिम मान रखता है, और फ़ॉर्मेटिंग केवल उस उत्तरजीवी को क्रमबद्ध करता है। क्योंकि पिछली घटना मिटा दी गई है, स्वरूपित आउटपुट यह तय करने के लिए अनुपयुक्त सबूत है कि मूल स्रोत में डुप्लिकेट थे या नहीं।
जब विशिष्टता मायने रखती है, तो सामान्य पार्सिंग या फ़ॉर्मेटिंग से पहले डुप्लिकेट-अवेयर टूलिंग के साथ मूल पाठ का निरीक्षण करें। परिणामी स्पष्ट मान पर बाद में स्कीमा और डोमेन सत्यापन लागू करें। सुरक्षा समीक्षा के लिए, असहमति मानने के बजाय वास्तविक अनुरोध पथ और पार्सर सेटिंग्स का पता लगाएं। व्यावहारिक नियम सरल है: वाक्यविन्यास स्वीकृति, डुप्लिकेट-नाम नीति और डाउनस्ट्रीम अर्थ अलग-अलग साक्ष्य के साथ अलग-अलग जांच हैं।