डेवलपर टूल · JSON फ़ॉर्मेटर और सत्यापनकर्ता
क्या JSON में मुख्य क्रम मायने रखता है? आदेश, समानता और RFC 8785
· पेजभूमि
json मानकों मान्यकरण
JSON विनिर्देश ऑब्जेक्ट को अव्यवस्थित कहता है, लेकिन वास्तविक पार्सर और सीरियलाइज़र आमतौर पर ऑर्डर को संरक्षित करते हैं, और हस्ताक्षर योजनाएं इस पर निर्भर करती हैं। यह पोस्ट इस बात को सुलझाती है कि विशेष विवरण क्या कहता है, कार्यान्वयन क्या करता है, और कैसे विहितीकरण तनाव को हल करता है।
वही डेटा, अलग-अलग बाइट्स
`{"city":"Oslo","temp":4}` और `{"temp":4,"city":"Oslo"}` में समान दो नाम और मान हैं, फिर भी उनके स्रोत बाइट्स भिन्न हैं। इंडेंटेशन किसी भी पार्स किए गए मान को बदले बिना कई और पाठ्य अंतर जोड़ सकता है। इसीलिए "समान JSON" को एक तुलना नियम की आवश्यकता है: क्या आप पाठ, पार्स की गई वस्तुओं, या किसी अन्य प्रोटोकॉल द्वारा परिभाषित विहित प्रतिनिधित्व की तुलना कर रहे हैं?
ToolAcre दोनों दस्तावेज़ों को एक ही इंडेंटेशन के साथ फ़ॉर्मेट करके व्हाइटस्पेस शोर को दूर कर सकता है। जब उस विकल्प का चयन किया जाता है तो यह ऑब्जेक्ट कुंजियों को पुनरावर्ती रूप से क्रमबद्ध भी कर सकता है। सॉर्टिंग सदस्य क्रम को जानबूझकर बदलता है लेकिन कभी भी सरणी तत्वों को स्थानांतरित नहीं करता है, क्योंकि सरणी स्थिति डेटा का प्रतिनिधित्व करती है। न तो सामान्य स्वरूपण और न ही यह वैकल्पिक प्रकार RFC 8785 विहित JSON उत्पन्न करता है, इसलिए आउटपुट को निर्दिष्ट हस्ताक्षर प्रारूप के लिए प्रतिस्थापित नहीं किया जाना चाहिए।
RFC 8259 क्या कहता है - एक ऑब्जेक्ट name/value जोड़ियों का एक अव्यवस्थित संग्रह है, और कार्यान्वयन ऑर्डर को उजागर कर सकता है या नहीं
RFC 8259 किसी ऑब्जेक्ट को name/value जोड़ियों के अव्यवस्थित संग्रह के रूप में वर्णित करता है। इसलिए, सॉफ़्टवेयर जो सदस्य क्रम को एक सामान्य JSON ऑब्जेक्ट के अर्थ के रूप में मानता है, उस अमूर्त मॉडल के बाहर के व्यवहार पर निर्भर करता है। सारणियाँ स्पष्ट रूप से क्रमबद्ध हैं, इसलिए `["draft","final"]` `["final","draft"]` के साथ विनिमेय नहीं है। ऑब्जेक्ट ऑर्डर और ऐरे ऑर्डर को कभी भी एक ही नियम द्वारा सामान्यीकृत नहीं किया जाना चाहिए।
RFC यह भी नोट करता है कि लाइब्रेरीज़ इस बात में भिन्न होती हैं कि वे कॉल करने वालों के सामने सदस्य ऑर्डर को उजागर करती हैं या नहीं। वह चेतावनी पोर्टेबल डिज़ाइन के लिए पर्याप्त है: एक ऑब्जेक्ट सदस्य को दूसरे से पहले रखकर प्राथमिकता या अनुक्रम को एन्कोड न करें। यदि अनुक्रम मायने रखता है, तो इसे किसी सरणी या स्पष्ट फ़ील्ड के साथ प्रस्तुत करें। स्थिर क्रम दिखाने वाला फ़ॉर्मेटर मनुष्यों के लिए सुविधाजनक है, लेकिन यह स्थिति को वस्तु की मानक-स्तरीय संपत्ति में नहीं बदलता है।
यह फ़ॉर्मेटर वास्तव में क्या करता है
सॉर्टिंग अक्षम होने पर, ToolAcre दस्तावेज़ को पार्स करता है और परिणामी JavaScript मान को क्रमबद्ध करता है। आउटपुट बाइट के लिए मूल टोकन स्ट्रीम बाइट को संरक्षित करने के बजाय JavaScript संपत्ति-गणना व्यवहार का पालन करता है। अधिकांश सामान्य स्ट्रिंग कुंजियाँ परिचित क्रम में दिखाई देती हैं, जबकि पूर्णांक-सूचकांक-जैसे नाम अन्य नामों से पहले निकाले जा सकते हैं। पुनर्क्रमीकरण के दौरान संख्या वर्तनी और भागने के विकल्पों को भी सामान्यीकृत किया जा सकता है।
सॉर्टिंग सक्षम होने पर, फ़ॉर्मेटर नए ऑब्जेक्ट बनाता है जिनकी अपनी कुंजियाँ प्रत्येक नेस्टेड ऑब्जेक्ट पर वर्णानुक्रम में होती हैं। `{"z":{"b":1,"a":2},"items":[{"d":4,"c":3},"x"]}` के लिए, ऑब्जेक्ट नाम `items`, `z` हो जाते हैं; नेस्टेड ऑब्जेक्ट नाम भी क्रमबद्ध हैं; और सरणी में अभी भी `"x"` से पहले का ऑब्जेक्ट मौजूद है। किसी सरणी के अंदर वस्तुओं को क्रमबद्ध करने का मतलब सरणी को ही क्रमबद्ध करना नहीं है।
जब बाइट क्रम मायने रखता है
जब भी कोई प्रक्रिया अमूर्त मान के बजाय सटीक बाइट्स का उपभोग करती है तो पाठ्य क्रम मायने रखता है। जब सदस्य चलते हैं या रिक्त स्थान बदलता है तो फ़ाइल हैश, कैश कुंजी, डिजिटल हस्ताक्षर या लाइन-आधारित अंतर बदल जाता है। यह अव्यवस्थित वस्तु मॉडल का खंडन नहीं करता है; इसका मतलब है कि आसपास की प्रक्रिया ने अपने इनपुट के हिस्से के रूप में एक बाइट प्रतिनिधित्व को चुना है। फिर प्रतिनिधित्व नियम स्पष्ट और साझा होने चाहिए।
नियमित समीक्षाओं के लिए, लगातार इंडेंटेशन और वैकल्पिक वर्णमाला क्रम से परिवर्तनों को देखना आसान हो सकता है। क्रिप्टोग्राफ़िक या प्रोटोकॉल कार्य के लिए, "स्थिर दिखता है" कोई अनुबंध नहीं है। निर्माता और सत्यापनकर्ता को हैशिंग या हस्ताक्षर करने से पहले अपने प्रोटोकॉल के लिए आवश्यक सटीक कैनोनिकलाइज़ेशन एल्गोरिदम का उपयोग करना चाहिए। यदि किCAल्गोरिदम का नाम नहीं है, तो यह न मानें कि ToolAcre का आउटपुट सभी संस्करणों, रनटाइम या एज-केस मानों में किसी अन्य सीरियलाइज़र से मेल खाएगा।
कुंजी सॉर्टिंग क्यों नहीं है RFC 8785
RFC 8785 संगत डेटा से दोहराए जाने योग्य बाइट्स के उत्पादन के लिए JSON कैनोनिकलाइज़ेशन योजना को परिभाषित करता है। इसका कार्य कुंजियों को वर्णानुक्रम में रखने से कहीं अधिक व्यापक है। यह स्ट्रिंग्स और संख्याओं के लिए सटीक क्रमांकन व्यवहार के साथ-साथ नियतात्मक संपत्ति सॉर्टिंग निर्दिष्ट करता है और इनपुट मॉडल पर बाधाएं लगाता है। सुंदर इंडेंटेशन कैनोनिकल आउटपुट का हिस्सा नहीं है, और स्थानीय-जागरूक सॉर्टिंग स्वीकार्य अनुमान नहीं है।
ToolAcre कोई RFC 8785 दावा नहीं करता। इसका सॉर्ट विकल्प `JSON.parse` और `JSON.stringify` पर आधारित एक पठनीयता सुविधा है; यह I-JSON पूर्व शर्तों को मान्य नहीं करता है या RFC के क्रमांकन नियमों को प्रतिस्थापित नहीं करता है। `1e-7` जैसे मान, गैर-ASCII वर्ण वाली कुंजी या एस्केप्ड स्ट्रिंग एक कैज़ुअल सॉर्ट किए गए फ़ॉर्मेटर और एक अनुरूप कैनोनिकलाइज़र के बीच अंतर प्रकट कर सकती है। जब JCS की आवश्यकता हो तो परीक्षण किए गए JCS कार्यान्वयन का उपयोग करें।
व्यावहारिक उदाहरण: दो दस्तावेज़ों की निष्पक्षता से तुलना करना
`{"meta":{"rev":2,"owner":"Mira"},"steps":["cut","pack"]}` की तुलना `{"steps":["cut","pack"],"meta":{"owner":"Mira","rev":2}}` से करें। दो रिक्त स्थान और सॉर्टिंग अक्षम दोनों के साथ प्रारूपित करें: व्हाइटस्पेस सुसंगत हो जाता है, लेकिन रूट और नेस्टेड सदस्य आदेश अभी भी भिन्न हो सकते हैं। कच्चे पाठ को समान घोषित करने के बजाय मूल्य-स्तरीय तुल्यता स्थापित करने के लिए दोनों को पार्स करें और उनके इच्छित फ़ील्ड की तुलना करें।
पुनरावर्ती कुंजी सॉर्टिंग चालू करें और दोनों उदाहरण समान ऑब्जेक्ट क्रम के साथ प्रस्तुत होते हैं, जबकि `steps` `cut` रहता है, फिर `pack`। यह मानव अंतर के लिए उपयोगी है, लेकिन यह अभी भी ToolAcre का सामान्यीकरण है, न कि RFC 8785 प्रमाण। यदि दूसरी सरणी `["pack","cut"]` थी, तो सॉर्टिंग कुंजियाँ उस अंतर को सही ढंग से दृश्यमान छोड़ देंगी क्योंकि सरणी बदलने से दर्शाया गया अनुक्रम बदल जाएगा।
इसमें क्या शामिल नहीं है
कुंजी सॉर्टिंग प्रत्येक एप्लिकेशन के लिए गहरी समानता को परिभाषित नहीं करती है। डुप्लिकेट नाम `JSON.parse` द्वारा स्वीकार किए जाते हैं, जो अंतिम मान रखता है, इसलिए फ़ॉर्मेटिंग सबूत मिटा सकता है कि एक स्रोत में दोहराव शामिल है। बड़े पूर्णांक पहले से ही JavaScript मान में सटीकता खो चुके हैं। एक डोमेन चयनित सरणियों को सेट के रूप में भी मान सकता है, लेकिन ToolAcre उस नियम का अनुमान नहीं लगा सकता है और इसलिए कभी भी सरणियों को पुन: व्यवस्थित नहीं करता है।
फ़ॉर्मेटर स्कीमा की तुलना नहीं करता है, डिफ़ॉल्ट लागू नहीं करता है, यूनिकोड को सामान्य नहीं करता है या यह तय नहीं करता है कि डाउनस्ट्रीम सिस्टम के लिए दो संख्या प्रतिनिधित्व स्वीकार्य हैं या नहीं। वे अलग अनुबंध हैं. प्रस्तुति शोर को कम करने के लिए फ़ॉर्मेटिंग का उपयोग करें, मूल्य समानता के लिए एक उद्देश्य-निर्मित संरचनात्मक तुलना और सटीक बाइट्स के लिए निर्दिष्ट कैनोनिकलाइज़र का उपयोग करें। उन नौकरियों को "सामान्यीकरण" शब्द के तहत मिलाने से वास्तव में तुलना की गई चीज़ों के बारे में गलत विश्वास पैदा होता है।
टेकअवे: ऑर्डर मॉडल के लिए महत्वहीन है और बाइट्स के लिए महत्वपूर्ण है
ऑब्जेक्ट सदस्य क्रम का RFC 8259 डेटा मॉडल में कोई अर्थ नहीं होता है, जबकि सरणी क्रम का अर्थ होता है। स्रोत बाइट्स अभी भी ऑर्डर और व्हाइटस्पेस दोनों को रिकॉर्ड करते हैं, इसलिए हैश, हस्ताक्षर और टेक्स्ट अंतर उन अंतरों को देखते हैं जिन्हें मूल्य-उन्मुख तुलना अनदेखा कर सकती है। टूल चुनने से पहले बताएं कि कौन सी परत मायने रखती है: पाठ्य पहचान, पार्स-मूल्य तुल्यता और प्रोटोकॉल-परिभाषित विहित पहचान तीन अलग-अलग प्रश्न हैं।
ToolAcre पहले दो वर्कफ़्लो को केवल अप्रत्यक्ष रूप से समर्थन करता है: सुसंगत स्वरूपण पाठ्य अंतर को स्पष्ट करता है, और पुनरावर्ती वर्णमाला ऑब्जेक्ट-कुंजी सॉर्टिंग मानव तुलना को शांत कर सकती है। सारणियाँ कभी क्रमबद्ध नहीं होतीं। परिणाम RFC 8785 विहित JSON नहीं है और इस पर ऐसे हस्ताक्षर नहीं किए जाने चाहिए जैसे कि यह थे। जब शाब्दिक साक्ष्य मायने रखता है तो मूल इनपुट को सुरक्षित रखें, खासकर इसलिए क्योंकि डुप्लिकेट कुंजियों को पार्स करने से केवल अंतिम मान बरकरार रहता है।