URL एन्कोड / डिकोड

URL (पर्सेंट) एन्कोडिंग कैसे काम करती है

एक URL में केवल वर्णों का एक सीमित समूह ही हो सकता है। उस समूह के बाहर की हर चीज़ — स्पेस, अधिकांश विराम-चिह्न, और ग़ैर-ASCII टेक्स्ट — को % के बाद वर्ण के UTF-8 बाइट मानों को हेक्साडेसिमल में लगाकर बदल दिया जाता है। एक स्पेस %20 बन जाता है, एक ऐम्परसैंड %26, और é बन जाता है %C3%A9।

कंपोनेंट बनाम फुल URI

यही वह भेद है जिसे अधिकांश टूल धुँधला कर देते हैं। कंपोनेंट मोड (encodeURIComponent) आरक्षित संरचनात्मक वर्णों को भी एन्कोड करता है (: / ? # [ ] @ & = +), इसलिए यह किसी एकल क्वेरी-स्ट्रिंग मान या पाथ सेगमेंट के लिए सही है। फुल-URI मोड (encodeURI) उन संरचनात्मक वर्णों को अपरिवर्तित छोड़ देता है और केवल स्पेस तथा अवैध वर्ण ठीक करता है, इसलिए यह एक पूरे URL को एक बार में एन्कोड करने के लिए है। ग़लत मोड इस्तेमाल करना टूटे हुए लिंकों का एक आम कारण है।

आरक्षित बनाम अनारक्षित वर्ण

RFC 3986 के अनुसार, अनारक्षित वर्ण A–Z a–z 0–9 - _ . ~ कभी एन्कोड नहीं होते। आरक्षित वर्णों का किसी URL में एक संरचनात्मक अर्थ होता है और वे केवल तभी एन्कोड होते हैं जब वे सीमांककों (delimiters) के बजाय डेटा के रूप में आते हैं।

संपूर्ण RFC 3986 वर्ण-समूह

URLs के लिए आधुनिक नियम-पुस्तिका RFC 3986 है, जो जनवरी 2005 में प्रकाशित हुई। यह पुराने RFC 2396 (तथा RFC 1808 और RFC 2732) को अप्रचलित करती है और मूल URL विनिर्देश RFC 1738 को अद्यतन करती है। RFC 3986 उन ASCII वर्णों को जिन्हें कोई URI इस्तेमाल कर सकता है, तीन समूहों में बाँटती है, और इन्हें सही करना ही पूरा खेल है।

आरक्षित वर्ण सीमांककों के रूप में अर्थ रखते हैं। जो URI किसी दूसरे से केवल किसी अनारक्षित वर्ण की पर्सेंट-एन्कोडिंग में भिन्न होता है, उसे समतुल्य माना जाता है, इसलिए A को %41 के रूप में एन्कोड करना वैध है पर व्यर्थ है और सुव्यवहृत सॉफ़्टवेयर इसे वापस सामान्यीकृत कर देता है। इसके विपरीत, आरक्षित वर्णों को जब भी वे किसी विभाजक के बजाय शाब्दिक डेटा के रूप में आते हैं तब पर्सेंट-एन्कोड किया जाना चाहिए: किसी खोज-शब्द के भीतर एक ऐम्परसैंड को %26 बनना होगा ताकि उसे दो क्वेरी पैरामीटरों के बीच का विभाजक न समझ लिया जाए।

कोई वर्ण पर्सेंट-एन्कोडेड ऑक्टेट कैसे बनता है

पर्सेंट-एन्कोडिंग सीधे वर्णों पर नहीं, बल्कि बाइटों पर काम करती है। RFC 3986 त्रिक व्याकरण pct-encoded = "%" HEXDIG HEXDIG परिभाषित करती है: एक शाब्दिक पर्सेंट चिह्न के बाद दो हेक्साडेसिमल अंक जो एक 8-बिट ऑक्टेट को व्यक्त करते हैं। स्पेस वर्ण (US-ASCII मान 32, बाइनरी 00100000, हेक्स 20) इसलिए %20 में एन्कोड होता है।

सादे ASCII से परे किसी भी चीज़ के लिए आधुनिक URLs में नियम स्पष्ट है: पहले टेक्स्ट को UTF-8 के रूप में एन्कोड करें, फिर प्रत्येक परिणामी बाइट को पर्सेंट-एन्कोड करें जो अनारक्षित समूह में नहीं है। चूँकि अधिकांश ग़ैर-ASCII वर्ण दो, तीन या चार UTF-8 बाइट घेरते हैं, वे कई त्रिकों में फैल जाते हैं। उच्चारण-चिह्नित é %C3%A9 बन जाता है; जापानी काताकाना अक्षर a (ア) %E3%82%A2 बन जाता है; इमोजी जैसा चार-बाइट वर्ण चार त्रिकों में फैल जाता है। यह टूल जिन JavaScript बिल्ट-इन का उपयोग करता है वे पहले से ही UTF-8 का पालन करते हैं, यही वजह है कि उच्चारण-चिह्नों, CJK टेक्स्ट और इमोजी का राउंड-ट्रिप सही ढंग से काम करता है।

encodeURI, encodeURIComponent और अप्रचलित escape

JavaScript तीन एन्कोडर देता है, और इन्हें आपस में भ्रमित करना एक क्लासिक बग है। नीचे की तालिका ठीक-ठीक बताती है कि इनमें से हर एक कौन-से वर्ण बिना-एन्कोड किए छोड़ता है — बाक़ी सब कुछ एक पर्सेंट-त्रिक बन जाता है।

ग्यारह विराम-चिह्न - _ . ! ~ * ' ( ) जिन्हें encodeURIComponent भी छोड़ देता है, वे RFC 3986 के अनारक्षित चिह्न हैं, साथ में कुछ पुरातन वर्ण। हर संरचनात्मक चीज़ — : / ? # [ ] @ और महत्वपूर्ण &, = तथा + — एन्कोड हो जाती है, यही ठीक वजह है कि किसी अलग-अलग मान के लिए encodeURIComponent सही विकल्प है। पुरातन escape फ़ंक्शन अप्रचलित और ग़ैर-मानक है: यह UTF-8 का उपयोग नहीं करता (यह 256 से नीचे के कोड बिंदुओं के लिए %XX और उससे ऊपर एक ग़ैर-मानक %uXXXX रूप उत्सर्जित करता है), इसलिए ć जैसा वर्ण ग़लत ढंग से अपने UTF-8 बाइटों के बजाय %u0107 बन जाता है। इसे URLs के लिए कभी इस्तेमाल न करें।

स्पेस की समस्या: %20 बनाम +

एक बाइट किसी भी अन्य से अधिक भ्रम पैदा करती है: स्पेस। RFC 3986 के अनुसार किसी सामान्य URI में एक स्पेस %20 होता है। पर application/x-www-form-urlencoded के रूप में सबमिट किए गए HTML फ़ॉर्म एक भिन्न, पुरानी परिपाटी का पालन करते हैं — जिसे आज WHATWG URL Standard में परिभाषित किया गया है — जहाँ एक स्पेस एक शाब्दिक प्लस चिह्न + बन जाता है, और इसलिए एक शाब्दिक प्लस को दोनों को अलग रखने के लिए %2B के रूप में एन्कोड किया जाता है। ब्राउज़र का URLSearchParams API इसी रूप का उपयोग करता है, इसलिए यह एक स्पेस को + के रूप में क्रमबद्ध करता है, जबकि encodeURIComponent %20 उत्पन्न करता है।

दोनों एक असली URL की क्वेरी स्ट्रिंग में वैध हैं, और एक सही डिकोडर + को स्पेस के रूप में केवल फ़ॉर्म-एन्कोडेड डेटा में मानता है — किसी पाथ में कभी नहीं। किसी पाथ सेगमेंट के भीतर + को स्पेस में डिकोड करना एक आम बग है जो फ़ाइल नाम और स्लग बिगाड़ देता है। यदि आप यहाँ फ़ॉर्म डेटा पेस्ट करते हैं और चाहते हैं कि प्लस चिह्नों को स्पेस माना जाए, तो डिकोड करने से पहले उन्हें बदल दें; सामान्य URLs के लिए, उन्हें वैसे ही रहने दें।

एन्कोडिंग URL के हिस्से पर निर्भर करती है

एक URL एक सपाट स्ट्रिंग नहीं है; यह कंपोनेंटों का एक अनुक्रम है — स्कीम, यूज़रइन्फ़ो, होस्ट, पोर्ट, पाथ, क्वेरी और फ़्रैगमेंट — और हर एक के पास वैध वर्णों का अपना समूह है। व्यावहारिक परिणाम:

• पाथ सेगमेंट में sub-delims और : @ हो सकते हैं, पर किसी एकल सेगमेंट के भीतर एक शाब्दिक / को %2F लिखना होगा, वरना उसे एक नई सेगमेंट सीमा के रूप में पढ़ा जाता है।
• क्वेरी स्ट्रिंग & और = को विभाजक मानती है, इसलिए इन्हें रखने वाले किसी भी मान को पर्सेंट-एन्कोड किया जाना चाहिए; हालाँकि ? और / किसी क्वेरी के भीतर बिना एस्केप किए अनुमत हैं।
• फ़्रैगमेंट (# के बाद) कभी सर्वर को नहीं भेजे जाते — ब्राउज़र उन्हें संभालता है — पर फिर भी ग़ैर-ASCII सामग्री के लिए पर्सेंट-एन्कोडिंग का पालन करते हैं।
• यूज़रइन्फ़ो (होस्ट से पहले शायद ही कभी इस्तेमाल होने वाला user:password@) को @ और : तब एन्कोड करना होगा जब वे विभाजकों के बजाय डेटा के रूप में आते हैं।

यही वजह है कि एक ही "पूरी चीज़ एन्कोड कर दो" पास ग़लत है: पहले हर कंपोनेंट को encodeURIComponent से एन्कोड करें, फिर उन्हें उन्हीं शाब्दिक संरचनात्मक वर्णों से जोड़ें जिनका आप वास्तव में इरादा रखते हैं।

अंतरराष्ट्रीय डोमेन और IRIs: Punycode, पर्सेंट-एन्कोडिंग नहीं

पर्सेंट-एन्कोडिंग पाथ, क्वेरी और फ़्रैगमेंट में ग़ैर-ASCII टेक्स्ट संभालती है, पर इसे होस्ट नाम में इस्तेमाल नहीं किया जा सकता — DNS केवल एक सीमित ASCII वर्णमाला स्वीकार करता है। अंतरराष्ट्रीयकृत डोमेन नाम इसके बजाय IDNA मानक के अंतर्गत Punycode (RFC 3492) से रूपांतरित होते हैं। हर ग़ैर-ASCII लेबल रूपांतरित होकर ASCII-संगत उपसर्ग xn-- पाता है: münchen.de बन जाता है xn--mnchen-3ya.de, और लेबल bücher बन जाता है xn--bcher-kva। ब्राउज़र मैत्रीपूर्ण यूनिकोड रूप दिखाते हैं पर वायर पर xn-- रूप भेजते हैं।

व्यापक अवधारणा IRI (Internationalized Resource Identifier, RFC 3987) है, जो हर जगह यूनिकोड की अनुमति देती है। एक IRI को एक सादे URI में इस तरह मैप किया जाता है: टेक्स्ट को सामान्यीकृत (Unicode NFC) करके, पाथ और क्वेरी में ग़ैर-ASCII वर्णों को UTF-8-एन्कोड करके, और उन बाइटों को पर्सेंट-एन्कोड करके — जबकि होस्ट को Punycode से रूपांतरित किया जाता है। तो https://en.wiktionary.org/wiki/Ῥόδος बन जाता है https://en.wiktionary.org/wiki/%E1%BF%AC%CF%8C%CE%B4%CE%BF%CF%82। संक्षेप में: होस्ट Punycode इस्तेमाल करता है, बाक़ी सब कुछ पर्सेंट-एन्कोडिंग।

डबल-एन्कोडिंग: वह बग जो एक परत ज़्यादा जोड़ देती है

डबल-एन्कोडिंग तब होती है जब पहले से एन्कोड किए गए टेक्स्ट को फिर से एन्कोड किया जाता है। पर्सेंट चिह्न स्वयं एक आरक्षित वर्ण है, इसलिए %20 को दूसरी बार एन्कोड करने पर %2520 मिलता है — क्योंकि अग्रणी % %25 बन जाता है। इसका उलटा भूल, दो परतें होने पर एक ही बार डिकोड करना, आउटपुट में भटके हुए %xx अनुक्रम छोड़ देती है। लक्षणों में ऐसे URLs शामिल हैं जो एड्रेस बार में %2520 दिखाते हैं, या ऐसे फ़ाइल नाम जो अपने भीतर एक शाब्दिक %20 लिए हुए आते हैं।

समाधान यह है कि आप जागरूक रहें कि कोई मान परतों — आपका कोड, एक HTTP लाइब्रेरी, एक प्रॉक्सी, एक फ़्रेमवर्क का राउटर — से गुज़रते हुए कितनी बार एन्कोड होता है, और ठीक उतनी ही बार डिकोड करें। URL बनाते समय एक बार एन्कोड करें; किसी मान को "सुरक्षा के लिए" कभी दो बार एन्कोडर से न गुज़ारें। किसी संदिग्ध मान की जाँच के लिए, उसे यहाँ बार-बार डिकोड करें: यदि दूसरी डिकोड परिणाम बदल देती है, तो वह डबल-एन्कोडेड था।

सुरक्षा: जहाँ भोली एन्कोडिंग और डिकोडिंग ग़लत हो जाती है

URL एन्कोडिंग वेब-भेद्यताओं का एक बार-बार आने वाला घटक है, लगभग हमेशा इसलिए क्योंकि किसी डिकोड किए गए मान पर बिना पुनः-सत्यापन के भरोसा कर लिया जाता है।

• ओपन रीडायरेक्ट। एक ?next= या ?return_to= पैरामीटर जिसे डिकोड करके एक रीडायरेक्ट लक्ष्य के रूप में इस्तेमाल किया जाता है, किसी हमलावर को उपयोगकर्ताओं को एक शत्रुतापूर्ण साइट पर भेजने देता है। डिकोड किए गए गंतव्य को होस्टों की एक अनुमति-सूची के विरुद्ध सत्यापित करें — कभी किसी मनमाने डिकोड किए गए URL पर रीडायरेक्ट न करें।
• क्रॉस-साइट स्क्रिप्टिंग (XSS)। डिकोडिंग %3Cscript%3E को वापस एक जीवित टैग में बदल देती है। यदि वह डिकोड किया गया टेक्स्ट HTML-एस्केप किए बिना किसी पेज में लिखा जाता है तो वह चल सकता है। पर्सेंट-डिकोडिंग और HTML-एस्केपिंग अलग-अलग काम हैं: मान के DOM तक पहुँचने से पहले दूसरा करें।
• फ़िल्टर और WAF बायपास। हमलावर पेलोड को एन्कोड और डबल-एन्कोड करते हैं — ../ के लिए ..%2F, या एक कोट के लिए %2527 — ताकि किसी ऐसे फ़िल्टर से बच निकलें जो केवल कच्चे रूप की जाँच करता है। सुरक्षा जाँच लगाने से पहले इनपुट को एक एकल विहित (canonical) डिकोड रूप में सामान्यीकृत करें, बाद में नहीं।
• लॉग और हेडर इंजेक्शन। किसी मान में इंजेक्ट किया गया एक डिकोड किया गया न्यूलाइन (%0A) या कैरिज रिटर्न (%0D) जो किसी लॉग लाइन या HTTP हेडर में पहुँच जाता है, प्रविष्टियाँ जाली बना सकता है या किसी प्रतिक्रिया को विभाजित कर सकता है। डिकोड करने के बाद नियंत्रण वर्ण हटा दें।

मूल बात: पर्सेंट-एन्कोडिंग एक परिवहन-सुविधा है, सुरक्षा-सीमा नहीं। जहाँ भी किसी डिकोड किए गए मान का अंततः उपयोग हो, उसे हमेशा सत्यापित और संदर्भानुसार एस्केप करें।

वेब लिंकों से परे: जहाँ-जहाँ और पर्सेंट-एन्कोडिंग दिखती है

पर्सेंट-एन्कोडिंग आपके ब्राउज़र बार के https:// पतों तक सीमित नहीं है; वही RFC 3986 नियम कई अन्य पहचानकर्ताओं को नियंत्रित करते हैं, और ऊपर बताई गई प्रति-संदर्भ अनुशासन हर एक पर लागू होती है।

• mailto: लिंक। mailto:hi@example.com?subject=Hello%20there&body=Line%20one जैसा पूर्व-भरा ईमेल लिंक विषय और मुख्य भाग में स्पेस तथा विराम-चिह्नों के लिए पर्सेंट-एन्कोडिंग का उपयोग करता है, और फ़ील्डों को अलग करने के लिए एक ऐम्परसैंड — इसलिए मुख्य भाग के टेक्स्ट में कोई भी शाब्दिक ऐम्परसैंड स्वयं %26 होना चाहिए।
• data: URIs। data:text/plain,Hello%20World जैसे इनलाइन संसाधन अपने पेलोड को पर्सेंट-एन्कोड करते हैं (या उसे इसके बजाय Base64 के रूप में ले जाते हैं), यही वजह है कि यह टूल एक Base64 एन्कोडर के साथ स्वाभाविक रूप से जुड़ता है।
• OAuth और रीडायरेक्ट पैरामीटर। एक OAuth redirect_uri एक पूरा URL है जो किसी अन्य URL की क्वेरी स्ट्रिंग के भीतर नेस्टेड होता है, इसलिए इसे encodeURIComponent से एक एकल कंपोनेंट के रूप में एन्कोड किया जाना चाहिए — एक पाठ्यपुस्तक स्थिति जहाँ एन्कोड करना भूल जाना (या डबल-एन्कोड करना) चुपचाप लॉगिन प्रवाह तोड़ देता है।
• HTTP प्रमाणीकरण और APIs। यूज़रइन्फ़ो कंपोनेंट में रखी गई साख (credentials), हस्ताक्षरित-अनुरोध हस्ताक्षर और कई REST पाथ पैरामीटर सभी एक सुसंगत, एकल-पास पर्सेंट-एन्कोडिंग पर निर्भर करते हैं ताकि सर्वर जो मान पुनर्निर्मित करता है वह आपके भेजे मान से मेल खाए।

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

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

URL एन्कोडिंग क्या है?

URL (पर्सेंट) एन्कोडिंग उन वर्णों को बदल देती है जो किसी URL में असुरक्षित या आरक्षित होते हैं — एक "%" के बाद उनका हेक्साडेसिमल बाइट मान लगाकर; उदाहरण के लिए एक स्पेस %20 बन जाता है और एक ऐम्परसैंड %26 बन जाता है। इससे मनमाना टेक्स्ट किसी URL के भीतर सुरक्षित रूप से यात्रा कर पाता है।

कंपोनेंट मोड बनाम फुल-URI मोड — मैं कौन-सा इस्तेमाल करूँ?

"कंपोनेंट" (encodeURIComponent) तब इस्तेमाल करें जब आप किसी एक टुकड़े को एन्कोड कर रहे हों जो किसी URL के भीतर जाता है — एक क्वेरी-स्ट्रिंग मान, एक पाथ सेगमेंट या एक फ़ॉर्म फ़ील्ड — क्योंकि यह :/?#[]@&=+ आदि को भी एन्कोड करता है। "फुल URI" (encodeURI) तब इस्तेमाल करें जब आपके पास एक पूरा URL हो और आप केवल स्पेस तथा अवैध वर्ण ठीक करना चाहते हों जबकि संरचनात्मक वर्ण अपरिवर्तित रहें।

क्या यह यूनिकोड और इमोजी संभालता है?

हाँ। एन्कोडिंग UTF-8 पर की जाती है, इसलिए उच्चारण-चिह्नित अक्षर, ग़ैर-लैटिन लिपियाँ और इमोजी पर्सेंट-एन्कोड होकर सही ढंग से वापस डिकोड होते हैं।

क्या कुछ भी सर्वर पर भेजा जाता है?

नहीं। एन्कोडिंग और डिकोडिंग पूरी तरह आपके ब्राउज़र में चलती है, इसलिए आपका डेटा आपके डिवाइस पर ही रहता है। यह टूल एक बार लोड होने के बाद ऑफ़लाइन भी काम करता है।

संबंधित टूल

• Base64 एन्कोडर / डिकोडर
• JSON फ़ॉर्मैटर और वैलिडेटर
• टेक्स्ट से हेक्स
• यूनिक्स टाइमस्टैम्प कन्वर्टर

सभी डेवलपर और डेटा रूपांतरण देखें →