JSON तुलना करें

अंतर

JSON तुलना के बारे में

JSON तुलना (JSON diff भी कहा जाता है) दो JSON संरचनाओं के बीच अंतर पहचानती है। कच्चे टेक्स्ट diff के विपरीत, यह संरचना को समझती है।

यह टूल दो JSON ऑब्जेक्ट की गहरी, पुनरावर्ती तुलना करता है। यह नेस्टेड ऑब्जेक्ट, ऐरे, स्ट्रिंग्स, संख्याएँ और बूलियन को संभालता है।

JSON का संक्षिप्त इतिहास

JSON की जीवनी औसत प्रोग्रामिंग भाषा की तुलना में छोटी है और काफ़ी कम नाटकीय भी। यह संक्षिप्त नाम State Software, Inc. में जन्मा-एक छोटी कंपनी जिसे Douglas Crockford और Chip Morningstar ने मार्च 2001 में सह-स्थापित किया था, जिसे बाद में Ajax वेब एप्लिकेशन कहा जाएगा। पहला JSON संदेश अप्रैल 2001 में Morningstar के Bay Area स्थित गैरेज में एक कंप्यूटर से भेजा गया था। Crockford यह दावा नहीं करते कि उन्होंने JSON का आविष्कार किया-उन्होंने इसे JavaScript के ऑब्जेक्ट-लिटरल वाक्यविन्यास से अलग किया, नाम दिया और एक वेबसाइट बनाई। उन्होंने 2002 में json.org हासिल किया और वहाँ रेलरोड-डायग्राम व्याकरण पोस्ट किया। चार वर्षों तक JSON मुँह-दर-मुँह और पुस्तकालय कार्यान्वयनों की एक धीमी धारा से फैला। दिसंबर 2005 में Yahoo! ने अपनी कुछ वेब सेवाएँ JSON में पेश करनी शुरू कीं-यही वह क्षण है जिसे अधिकांश इतिहासकार JSON के मुख्यधारा में प्रवेश का संकेत मानते हैं। मानकीकरण लहरों में आया: RFC 4627 (जुलाई 2006), स्वयं Crockford द्वारा लिखी गई, सूचनात्मक स्थिति के साथ, Standards Track नहीं; ECMA-404 पहला संस्करण (अक्टूबर 2013); RFC 7159 (मार्च 2014), जिसने JSON को IETF Standards Track पर रखा और ऊपरी-स्तर के मान के ऑब्जेक्ट या एरे होने की आवश्यकता को ढीला किया। मौजूदा संस्करण हैं RFC 8259 (दिसंबर 2017), अब Internet Standard STD 90, और ECMA-404 दूसरा संस्करण (दिसंबर 2017)। दोनों व्याकरण में जानबूझकर एक-समान हैं; IETF पाठ वह सुरक्षा और अंतर-संचालन मार्गदर्शन जोड़ता है जिसे Ecma पाठ जानबूझकर छोड़ देता है।

दो एल्गोरिथमिक परिवार: पंक्ति-दर-पंक्ति diff और संरचनात्मक diff

