डेवलपर टूल · JSON फ़ॉर्मेटर और सत्यापनकर्ता
JSON के मानक इतिहास: RFC 4627 से RFC 8259 और ECMA-404
· पेजभूमि
json मानकों मान्यकरण
JSON को दो मानक निकायों द्वारा कम से कम चार बार निर्दिष्ट किया गया है। यह पोस्ट डगलस क्रॉकफ़ोर्ड के json.org से RFC 8259 और ECMA-404 तक का रास्ता बताती है, और बताती है कि इस दौरान डेवलपर्स के लिए वास्तव में क्या बदलाव आया।
मेरा पार्सर किस विशिष्टता का अनुसरण कर रहा है?
पार्सर किस विशिष्टता का अनुसरण कर रहा है? उत्तर आमतौर पर सामान्य वस्तुओं और सरणियों के बजाय किनारों पर दिखाई देता है। शीर्ष-स्तरीय स्ट्रिंग जैसे `"ready"`, एक अग्रणी बाइट-ऑर्डर चिह्न, डुप्लिकेट सदस्य नाम और असामान्य रूप से बड़ी संख्या का परीक्षण करें। विभिन्न दस्तावेज़ विभिन्न स्तरों पर सिंटैक्स और इंटरऑपरेबिलिटी पर चर्चा करते हैं, जबकि कार्यान्वयन अपने स्वयं के डेटा प्रकार और त्रुटि व्यवहार जोड़ते हैं। किसी मानक का नामकरण तभी उपयोगी होता है जब देखे गए पार्सर अनुबंध को प्रत्येक JSON कार्यान्वयन के बारे में मान्यताओं से अलग रखा जाता है।
ToolAcre के लिए भंडार साक्ष्य सामान्य मानक इतिहास की तुलना में ठोस और संकीर्ण है। फ़ॉर्मेटर मान उत्पन्न करने के लिए `JSON.parse` और उन्हें उत्सर्जित करने के लिए `JSON.stringify` का उपयोग करता है; पार्स विफलता के बाद, एक स्थानीय स्कैनर एक स्थिर निदान स्थिति और कारण प्रदान करता है।
json.org और JSON का प्रारंभिक विवरण
json.org ने JSON को JavaScript के ऑब्जेक्ट-लिटरल सिंटैक्स से प्राप्त एक कॉम्पैक्ट नोटेशन के रूप में प्रस्तुत किया और एक छोटे व्याकरण के साथ इसकी मूल संरचनाओं को प्रलेखित किया। उस प्रारंभिक विवरण ने डेवलपर्स को ऑब्जेक्ट, एरेज़, स्ट्रिंग्स, नंबर, बूलियन और नल के लिए एक साझा नाम और संदर्भ देने में मदद की। यहां ऐतिहासिक साक्ष्यों का हवाला दिए बिना यह दावा करने की तुलना में पेज का प्रारंभिक सार्वजनिक स्पष्टीकरण के रूप में वर्णन करना अधिक सुरक्षित है कि एक पेज या व्यक्ति ने अकेले ही एक प्रारूप की खोज की या उसे अपनाने की स्थापना की।
वर्तमान रिपॉजिटरी स्रोतों में json.org का अभिलेखीय इतिहास, ब्राउज़र उपयोग या समिति चर्चाएं शामिल नहीं हैं। वे दिखाते हैं कि यह एप्लिकेशन आज JSON को कैसे पार्स और निदान करता है। तदनुसार, इस लेख में ऐतिहासिक कथन दिनांकित मानक दस्तावेज़ों के करीब रहते हैं और उन उद्देश्यों या बाज़ार प्रभावों को जिम्मेदार ठहराने से बचते हैं जिन्हें वे स्थानीय फ़ाइलें साबित नहीं कर सकती हैं।
RFC 4627 2006 में - पहला IETF विवरण, एप्लिकेशन/json मीडिया प्रकार और नियम कि टेक्स्ट को एक ऑब्जेक्ट या ऐरे होना चाहिए
RFC 4627, 2006 में प्रकाशित, इंटरनेट इंटरचेंज के लिए JSON का वर्णन करता है और `application/json` मीडिया प्रकार पंजीकृत करता है। इसकी JSON पाठ की परिभाषा के लिए शीर्ष स्तर पर एक ऑब्जेक्ट या सरणी की आवश्यकता होती है, भले ही स्ट्रिंग, संख्याएं और अक्षर उन कंटेनरों के अंदर मान के रूप में मौजूद हों। वह प्रतिबंध एक उपयोगी ऐतिहासिक अंतर है क्योंकि केवल `"ready"` वाला दस्तावेज़ RFC 4627 की JSON-पाठ परिभाषा से बाहर रहते हुए बाद के फॉर्मूलेशन में एक वैध मान हो सकता है।
दस्तावेज़ में उस समय उपलब्ध कार्यान्वयन के संदर्भ में एन्कोडिंग और सुरक्षा चिंताओं पर भी चर्चा की गई। इसे इस रिपॉजिटरी के चेंजलॉग के रूप में नहीं पढ़ा जाना चाहिए: ToolAcre में RFC 4627 संगतता मोड शामिल नहीं है, और इसका पार्सर पथ होस्ट JavaScript इंजन को मूल्य निर्माण का प्रतिनिधित्व करता है।
ECMA-404 2013 में - एक्मा का न्यूनतम सिंटैक्स-केवल मानक, और क्यों दो संगठनों ने एक प्रारूप का वर्णन किया
ECMA-404, पहली बार 2013 में प्रकाशित, JSON सिंटैक्स को जानबूझकर संक्षिप्त रूप में निर्दिष्ट करता है। इसका फोकस प्रत्येक नेटवर्क उपयोग के लिए पूर्ण इंटरचेंज प्रोफ़ाइल के बजाय वैध JSON टेक्स्ट का व्याकरण है। वह दायरा यह समझाने में मदद करता है कि क्यों ECMA-404 और IETF दस्तावेज़ समान मूल नोटेशन का वर्णन कर सकते हैं, जबकि आसपास के अंतर-संचालनीयता मार्गदर्शन में भिन्नता है जिस पर वे जोर देते हैं। दो मानक निकायों का अस्तित्व सामान्य उपयोग में दो असंगत प्रारूपों का संकेत नहीं देता है।
संगठनों ने विशेष प्रकाशन पथ क्यों चुना, इसके दावों के लिए इस कोडबेस से परे दस्तावेजी स्रोतों की आवश्यकता होती है, इसलिए यह लेख मानकों की तारीखों से समिति के उद्देश्यों का अनुमान नहीं लगाता है। प्रासंगिक व्यावहारिक बिंदु यह है कि RFC 8259 और ECMA-404 का उद्देश्य सिंटैक्स पर संरेखित करना है, जबकि RFC 8259 उन अनुशंसाओं की आपूर्ति करता है जो इंटरऑपरेबल एक्सचेंज के लिए मायने रखती हैं।
RFC 7159 और RFC 8259
RFC 7159 ने 2014 में RFC 4627 को प्रतिस्थापित कर दिया और ऑब्जेक्ट-या-सरणी-केवल शीर्ष-स्तरीय नियम को हटाते हुए, JSON पाठ की परिभाषा को किसी भी क्रमबद्ध मान तक विस्तृत कर दिया। RFC 8259 ने 2017 में RFC 7159 को प्रतिस्थापित कर दिया और JSON के लिए आमतौर पर उद्धृत IETF संदर्भ बना रहता है। एक बंद पारिस्थितिकी तंत्र के बाहर सिस्टम के बीच आदान-प्रदान के लिए JSON के लिए UTF-8 की आवश्यकता होती है और केवल व्याकरण का दिखावा करने के बजाय संख्याओं, डुप्लिकेट नामों, यूनिकोड और बाइट-ऑर्डर चिह्नों के बारे में अंतर-संचालनीयता सावधानियां दर्ज करना हर जगह समान परिणाम की गारंटी देता है।
शीर्ष-स्तरीय `true` ToolAcre में आधुनिक रूट-वैल्यू नियम का पालन करने का एक संक्षिप्त तरीका है क्योंकि `JSON.parse` इसे स्वीकार करता है। वह परिणाम इस कार्यान्वयन के व्यवहार को प्रदर्शित करता है; जब प्रत्येक ब्राउज़र, सर्वर या API ने व्यापक परिभाषा को अपनाया तो इसका पुनर्निर्माण नहीं हुआ।
कामकाजी डेवलपर्स के लिए क्या बदलाव आया?
कामकाजी डेवलपर्स के लिए, सबसे स्पष्ट विनिर्देश परिवर्तन मूल में किसी भी JSON मान की आधुनिक स्वीकृति और इंटरऑपरेबल एन्कोडिंग के लिए मजबूत मार्गदर्शन हैं। कम दिखाई देने वाला सबक यह है कि वैध वाक्यविन्यास अभी भी कार्यान्वयन विकल्प छोड़ता है। डुप्लिकेट ऑब्जेक्ट नाम ध्वस्त हो सकते हैं, सदस्य क्रम एक अर्थ संबंधी अनुबंध नहीं है, बहुत बड़ी संख्याएँ सटीकता खो सकती हैं, और असामान्य यूनिकोड अनुक्रम पुस्तकालयों के माध्यम से अलग-अलग यात्रा कर सकते हैं। इसलिए एक मानक-अनुपालक दस्तावेज़ एक एप्लिकेशन स्कीमा से अतिरिक्त बाधाओं का पात्र हो सकता है।
इस फ़ॉर्मेटर में, डुप्लिकेट नाम और नंबर टोकन पहले `JSON.parse` से गुजरते हैं, इसलिए बाद में फ़ॉर्मेटिंग मूल शाब्दिक दस्तावेज़ के बजाय परिणामी JavaScript मान को दर्शाता है। विफलता के बाद स्कैनर निदान में योगदान देता है; यह डुप्लिकेट सदस्यों या मनमानी-सटीक संख्याओं को संरक्षित नहीं करता है। वे भंडार-समर्थित अवलोकन हैं।
इसमें क्या शामिल नहीं है
इसमें JSON के शीर्ष पर स्तरित विनिर्देश शामिल नहीं हैं। JSON स्कीमा दस्तावेज़ आकार और मूल्यों पर बाधाओं का वर्णन करती है; JSON पॉइंटर दस्तावेज़ के भीतर स्थानों को संबोधित करता है; JSON पैच परिवर्तनों का प्रतिनिधित्व करता है। वे मूल व्याकरण से विभिन्न समस्याओं का समाधान करते हैं और उन्हें JSON के बाद के संस्करणों के रूप में नहीं माना जाना चाहिए। JSONC, JSON5 और इसी तरह के संलेखन प्रारूप भी स्वीकृत वाक्यविन्यास का विस्तार या परिवर्तन करते हैं और चुपचाप सख्त सत्यापन में तब्दील होने के बजाय अपने स्वयं के पार्सर की आवश्यकता होती है।
यह लेख JSON को अपनाने, ब्राउज़र समर्थन या XML के साथ प्रतिस्पर्धा के व्यापक सामाजिक इतिहास से भी बचता है क्योंकि सूचीबद्ध रिपॉजिटरी स्रोत उस कथा की पुष्टि नहीं कर सकते हैं। इस अंतर को भरने के लिए किसी बाहरी उद्धरण का आविष्कार नहीं किया गया है।
टेकअवे: RFC 8259 उद्धरण का संदर्भ है
RFC 8259 वर्तमान JSON सिंटैक्स और इंटरऑपरेबिलिटी मार्गदर्शन के लिए व्यावहारिक IETF संदर्भ है, जिसमें ECMA-404 संरेखित एक्मा सिंटैक्स मानक प्रदान करता है। RFC 4627 और RFC 7159 यह समझने के लिए उपयोगी हैं कि प्रकाशित परिभाषा कैसे बदल गई, खासकर शीर्ष स्तर पर। प्राधिकरण के लिए अस्पष्ट अपील के रूप में "JSON विशिष्टता" का उपयोग करने के बजाय सटीक दावे का समर्थन करने वाले दस्तावेज़ का हवाला दें, और किसी विशेष पार्सर में देखे गए कार्यान्वयन व्यवहार से मानक नियमों को अलग करें।
ToolAcre के लिए, बचाव योग्य कथन यह है कि रिपॉजिटरी JavaScript के JSON पार्सर और सीरिएलाइज़र का उपयोग करता है और विफलताओं के बाद निदान के लिए एक सख्त स्थानीय स्कैनर जोड़ता है। शीर्ष-स्तरीय मानों, विकृत विराम चिह्नों और संख्या प्रबंधन के परीक्षण उस मार्ग का वर्णन करते हैं; वे ऐतिहासिक स्रोत नहीं हैं।