JSON फ़ाइल क्या होती है?

JSON एक सादा टेक्स्ट फ़ॉर्मेट है, जो किसी भी एडिटर में खुल जाता है। इसका इस्तेमाल प्रोग्रामों के बीच डेटा ले जाना और वेब के लिए होता है।

एक्सटेंशन .json है और पूरा नाम JavaScript Object Notation। दोनों उतना नहीं बताते जितना यह कि फ़ाइल अंदर क्या-क्या रख सकती है — और इस पन्ने का बाक़ी हिस्सा इसी के बारे में है।

यह 2001 तक पीछे जाता है। विनिर्देश RFC 8259 है।

उम्र एक व्यावहारिक वजह से काम की है: फ़ॉर्मेट जितना पुराना, उतने ज़्यादा प्रोग्रामों को उसे सीखने का वक़्त मिला है।

यह पूरा प्रकाशित है, इसलिए कोई भी इसे देखकर अंदाज़ा लगाने के बजाय दस्तावेज़ पढ़कर लागू कर सकता है। यही वजह है कि यह फ़ॉर्मेट इतने सारे प्रोग्रामों में मिलता है, और यही वजह है कि बीस साल पहले लिखी गई फ़ाइलें आज भी खुल जाती हैं। पर विनिर्देश का प्रकाशित होना और उसका रॉयल्टी-मुक्त होना एक बात नहीं है: जहाँ फ़ॉर्मेट किसी कोडेक को अपने अंदर लपेटता है, वहाँ पेटेंट का लाइसेंस एक अलग सवाल है, और मानक उसका जवाब नहीं देता।

JSON फ़ाइल अपना अंदरूनी हिस्सा हूबहू सहेजती है। दोबारा सहेजने से कुछ नहीं बदलता, इसलिए इसे जितनी बार चाहें खोलिए, बदलिए और फिर से सहेजिए — नुक़सान जमा नहीं होता। यही बात इसे सौंपने का नहीं, काम करने का फ़ॉर्मेट बनाती है।

JSON फ़ाइल में टिप्पणी लिखने का कोई तरीक़ा नहीं है। समझाने वाली हर बात फ़ाइल के बाहर रहनी पड़ेगी — इसे ऐसे किसी काम के लिए चुनने से पहले यह जान लेना चाहिए जिसे कोई इंसान हाथ से सँभालेगा।

Visual Studio Code, jq और Postman इसे पढ़ते हैं, और इसी तरह के ज़्यादातर दूसरे प्रोग्राम भी।

फ़ाइल न खुले तो कसूर फ़ॉर्मेट का शायद ही कभी होता है — अक्सर प्रोग्राम ही फ़ॉर्मेट से पुराना होता है। किसी पुरानी चीज़ में बदल लेना इससे निकलने का भरोसेमंद रास्ता है, और इस वेबसाइट का बाक़ी हिस्सा इसी के लिए है।

इसे हर मौजूदा ब्राउज़र पढ़ लेता है।

इसलिए इसे किसी पन्ने पर रखना या संदेश के साथ भेजना बेफ़िक्र होकर किया जा सकता है — सामने वाले ने क्या इंस्टॉल कर रखा है, यह सोचने की ज़रूरत नहीं।

JSON इसलिए बना है कि इसे खोला और बदला जाए। जब तक काम चल रहा है फ़ाइल इसी फ़ॉर्मेट में रखिए, और जब भी बनी हुई प्रति चाहिए हो, इसी से निर्यात कीजिए।

JSON दस्तावेज़ ऑब्जेक्ट, सरणी, स्ट्रिंग, संख्या, बूलियन और null से बनता है। यही पूरी शब्दावली है, और इस छोटी सूची ने ही इस फ़ॉर्मेट को सब जगह पहुँचाया: हर प्रोग्रामिंग भाषा में पहले से ये छह हैं, इसलिए दस्तावेज़ पढ़ना बस एक फ़ंक्शन बुलाना है।

विनिर्देश कुछ पन्नों में समा जाता है। इसे डिज़ाइन नहीं, वर्णित किया गया — Douglas Crockford ने JavaScript में पहले से मौजूद object literal वाक्य-रचना ली और जो पहले से काम कर रहा था वह लिख दिया।

JSON में जान-बूझकर कोई टिप्पणी नहीं, और यह फ़ॉर्मेट की सबसे शिकायती विशेषता है। तर्क था कि टिप्पणियाँ पार्सिंग निर्देश बुलावा देती हैं, और नतीजा यह है कि JSON चाहे वायर फ़ॉर्मेट के रूप में कितना ही अच्छा हो, कॉन्फ़िगरेशन भाषा के रूप में कमज़ोर है।