कंप्यूटर विज्ञान 1970 के दशक से diff के बारे में सोच रहा है। Douglas McIlroy (वही McIlroy जिन्होंने Unix pipes का आविष्कार किया) और James W. Hunt ने 1970 के दशक की शुरुआत में मूल Unix diff लिखा; यह 1974 में Unix के 5वें संस्करण के हिस्से के रूप में जारी हुआ, और अंतर्निहित एल्गोरिथम जून 1976 में Bell Labs Computing Science Technical Report #41 में दस्तावेज़ीकृत किया गया। Hunt-McIlroy सबसे लंबे साझा उप-अनुक्रम की समस्या पर आधारित है-पंक्तियों का वह सबसे लंबा अनुक्रम खोजें जो दोनों इनपुट में क्रमशः प्रकट हो, और जो उस अनुक्रम में नहीं है वह या तो विलोपन है या प्रविष्टि। एक दशक बाद, Eugene W. Myers ने Algorithmica Vol 1, Issue 2 (1986) में «An O(ND) Difference Algorithm and Its Variations» प्रकाशित किया, जिसने समस्या को एक «एडिट ग्राफ़» पर सबसे छोटे-पथ खोज के रूप में पुनः परिभाषित किया-एक तेज़ Unix diff कार्यान्वयन का आधार जो अपने पूर्ववर्ती से दो से चार गुना तेज़ चला। आज, git diff LibXDiff में histogram एल्गोरिथम पर डिफ़ॉल्ट है, सामान्यतः साधारण Myers से तेज़ और अधिक पठनीय आउटपुट देता है, विशेषकर हटाए गए ब्लॉकों के आसपास। Patience diff (Bram Cohen, 2008) एक और LCS परिशोधन है जो अद्वितीय एंकर पंक्तियों को प्राथमिकता देता है। ये सभी एक ही विषय की भिन्नताएँ हैं: पंक्ति-दर-पंक्ति LCS, इनपुट को अपारदर्शी टोकनों के एक सपाट अनुक्रम के रूप में मानना। इनमें से कोई भी नहीं जानता कि JSON क्या है।

संरचनात्मक diff परिवार एक अलग दृष्टिकोण अपनाता है: दोनों इनपुट को समानांतर रूप से चलाओ, प्राथमिक मानों की सख़्त समानता से तुलना करो, ऑब्जेक्ट कुंजियों का संघ निकालो (केवल-बाएँ-मौजूद का अर्थ «हटाया गया», केवल-दाएँ-मौजूद का अर्थ «जोड़ा गया», दोनों-में-मौजूद का अर्थ पुनरावर्तन), और एरे को इंडेक्स से चलाओ। प्रत्येक स्थान पर, पुनरावर्तन। यदि कोई एरे लंबा हो, अतिरिक्त तत्व जोड़े या हटाए गए हैं। प्रकार में बदलाव (संख्या बनाम स्ट्रिंग, ऑब्जेक्ट बनाम एरे) «प्रकार बदला» प्रविष्टियाँ बनाते हैं। यह वही एल्गोरिथम है जिसे jsondiffpatch अपने आधार-मामले के रूप में कार्यान्वित करता है, और यही एल्गोरिथम यह उपकरण कार्यान्वित करता है। इसकी मज़बूती यह है कि आउटपुट सार्थक है: हर रिपोर्ट किए गए परिवर्तन का दस्तावेज़ के भीतर एक पथ है (user.address.city, items[3].price) और स्पष्ट शब्दार्थ। इसकी कमज़ोरी तीसरा चरण है-एरे की इंडेक्स से तुलना-जो किसी लंबे एरे के आरंभ के पास कोई तत्व डालते ही बकवास उगलने लगती है।

JSON diff की सबसे कठिन समस्या: एरे

