मुफ़्त URL एन्कोडर / डिकोडर

URL एन्कोडिंग वास्तव में क्या करती है

URL एन्कोडिंग (जिसे परसेंट-एन्कोडिंग भी कहा जाता है) वह तंत्र है जिसका उपयोग वेब किसी URL में मनमाने वर्ण डेटा को समायोजित करने के लिए करता है। URL मूल रूप से एक छोटे ASCII वर्णमाला के लिए डिज़ाइन किए गए थे (अक्षर, अंक और विराम चिह्नों का एक छोटा सेट) और इस वर्णमाला से बाहर के वर्ण (रिक्त स्थान, उच्चारण-चिह्नित अक्षर, ऐम्परसैंड, स्लैश जो पथ-विभाजक नहीं हैं, इमोजी, कुछ भी सिरिलिक, CJK या अरबी) HTTP, सर्वर लॉग, ब्राउज़र पता-पट्टियों, कॉपी-पेस्ट हैंडलर्स और शेल पाइप्स से सुरक्षित यात्रा करने के लिए एस्केप किए जाने चाहिए। एन्कोडिंग नियम सीधा है: वर्ण के UTF-8 बाइट अनुक्रम को लें, प्रत्येक बाइट को परसेंट चिह्न के बाद दो हेक्साडेसिमल अंकों के रूप में लिखें। एक रिक्त स्थान (एक बाइट, 0x20) %20 बन जाता है। एक ऐम्परसैंड (0x26) %26 बन जाता है। यूरो चिह्न € (तीन UTF-8 बाइट E2 82 AC) %E2%82%AC बन जाता है। एन्कोडेड रूप उत्क्रमणीय है (वेब पर हर URL पार्सर इसे डिकोड करना समझता है) और परिणाम एक स्ट्रिंग है जिसमें केवल “सुरक्षित” ASCII वर्ण होते हैं।

एन्कोडिंग नियम का संक्षिप्त इतिहास

परसेंट-एन्कोडिंग सम्मेलन RFC 1738 (“Uniform Resource Locators (URL)”, टिम बर्नर्स-ली, लैरी मासिंटर और मार्क मैक्काहिल, दिसंबर 1994) तक जाता है, जो IETF द्वारा प्रकाशित पहला औपचारिक URL विनिर्देश था। RFC 1738 ने मूल “आरक्षित” वर्ण सेट (URL में संरचनात्मक अर्थ रखने वाले वर्ण जिन्हें डेटा के रूप में उपयोग किए जाने पर एन्कोड किया जाना चाहिए) और मूल “अनारक्षित” सेट (वर्ण जिन्हें कभी एन्कोडिंग की आवश्यकता नहीं) को परिभाषित किया। विनिर्देश को RFC 2396 (बर्नर्स-ली, फील्डिंग, मासिंटर, अगस्त 1998) में काफ़ी संशोधित किया गया और फिर (निश्चित रूप से) RFC 3986 (“Uniform Resource Identifier (URI): Generic Syntax”, बर्नर्स-ली, फील्डिंग, मासिंटर, जनवरी 2005) में, जो आज भी औपचारिक URI विनिर्देश है। RFC 3986 ने अनारक्षित सेट को टिल्ड वर्ण (~) तक विस्तारित किया, IRI में गैर-ASCII वर्णों के लिए एन्कोडिंग के रूप में UTF-8 को औपचारिक रूप दिया, और इस बारे में नियमों को कड़ा किया कि आरक्षित वर्णों को कब परसेंट-एन्कोड किया जाना चाहिए बनाम कब वैसा ही छोड़ा जाना चाहिए। गैर-ASCII URI के लिए, RFC 3987 (“Internationalized Resource Identifiers”, ड्यूर्स्ट और सूइग्नार्ड, जनवरी 2005) ने IRI विस्तार को परिभाषित किया जो URL को नेटिव यूनिकोड वर्णों को धारण करने देता है, IRI रूप को UTF-8 + परसेंट-एन्कोडिंग के माध्यम से मानक URI रूप पर मैप करते हुए। विशेष रूप से डोमेन नामों के लिए, RFC 3492 ने Punycode (कोस्टेलो, मार्च 2003) को परिभाषित किया, जो DNS में यूनिकोड डोमेन लेबल (xn--exmpla-...) का प्रतिनिधित्व करने के लिए उपयोग किया जाने वाला एन्कोडिंग है, संरचनात्मक रूप से समान लेकिन एक अलग एल्गोरिथम का उपयोग करता है। आधुनिक वेब का वस्तुतः URL विनिर्देश WHATWG URL Living Standard है, जिसका संपादन ऐन वैन केस्टेरन करती हैं, जो ब्राउज़रों के वास्तविक व्यवहार को एन्कोड करता है, कभी-कभी व्यवहार में URL कैसे काम करते हैं इसके साथ पिछली-संगतता के लिए RFC 3986 से विचलित होते हुए।

