JSON एस्केप टूल

यह कैसे काम करता है

1. अपनी स्ट्रिंग पेस्ट करें: एस्केप करने के लिए टेक्स्ट दर्ज करें, यह उद्धरण, न्यूलाइन या अन्य विशेष वर्णों वाला कच्चा टेक्स्ट हो सकता है।
2. एस्केप या अन-एस्केप चुनें: चुनें कि आप टेक्स्ट को JSON में एम्बेड करने के लिए एस्केप करना चाहते हैं, या अन-एस्केप करना चाहते हैं।
3. परिणाम कॉपी करें: एस्केप या अन-एस्केप किया गया आउटपुट तुरंत प्रकट होता है। अपने कोड में उपयोग के लिए इसे कॉपी करें।

JSON एस्केप क्यों इस्तेमाल करें?

JSON स्ट्रिंग्स में कठोर एस्केप नियम होते हैं, दोहरे उद्धरण को \", न्यूलाइन को \n, बैकस्लैश को \\ बनना चाहिए।

विशेषताएँ

• पूर्ण एस्केप कवरेज: उद्धरण, बैकस्लैश, न्यूलाइन, टैब, कैरिज रिटर्न को संभालता है।
• द्विदिशीय: एक ही टूल में एस्केप (टेक्स्ट → JSON स्ट्रिंग) और अन-एस्केप (JSON स्ट्रिंग → टेक्स्ट) दोनों।
• तत्काल परिणाम: जब आप टाइप करते हैं, आउटपुट बिना देरी के अपडेट होता है।
• क्लिपबोर्ड पर कॉपी: एस्केप किए गए या अन-एस्केप किए गए परिणाम की एक-क्लिक कॉपी।
• गोपनीयता प्राथमिकता: सभी प्रसंस्करण स्थानीय रूप से होता है, संवेदनशील स्ट्रिंग्स कभी आपके डिवाइस से नहीं जातीं।

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

JSON एस्केप कौन से वर्ण संभालता है?