मान लीजिए आपके «पहले» JSON में एरे ["alpha", "beta", "gamma", "delta"] है और «बाद» JSON में ["alpha", "new", "beta", "gamma", "delta"]। एक भोला, इंडेक्स-आधारित diff चार परिवर्तन रिपोर्ट करेगा: इंडेक्स 1 «beta» से «new» बदल गया; इंडेक्स 2 «gamma» से «beta» बदल गया; इंडेक्स 3 «delta» से «gamma» बदल गया; इंडेक्स 4 ने «delta» जोड़ा। एक इंसान इसे देखकर कहेगा कि एक ही परिवर्तन है: इंडेक्स 1 पर एक अकेली प्रविष्टि। यह वही LCS समस्या है जिसे पंक्ति-diff परिवार ने 1970 के दशक में हल किया था, बस JSON मानों के एरे पर लागू, टेक्स्ट पंक्तियों के एरे पर नहीं। jsondiffpatch ठीक यही करता है-दोनों एरे का LCS गणना करता है और उसके सापेक्ष प्रविष्टियाँ और विलोपन उगलता है। प्राथमिक मानों के एरे के लिए यह अच्छा काम करता है। ऑब्जेक्टों के एरे के लिए नहीं: [{id: 1, name: "Alice"}] बनाम [{id: 1, name: "Alicia"}] में संदर्भ-समानता के अर्थ में कोई साझा उप-अनुक्रम नहीं है, इसलिए भोला LCS रिपोर्ट करेगा कि «पूरा बायाँ तत्व हटाओ, पूरा दायाँ तत्व जोड़ो», जबकि सच्चाई यह है कि एक तत्व का एक फ़ील्ड बदला। jsondiffpatch का समाधान है objectHash कॉलबैक: कॉल करने वाला एक फ़ंक्शन प्रदान करता है जो प्रत्येक ऑब्जेक्ट को एक पहचान-कुंजी पर मैप करता है (आम तौर पर obj => obj.id), और diff एरे के तत्वों को संदर्भ से नहीं, पहचान से मिलाता है। यह एक कठिन सामान्य समस्या है जिसे कोई भी पूरी तरह से हल नहीं कर सका। Absolutool उपकरण, अपने ही FAQ के अनुसार, एरे की तुलना इंडेक्स से करता है-यह न LCS कार्यान्वित करता है, न objectHash। यह एक छोटे, मुफ़्त उपकरण के लिए एक जानबूझकर लिया गया दायरा है: यह ऑब्जेक्ट diff में उत्कृष्ट है और उन एरे में कमज़ोर है जहाँ तत्व डाले या पुनः-क्रमबद्ध किए गए हों।

JSON Patch (RFC 6902): diff को परिवहन प्रारूप के रूप में

RFC 6902, «JavaScript Object Notation (JSON) Patch», अप्रैल 2013 में प्रकाशित हुआ। यह मीडिया प्रकार application/json-patch+json और छह-संक्रिया वाली patch भाषा परिभाषित करता है: add, remove, replace, move, copy, test। एक patch स्वयं एक JSON दस्तावेज़ है-संक्रिया-ऑब्जेक्टों का एक एरे, प्रत्येक के पास एक op कुंजी, एक path कुंजी (लक्ष्य स्थान की ओर एक JSON Pointer) और उपयुक्त रूप से एक मान या from फ़ील्ड। संक्रियाएँ क्रम में, परमाण्विक रूप से लागू होती हैं: यदि कोई एक भी विफल हो, तो पूरा patch अस्वीकार कर दिया जाता है। पथ-वाक्यविन्यास उसी महीने प्रकाशित सहयोगी दस्तावेज़ RFC 6901, «JSON Pointer» से आता है-स्लैश से अलग संदर्भ-टोकनों का एक छोटा-सा स्ट्रिंग वाक्यविन्यास (/user/address/city का अर्थ है «user के अंदर address के अंदर कुंजी city पर मान»; /items/3 का अर्थ है «items का चौथा तत्व», ज़ीरो-इंडेक्सिंग में)। चूँकि / और ~ विशेष हैं, उन्हें क्रमशः ~1 और ~0 में एस्केप किया जाता है (इसी क्रम में-पहले ~1 को डिकोड किया जाए ताकि दोहरे-डिकोडिंग बग न हों)। JSON Patch वह सही आउटपुट प्रारूप है जब कोई JSON diff उपकरण परिणाम को किसी और मशीन को खिलाना चाहे। HTTP PATCH विधि (RFC 5789) ठीक इसी तरह के आंशिक-अद्यतन लोड के लिए डिज़ाइन की गई थी। Kubernetes अपने स्वयं के strategic-merge-patch प्रारूप के साथ-साथ RFC 6902 का भी समर्थन करता है। यह उपकरण फिलहाल JSON Patch उत्पन्न नहीं करता-यह भविष्य की एक सुविधा-दिशा है, वर्तमान की नहीं।

JSON Merge Patch (RFC 7396): आसान, हानिकारक विकल्प

