हर सदस्य या मद अलग पंक्ति में, प्रति स्तर 2 स्पेस का इंडेंट।
स्ट्रिंग और संख्याएँ जैसी लिखी हैं वैसी ही कॉपी होती हैं; एस्केप और संख्या के प्रारूप नहीं बदलते।
JSON फ़ॉर्मैटर और वैलिडेटर के बारे में
यह वैलिडेटर RFC 8259 व्याकरण से पाठ पढ़ता है: ऑब्जेक्ट, ऐरे, दोहरे उद्धरण वाली स्ट्रिंग, संख्या, true, false और null; इनके अलावा कुछ नहीं। सफल होने पर उन्हीं मानों को प्रति पंक्ति एक सदस्य और हर स्तर पर 2 स्पेस, 4 स्पेस या टैब के साथ लिखता है, या स्ट्रिंग के बाहर का खाली स्थान हटाकर मिनिफ़ाई करता है। असफल होने पर पंक्ति, कॉलम और उस जगह अपेक्षित तत्व बताता है।
डेवलपर इससे API उत्तर और कॉन्फ़िग फ़ाइलें पढ़ते हैं तथा भेजे जाने वाले डेटा का आकार घटाते हैं। डिफ़ॉल्ट ऑब्जेक्ट में 6 कुंजियाँ, 10 मान और नेस्टिंग के 2 स्तर हैं। 2 स्पेस से फ़ॉर्मैट करने पर आकार 127 से 170 बाइट होता है।
स्ट्रिंग और संख्याएँ जैसी लिखी हैं वैसी ही कॉपी होती हैं। इससे एस्केप क्रम और 12345678901234567890123 जैसे बड़े पूर्णांक के हर अंक सुरक्षित रहते हैं।
JSON को फ़ॉर्मैट और जाँचने का तरीका
JSON मान्य होने के लिए RFC 8259 का व्याकरण मानना चाहिए: ब्रेस में ऑब्जेक्ट, ब्रैकेट में ऐरे, दोहरे उद्धरण वाली स्ट्रिंग और कुंजियाँ, संख्याएँ, true, false तथा null। कॉमा केवल मदों के बीच होता है। फ़ॉर्मैट करने से पढ़ना आसान होता है; डेटा का अर्थ नहीं बदलना चाहिए।
यह टूल पहले व्याकरण जाँचता है। सही पाठ को 2 स्पेस, 4 स्पेस या टैब से पढ़ने योग्य बना सकते हैं। मिनिफ़ाई विकल्प स्ट्रिंग के बाहर का खाली स्थान हटाता है। वैकल्पिक कुंजी-छँटाई केवल ऑब्जेक्ट में होती है; ऐरे की मदें उसी क्रम में रहती हैं।
छोटे उदाहरण से आकार जाँचें
यह दस्तावेज़ 25 UTF-8 बाइट का है:
{"id":7,"tags":["a","b"]}
2 स्पेस से फ़ॉर्मैट करने पर 47 बाइट बनते हैं:
{
"id": 7,
"tags": [
"a",
"b"
]
}
4 स्पेस से वही डेटा 61 बाइट है। भेजते समय छोटा रूप उपयोगी हो सकता है; पढ़ते या संस्करणों का अंतर देखते समय इंडेंट वाला रूप। स्ट्रिंग के अंदर के स्पेस और पंक्ति-विराम के एस्केप हटाना मिनिफ़ाई नहीं है, बल्कि डेटा बदलना है।
आम गलतियाँ और त्रुटि का स्थान
[1, 2,] का अंतिम कॉमा, {'a':1} के एकहरे उद्धरण और {a:1} की बिना उद्धरण वाली कुंजी अमान्य हैं। // या /* */ टिप्पणियाँ JSONC या JSON5 में हो सकती हैं, मानक JSON में नहीं। NaN, Infinity, 0x10, +1, 007 और .5 भी मान्य JSON संख्या नहीं हैं; दशमलव के लिए 0.5 लिखें।
स्ट्रिंग में वास्तविक टैब या नई पंक्ति के बजाय \t या \n लिखें। दो ऑब्जेक्ट साथ पेस्ट करना एक दस्तावेज़ नहीं बनाता; उन्हें ऐरे में रखें। त्रुटि का स्थान वह है जहाँ पार्सर को समस्या पता चली। असली गलती उससे पहले हो सकती है।
{
"a": 1
"b": 2
}
यहाँ दूसरी पंक्ति के अंत में कॉमा छूटा है, पर त्रुटि तीसरी पंक्ति के कॉलम 3 पर "b" से पता चलती है। बताए स्थान से पहले का अक्षर, फिर पिछला बंद न हुआ उद्धरण या ब्रैकेट देखें।
कुंजियाँ, मान और नेस्टिंग की गिनती
उदाहरण
कुंजियाँ
गहराई
मान
परिणाम बाइट
डिफ़ॉल्ट
6
2
10
170
मिनिफ़ाई डिफ़ॉल्ट
6
2
10
127
शीर्ष स्तर की संख्या
0
0
1
2
दोहराई कुंजियाँ
5
2
6
64
बड़ा सटीक पूर्णांक
1
1
2
42
डिफ़ॉल्ट 127-बाइट ऑब्जेक्ट {"name":"CalcOpenly",…,"license":null} है। 2 स्पेस से परिणाम 170 बाइट होता है। उसके 10 मानों में 1 ऑब्जेक्ट, 1 ऐरे, 5 स्ट्रिंग, 1 संख्या, 1 बूलियन और 1 null हैं। छह कुंजियाँ अलग गिनी जाती हैं। अकेला 42 भी पूरा मान्य दस्तावेज़ है; उसकी नेस्टिंग 0 है। सपाट ऑब्जेक्ट की गहराई 1 होती है।
बड़े पूर्णांक और दोहराई कुंजियाँ
JSON का व्याकरण अंकों की अधिकतम गिनती तय नहीं करता। लेकिन अनेक पार्सर IEEE 754 डबल लेते हैं, जिसमें हर पूर्णांक केवल 2^53 − 1 = 9,007,199,254,740,991 तक सटीक है। JavaScript का JSON.parse, 12345678901234567890123 को 1.2345678901234568e+22 बना देता है। दूसरे सिस्टम को बड़े ID भेजते समय स्ट्रिंग लेना अधिक भरोसेमंद है।
यहाँ संख्या का टोकन वैसा ही कॉपी होता है। इसलिए तालिका का 30-अंक वाला id सुरक्षित रहता है। स्ट्रिंग के \u00e9 जैसे एस्केप भी é में बदले बिना वैसे ही लिखे जाते हैं।
दोहराव वाला उदाहरण {"a":1,"a":2,"nested":{"a":3,"a":4}} चारों a सदस्य रखता है और चेतावनी देता है। RFC 8259 नाम अद्वितीय रखने को कहता है। JavaScript और अनेक दूसरे पार्सर केवल अंतिम मान रखते हैं; कुछ पहला रखते हैं या अस्वीकार करते हैं। फ़ॉर्मैट करने से इस असंगति का समाधान अपने आप नहीं होता।
सीमा और निजी डेटा
पृष्ठ अधिकतम 200,000 अक्षर लेता है। ऑब्जेक्ट ही आवश्यक नहीं; शीर्ष स्तर पर संख्या, स्ट्रिंग, बूलियन या null भी हो सकता है। छँटाई Unicode कोड पॉइंट के क्रम में है और मूल संख्याओं का लिखा प्रारूप सुरक्षित रहता है। पृष्ठ का पता और डिवाइस का इतिहास पाठ रख सकते हैं, इसलिए API उत्तर से टोकन और व्यक्तिगत डेटा पहले हटा दें।
ठीक वही बाइट आवश्यक हों तो हैश कैलकुलेटर से जाँचें। इंडेंट, कुंजी का क्रम और अंतिम नई पंक्ति बदलने पर डाइजेस्ट भी बदलता है।
जाँच का स्रोत: उदाहरण जाँच: RFC 8259 §2 में कोई भी मान शीर्ष स्तर हो सकता है
खाली कंटेनर एक पंक्ति में रहते हैं
JSON
{"a":[],"b":{}}
आउटपुट
पढ़ने योग्य बनाएँ
इंडेंट के लिए
4 स्पेस
फ़ॉर्मैट किया JSON
{
"a": [],
"b": {}
}
कुंजियाँ
2
जाँच का स्रोत: स्वतंत्र गणना
सवाल
JSON में आम सिंटैक्स त्रुटियाँ कौन सी हैं?
अंतिम मद के बाद कॉमा, एकहरे उद्धरण और बिना उद्धरण की कुंजियाँ आम कारण हैं। JSON में हर स्ट्रिंग और कुंजी के लिए दोहरे उद्धरण चाहिए और अंतिम मद के बाद कॉमा नहीं हो सकता। RFC 8259 में टिप्पणियाँ, NaN, Infinity और हेक्स संख्याएँ भी अमान्य हैं, भले JavaScript अपने कोड में कुछ को स्वीकार करे। यहाँ त्रुटि का पंक्ति और कॉलम मिलता है, जिससे गलत जगह तक सीधे पहुँचा जा सके।
क्या JSON में टिप्पणियाँ लिख सकते हैं?
नहीं। RFC 8259 और ECMA-404 में टिप्पणी का सिंटैक्स नहीं है, इसलिए मानक पार्सर // और /* */ को अस्वीकार करता है। Douglas Crockford ने शुरुआती प्रारूप से टिप्पणियाँ हटा दी थीं, क्योंकि लोग उनमें पार्सर निर्देश रखने लगे थे। टिप्पणियाँ चाहने वाली कॉन्फ़िग फ़ाइलें JSON5 या JSONC लेती हैं; VS Code की settings.json इसका उदाहरण है। यह वैलिडेटर ऐसी फ़ाइल को अमान्य JSON बताता है।
JSON की संख्या कितनी बड़ी हो सकती है?
RFC 8259 कोई सीमा तय नहीं करता, लेकिन IEEE 754 डबल लेने वाले अनेक पार्सर के कारण केवल −(2^53 − 1) से 2^53 − 1 = 9,007,199,254,740,991 तक के पूर्णांक विश्वसनीय रूप से साझा किए जा सकते हैं। यह टूल हर अंक वैसा ही कॉपी करता है, पर JavaScript का JSON.parse, 12345678901234567890123 को 1.2345678901234568e22 बना देता है। इसलिए बड़े ID को स्ट्रिंग में भेजें।
क्या JSON में एक कुंजी दोबारा आ सकती है?
RFC 8259 कहता है कि ऑब्जेक्ट के नाम अद्वितीय होने चाहिए (SHOULD)। इसलिए दोहराव व्याकरण में स्वीकार है, पर भरोसेमंद नहीं। JavaScript का JSON.parse और Python का json केवल अंतिम मान रखते हैं; दूसरे पार्सर पहला मान रख सकते हैं या दस्तावेज़ अस्वीकार कर सकते हैं। यह वैलिडेटर दोहराव स्वीकार करके ऑब्जेक्ट की पंक्ति और कॉलम के साथ चेतावनी देता है, ताकि दूसरी प्रणाली के पढ़ने से पहले उसे ठीक कर सकें।
JSON को पढ़ने योग्य बनाने और मिनिफ़ाई करने में क्या अंतर है?
पढ़ने योग्य रूप में हर सदस्य अलग पंक्ति पर और हर स्तर पर 2 या 4 स्पेस अथवा टैब होता है; इससे डेटा और बदलाव पढ़ना आसान होता है। मिनिफ़ाई करने से स्ट्रिंग के बाहर के सभी स्पेस और पंक्ति-विराम हटते हैं। डेटा दोनों में समान रहता है। डिफ़ॉल्ट उदाहरण पढ़ने योग्य बनाने पर 127 से 170 बाइट होता है; मिनिफ़ाई उदाहरण 45 से 33 बाइट होता है।
इस कैलकुलेटर में स्वतंत्र स्रोतों के उत्तरों वाले 6 हल किए गए उदाहरण शामिल हैं। ये परीक्षण समूह में चलते हैं और आप इन्हें यहाँ भी चला सकते हैं।
यह कैलकुलेटर अपनी वेबसाइट पर लगाएँ
जहाँ कैलकुलेटर दिखाना है, वहाँ इसे पेस्ट करें। इसका उपयोग मुफ़्त है, यहाँ किए गए सुधार इसमें अपने आप पहुँच जाते हैं, और उसके नीचे की श्रेय पंक्ति मूल पेज का लिंक देती है, जिससे आपके पाठक पूरा संस्करण देख सकते हैं।