संक्षेप में: URL एन्कोडिंग (प्रतिशत-एन्कोडिंग) असुरक्षित वर्णों को %XX अनुक्रमों से बदल देती है ताकि लिंक स्पेस, उच्चारण-चिह्न और चिह्नों में टिके रहें। एक स्पेस %20 बनता है, एम्परसैंड %26। कुंजी यह जानना है कि पूरी URL कब एन्कोड करें बनाम केवल एक क्वेरी मान — और यह कि encodeURIComponent और encodeURI परस्पर विनिमेय नहीं हैं।
एक URL सुरक्षित रूप से केवल सीमित वर्ण-समुच्चय रख सकता है। बाक़ी सब — स्पेस, उच्चारण-चिह्न वाले अक्षर, और ?, &, #, = जैसे आरक्षित चिह्न — को प्रतिशत-एन्कोडेड होना चाहिए, वरना लिंक टूट जाता है या अनपेक्षित जगह इशारा करता है।

प्रतिशत-एन्कोडिंग वास्तव में क्या करती है
हर असुरक्षित वर्ण को एक प्रतिशत-चिह्न और उसके हेक्साडेसिमल बाइट-मान से बदल दिया जाता है। स्पेस %20 है, एम्परसैंड %26, प्रश्नचिह्न %3F। डिकोडिंग इस प्रक्रिया को उलट देती है, हर वैध %XX को मूल वर्ण में लौटाकर।
स्पेस के लिए %20 बनाम +
दोनों «स्पेस» का अर्थ दे सकते हैं, पर एक ही जगह नहीं। %20 पूरे URL पथ और क्वेरी में उपयोग होने वाला प्रतिशत-एन्कोडेड स्पेस है। धन-चिह्न + केवल application/x-www-form-urlencoded संदर्भ (फ़ॉर्म सबमिशन और क्वेरी स्ट्रिंग) में स्पेस दर्शाता है, अन्यत्र इसे शाब्दिक माना जाता है। संशय में, %20 अधिक सुरक्षित व सार्वभौमिक विकल्प है।
encodeURIComponent बनाम encodeURI
यही वह अंतर है जो उलझाता है। URL में डाले जाने वाले एकल मान के लिए encodeURIComponent उपयोग करें — जैसे ?q=hello%20world में खोज-शब्द। यह & और = जैसे आरक्षित वर्णों को एन्कोड करता है ताकि उन्हें URL संरचना न समझ लिया जाए। पूरी URL के लिए ही encodeURI उपयोग करें, जहाँ उन आरक्षित वर्णों को अपना संरचनात्मक अर्थ बनाए रखना चाहिए। पूरी URL को encodeURIComponent से एन्कोड करना उसके अपने :// और ? बिगाड़ देगा; एकल पैरामीटर को encodeURI से एन्कोड करना ख़तरनाक वर्णों को बिना-एस्केप छोड़ देता है।
कब एन्कोड करें
- उपयोगकर्ता इनपुट से क्वेरी स्ट्रिंग बनाते समय (खोज-शब्द, फ़िल्टर, नाम)।
- किसी लिंक को
?redirect=या?url=पैरामीटर के रूप में दूसरे लिंक में रखते समय। - स्पेस या उच्चारण-चिह्न वाले फ़ाइल-नाम या पथ संभालते समय।
- ऐसे लिंक को डिबग करते समय जो लोकल में चले पर साझा करने पर टूटे।
URL एन्कोडिंग Base64 नहीं है
ये अलग समस्याएँ हल करती हैं। प्रतिशत-एन्कोडिंग असुरक्षित वर्णों को URL के भीतर सुरक्षित बनाती है; Base64 बाइनरी डेटा को सघन ASCII स्ट्रिंग में फिर से एन्कोड करता है, और लिंक में जाने पर उसके आउटपुट को भी URL-एन्कोडिंग चाहिए। ग़लत चुनना ऐसे लिंक देता है जो एन्कोडेड दिखते हैं पर काम नहीं करते।
एक व्यावहारिक वर्कफ़्लो
कच्चा मान URL एन्कोडर / डिकोडर में पेस्ट करें ताकि पैरामीटर एन्कोड करें या संदिग्ध %XX स्ट्रिंग डिकोड करें — यह वैध अनुक्रम डिकोड करता है और अवैध को चुपचाप बिगाड़ने के बजाय संकेत देता है। यदि वही सामग्री Base64 से भी गुज़रती है, तो Base64 एन्कोडर / डिकोडर से जाँचें ताकि दोनों चरण सही क्रम में लगें।
बचने योग्य आम ग़लतियाँ
- पूरी URL को
encodeURIComponentसे एन्कोड कर उसकी संरचना तोड़ना। - यह मानना कि
+URL में हर जगह स्पेस है। - दोहरी एन्कोडिंग — पहले से एन्कोडेड स्ट्रिंग को फिर एन्कोडर से गुज़ारना।
- प्रतिशत-एन्कोडिंग को Base64 से भ्रमित करना।
हिस्सों को एन्कोड करें, पूरे को नहीं, और स्पेस, उच्चारण-चिह्न या नेस्टेड URL वाला लिंक सही-सलामत पहुँचेगा।