RFC 7396, «JSON Merge Patch», अक्टूबर 2014 में Paul Hoffman और James Snell द्वारा प्रकाशित हुआ। यह कोई संक्रिया प्रयोग ही नहीं करता-patch दस्तावेज़ बस एक आंशिक JSON ऑब्जेक्ट है जो मूल पर ओवरले हो जाता है। patch में मौजूद कोई भी फ़ील्ड मूल में संगत फ़ील्ड को अधिलिखित कर देता है; patch में जिस फ़ील्ड को null कर दिया गया हो, वह हटा दिया जाता है; जो फ़ील्ड patch में नहीं है, वह अपरिवर्तित रहता है; एरे पूरे-के-पूरे बदले जाते हैं, कभी मिलाए नहीं जाते। Merge Patch संक्षिप्त है और हाथ से लिखना आसान। समझौता है-अभिव्यक्ति की कमी: किसी फ़ील्ड को शाब्दिक null पर सेट करने का कोई तरीक़ा नहीं (क्योंकि null का अर्थ है «हटाओ»); किसी एरे के एक ही तत्व को बदलने का कोई तरीक़ा नहीं (पूरा एरे बदल जाता है); move या copy को व्यक्त करने का कोई तरीक़ा नहीं; «मैंने इस फ़ील्ड को छुआ ही नहीं» और «मैं इसे इसके मौजूदा मान पर सेट करना चाहता हूँ» के बीच भेद करने का कोई तरीक़ा नहीं। रोज़मर्रा के अधिकांश API अद्यतनों के लिए ये सीमाएँ स्वीकार्य हैं-यही कारण है कि दोनों प्रारूपों में Merge Patch अधिक लोकप्रिय है। जिन परिदृश्यों में इनमें से कोई सीमा काटे, RFC 6902 जीतता है। Kubernetes दोनों प्रारूपों का जानबूझकर उपयोग करता है-प्रत्येक संदर्भ के लिए सही वाला चुनकर।

दृश्य diff किस तरह दिखाया जाता है

एक संरचनात्मक diff को दिखाने के लिए तीन सामान्य दृश्य परंपराएँ हैं। साथ-साथ (Side-by-side)-दो स्तंभ, बायाँ मूल, दायाँ संशोधित, संगत पंक्तियाँ संरेखित (यह उपकरण इनपुटों के लिए यही लेआउट उपयोग करता है)। इनलाइन यूनिफ़ाइड diff-एक ही स्तंभ में हटाई गई पंक्तियाँ (आम तौर पर - उपसर्ग और लाल रंग), जोड़ी गई पंक्तियाँ (+, हरा), और अपरिवर्तित संदर्भ पंक्तियाँ (कोई उपसर्ग नहीं, सादा पाठ)-यह git diff का डिफ़ॉल्ट लेआउट है। ट्री दृश्य-JSON को एक मोड़ने-योग्य ट्री के रूप में दिखाओ, बदले हुए नोड हाइलाइट, अपरिवर्तित नोड फ़ोल्ड। पारिस्थितिकी तंत्र में रंग-परंपराएँ उल्लेखनीय रूप से समान हैं: हरा = जोड़, लाल = हटाव, पीला/अंबर = बदले हुए मान, तटस्थ ग्रे = अपरिवर्तित। यह उपकरण इस परंपरा का ठीक-ठीक पालन करता है: हल्का हरा जोड़ के लिए, हल्का लाल हटाव के लिए, हल्का पीला परिवर्तन के लिए। अधिकांश उपयोगकर्ता इन रंगों को GitHub, GitLab, BitBucket, हर IDE के diff दृश्य और दर्जनों ऑनलाइन उपकरणों से पहचान लेंगे।

सामान्य उपयोग

