URL एन्कोडिंग और डिकोडिंग, डेवलपरों के लिए समझाई गई
किसी URL में एक स्पेस टाइप कीजिए, या कोई सिरिलिक शब्द, या कोई ऐसा एम्परसैंड जो पते के बजाय आपके डेटा का हिस्सा हो, और कुछ न कुछ टूटना तय है। वेब केवल ASCII अक्षरों के एक छोटे, पूर्वानुमेय समूह के लिए सुरक्षित परिवहन की गारंटी देता है। बाक़ी सब कुछ एक ऐसे फ़ॉर्मैट में लपेटा जाना ज़रूरी है जिस पर राउटर, सर्वर और ब्राउज़र सब सहमत हों। वह फ़ॉर्मैट है पर्सेंट-एन्कोडिंग, जिसे आम तौर पर URL एन्कोडिंग कहा जाता है, और यह पृष्ठ आपको टेक्स्ट को सीधे आपके ब्राउज़र में किसी भी दिशा में बदलने देता है।
पर्सेंट-एन्कोडिंग असल में क्या है
नियम यांत्रिक और पालन करने में आसान है। कोई भी ऐसा अक्षर जो ज्यों का त्यों नहीं दिख सकता, उसकी जगह एक % चिह्न और उसके बाद दो हेक्साडेसिमल अंक रख दिए जाते हैं जो उस अक्षर के बाइट मान को दर्शाते हैं। एक स्पेस %20 बन जाता है। एक प्लस चिह्न %2B बन जाता है। नंबर चिह्न %23 बन जाता है। जब कोई अक्षर कई बाइट्स पर मैप होता है, जैसा UTF-8 के अंतर्गत अधिकांश ग़ैर-ASCII टेक्स्ट करता है, तो आपको बस एक के बाद एक कई त्रिक मिल जाते हैं: यूरो चिह्न %E2%82%AC में बदल जाता है। डिकोडिंग इस प्रक्रिया को उलट देती है, हर त्रिक को वापस उसकी मूल बाइट में पढ़ते हुए।
यह परिपाटी URI विनिर्देश (RFC 3986) में परिभाषित है और यह जानबूझकर उबाऊ है। उबाऊपन ही असल बात है। ग्रह पर हर सुव्यवस्थित HTTP क्लाइंट और सर्वर इन्हीं नियमों को लागू करता है, इसलिए जो लिंक एक जगह सही ढंग से एन्कोड किया गया हो वह हर दूसरी जगह सही-सलामत पहुँचता है।
इसका अस्तित्व क्यों ज़रूरी है
URL दो तरह के अक्षर ढोते हैं जिनके काम बहुत अलग हैं। आरक्षित अक्षर जैसे /, ?, #, &, = और : संरचनात्मक होते हैं। वे एक पार्सर को बताते हैं कि पथ कहाँ ख़त्म होता है और क्वेरी स्ट्रिंग कहाँ शुरू होती है, या एक पैरामीटर कहाँ रुकता है और अगला कहाँ शुरू होता है। यदि आपके वास्तविक डेटा में इनमें से कोई चिह्न मौजूद हो, तो उसे एन्कोड किया जाना चाहिए ताकि पार्सर उसे विराम-चिह्न समझ न बैठे। A&B/2024 जैसा कोई ऑर्डर संदर्भ यदि कच्चा ही किसी क्वेरी स्ट्रिंग में डाल दिया जाए तो वह दो पैरामीटर और एक पथ खंड के रूप में ग़लत पढ़ा जाएगा।
फिर हैं असुरक्षित और ग़ैर-ASCII अक्षर: स्पेस, उद्धरण चिह्न, कोण कोष्ठक, उच्चारण-चिह्न वाले अक्षर, इमोजी, और साधारण ASCII श्रेणी के बाहर की हर चीज़। इनका किसी URL में ज्यों का त्यों दिखना ठीक नहीं, या तो इसलिए कि वे परिवहन में विकृत हो जाते हैं या इसलिए कि उनका कोई परिभाषित प्रतिनिधित्व नहीं है। इन्हें एन्कोड करना लिंक को साफ़ और पूर्वानुमेय रखता है, बजाय इसके कि परिणाम संयोग के भरोसे छोड़ दिया जाए।
यह असली काम में कहाँ दिखता है
क्वेरी स्ट्रिंग शास्त्रीय मामला है। आप ?key=... में जो भी मान जोड़ते हैं उसे एन्कोड किया जाना चाहिए ताकि उपयोगकर्ता का इनपुट संरचना को तोड़ न सके। यही बात application/x-www-form-urlencoded के रूप में भेजे गए HTML फ़ॉर्म सबमिशन पर भी लागू होती है, जहाँ ब्राउज़र फ़ील्ड मानों को स्वतः एन्कोड कर देता है (और, ऐतिहासिक परिपाटी से, स्पेस को %20 के बजाय + में बदल देता है)। आप इससे तब भी टकराएँगे जब आप ग़ैर-लैटिन शीर्षकों वाले पृष्ठों की ओर इशारा करने वाले लिंक बनाते हैं, जब API अनुरोध हाथ से रचते हैं, जब रीडायरेक्ट लक्ष्यों को पैरामीटर के रूप में पास करते हैं, और जब यह डीबग करते हैं कि एड्रेस बार में ठीक दिखने वाला अनुरोध सर्वर तक गड्डमड्ड क्यों पहुँचता है।
encodeURI बनाम encodeURIComponent
JavaScript दो एन्कोडर के साथ आता है, और ग़लत वाला चुनना एक आम बग है। फ़र्क दायरे का है। encodeURIComponent डेटा के किसी एक टुकड़े के लिए है, जैसे एक क्वेरी मान। यह लगभग सब कुछ एन्कोड कर देता है, जिसमें आरक्षित अक्षर /, ?, :, @, &, =, + और # भी शामिल हैं। जब डेटा को उन चिह्नों को साधारण टेक्स्ट के रूप में रखने की अनुमति हो, तो आपको ठीक यही चाहिए।
encodeURI एक पूरे पते के लिए है जिसे आप काम करता हुआ रखना चाहते हैं। यह संरचनात्मक अक्षरों को छोड़ देता है, इसलिए वे स्लैश, कोलन और प्रश्नचिह्न जो URL को बाँधे रखते हैं, बचे रहते हैं। इसे तब इस्तेमाल करें जब आपके पास एक पूरा URL हो और आप केवल स्पेस या ग़ैर-ASCII अक्षरों को साफ़ करना चाहते हों; जब भी आप किसी बड़े URL में कोई मान डाल रहे हों तो encodeURIComponent की ओर बढ़ें। एक सरल नियम: पूरे लिंक को encodeURI से एन्कोड करें, और जो हिस्से आप उसमें ठूँसते हैं उन्हें encodeURIComponent से।
सब कुछ आपकी मशीन पर ही रहता है
यह टूल पूरी तरह आपके ब्राउज़र में चलता है। आप जो टेक्स्ट पेस्ट करते हैं वह उन्हीं मानक रूटीनों से स्थानीय रूप से एन्कोड या डिकोड होता है और कभी किसी सर्वर तक नहीं जाता, जिससे यह टोकन, हस्ताक्षरित पैरामीटर या किसी भी ऐसी चीज़ के लिए सुरक्षित हो जाता है जिसे आप तार पर भेजना नहीं चाहेंगे। यदि आप अन्य टेक्स्ट रूपांतरणों के साथ काम करते हैं, तो Base64 कन्वर्टर इसके ठीक बगल में बैठता है, और आप ज़्यादा रोज़मर्रा के सहायकों के लिए डेवलपर टूल का पूरा सेट देख सकते हैं।
अक्सर पूछे जाने वाले सवाल
किसी URL में %20 का क्या मतलब है?
यह एक एन्कोडेड स्पेस है। स्पेस अक्षर किसी URL में ज्यों का त्यों अनुमत नहीं है, इसलिए उसकी जगह एक पर्सेंट चिह्न और हेक्साडेसिमल मान 20 रख दिया जाता है, जो एक स्पेस का बाइट मान है।
मुझे कभी-कभी %20 के बजाय एक प्लस चिह्न क्यों दिखता है?
application/x-www-form-urlencoded प्रकार का HTML फ़ॉर्म डेटा ऐतिहासिक परिपाटी से स्पेस को एक प्लस चिह्न के रूप में एन्कोड करता है। किसी सामान्य पथ या क्वेरी में, एक स्पेस %20 के रूप में एन्कोड होता है। दोनों अपने उचित संदर्भ में वापस एक स्पेस में डिकोड होते हैं।
मुझे encodeURI के बजाय encodeURIComponent कब इस्तेमाल करना चाहिए?
किसी ऐसे एकल मान के लिए encodeURIComponent इस्तेमाल करें जिसे आप किसी URL में डाल रहे हैं, जैसे कोई क्वेरी पैरामीटर, क्योंकि यह आरक्षित अक्षरों को भी एन्कोड करता है। किसी पूरे पते के लिए encodeURI इस्तेमाल करें जब आप उन स्लैश, कोलन और प्रश्नचिह्नों को बनाए रखना चाहते हों जो उसे बाँधे रखते हैं।
क्या URL एन्कोडिंग मेरे डेटा का अर्थ बदल देती है?
नहीं। एन्कोडिंग पूरी तरह उलटाने योग्य है। परिणाम को डिकोड करने पर ठीक मूल टेक्स्ट वापस मिलता है, बाइट दर बाइट, बशर्ते दोनों सिरों पर वही अक्षर सेट इस्तेमाल हो।
उच्चारण-चिह्नों या इमोजी जैसे ग़ैर-ASCII अक्षर कैसे सँभाले जाते हैं?
उन्हें पहले UTF-8 बाइट्स में बदला जाता है, फिर हर बाइट अपना ही पर्सेंट त्रिक बन जाती है। इसलिए एक उच्चारण-चिह्न वाला अक्षर या इमोजी एन्कोडेड आउटपुट में कई त्रिकों में फैल सकता है।
क्या इस टूल का उपयोग करते समय मेरा टेक्स्ट किसी सर्वर पर भेजा जाता है?
नहीं। एन्कोडिंग और डिकोडिंग पूरी तरह आपके ब्राउज़र में होती है। आप जो भी पेस्ट करते हैं वह अपलोड नहीं होता, इसलिए इसका उपयोग निजी या संवेदनशील स्ट्रिंग के साथ करना सुरक्षित है।