URL एन्कोडिंग समझें: परसेंट-एन्कोडिंग, %20 और आम गड़बड़ियाँ

URL एन्कोडिंग असल में क्या है

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

यही तरीका उन अक्षरों पर भी लगता है जो मान्य तो हैं पर कोई मतलब रखते हैं। ? क्वेरी शुरू करता है और & पैरामीटर अलग करता है, इसलिए दाल & चावल खोजने पर & को %26 भेजना पड़ता है, वरना सर्वर को एक की जगह दो पैरामीटर दिखते हैं।

बस इतना ही काम है: किसी मान को URL के अंदर सुरक्षित रखना, URL का मतलब बदले बिना। यह न कम्प्रेशन है, न एन्क्रिप्शन, न सुरक्षा फ़िल्टर।

कोई अक्षर %XX कैसे बनता है

एन्कोडिंग अक्षरों पर नहीं, बाइट्स पर होती है। पहले टेक्स्ट UTF-8 बाइट्स में बदलता है, फिर हर बाइट जिसे एन्कोड करना है, % और उसके हेक्स मान के रूप में लिखा जाता है।

ASCII अक्षर एक बाइट का होता है, इसलिए स्पेस (बाइट 32, हेक्स 20) बनता है %20। ASCII से बाहर के अक्षर UTF-8 में दो से चार बाइट लेते हैं, और हर बाइट का अपना कोड होता है:

• न → बाइट E0 A4 A8 → %E0%A4%A8
• ₹ → बाइट E2 82 B9 → %E2%82%B9
• 😀 → बाइट F0 9F 98 80 → %F0%9F%98%80

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

आरक्षित, अनारक्षित, और संदर्भ क्यों मायने रखता है

RFC 3986 URL के अक्षरों को दो समूहों में बाँटता है।

अनारक्षित अक्षर — A–Z a–z 0–9 - . _ ~ — को कभी एन्कोड करने की ज़रूरत नहीं होती। ऐसा करना मान्य है पर बेकार है, और अच्छा एन्कोडर इन्हें नहीं छूता।

आरक्षित अक्षर — : / ? # [ ] @ ! $ & ' ( ) * + , ; = — URL की बनावट तय करते हैं। इन्हें एन्कोड करना है या नहीं, यह इस पर निर्भर है कि ये कहाँ हैं। पाथ के हिस्सों के बीच का / स्लैश ही रहना चाहिए; पैरामीटर में भेजे फ़ाइल नाम के अंदर का / %2F बनना चाहिए। इसलिए "URL एन्कोड करने" का कोई एक सही तरीका नहीं है: हर हिस्से को उसकी जगह के हिसाब से एन्कोड किया जाता है।

encodeURIComponent बनाम encodeURI

JavaScript में दो बिल्ट-इन फ़ंक्शन हैं, और ग़लत वाला चुनना URL की सबसे आम गड़बड़ी है।

a&b=c जैसे मान पर encodeURI चलाएँ तो & और = बचे रहते हैं, और एक पैरामीटर दो बन जाता है। पूरे URL पर encodeURIComponent चलाएँ तो हर / और : एस्केप हो जाता है और लिंक, लिंक नहीं रहता। नियम: URL को हिस्सों से बनाएँ और हर मान को encodeURIComponent से एन्कोड करें — या बेहतर, यह काम URLSearchParams पर छोड़ दें।

दूसरी भाषाओं में भी यही बँटवारा है: Python में quote और quote_plus, PHP में rawurlencode और urlencode। हमारा URL एन्कोडर और डिकोडर दोनों मोड देता है ताकि आप अपने इनपुट पर फ़र्क़ देख सकें।

+ या %20: फ़ॉर्म वाला अपवाद

पाथ में स्पेस %20 होता है और + बस प्लस चिह्न। लेकिन डिफ़ॉल्ट application/x-www-form-urlencoded टाइप से भेजे गए HTML फ़ॉर्म क्वेरी में स्पेस को + लिखते हैं, और सर्वर उसे वापस स्पेस में बदलते हैं।