• कोड परिवर्तन से पहले और बाद में API प्रतिक्रियाओं की तुलना करें
• कॉन्फ़िगरेशन फ़ाइलों के बीच अंतर खोजें
• उत्पन्न lockfile की समीक्षा। package-lock.json, yarn.lock, poetry.lock, Cargo.lock और terraform.tfstate सब मशीन-निर्मित JSON या JSON-संलग्न फ़ाइलें हैं जो सामान्य विकास के दौरान शोरगुलिया तरीक़े से बदलती हैं। यह समझने के लिए कि वास्तव में क्या हिला, JSON-समझदार diff टेक्स्ट diff से कहीं अधिक उपयोगी है।
• क्रमबद्धीकरण के राउंड-ट्रिप सत्यापित करना। एक डेटाबेस पंक्ति को JSON में सीरियलाइज़ करो, नेटवर्क से गुज़ारो, डी-सीरियलाइज़ करो, फिर से सीरियलाइज़ करो। क्या कुछ बदला? कस्टम सीरियलाइज़र में चुपके बग-विशेषकर तिथियों, संख्यात्मक यथार्थता और null प्रबंधन के आसपास-को diff पकड़ लेता है।
• JSON आउटपुट के लिए रिग्रेशन परीक्षण। एक ज्ञात-सही JSON आउटपुट का स्नैपशॉट लो; बाद के प्रत्येक रन में उस स्नैपशॉट से diff करो और यदि कुछ बदला हो तो परीक्षण असफल कर दो।
• schema मसौदों की तुलना। JSON Schema और OpenAPI दस्तावेज़ स्वयं JSON हैं। किसी schema के दो संस्करणों का diff ठीक-ठीक दिखाता है कि कौन-से फ़ील्ड आवश्यक/वैकल्पिक बने या जिनके प्रकार सख़्त हुए।
• डेटा माइग्रेशन की सटीकता सत्यापित करें

जानने योग्य किनारे के मामले

संख्या-यथार्थता। RFC 8259 कहता है कि JSON संख्याएँ मनमानी-यथार्थता वाली हैं और किसी संख्या में कितने अंक हो सकते हैं इसकी कोई ऊपरी सीमा तय नहीं करता। हालाँकि, JavaScript प्रत्येक संख्या को 64-बिट IEEE 754 डबल के रूप में पार्स करता है। Number.MAX_SAFE_INTEGER (2⁵³ − 1 = 9,007,199,254,740,991) से ऊपर के पूर्णांक, JavaScript-आधारित diff से राउंड-ट्रिप करते समय चुपचाप यथार्थता खो सकते हैं। यही समस्या फ़्लोटिंग-पॉइंट को भी प्रभावित करती है-प्रसिद्ध रूप से 0.1 + 0.2 IEEE 754 में ठीक 0.3 नहीं होता। सख़्त JSON अंतिम-अल्पविराम और टिप्पणियाँ भी प्रतिबंधित करता है; दोनों RFC 8259 के अनुसार सिंटैक्स त्रुटियाँ हैं। JSON5 (json5.org) एक औपचारिक महासमुच्चय है जो टिप्पणियाँ, अंतिम-अल्पविराम, एकल उद्धरण, बिना-उद्धरण कुंजियाँ, हेक्स संख्याएँ, अग्रणी/अनुगामी दशमलव बिंदु, और Infinity/NaN की अनुमति देता है। JSONC Microsoft का «कमेंट्स वाला JSON» मोड है जो VS Code की सेटिंग फ़ाइलों में उपयोग होता है। यह उपकरण JSON.parse() का उपयोग करता है, इसलिए दोनों को अस्वीकार करेगा-चिपकाने से पहले टिप्पणियाँ और अंतिम अल्पविराम हटा दें।

तिथि-स्ट्रिंग। JSON में कोई मूल तिथि-प्रकार नहीं है। तिथियाँ आम तौर पर स्ट्रिंगों के रूप में एनकोड की जाती हैं-वास्तविक मानक है ISO 8601 (और विशेष रूप से अधिकांश इंटरनेट API द्वारा प्रयुक्त RFC 3339 उपप्रोफ़ाइल): YYYY-MM-DDTHH:MM:SS[.fff]Z। एक ऐसा diff जो तिथियों को स्ट्रिंग के रूप में तुलना करे, 2024-01-01T00:00:00Z और 2024-01-01T00:00:00.000Z को भिन्न रिपोर्ट करेगा-जबकि वे एक ही क्षण को निरूपित करते हैं-क्योंकि स्ट्रिंग्स भिन्न हैं। दोहरी कुंजियाँ। RFC 8259 §4 कहता है «एक ऑब्जेक्ट के भीतर नाम SHOULD अद्वितीय हों»-SHOULD मानक रूप से MUST से कमज़ोर है। JavaScript का JSON.parse() दोहरी कुंजियाँ स्वीकार करता है और चुपचाप अंतिम वाली रख लेता है; अन्य पार्सर पहली रख सकते हैं या त्रुटि उठा सकते हैं। null बनाम अनुपस्थित। {"a": null} और {} अलग-अलग JSON मान हैं। यह उपकरण पहले को «कुंजी a का मान null है» और दूसरे को «कोई कुंजी a नहीं है» के रूप में रिपोर्ट करता है-दोनों को सही ढंग से अलग किया जाता है। JSON Merge Patch द्वारा null को विलोपन-संकेत के रूप में मानना, प्रारूप-स्तर पर ही यह स्वीकार है कि यह भेद वास्तविक और जटिल है।

