UltKit
इमेज11
PDF13
डॉक्यूमेंट और डेटा7
वीडियो6
ऑडियो4
और टूल्स22

URL एनकोड और डिकोड

टेक्स्ट को URL में डालने लायक सुरक्षित बनाएँ, या %20 जैसे सीक्वेंस को वापस पढ़ने लायक अक्षरों में बदलें। यह टूल आपके ब्राउज़र के अपने encodeURIComponent, encodeURI और decodeURIComponent का इस्तेमाल करता है, क्वेरी पैरामीटर को टेबल में दिखाता है, और सर्वर पर कुछ नहीं भेजता।

मोड

0 अक्षर · 0 शब्द · 0 पंक्तियाँ

0 अक्षर · 0 शब्द · 0 पंक्तियाँ

यह पूरी तरह इसी ब्राउज़र टैब में चलता है। आपका टेक्स्ट न अपलोड होता है, न सेव किया जाता है।

हर फ़ंक्शन क्या एस्केप करता है

ब्राउज़र के अपने फ़ंक्शन से निकाला गया। encodeURIComponent अक्षर, अंक और ये चिह्न नहीं बदलता: ! ' ( ) * - . _ ~

अक्षरencodeURIComponentencodeURI
(स्पेस)%20%20
!!!
"%22%22
#%23#
$%24$
%%25%25
&%26&
'''
(((
)))
***
+%2B+
,%2C,
/%2F/
:%3A:
;%3B;
=%3D=
?%3F?
@%40@
[%5B%5B
]%5D%5D
{%7B%7B
}%7D%7D
|%7C%7C
\%5C%5C
^%5E%5E
`%60%60
<%3C%3C
>%3E%3E
~~~
---
___
...
é%C3%A9%C3%A9
€%E2%82%AC%E2%82%AC
😀%F0%9F%98%80%F0%9F%98%80

परसेंट-एनकोडिंग और RFC 3986 के रिज़र्व्ड अक्षर

URL में ASCII के सीमित अक्षर ही आ सकते हैं। URI सिंटैक्स की 2005 की स्पेसिफ़िकेशन RFC 3986 इन्हें दो समूहों में बाँटती है। Unreserved अक्षर, यानी A–Z, a–z, 0–9 और चार चिह्न - . _ ~, को कभी एन्कोड करने की ज़रूरत नहीं पड़ती। Reserved अक्षरों का अपना काम होता है: सामान्य डिलिमिटर : / ? # [ ] @ स्कीम, होस्ट, पाथ, क्वेरी और फ़्रैगमेंट को अलग करते हैं, और सब-डिलिमिटर ! $ & ' ( ) * + , ; = उनके अंदर के आइटम अलग करते हैं, जैसे क्वेरी स्ट्रिंग में & और =। बाकी हर अक्षर, और डेटा के रूप में इस्तेमाल हुआ कोई भी reserved अक्षर, पर्सेंट-एन्कोड करना ज़रूरी है।

पर्सेंट-एन्कोडिंग एक बाइट को % और उसके बाद दो हेक्साडेसिमल अंकों के रूप में लिखती है। टेक्स्ट पहले UTF-8 में बदला जाता है, इसलिए स्पेस %20 बन जाता है, é (दो बाइट) %C3%A9 बन जाता है और एक इमोजी चार %XX समूहों में बदल जाता है। इसी वजह से "café & bar" की खोज लिंक में caf%C3%A9%20%26%20bar बनकर आती है: & को एन्कोड किया जाता है ताकि सर्वर उसे नए पैरामीटर की शुरुआत न समझे।

encodeURIComponent, encodeURI और डिकोडिंग

encodeURIComponent किसी एक हिस्से के लिए सही विकल्प है, जैसे क्वेरी की वैल्यू, पाथ का एक सेगमेंट या पैरामीटर के रूप में भेजा गया रीडायरेक्ट URL। यह unreserved अक्षरों और ! ' ( ) * को छोड़कर सब कुछ एस्केप करता है; इन्हें JavaScript ऐतिहासिक कारणों से वैसा ही छोड़ देता है। encodeURI (पूरा URL) मानता है कि इनपुट पहले से पूरा पता है और reserved अक्षरों को जस का तस रखता है, इसलिए https://example.com/a b?q=1 में सिर्फ़ स्पेस एन्कोड होता है। पैरामीटर की वैल्यू पर encodeURI इस्तेमाल करना एक आम बग है: वैल्यू के अंदर का & या # बचा रह जाएगा और URL तोड़ देगा।

Decode दोनों में से किसी भी फ़ंक्शन को पलट देता है। GET से भेजे गए HTML फ़ॉर्म पुराने application/x-www-form-urlencoded फ़ॉर्मेट का इस्तेमाल करते हैं, जिसमें स्पेस %20 की जगह + लिखा जाता है; ऐसे मामलों में Treat + as a space चुना रहने दें, और जब सचमुच प्लस चिह्न मायने रखता हो, जैसे फ़ोन नंबर में, तो उसे हटा दें। अगर इनपुट में ऐसा % है जिसके बाद दो हेक्स अंक नहीं हैं, या ऐसे बाइट हैं जो वैध UTF-8 नहीं हैं, तो डिकोडिंग अंदाज़ा लगाने की जगह साफ़ संदेश के साथ विफल हो जाती है। जब टेक्स्ट में क्वेरी स्ट्रिंग होती है, तो उसके पैरामीटर टूल के नीचे एक टेबल में डिकोड होकर दिखते हैं। URL में बाइनरी डेटा के लिए Base64url आम विकल्प है।

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

URL में स्पेस %20 होना चाहिए या प्लस (+) चिह्न?
पाथ में और RFC 3986 के अनुसार स्पेस %20 होता है। + रूप का मतलब स्पेस सिर्फ़ उन क्वेरी स्ट्रिंग में है जो HTML फ़ॉर्म के तरीके से एन्कोड की गई हों, इसलिए %20 हर जगह सुरक्षित विकल्प है।
मेरे URL में %2520 क्यों आ गया?
यह दो बार एन्कोड हुआ है। पहले चरण में स्पेस %20 बना, और दूसरे में % खुद %25 के रूप में एन्कोड हो गया। एक बार डिकोड करने से अतिरिक्त परत हट जाएगी, और अपने कोड में वैल्यू को सिर्फ़ एक ही जगह एन्कोड करें।
किन अक्षरों को कभी परसेंट-एनकोडिंग की ज़रूरत नहीं होती?
RFC 3986 के unreserved अक्षर: A से Z तक के अक्षर दोनों केस में, 0 से 9 तक के अंक, और हाइफ़न, पीरियड, अंडरस्कोर और टिल्ड।
क्या URL में बिना एनकोडिंग के गैर-अंग्रेज़ी अक्षर हो सकते हैं?
ब्राउज़र इन्हें दिखा देते हैं, लेकिन नेटवर्क पर पाथ या क्वेरी का हर गैर-ASCII अक्षर पर्सेंट-एन्कोडेड UTF-8 के रूप में भेजा जाता है। डोमेन नामों के लिए अलग प्रणाली Punycode है, जो उन्हें xn-- लेबल में बदल देती है।
डिकोड करते समय गलत (malformed) सीक्वेंस की त्रुटि क्यों आती है?
टेक्स्ट में ऐसा % है जिसके बाद दो हेक्साडेसिमल अंक नहीं हैं, जैसे सीधा "100%", या बाइट अमान्य UTF-8 में डिकोड होते हैं। डिकोड करने से पहले अकेले % चिह्नों को %25 के रूप में एन्कोड करें।