JSON को एस्केप करने की आवश्यकता होती है: दोहरे उद्धरण ("), बैकस्लैश (\), फ़ॉरवर्ड स्लैश (/), न्यूलाइन (\n), कैरिज रिटर्न (\r) आदि।

मेरी JSON पार्स त्रुटि एस्केपिंग के कारण क्यों है?

सामान्य कारणों में स्ट्रिंग मान के अंदर अन-एस्केप किए गए दोहरे उद्धरण, स्ट्रिंग्स में शाब्दिक न्यूलाइन, या अनुचित बैकस्लैश शामिल हैं।

क्या इसमें घेरने वाले उद्धरण शामिल हैं?

डिफ़ॉल्ट रूप से, टूल सामग्री को उद्धरण में रखे बिना एस्केप करता है, ताकि आप परिणाम को अपनी JSON स्ट्रिंग में पेस्ट कर सकें।

JSON स्ट्रिंग स्पेक, एक तालिका में

RFC 8259 (दिसंबर 2017, Tim Bray द्वारा) वर्तमान JSON मानक है, RFC 7159 और मूल RFC 4627 की जगह लेता है। स्पेक की धारा 7 बिल्कुल सूचीबद्ध करती है कि स्ट्रिंग लिटरल के अंदर कौन से वर्ण ESCAPE होने चाहिए:

समकक्ष नियम ECMA-404 (दूसरा संस्करण, दिसंबर 2017) में हैं, IETF स्पेक के साथ सिंक में रखे जाते हैं। JSON में ऑक्टल (\012) या हेक्सादशमलव (\x41) एस्केप नहीं हैं, वे केवल JavaScript के लिए हैं; JSON केवल उपरोक्त आठ नामित एस्केप प्लस \uXXXX का समर्थन करता है।

\uXXXX एस्केप और सरोगेट जोड़ी जाल

JSON के \uXXXX अनुक्रम UTF-16 कोड इकाइयों को एन्कोड करते हैं, यूनिकोड कोड पॉइंट को नहीं। यह इमोजी और पूरक प्लेन वर्णों के लिए मायने रखता है। 😀 (U+1F600) जैसा एकल इमोजी \u1F600 के रूप में एस्केप नहीं होता है (वह कानूनी चार-हेक्स-अंक रूप भी नहीं है), बल्कि सरोगेट जोड़ी के रूप में: \uD83D\uDE00, उच्च और निम्न सरोगेट को एन्कोड करने वाले दो लगातार एस्केप। उच्च-सरोगेट श्रेणी U+D800–U+DBFF है; निम्न-सरोगेट श्रेणी U+DC00–U+DFFF है; मिलकर वे U+10000 से U+10FFFF (पूरक प्लेन) को कवर करते हैं।

यह एस्केप किए गए इमोजी बग का सबसे आम स्रोत है। RFC 8259 धारा 7 स्पष्ट रूप से कहती है: «एक विस्तारित वर्ण को एस्केप करने के लिए जो बेसिक मल्टीलिंगुअल प्लेन में नहीं है, वर्ण को 12-वर्ण अनुक्रम के रूप में दर्शाया गया है, जो UTF-16 सरोगेट जोड़ी को एन्कोड करता है।» 👨‍👩‍👧‍👦 जैसा चार का परिवार इमोजी, जो तकनीकी रूप से चार आधार इमोजी प्लस तीन शून्य-चौड़ाई जोड़ने वाले हैं, JSON स्ट्रिंग में 30+ वर्णों के रूप में एस्केप होता है। बाइट गिनती तदनुसार फूलती है: कच्चे 25 UTF-8 बाइट, JSON एस्केप के बाद ~58 बाइट।

HTML, URL, SQL और CSV के अंदर JSON

JSON एस्केप अपने आप पर्याप्त नहीं है जब JSON किसी अन्य प्रारूप में एम्बेड किया गया है। प्रत्येक संदर्भ अपनी परत जोड़ता है।

HTML के अंदर JSON। क्लासिक जाल <script>const data = {{ payload | json }};</script> है जब payload में लिटरल उपस्ट्रिंग </script> है। HTML पार्सर स्ट्रिंग के बीच में स्क्रिप्ट टैग बंद करता है और JSON का बाकी हिस्सा पेज पर दृश्यमान टेक्स्ट के रूप में रेंडर होता है। समाधान वैकल्पिक \/ एस्केप है: <\/script> JSON-वैध और HTML-सुरक्षित है। OWASP की क्रॉस-साइट स्क्रिप्टिंग चीट शीट HTML एम्बेडिंग के लिए लक्षित JSON में हमेशा <, >, & और ' को एस्केप करने की सिफारिश करती है।

URL क्वेरी स्ट्रिंग के अंदर JSON। दो परतें: पहले JSON एस्केप, फिर पर्सेंट-एन्कोडिंग। {"name":"Bob"} %7B%22name%22%3A%22Bob%22%7D बन जाता है। पर्सेंट-एन्कोडिंग भूलना JSON-इन-URL मालफॉर्मेड बग का #1 कारण है।

SQL के अंदर JSON। PostgreSQL jsonb कॉलम में संग्रहीत मान को मूल रूप से पार्स किया जाता है, कोई और एस्केप आवश्यक नहीं है। लेकिन SQL स्ट्रिंग लिटरल में एम्बेड किया गया JSON (INSERT INTO t (data) VALUES ('{"key":"value"}')) JSON के ऊपर SQL-स्ट्रिंग एस्केप की आवश्यकता है: डबल किए गए सिंगल कोट (''), या बेहतर, पैरामीटराइज़्ड क्वेरीज़ का उपयोग करें।

CSV कोशिकाओं के अंदर JSON। CSV का कोटिंग JSON से अलग है (CSV डबल कोट "" का उपयोग करता है, बैकस्लैश अनुक्रमों का नहीं)। CSV सेल में JSON एम्बेड करने के लिए दोनों परतों की आवश्यकता है: स्ट्रिंग को JSON-एस्केप करें, फिर परिणाम को CSV-एस्केप करें ("..." में लपेटें, किसी भी आंतरिक " को दोगुना करें)।

विभिन्न भाषाओं में रनटाइम API

JSON कहाँ से आया, और Crockford ने क्या छोड़ा

JSON को पहली बार Douglas Crockford ने 2001 में State Software में औपचारिक रूप दिया था, मूल रूप से असिंक्रोनस डेटा एक्सचेंज के लिए JavaScript ऑब्जेक्ट को क्रमबद्ध करने के लिए। पहली सार्वजनिक उल्लेख 2003 में JSON.org साइट पर थी। Crockford ने इसे जुलाई 2006 में RFC 4627 के रूप में औपचारिक रूप से निर्दिष्ट किया, आंशिक रूप से उसी समय के आसपास एक प्रतिस्पर्धी पेटेंट प्रयास का मुकाबला करने के लिए। मानक दिसंबर 2017 में RFC 8259 के साथ STD 90 स्थिति में चला गया।

JSON का सबसे बड़ा डिज़ाइन निर्णय इसे JavaScript का सबसेट बनाना था, ताकि कोई भी JSON दस्तावेज़ JS इंटरप्रेटर में eval'd हो सके और सही मान प्राप्त कर सके। इसने ब्राउज़र अपनाने को बिना घर्षण के बना दिया लेकिन कुछ JS विशिष्टताओं को स्थायी रूप से लॉक कर दिया: कोई पूर्णांक प्रकार नहीं (सभी संख्याएँ IEEE 754 डबल हैं), कोई दिनांक प्रकार नहीं, कोई NaN या Infinity नहीं। 2⁵³−1 से ऊपर के बड़े पूर्णांकों को मौन परिशुद्धता हानि से बचने के लिए स्ट्रिंग क्रमबद्धीकरण ("id": "9007199254740993") की आवश्यकता होती है।

Crockford ने जानबूझकर ऐसी चीज़ें छोड़ दीं जिनकी आप कमी महसूस कर सकते हैं: टिप्पणियाँ («मैंने JSON से टिप्पणियाँ हटा दीं क्योंकि मैंने देखा कि लोग पार्सिंग निर्देशों को रखने के लिए उनका उपयोग कर रहे थे, एक प्रथा जो इंटरऑपरेबिलिटी को नष्ट कर देती», मई 2012), अनुगामी अल्पविराम, और स्कीमा भाषा (बाद में JSON Schema के रूप में जोड़ा गया, अलग से बनाए रखा गया, वर्तमान मसौदा 2020-12)। समुदाय संस्करण JSON5 टिप्पणियों और अनुगामी अल्पविरामों को पुनर्स्थापित करता है लेकिन RFC-अनुपालन नहीं है; इसका उपयोग मुख्य रूप से कॉन्फ़िग फ़ाइलों (.babelrc, .swcrc) में किया जाता है जहाँ मनुष्य संपादित करते हैं।

सामान्य उपयोग के मामले

• HTML विशेषताओं में डेटा एम्बेड करना, ", <, > के साथ एक स्ट्रिंग चिपकाएँ, data-* विशेषताओं या इनलाइन script टैग के लिए एक सुरक्षित रूप प्राप्त करें।
• हाथ से API अनुरोध निकाय बनाना, जब एंडपॉइंट को curl कर रहे हों और payload में उद्धरण या नई पंक्तियाँ हों।
• लॉग-लाइन payloads बनाना जहाँ संदेश को दूसरी तरफ शेल कोटिंग प्लस JSON पार्सिंग से बचना चाहिए।
• लेगेसी डेटा माइग्रेट करना CSV / XML / TSV से JSON में, मैनुअल कोट एस्केप पास।
• सर्वर प्रतिक्रियाओं का डिबग करना जहाँ मान में \u अनुक्रम हैं, यह देखने के लिए unescape करें कि यह वास्तव में क्या है।
• परीक्षण लिखना, अपेक्षित JSON आउटपुट चिपकाएँ और परीक्षण assertion में शामिल करने के लिए इसे एस्केप करें।
• टेम्पलेटिंग इंजन (Jinja2, Nunjucks, Liquid, ERB) जो JavaScript या HTML में JSON एम्बेड करते हैं।

सामान्य गलतियाँ

1. JavaScript एस्केप का उपयोग करना जो JSON-वैध नहीं हैं। «A» के लिए \x41 और नई पंक्ति के लिए \012 JS स्ट्रिंग लिटरल में वैध हैं लेकिन JSON में अमान्य हैं। JSON केवल आठ नामित एस्केप प्लस \uXXXX की अनुमति देता है।
2. JSON स्ट्रिंग के लिए एकल उद्धरण का उपयोग करना। 'hello' JavaScript में काम करता है लेकिन JSON अमान्य है। JSON स्ट्रिंग को दोहरे उद्धरण का उपयोग करना चाहिए।
3. उद्धरण रहित ऑब्जेक्ट कुंजियाँ। {name: "Bob"} JavaScript में काम करता है लेकिन JSON अमान्य है। कुंजियाँ डबल उद्धरण में स्ट्रिंग लिटरल होनी चाहिए।
4. अनुगामी अल्पविराम। [1,2,3,] JS में काम करता है लेकिन JSON अमान्य है। RFC 8259 स्पष्ट रूप से उन्हें मना करता है।
5. इनलाइन टिप्पणियाँ। // foo और /* foo */ मानक JSON में अमान्य हैं। यदि आपको टिप्पणियों की आवश्यकता है तो JSON5 का उपयोग करें; उम्मीद करें कि हर पार्सर इसे स्वीकार नहीं करेगा।
6. एक इमोजी को एकल \uXXXX के रूप में हाथ से एस्केप करना। U+FFFF से ऊपर के इमोजी को UTF-16 सरोगेट जोड़ी की आवश्यकता होती है, दो \uXXXX एस्केप एक के पीछे एक।

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

क्या मुझे हमेशा फॉरवर्ड स्लैश / एस्केप करना चाहिए?

नहीं, फॉरवर्ड स्लैश / JSON में बिना एस्केप के अनुमति है; एस्केप \/ वैकल्पिक है। अपवाद है जब JSON HTML <script> टैग के अंदर एम्बेड किया गया है: / को \/ के रूप में एस्केप करना लिटरल उपस्ट्रिंग </script> को टैग को समय से पहले बंद होने से रोकता है। कुछ एन्कोडर (PHP में JSON_HEX_TAG, कस्टम JS प्रतिस्थापन) ऐसा करते हैं; अधिकांश नहीं करते।

JSON.stringify मेरे गैर-ASCII वर्णों को क्यों एस्केप करता है?

डिफ़ॉल्ट रूप से नहीं करता। JavaScript में JSON.stringify("café") लिटरल é के साथ "café" उत्पन्न करता है। जो आप देख रहे हैं वह एक अलग पुस्तकालय हो सकता है: Python का json.dumps डिफ़ॉल्ट रूप से ensure_ascii=True है और ASCII के बाहर सब कुछ \uXXXX के रूप में एस्केप करता है; PHP का json_encode समान रूप से व्यवहार करता है जब तक आप JSON_UNESCAPED_UNICODE पास नहीं करते। दोनों व्यवहार वैध JSON हैं, लेकिन फ़ाइल आकार और पठनीयता भिन्न है।

क्या JSON बाइनरी डेटा संग्रहीत कर सकता है?

सीधे नहीं। JSON स्ट्रिंग यूनिकोड वर्णों के अनुक्रम हैं, बाइट्स नहीं। मानक workaround पहले बाइनरी को Base64 एन्कोड करना है, फिर परिणामी ASCII स्ट्रिंग को सामान्य JSON मान के रूप में संग्रहीत करना। एन्कोडेड डेटा कच्चे बाइट्स से ~33% बड़ा है। बहुत बड़े बाइनरी के लिए, BSON, MessagePack, या CBOR जैसे बाइनरी प्रारूप का उपयोग करें, या बाइट्स को अलग से संग्रहीत करें और उन्हें URL द्वारा संदर्भित करें।

कुछ उपकरण \u00e9 के बजाय é क्यों दिखाते हैं?

दोनों एक ही वर्ण के लिए वैध JSON हैं। "caf\u00e9" और "café" समान स्ट्रिंग में डिकोड होते हैं। कुछ एन्कोडर अधिकतम क्रॉस-एन्कोडिंग सुरक्षा के लिए गैर-ASCII को एस्केप करते हैं (आउटपुट शुद्ध ASCII है इसलिए उपभोक्ता की एन्कोडिंग मायने नहीं रखती), अन्य पठनीयता के लिए मूल UTF-8 को संरक्षित करते हैं। आपके JSON का उपभोग करने वाली चीज़ के आधार पर चुनें।

क्या मेरा टेक्स्ट कहीं अपलोड किया जाता है?

नहीं। टूल पूरी तरह से क्लाइंट-साइड पर ब्राउज़र के मूल JSON.stringify और JSON.parse API का उपयोग करता है। कोई नेटवर्क कॉल नहीं, कोई एनालिटिक्स नहीं, कोई लॉगिंग नहीं। API टोकन, आंतरिक डेटा, या किसी भी चीज़ को एस्केप करने के लिए सुरक्षित जिसे आप सर्वर-साइड एस्केप टूल में चिपकाएँगे नहीं।