2026 का पारिस्थितिकी तंत्र

ओपन-सोर्स JSON diff पर मुट्ठी भर पुस्तकालयों का प्रभुत्व है। jsondiffpatch (Benjamin Eidelman, 2012 में प्रथम प्रकाशन) JavaScript की वास्तविक पुस्तकालय है: GitHub पर ~5k सितारे, objectHash, LCS एरे, उल्टे पैच, और एक दृश्य HTML फ़ॉर्मेटर का समर्थन। json-diff (Andrey Tarantsov) मानक Node CLI उपकरण है-Python, Go और Rust में समान्तर कार्यान्वयन भी इसी नाम से मौजूद हैं। DeepDiff (Sep Dehpour) प्रमुख Python पुस्तकालय है-पुनरावर्ती diff, क्रम को नज़रअंदाज़ करने, संख्यात्मक प्रकार-परिवर्तनों को नज़रअंदाज़ करने आदि अनेक सूक्ष्म नियंत्रणों के साथ। Linux Foundation के Jackson (Java) का JsonNode diff JVM पर मानक विकल्प है। jq के पास मूल diff आदेश तो नहीं, पर = और // ऑपरेटर-परिवार सरल संरचनात्मक तुलनाएँ व्यक्त कर सकते हैं। VS Code का अंतर्निहित diff JSON को टेक्स्ट-मोड में संभालता है; JSON Tools एक्सटेंशन JSON-समझदार तुलना जोड़ता है। Diffchecker जैसे ऑनलाइन उपकरण JSON मोड पेश करते हैं जो मूलतः वही पुनरावर्ती परिक्रमा है जिसे यह उपकरण कार्यान्वित करता है-अक्सर उपरोक्त पुस्तकालयों के ऊपर ही बनी होती है।

यहाँ «केवल-ब्राउज़र» क्यों मायने रखता है

किसी सर्वर पर दो JSON पेलोडों का diff करने के लिए दोनों को अपलोड करना पड़ता है। साधारण सार्वजनिक-डेटा उदाहरणों के लिए यह हानिरहित है। पर ऐसी API प्रतिक्रियाओं के लिए जिनमें प्रमाणीकरण टोकन, ग्राहक PII, आंतरिक कर्मचारी रिकॉर्ड, कॉन्फ़िगरेशन रहस्य या अप्रकाशित उत्पाद-डेटा हों-यह हानिरहित नहीं है। सबसे ईमानदार विलोपन-नीति के बाद भी, वह अपलोड सर्वर लॉग में, संभवतः CDN कैश में, संभवतः किसी एनालिटिक्स पाइपलाइन में, संभवतः किसी बैकअप में बैठा रहता है। केवल-ब्राउज़र diff कभी प्रसारित नहीं करता-JSON आपके टैब में ही पूरी तरह पार्स और चला जाता है। आप Compare दबाते समय DevTools के Network टैब को खोलकर सत्यापित कर सकते हैं; कोई आउटबाउंड अनुरोध नहीं होगा। API प्रतिक्रियाओं की किसी आधार रेखा से तुलना, वातावरणों के बीच कॉन्फ़िगरेशन-बहाव की डिबगिंग, या आंतरिक पैकेज URL वाले lockfile में परिवर्तनों के लेखापरीक्षा के लिए-«JSON मेरे डिवाइस से बाहर नहीं जाता» वही वास्तुकला है जो वास्तविक उत्पादन-डेटा पर इस उपकरण को सुरक्षित रूप से उपयोग करने योग्य बनाती है।