आरक्षित, अनारक्षित और वे वर्ण जो हमेशा एन्कोड होते हैं

RFC 3986 URI वर्णों को तीन वर्गों में विभाजित करता है। अनारक्षित वर्णों: अक्षर A-Z a-z, अंक 0-9, और चार चिह्न - _ . ~: को कभी एन्कोडिंग की आवश्यकता नहीं होती और एन्कोडिंग पर वे कभी अर्थ प्राप्त नहीं करते। आरक्षित वर्णों: : / ? # [ ] @ ! $ & ' ( ) * + , ; =: का URL में संरचनात्मक अर्थ होता है (स्लैश पथ खंडों को अलग करता है, प्रश्न चिह्न क्वेरी का परिचय देता है, ऐम्परसैंड क्वेरी पैरामीटर अलग करता है, हैश फ़्रैगमेंट का परिचय देता है)। आरक्षित वर्ण अपनी संरचनात्मक भूमिका में बिना-एन्कोड दिखाई दे सकते हैं; जब वे साधारण डेटा के रूप में उपयोग किए जाते हैं तो उन्हें एन्कोड किया जाना चाहिए। अन्य सभी वर्ण: नियंत्रण वर्ण, रिक्त स्थान, स्वयं परसेंट और गैर-ASCII UTF-8 अनुक्रम का कोई भी बाइट, को हमेशा परसेंट-एन्कोड किया जाना चाहिए। परसेंट वर्ण विशेष है: डेटा के रूप में प्रकट होने पर इसे %25 के रूप में एन्कोड किया जाना चाहिए, क्योंकि URL संदर्भ में बिना-एन्कोडेड परसेंट एक परसेंट-एन्कोडेड एस्केप का परिचय देता है जिसे पार्सर डिकोड करने की कोशिश करेगा। उस चरण को छोड़ना कुछ सबसे आम URL-हैंडलिंग बग्स पैदा करता है।

encodeURI बनाम encodeURIComponent, किसका कब उपयोग करें

JavaScript दो अंतर्निहित एन्कोडर के साथ आता है, दोनों 1999 (ES3) से ECMAScript में मानकीकृत हैं। उनके बीच का चयन वेब कोड में सबसे आम URL-एन्कोडिंग निर्णय है, और गलत होने पर यह सूक्ष्म बग्स पैदा करता है जो सरल इनपुट पर परीक्षण पास कर लेते हैं लेकिन ऐम्परसैंड, हैश या स्लैश वाले वास्तविक उपयोगकर्ता डेटा पर टूट जाते हैं।