तीन तोड़-जोड़ चलन में हैं। underscore-comment जैसा नाम वाली कुंजी, जिसे हर पार्सर स्वीकार करेगा और हर स्कीमा वैलिडेटर ठुकराएगा। JSON5 और JSONC, जो टिप्पणी और trailing comma जोड़ते हैं और JSON नहीं हैं। और ईमानदार जवाब: इंसान के सँभाले किसी भी चीज़ के लिए TOML या YAML।

JSON पूर्णांक और फ़्लोटिंग पॉइंट में फ़र्क़ नहीं करता। ज़्यादातर पार्सर हर संख्या को डबल की तरह पढ़ते हैं, और डबल पूर्णांक को सटीक रूप से क़रीब नौ क्वाड्रिलियन तक ही रख सकता है।

उससे आगे, मूल्य चुपचाप बदल जाते हैं। 64-बिट डेटाबेस पहचान, बड़ी वित्तीय राशि — सब भेजे गए से अलग संख्या बनकर वापस आ सकते हैं, बिना कहीं कोई एरर के। इलाज है ऐसे मूल्य स्ट्रिंग की तरह भेजना, जो हर गंभीर API करता है।

दोहरी कुंजियाँ मना नहीं हैं। पार्सर अलग-अलग बरतते हैं — ज़्यादातर आख़िरी रखते हैं, कुछ पहली, कुछ एरर देते हैं — और किसी भी बर्ताव पर भरोसा करता दस्तावेज़ JSON पर नहीं, किसी लागू रूप पर भरोसा कर रहा होता है।

कुंजी क्रम भी सुरक्षित रखा जाने की गारंटी नहीं, इसलिए ऑब्जेक्ट को क्रमबद्ध संरचना मानना ग़लती है; क्रम मायने रखे तो सरणी इस्तेमाल कीजिए। और कोई तारीख़ नहीं है: सार्वभौमिक रिवाज़ है ISO 8601 स्ट्रिंग, और हर पार्सर आपको स्ट्रिंग सौंपता है जिसे कुछ और समझना पड़ता है।

JSON UTF-8 है। विनिर्देश सिस्टम के बीच बदले जाने वाली किसी भी चीज़ के लिए यह कहता है, और व्यावहारिक निष्कर्ष है कि byte order mark की इजाज़त नहीं — फ़ाइल की शुरुआत के वे तीन अदृश्य बाइट पार्स असफलता का कारण बनते हैं जो आमतौर पर पहले अक्षर को दोष देती है।

अगर कोई JSON फ़ाइल पार्स होने में असफल हो और एडिटर में बिलकुल सही दिखे, यही सबसे पहले जाँचने लायक़ है। «बिना BOM के UTF-8» वह सेटिंग है, और यहाँ यह सिर्फ़ झुँझलाने वाली नहीं, सचमुच घातक है।

JSON दस्तावेज़ पार्स होने से पहले पूरा होना चाहिए — बंद ब्रैकेट ही उसे मान्य बनाता है — इसलिए रिकॉर्ड की दस-गीगाबाइट सरणी को पहली एंट्री उपलब्ध होने से पहले पूरी याददाश्त में पढ़ना पड़ता है। बड़े निर्यात और लॉग पाइपलाइन के लिए यह घातक है।

NDJSON, JSON Lines भी कहलाता है, हर लाइन पर एक पूरा JSON ऑब्जेक्ट रखकर इसे हल करता है, बिना घेरने वाली सरणी के। हर लाइन स्वतंत्र रूप से पार्स होती है, इसलिए किसी भी आकार की फ़ाइल पंक्ति-दर-पंक्ति स्ट्रीम होती है।

JSON Schema मान्य दस्तावेज़ बताने का मानक तरीक़ा है, और दो सिस्टम के बीच किसी भी इंटरफ़ेस के लिए इस्तेमाल करने लायक़ है — यह «API ने कुछ अजीब लौटाया» को किसी ख़ास फ़ील्ड नाम वाली सटीक ग़लती में बदल देता है।

रोज़ के काम के लिए, JSON समर्थन वाला एडिटर अहम आधा हिस्सा मुफ़्त देता है: छूटा या फ़ालतू कॉमा वहीं चिह्नित होता है, और एक लंबी लाइन में आई मशीन-बनी JSON पढ़ने लायक़ बन सकती है।