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

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

सबसे आम URL एनकोडिंग ग़लती, काफ़ी अंतर से, किसी जोड़ी गई पूरी URL को ग़लत फ़ंक्शन से एनकोड करना है — `encodeURIComponent` इस्तेमाल करना, जो `/`, `:`, `&` और `?` सहित हर रिज़र्व्ड कैरेक्टर को किसी अकेली वैल्यू की बजाय पूरे पते पर एस्केप कर देता है। प्रोटोकॉल के बाद का `://`, `%3A%2F%2F` बन जाता है, क्वेरी पैरामीटर अलग करने वाला हर `&`, `%26` बन जाता है, और URL बिल्कुल भी URL नहीं रह जाती — यह किसी सर्वर द्वारा पार्स की जा सकने वाली किसी संरचना के बिना एक लंबी एनकोडेड स्ट्रिंग बन जाती है। सही तरीक़ा उल्टा क्रम है: पहले हर अकेली वैल्यू एनकोड करें — सर्च टर्म, रीडायरेक्ट डेस्टिनेशन, जो भी असली डेटा हो — और सिर्फ़ तभी उन पहले से एनकोड की वैल्यू को आस-पास की URL संरचना में डालें, बाद में जुड़े हुए सेट को कभी दोबारा एनकोड न करें।

यही ठीक वजह है कि यह टूल एक सामान्य "एनकोड करें" बटन की बजाय दो अलग मोड देता है: किसी अकेली वैल्यू को एनकोड करने के लिए कंपोनेंट मोड जो किसी URL का हिस्सा बनने वाली है, और पूरे पते को एनकोड करने के दुर्लभ मामले के लिए पूरा-URL मोड जबकि जान-बूझकर इसके संरचनात्मक कैरेक्टर बरक़रार रखे जाते हैं।

स्पेस के लिए दो अलग एनकोडिंग परंपराएँ आज भी सक्रिय इस्तेमाल में हैं, और ये एक-दूसरे की जगह इस्तेमाल नहीं हो सकतीं। पर्सेंट एनकोडिंग, सामान्य-मक़सद वाला स्टैंडर्ड, किसी स्पेस को `%20` के रूप में दर्शाता है और URL में कहीं भी वैध है — पाथ, क्वेरी स्ट्रिंग, हर जगह। स्पेस के लिए `+` परंपरा एक पुरानी और ख़ास तौर पर `application/x-www-form-urlencoded` कंटेंट टाइप इस्तेमाल करने वाले HTML फ़ॉर्म सबमिशन के लिए सीमित स्टैंडर्ड से आती है, और सिर्फ़ क्वेरी स्ट्रिंग के अंदर वैध है; किसी URL पाथ में दिखने वाला लिटरल `+` बिल्कुल भी स्पेस के रूप में नहीं समझा जाता, यह बस प्लस कैरेक्टर है। यह टूल हमेशा `%20` बनाता है, जो किसी भी संदर्भ में वैध है, और किसी एनकोडेड URL को वापस पढ़ते समय दोनों फ़ॉर्म को सही तरीक़े से डिकोड करता है।

पर्सेंट एनकोडिंग के नियम किसी भी URL पर लागू होते हैं चाहे उसे कोई भी बनाए या इस्तेमाल करे — किसी बैकएंड सर्विस द्वारा बनाया गया वेबहुक पेलोड, किसी मोबाइल ऐप द्वारा खोला गया डीप लिंक, किसी स्क्रिप्ट द्वारा जोड़ी गई API रिक्वेस्ट। जहाँ भी स्पेस, एम्परसेंड, या ग़ैर-ASCII कैरेक्टर रख सकने वाली कोई वैल्यू किसी URL स्ट्रिंग में डाली जाए, वही एनकोड-वैल्यू-को-डालने-से-पहले वाला नियम लागू होता है, यही वजह है कि यह ब्राउज़र जितनी ही बैकएंड और स्क्रिप्टिंग की चिंता है।