URL में « encoder » और « decoder » का क्या अर्थ है?
URL की एन्कोडिंग (« url encode », « urlencode ») पते में हर निषिद्ध अक्षर — स्पेस, एक्सेंट, एम्परसैंड, प्लस चिह्न — को % के बाद उस बाइट के दो हेक्साडेसिमल अंक वाली सीक्वेंस में बदल देता है। URL की डीकोडिंग (« url decode », « decoder url ») इन सीक्वेंस को उलटा पढ़ता है: बाइट दोबारा जोड़े जाते हैं और फिर घोषित एन्कोडिंग — ज़्यादातर UTF-8 — के अनुसार अक्षरों में बदले जाते हैं। यही जोड़ी लोग तब ढूँढते हैं जब वे « encoder decoder url » या « percent encoding online » टाइप करते हैं।
percent-encoding न तो कंप्रेशन है न ही एन्क्रिप्शन: एक्सेंट वाला शब्द दोगुना लंबा हो जाता है, और कोई भी उसे आँखों से पढ़ सकता है। इसका एक ही काम है — किसी भी बाइट को URL में पहुँचाना, जो डिफ़ॉल्ट रूप से केवल ASCII के एक उपसमूह की अनुमति देती है। उल्टा, Base64 पूरी तरह टेक्स्ट वाले चैनलों में बाइट ले जाने के काम आता है — दोनों दिखने में मिलते-जुलते हैं लेकिन आपस में बदले नहीं जा सकते।
URL को percent-encoding में कैसे एन्कोड करें
चरण 1: टेक्स्ट को चुने गए कैरेक्टर सेट के अनुसार बाइट में बदला जाता है, डिफ़ॉल्ट रूप से UTF-8। चरण 2: हर बाइट के लिए यह देखा जाता है कि उससे मेल खाता अक्षर चुने गए स्कोप की अनुमत अक्षरों की सूची में है या नहीं। चरण 3: अगर है तो वह ज्यों का त्यों कॉपी हो जाता है; नहीं तो इसके बजाय यह बनता है %XX, जहाँ XX उस बाइट के दो हेक्साडेसिमल अंक हैं। चरण 4: अगर स्पेस को + वाला विकल्प चालू हो, तो बाइट 32 को प्लस चिह्न से बदल दिया जाता है, न कि %20.
ठोस उदाहरण: « café & été » को कंपोनेंट स्कोप में एन्कोड करने पर मिलता है caf%C3%A9%20%26%20%C3%A9t%C3%A9। इस टेक्स्ट को एन्कोडर में बस टाइप करें: परिणाम, इनपुट साइज़, आउटपुट साइज़ और ओवरहेड कुंजी छोड़ने से पहले ही दिख जाते हैं।
चार एन्कोडिंग स्कोप
यह कंपोनेंट स्कोप केवल अक्षर, अंक और - _ . ! ~ * ' ( ) : यह किसी पैरामीटर के मान जैसी है, और यह मेल खाती है encodeURIComponent। यह क्वेरी स्ट्रिंग अतिरिक्त रूप से एम्परसैंड और बराबरी के चिह्न भी रखती है, ताकि पूरी query string पुनर्निर्माण हो सके। यह पाथ सेगमेंट की अनुमति है / : @ & = + $ , ; , ताकि स्लैश न टूटें। पूर्ण URL और जोड़ती है ?, #, [ और ] : लगभग कुछ भी एस्केप नहीं होता, सिर्फ़ स्पेस और गैर-ASCII अक्षर बदलते हैं, अर्थात %XX.
एन्कोड किए गए URL को कैसे डीकोड करें
डीकोडिंग स्ट्रिंग को बाएँ से दाएँ पढ़ती है: प्रतिशत चिह्न के बाद दो हेक्साडेसिमल अंक से एक बाइट बनता है, बाकी हर अक्षर चुनी गई एन्कोडिंग के अनुसार रूपांतरण के बाद कॉपी हो जाता है। फिर बाइट जोड़कर अक्षर बनाए जाते हैं — « é » के लिए दो बाइट, « 日 » के लिए तीन, किसी emoji के लिए चार। « डीकोड » टैब हर मिली सीक्वेंस, उसकी स्थिति, उसके बाइट और संबंधित टेक्स्ट दिखाता है।
अगर प्रतिशत चिह्न के बाद दो मान्य अंक नहीं हैं तो त्रुटि साफ़ दिखती है: अधूरी सीक्वेंस या अमान्य हेक्साडेसिमल अक्षर। « % ठीक करें » बटन अलग-थलग प्रतिशत चिह्नों को बदलकर यह बना देता है %25, जिससे स्ट्रिंग बिना कोई जानकारी खोए डीकोड हो जाती है — आंशिक रूप से एस्केप किए गए URL को संभालने का सबसे सुरक्षित विकल्प।
स्पेस: %20 या + — फ़ॉर्म का नियम
%20 सख्त percent-encoding वाला स्पेस है: यह पाथ, क्वेरी, फ़्रैगमेंट और हेडर में काम करता है। संकेत +, केवल उस फ़ॉर्मेट में स्पेस है application/x-www-form-urlencoded जिसे HTML फ़ॉर्म और परंपरागत रूप से query strings इस्तेमाल करती हैं। बाकी जगह यह सिर्फ़ प्लस चिह्न रहता है — और चूँकि इसे आसानी से गलत समझा जाता है, कोई मान एन्कोड करते समय इसे %2B जैसे ही कोई मान एन्कोड करता है।
व्यवहार में: किसी फ़ॉर्म फ़ील्ड भरने या किसी <form> का व्यवहार दोहराने के लिए, « स्पेस को + »चुनें। रीडायरेक्ट URL, canonical या शेयर किए गए लिंक के लिए हमेशा %20। डीकोडर + को डिफ़ॉल्ट रूप से स्पेस मानता है और आप इस व्यवहार को एक क्लिक में बंद कर सकते हैं।
RFC 3986: unreserved, sub-delim और gen-delim
RFC 3986 ASCII अक्षरों को तीन श्रेणियों में बाँटता है। गैर-आरक्षित अक्षर — अक्षर, अंक, - _ . ~ — हमेशा ज्यों के त्यों रखे जाते हैं। सब-डिलिमिटर ! $ & ' ( ) * + , ; = और जनरिक डिलिमिटर : / ? # [ ] @ संरचनात्मक अर्थ रखते हैं: ये अथॉरिटी, पाथ, क्वेरी और फ़्रैगमेंट को अलग करते हैं। बाकी सब कुछ — स्पेस, उद्धरण चिह्न, एंगल ब्रैकेट, कर्ली ब्रैकेट, प्रतिशत चिह्न — को एन्कोड करना होता है।
यही श्रेणियाँ « RFC 3986 & संदर्भ » टैब अक्षर-दर-अक्षर दिखाता है: किसी टाइल पर क्लिक करके उसका हेक्साडेसिमल कोड, उसकी श्रेणी और उसे बरकरार रखने वाले स्कोप देखें। यह सबसे तेज़ संदर्भ है इस सवाल का जवाब पाने के लिए « क्या मुझे इस अक्षर को एस्केप करना चाहिए? »।
एक्सेंट वाले अक्षर, emoji और UTF-8
URL केवल सुरक्षित ASCII बाइट ले जाती है, इसलिए U+007F से आगे का हर अक्षर एन्कोड करना होता है। UTF-8 में « é » का मान है C3 A9 और यह बनता है %C3%A9, « 日 » तीन बाइट का है और तीन सीक्वेंस बनाता है, एक emoji चार बाइट लेता है और आठ एन्कोड किए गए अक्षरों में बदलता है। अगर परिणाम लंबा लगे तो यह बग नहीं है: यह सभी प्रोटोकॉल के साथ संगतता की कीमत है। अंत में मूल कैरेक्टर सेट का ध्यान रखें — Latin-1 में एन्कोड की गई स्ट्रिंग को UTF-8 में डीकोड करने पर गलत अक्षर बनते हैं, इसीलिए « डीकोड » टैब में ये चार विकल्प दिए गए हैं।
encodeURIComponent हमेशा क्यों काफी नहीं है
encodeURIComponent सब कुछ एन्कोड करता है, सिवाय A-Z a-z 0-9 - _ . ! ~ * ' ( ), जो किसी पैरामीटर के मान के लिए ठीक है लेकिन पूरी URL तोड़ देता है, क्योंकि यह स्लैश, कॉलन और एम्परसैंड भी एस्केप कर देता है। encodeURI उल्टा काम करता है: यह URL की संरचना बनाए रखता है लेकिन स्पेस और एक्सेंट होने देता है, इसलिए सादे टेक्स्ट पर यह विफल हो जाता है। दोनों व्यवहार यहाँ कवर हैं — और भी बहुत कुछ, क्योंकि « क्वेरी स्ट्रिंग » स्कोप और « पाथ सेगमेंट » स्कोप दोनों के बीच की दूरी पाट देते हैं।
Percent-encoding और Base64: दो अलग उपकरण
percent-encoding बाइट-दर-बाइट बदलता है और मूल टेक्स्ट को पढ़ने लायक रखता है, लेकिन लंबाई काफी बढ़ जाती है। Base64 बाइट तीन-तीन के समूह में 64 अक्षरों के अल्फ़ाबेट में लिखता है: छोटा लेकिन पूरी तरह अपठनीय, और बिना URL-safe वेरिएंट के URL में इस्तेमाल लायक नहीं। « क्रॉस एन्कोडिंग » टैब दोनों को एक ही नज़र में दिखाता है, साथ में हेक्साडेसिमल बाइट, HTML एंटिटी और एस्केप की गई JSON स्ट्रिंग — कॉपी करने से पहले सही रूप चुनने के लिए।
आम गलतियाँ: डबल एन्कोडिंग और अकेला %
सबसे आम गलती है एक ही स्ट्रिंग को दो बार एस्केप कर देना: एक स्पेस के लिए पहले %20, फिर %2520, और सर्वर को सचमुच « %20 » ही मिलता है। दूसरी गलती प्रतिशत चिह्न को भूल जाना है, जिसे बदलकर यह बनना चाहिए %25 — अन्यथा डीकोडर उसे किसी सीक्वेंस की शुरुआत समझ लेता है और क्रैश या कट जाता है। अंत में, किसी फ़ॉर्म पैरामीटर में + को बिना एस्केप छोड़ना ऐसा है जैसे आपने माँगे बिना एक स्पेस जोड़ दिया हो। डीकोडर गलत बनी सीक्वेंस बताता है, और « % ठीक करें » बटन दूसरे मामले को बिना किसी नुकसान के ठीक कर देता है।
एन्कोड किए गए URL कहाँ छिपे रहते हैं
ट्रैकिंग query strings में UTM, में redirect_uri और स्थिति OAuth, में webhooks जिनके लक्षित URL में नेस्टेड पैरामीटर होते हैं, callback URL हस्ताक्षरित, सर्वर लॉग में, sitemaps और canonical में, <a href> क्लाइंट-साइड पर बनाए गए, JWT जिनका payload Base64URL में है, data: और हेडर Location, और GET से सबमिट हर HTML फ़ॉर्म में। एक सेकंड में एन्कोड और डीकोड करना आने पर एक स्ट्रिंग के लिए टर्मिनल खोलना नहीं पड़ता।
परफ़ॉर्मेंस और बेस्ट प्रैक्टिस
ब्राउज़र में एन्कोडिंग और डीकोडिंग लीनियर हैं और कई मेगाबाइट पर भी कोई खास लागत नहीं देते: हर अक्षर केवल एक बार प्रोसेस होता है, न कोई रिकर्शन, न प्रति-अक्षर एलोकेशन। असली परेशानी सिर्फ़ डबल एन्कोडिंग है — सहेजने से पहले हमेशा राउंड-ट्रिप जाँचें — और कई किलोबाइट लंबी URLs, जो 2 000 अक्षर से आगे प्रॉक्सी द्वारा अक्सर काट दी जाती हैं। उत्पादित स्ट्रिंग के बगल में इस्तेमाल किया गया स्कोप दर्ज रखें: « कंपोनेंट » और « पूर्ण URL » एक ही टेक्स्ट पर अलग परिणाम देते हैं।
किसके लिए अनुशंसित
back-end और front-end डेवलपर (query strings, रीडायरेक्ट, OAuth), इंटीग्रेटर और तकनीकी लेखक (UTM लिंक, canonical, ट्रैकिंग), सिस्टम एडमिन और DevOps (webhooks, हस्ताक्षरित URLs, लॉग), टेस्टर और पेंटेस्टर (पैरामीटर फ़ज़िंग, फ़िल्टर बाइपास), छात्र (UTF-8, ASCII और RFC 3986 को समझने के लिए), और हर उस व्यक्ति को जिसे एक चाहिए ऑनलाइन URL एन्कोडर डीकोडर , तेज़, पूर्ण और निजी — साथ में Base64 एन्कोडर डीकोडर और JSON फ़ॉर्मेटर.