• encodeURIComponent: अनारक्षित सेट को छोड़कर सब कुछ एन्कोड करता है। इसका उपयोग तब करें जब आप एक एकल डेटा का टुकड़ा एन्कोड कर रहे हों जो URL में एम्बेड किया जाएगा, एक क्वेरी पैरामीटर मान, एक पथ खंड, एक फ़्रैगमेंट पहचानकर्ता, एक फ़ॉर्म फ़ील्ड मान। स्ट्रिंग hello world&more hello%20world%26more बन जाती है, अंदर का ऐम्परसैंड एन्कोड हो जाता है, इसलिए जब URL को बाद में पढ़ा जाता है तो इसे क्वेरी-पैरामीटर विभाजक के रूप में पार्स नहीं किया जाता। यह “मेरे पास उपयोगकर्ता इनपुट है, मैं इसे URL में सुरक्षित रूप से रखना चाहता हूँ” के लिए सही उपकरण है।
• encodeURI: केवल उन वर्णों को एन्कोड करता है जो URL में कहीं भी अवैध हैं। यह जान-बूझकर आरक्षित वर्णों (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) को बरकरार छोड़ देता है क्योंकि वे संरचनात्मक काम कर रहे हो सकते हैं। इसका उपयोग तब करें जब आप एक पूरी URL एन्कोड कर रहे हों जिसकी संरचना पहले से जगह पर है, एक URL जिसमें अपने स्वयं के ? और & विभाजक हों, एक URL जिसमें पथ या क्वेरी में गैर-ASCII वर्ण हों जिन्हें URL व्याकरण को बाधित किए बिना एन्कोड करने की आवश्यकता हो। स्ट्रिंग https://example.com/search?q=hello world https://example.com/search?q=hello%20world बन जाती है, स्लैश और प्रश्न चिह्न संरक्षित रहते हैं, केवल रिक्त स्थान एन्कोड हो जाता है।

मानसिक नियम: डेटा के लिए encodeURIComponent, URL के लिए encodeURI। गलत का उपयोग करें और आप या तो URL संरचना तोड़ देंगे (पूरी URL पर encodeURIComponent उन स्लैश और ऐम्परसैंड को एस्केप कर देता है जिनकी आपको आवश्यकता थी) या उपयोगकर्ता इनपुट को एस्केप करने में विफल होंगे (क्वेरी मान पर encodeURI ऐम्परसैंड को जाने देता है और आपका डेटा कई पैरामीटर के रूप में पार्स हो जाता है)।

application/x-www-form-urlencoded, अन्य एन्कोडिंग

एक दूसरा, संबंधित एन्कोडिंग है जो विशेष रूप से HTML फ़ॉर्म प्रस्तुति के लिए उपयोग किया जाता है: application/x-www-form-urlencoded। यह URL परसेंट-एन्कोडिंग के लगभग समान दिखता है एक विवरण को छोड़कर, रिक्त स्थान %20 के बजाय + के रूप में एन्कोड किए जाते हैं। यह सम्मेलन मूल HTML फ़ॉर्म विनिर्देश से आता है और URL Living Standard में विशेष रूप से application/x-www-form-urlencoded सीरियलाइज़र के लिए संरक्षित है। फ़ॉर्म-एन्कोडेड डेटा के डिकोडर्स को सम्मेलन को उलटना होगा: फ़ॉर्म डेटा में एक शाब्दिक + को %2B के रूप में एन्कोड किया जाता है, और एन्कोडेड स्ट्रिंग में + रिक्त स्थान में डिकोड हो जाता है। JavaScript का URLSearchParams API इस सम्मेलन को स्वचालित रूप से संभालता है; encodeURIComponent नहीं करता, यह हमेशा रिक्त स्थानों को %20 के रूप में एन्कोड करता है। HTML फ़ॉर्म क्रिया के लिए हाथ से इकट्ठा की जाने वाली क्वेरी स्ट्रिंग्स के लिए, प्रत्येक मान पर अलग-अलग encodeURIComponent कॉल करने के बजाय URLSearchParams का उपयोग करें।

जब आपको वास्तव में इस उपकरण की आवश्यकता होती है