अक्सर पूछे जाने वाले प्रश्न

क्या कुंजी क्रम तुलना को प्रभावित करता है?

नहीं। JSON ऑब्जेक्ट विनिर्देश के अनुसार अनऑर्डर्ड हैं, इसलिए {"a":1, "b":2} और {"b":2, "a":1} समान माने जाते हैं। केवल मान भिन्नताएँ रिपोर्ट की जाती हैं।

ऐरे की तुलना कैसे की जाती है?

ऐरे इंडेक्स के अनुसार तुलना किए जाते हैं। यदि दोनों इनपुट के बीच इंडेक्स 2 पर ऐरे भिन्न है, तो विशिष्ट इंडेक्स की रिपोर्ट की जाती है।

गहराई से नेस्टेड ऑब्जेक्ट के साथ क्या होता है?

तुलना पूरी तरह पुनरावर्ती है। किसी भी गहराई पर नेस्टेड ऑब्जेक्ट और ऐरे प्रॉपर्टी-दर-प्रॉपर्टी तुलना किए जाते हैं।

मेरे बड़े पूर्णांक की तुलना ग़लत क्यों दिख रही है?

JavaScript प्रत्येक JSON संख्या को 64-बिट IEEE 754 डबल के रूप में पार्स करता है। Number.MAX_SAFE_INTEGER (2⁵³ − 1 = 9,007,199,254,740,991) से ऊपर पूर्णांक चुपचाप यथार्थता खो सकते हैं। इसलिए 9007199254740993 वाली एक JSON फ़ाइल 9007199254740992 वाली फ़ाइल से समान दिख सकती है। यह अंतर्निहित संख्या-प्रतिनिधित्व की सीमा है, diff उपकरण की नहीं। यदि आप 64-बिट IDs (Twitter snowflake IDs, Discord IDs, बड़ी डेटाबेस कुंजियाँ) वाले डेटा का diff कर रहे हैं, तो अपने सीरियलाइज़र से उन्हें संख्याओं के बजाय स्ट्रिंगों के रूप में निकलवाएँ। फ़्लोटिंग-पॉइंट तुलना के साथ भी वही सावधानी है: प्रसिद्ध रूप से 0.1 + 0.2 IEEE 754 में ठीक 0.3 नहीं होता।

क्या मैं JSON5 या JSONC (कमेंट्स वाला JSON) तुलना कर सकता हूँ?

सीधे नहीं। यह उपकरण ब्राउज़र के अंतर्निहित JSON.parse() का उपयोग करता है, जो सख़्ती से RFC 8259 का पालन करता है-टिप्पणियाँ, अंतिम-अल्पविराम, एकल-उद्धरण स्ट्रिंग्स और बिना-उद्धरण कुंजियाँ सिंटैक्स त्रुटियाँ हैं। यदि आपका इनपुट JSON5 (json5.org) या VS Code-शैली JSONC है, तो पहले टिप्पणियाँ और अंतिम-अल्पविराम हटा दें, या jsonc-parser जैसे उपकरण से सख़्त JSON में बदलकर फिर चिपकाएँ।

क्या मेरा JSON किसी सर्वर पर भेजा जाता है?

नहीं। तुलना पूरी तरह आपके ब्राउज़र में JavaScript के द्वारा चलती है। चिपकाया गया JSON कभी नेटवर्क पार नहीं करता-Compare दबाते समय DevTools के Network टैब में सत्यापित करें, या पृष्ठ लोड हो जाने के बाद उसे ऑफ़लाइन (एयरप्लेन मोड) कर लें-फिर भी diff काम करेगा। प्रमाणीकरण टोकन वाली API प्रतिक्रियाओं, रहस्यों वाली कॉन्फ़िगरेशन फ़ाइलों, या ग्राहक PII वाले डेटाबेस एक्सपोर्ट की तुलना के लिए सुरक्षित।

संबंधित टूल