दिक़्क़त तब आती है जब दोनों तरीके टकराते हैं। +91 98765 43210 जैसा नंबर बिना एन्कोड किए क्वेरी में डालें तो वह 91 98765 43210 बनकर पहुँचता है, क्योंकि सर्वर ने + को स्पेस पढ़ा। हल है प्लस को %2B लिखना, जो फ़ॉर्म के नियम मानने वाला हर एन्कोडर करता है। अगर पता न हो कि दूसरी तरफ़ कौन-सा तरीका चलता है, तो स्पेस के लिए %20 और प्लस के लिए %2B हमेशा सुरक्षित हैं।

डबल एन्कोडिंग और %2520 वाली गड़बड़ी

%25 ख़ुद प्रतिशत चिह्न का एन्कोडेड रूप है। इसलिए URL में %2520 दिखे, तो वह दूसरी बार एन्कोड हुआ %20 है: कोई मान पहले से एन्कोड होने के बाद फिर एन्कोडर से गुज़रा।

यह आम तौर पर किसी सीमा पर होता है — कोई फ़्रेमवर्क उस पैरामीटर को एन्कोड कर देता है जिसे कॉल करने वाला कोड पहले ही एन्कोड कर चुका था, या रीडायरेक्ट URL को दूसरे URL में डालने के लिए एक बार एन्कोड किया जाता है और फिर कोई लाइब्रेरी दोबारा करती है। दिखने वाला असर: 404, शाब्दिक %20 की खोज, या प्रतिशत चिह्नों से भरा फ़ाइल नाम।

दो बार डिकोड करने से मूल मिल जाता है, पर असली हल दूसरा एन्कोडर ढूँढकर हटाना है। ठीक एक बार एन्कोड करें — उसी समय जब मान URL में डाला जाए।

एन्कोडिंग न एस्केपिंग है, न एन्क्रिप्शन

परसेंट-एन्कोडिंग किसी मान को URL के अंदर सुरक्षित बनाती है। HTML, JavaScript या SQL के लिए यह कुछ नहीं करती। सर्वर जैसे ही %3Cscript%3E डिकोड करता है, उसके पास फिर से सामान्य <script> होता है, इसलिए आउटपुट को उसकी मंज़िल के हिसाब से एस्केप करना और डेटाबेस क्वेरी में पैरामीटर इस्तेमाल करना अब भी ज़रूरी है।

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

जब डिकोडिंग गड़बड़ हो

URL की ज़्यादातर समस्याएँ इनमें से एक होती हैं:

• "URIError: malformed URI sequence"। किसी % के बाद दो हेक्स अंक नहीं हैं, या बाइट्स सही UTF-8 नहीं हैं। असली प्रतिशत चिह्न ख़ुद %25 के रूप में भेजना होता है।
• अक्षर अजीब चिह्न या � बनकर आते हैं। बाइट्स एक कैरेक्टर सेट में लिखे और दूसरे में पढ़े गए। पक्का करें कि दोनों तरफ़ UTF-8 हो।
• कोई पैरामीटर & पर कट जाता है। मान एन्कोड नहीं हुआ, या encodeURIComponent की जगह encodeURI से हुआ।
• प्लस चिह्न स्पेस बन जाते हैं। फ़ॉर्म डिकोडिंग ने + को स्पेस माना। असली प्लस को %2B लिखें।
• %2520, %253D वग़ैरह। डबल एन्कोडिंग: दूसरा एन्कोडर ढूँढें।

URL को किसी डिकोडर में पेस्ट करें और हर क्वेरी पैरामीटर अलग से देखें — आम तौर पर कुछ सेकंड में समस्या साफ़ दिख जाती है।

संबंधित टूल और गाइड:

• URL एन्कोडर और डिकोडर - टेक्स्ट या पूरा URL परसेंट-एन्कोड करें, %XX को टेक्स्ट में बदलें और हर पैरामीटर देखें।
• Base64 एनकोडर और डिकोडर - टेक्स्ट को Base64 में बदलें या वापस डिकोड करें, URL-safe आउटपुट और सही UTF-8 के साथ।
• Base64 समझें: एन्कोडिंग और डिकोडिंग असल में कैसे काम करती हैं

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