• API कॉल को डिबग करना। आप एक REST एंडपॉइंट को एक क्वेरी पैरामीटर के साथ हिट कर रहे हैं जिसमें रिक्त स्थान या विशेष वर्ण हैं और 400 त्रुटियाँ या अप्रत्याशित परिणाम वापस मिल रहे हैं। यहाँ पैरामीटर मान को एन्कोड करें, परिणाम को अपने अनुरोध में पेस्ट करें, और पुष्टि करें कि API इनपुट को सही ढंग से व्यवहार करता है।
• हाथ से एक साझा करने योग्य URL बनाना। खोज परिणाम पृष्ठ, SaaS डैशबोर्ड के फ़िल्टर्ड दृश्य, या पूर्व-भरे फ़ॉर्म के लिए एक डीप-लिंक बनाना, कहीं भी आपको URL में एक खोज क्वेरी या चयन स्थिति एम्बेड करने की आवश्यकता हो।
• कैप्चर की गई URL को डिकोड करना यह पढ़ने के लिए कि वास्तव में उसमें क्या है। एक लॉग की गई URL में %E2%9C%93%20done है, वह क्या डिकोड होता है? पेस्ट करें, डिकोड दबाएँ, ✓ done देखें।
• OAuth और वेबहुक URL। OAuth प्रवाह में redirect_uri पैरामीटर को सटीक रूप से परसेंट-एन्कोड किया जाना चाहिए; गलत होने पर अपारदर्शी “redirect_uri mismatch” त्रुटियाँ आती हैं। उपयोगकर्ता डेटा वाले क्वेरी पैरामीटर से युक्त वेबहुक URL को सावधानीपूर्ण एन्कोडिंग की आवश्यकता होती है।
• डाउनलोड लिंक में गैर-ASCII वर्णों वाले फ़ाइल नाम। café-menu.pdf नामक फ़ाइल का सीधा लिंक काम करने के लिए सभी ब्राउज़रों और शेल टूल्स में é को परसेंट-एन्कोड करने की आवश्यकता होती है।
• डेटाबेस कनेक्शन स्ट्रिंग्स। PostgreSQL, MySQL और समान डेटाबेस URL (postgres://user:p@ssw0rd@host/db) को पासवर्ड में @, :, / या अन्य आरक्षित वर्ण होने पर परसेंट-एन्कोड करने की आवश्यकता होती है जो URL पार्सर को भ्रमित कर देंगे।

सुरक्षा: एन्कोडिंग सौंदर्य से परे क्यों मायने रखती है

गलत URL एन्कोडिंग वेब कमज़ोरियों का एक पुराना स्रोत है। HTTP रिस्पॉन्स स्प्लिटिंग URL पैरामीटर में बिना-एन्कोडेड पंक्ति विरामों (CR, LF, %0D%0A) का शोषण करता है जो HTTP हेडर में परावर्तित होते हैं, हमलावर को मनमाने हेडर या यहाँ तक कि एक पूरी प्रतिक्रिया इंजेक्ट करने देते हैं। ओपन रीडायरेक्ट्स भोली URL हैंडलिंग का शोषण करते हैं जो रीडायरेक्ट करने से पहले उपयोगकर्ता-प्रदत्त URL को सही ढंग से डिकोड और मान्य नहीं करती। सर्वर-साइड रिक्वेस्ट फ़ोर्जरी (SSRF) URL अनुमति-सूचियों को बायपास करने के लिए एन्कोडेड वर्णों का दुरुपयोग कर सकता है, एक रेगेक्स जो “http://internal” को ब्लॉक करता है, “http://%69nternal” से चूक जाता है यदि सर्वर रेगेक्स जाँच के बाद डिकोड करता है। URL पैरामीटर के माध्यम से SQL इंजेक्शन स्वयं में एक URL-एन्कोडिंग समस्या नहीं है लेकिन तब बढ़ जाती है जब एकल उद्धरण और अन्य SQL मेटा-वर्ण डेटाबेस क्वेरी तक जीवित रह जाते हैं। 2000 के दशक की शुरुआत से OWASP की अनुशंसा रही है: अंदर आते समय सीमा पर एन्कोड करें, बाहर जाते समय सीमा पर डिकोड करें, एक ही बफ़र में एन्कोडेड और डिकोडेड रूपों को कभी न मिलाएँ। यह उपकरण ठीक एन्कोड/डिकोड चरण करता है, परिणाम के साथ आप क्या करते हैं यह आप पर निर्भर है, और सुरक्षा की ज़िम्मेदारी अनुप्रयोग परत पर है।

डबल एन्कोडिंग, सबसे आम बग

डबल एन्कोडिंग तब होती है जब पहले से एन्कोडेड स्ट्रिंग को फिर से एन्कोड किया जाता है। पहले से एन्कोडेड URL में रिक्त स्थान वर्ण %20 है; उसे फिर से एन्कोड करें और आपको %2520 मिलता है (क्योंकि % %25 में एन्कोड होता है)। जब प्राप्तकर्ता एक बार डिकोड करता है, तो उसे रिक्त स्थान के बजाय %20 वापस मिलता है। जब वे दो बार डिकोड करते हैं (दुर्लभ मामलों में जहाँ डबल-डिकोडिंग समर्थित है), तो उन्हें रिक्त स्थान मिलता है, लेकिन अधिकांश पार्सर ऐसा नहीं करते, और URL में पता-पट्टी में चुपचाप दृश्य %20 होता है। उपाय हमेशा है: यदि आप नहीं जानते कि इनपुट पहले से एन्कोडेड है या नहीं, तो पहले डिकोड करें, फिर ठीक एक बार एन्कोड करें। वही पैटर्न कोड में लागू होता है, एक ही स्ट्रिंग पर encodeURIComponent को कभी दो बार न कॉल करें। यदि आपको किसी मान को राउंड-ट्रिप करना ही है, तो नए संदर्भ के लिए फिर से एन्कोड करने से पहले पिछली एन्कोडिंग को डिकोड करें। इस उपकरण का स्वैप बटन निदान चक्र में मदद करता है: एक संदिग्ध URL पेस्ट करें, अंदर क्या है यह देखने के लिए डिकोड पर क्लिक करें, स्वैप पर क्लिक करें, कैनोनिकल एन्कोडेड रूप वापस पाने के लिए एन्कोड पर क्लिक करें।

गोपनीयता: केवल ब्राउज़र में निष्पादन

URL अक्सर संवेदनशील डेटा रखती हैं, क्वेरी पैरामीटर में प्रमाणीकरण टोकन, पथ खंडों में उपयोगकर्ता पहचानकर्ता, व्यक्तिगत संदर्भ वाली खोज क्वेरी, OAuth स्थिति मान, API कुंजियाँ शामिल करने वाली वेबहुक URL। सर्वर-साइड URL एन्कोडर अपने लॉग में उनमें पेस्ट की गई हर URL की एक प्रति लेते हैं। यह उपकरण JavaScript के अंतर्निहित encodeURIComponent, encodeURI, decodeURIComponent और decodeURI फ़ंक्शनों का उपयोग करता है जो आपके ब्राउज़र टैब में स्थानीय रूप से चलते हैं। कोई अपलोड चरण नहीं, कोई टेलीमेट्री नहीं, कोई लॉगिंग नहीं, एन्कोड पर क्लिक करते समय DevTools के नेटवर्क टैब में सत्यापित करें (कोई अनुरोध नहीं भेजा जाता), या लोड होने के बाद पृष्ठ को ऑफ़लाइन (एयरप्लेन मोड) ले जाएँ और एन्कोडर अभी भी काम करता है। टोकन, API कुंजियों, आंतरिक एंडपॉइंट्स वाली URL के लिए सुरक्षित, या कोई भी URL जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी नहीं देखना चाहेंगे।

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

मुझे कब पाठ को URL-एनकोड करना चाहिए?

जब भी आप उपयोगकर्ता इनपुट या विशेष वर्णों वाले डेटा को URL में एम्बेड करते हैं, क्वेरी स्ट्रिंग में खोज क्वेरी, पथ में फ़ाइल नाम, API अनुरोधों में पैरामीटर मान, OAuth प्रवाह में रीडायरेक्ट लक्ष्य। एन्कोडिंग के बिना, विशेष वर्ण या तो URL संरचना तोड़ देते हैं (मान में बिना-एस्केप किया & पैरामीटर विभाजक के रूप में पार्स हो जाता है) या सुरक्षा कमज़ोरियाँ पैदा करते हैं (बिना-एस्केप की गई पंक्ति विराम HTTP रिस्पॉन्स स्प्लिटिंग सक्षम करती है)। अंगूठे का नियम: कोई भी स्ट्रिंग जिसमें अक्षरों, अंकों और चार चिह्नों -_.~ के अलावा कुछ भी हो, URL में जाने से पहले एन्कोडिंग की आवश्यकता होती है।

डबल एनकोडिंग क्या है और मैं इससे कैसे बचूँ?

डबल एन्कोडिंग तब होती है जब पहले से एन्कोडेड पाठ को दूसरी बार एन्कोड किया जाता है, %20 को %2520 में बदलते हुए (क्योंकि स्वयं परसेंट वर्ण %25 के रूप में एन्कोड होता है)। एक बार डिकोड करने वाले प्राप्तकर्ताओं को मूल के बजाय आधा-डिकोड किया रूप वापस मिलता है। हमेशा: यदि आप नहीं जानते कि स्ट्रिंग पहले से एन्कोडेड है या नहीं, तो पहले डिकोड करें, फिर ठीक एक बार एन्कोड करें। कोड में, दूसरे encodeURIComponent के आउटपुट पर encodeURIComponent को कभी कॉल न करें।

क्या यह टूल संवेदनशील URL के लिए सुरक्षित है?

हाँ। एन्कोडर/डिकोडर JavaScript के अंतर्निहित फ़ंक्शनों का उपयोग करता है जो पूरी तरह से आपके ब्राउज़र में चलते हैं। आप जो URL पेस्ट करते हैं वह कभी नेटवर्क पार नहीं करती, एन्कोड पर क्लिक करते समय DevTools के नेटवर्क टैब में सत्यापित करें (कोई अनुरोध नहीं भेजा जाता), या लोड होने के बाद पृष्ठ को ऑफ़लाइन (एयरप्लेन मोड) ले जाएँ। OAuth टोकन, API कुंजियाँ, आंतरिक एंडपॉइंट पते या कोई भी मान जिसे आप तीसरे पक्ष के सर्वर पर लॉग नहीं देखना चाहेंगे, वाली URL के लिए सुरक्षित।

मेरे फ़ॉर्म डेटा में %20 के बजाय प्लस चिह्न क्यों हैं?

HTML फ़ॉर्म प्रस्तुति एक अलग लेकिन संबंधित एन्कोडिंग का उपयोग करती है जिसे application/x-www-form-urlencoded कहा जाता है, जो ऐतिहासिक सम्मेलन के अनुसार रिक्त स्थानों को %20 के बजाय + के रूप में एन्कोड करता है। दोनों रूप URL क्वेरी स्ट्रिंग्स में मान्य हैं; आधुनिक पार्सर दोनों को स्वीकार करते हैं। JavaScript का URLSearchParams API फ़ॉर्म-एन्कोडेड सम्मेलन का उपयोग करता है; encodeURIComponent हमेशा %20 का उपयोग करता है। यदि आपके डेटा को पुराने फ़ॉर्म-हैंडलिंग कोड के साथ अंतर-संचालन करना है, तो URLSearchParams का उपयोग करें; यदि यह कहीं और जा रहा है, तो दोनों रूप काम करते हैं।

गैर-ASCII वर्णों और इमोजी का क्या?

आधुनिक URL एन्कोडिंग UTF-8 का उपयोग करती है: प्रत्येक गैर-ASCII वर्ण को उसके मल्टी-बाइट UTF-8 प्रतिनिधित्व में परिवर्तित किया जाता है, फिर प्रत्येक बाइट को परसेंट-एन्कोड किया जाता है। यूरो चिह्न (€, तीन UTF-8 बाइट) %E2%82%AC बन जाता है; रॉकेट 🚀 जैसा एक इमोजी (चार बाइट) %F0%9F%9A%80 बन जाता है। RFC 3987 (IRI) और WHATWG URL Standard दोनों इस UTF-8-पहले सम्मेलन को औपचारिक रूप देते हैं। पुराने सिस्टम कभी-कभी Latin-1 या अन्य एन्कोडिंग का उपयोग करते थे; यदि आप पुरानी URL डिकोड कर रहे हैं और परिणाम भ्रमित दिखता है, तो स्रोत ने परसेंट-एन्कोडिंग से पहले एक अलग वर्ण एन्कोडिंग का उपयोग किया हो सकता है।

संबंधित टूल