URL एनकोडर
विशेष वर्णों को एनकोड करके टेक्स्ट को URL-सुरक्षित प्रारूप में परिवर्तित करें।
एनकोड करने के लिए टेक्स्ट दर्ज करें:
URL Encoder / Decoder का उपयोग कैसे करें
- 1
अपना टेक्स्ट या URL दर्ज करें
जिस टेक्स्ट को आप एनकोड करना चाहते हैं या जिस URL-एनकोडेड स्ट्रिंग को आप डिकोड करना चाहते हैं उसे इनपुट बॉक्स में पेस्ट करें।
- 2
encode या decode चुनें
टेक्स्ट को URL-सुरक्षित फ़ॉर्मैट में बदलने के लिए Encode चुनें, या percent-encoded टेक्स्ट को वापस सामान्य में बदलने के लिए Decode चुनें।
- 3
कन्वर्ज़न चलाएँ
इनपुट को चुनी हुई दिशा में तुरंत बदलने के लिए उसे प्रोसेस करें।
- 4
नतीजा कॉपी करें
एनकोड या डिकोड किया आउटपुट लिंक, क्वेरी स्ट्रिंग, या API अनुरोधों में इस्तेमाल के लिए कॉपी करें।
URL एन्कोडिंग और पर्सेंट-एन्कोडिंग की व्याख्या
URL एन्कोडिंग है क्या
URL एन्कोडिंग, जिसे अधिक सटीक रूप से पर्सेंट-एन्कोडिंग कहते हैं, वह तंत्र है जो किसी URL को ऐसे वर्ण ले जाने देता है जिन्हें वह अन्यथा दर्शा ही नहीं सकता। एक URL ASCII वर्णों के एक छोटे समूह तक सीमित होता है, और उन वर्णों में से कई का कोई विशेष संरचनात्मक अर्थ होता है। पर्सेंट-एन्कोडिंग किसी भी समस्याग्रस्त वर्ण को एक पर्सेंट चिह्न और उसके बाद उसके बाइट मान के दो हेक्साडेसिमल अंकों से बदल देती है, इसलिए एक स्पेस बन जाता है %20 और एक हैश बन जाता है %23।
नियम RFC 3986 में परिभाषित हैं, वह मानक जो URI सिंटैक्स को नियंत्रित करता है। लक्ष्य सरल है: यह सुनिश्चित करना कि किसी URL के भीतर रखा गया मान ठीक उसी रूप में प्रेषित और पार्स हो जैसा इरादा था, बिना किसी भटके हुए वर्ण के किसी सीमांकक समझ लिए जाने या रास्ते में किसी सॉफ़्टवेयर द्वारा गिरा दिए जाने के।
आरक्षित बनाम अनारक्षित वर्ण
RFC 3986 वर्णों को समूहों में बाँटता है। अनारक्षित समूह हमेशा सुरक्षित है और कभी एन्कोड नहीं किया जाता: अक्षर A-Z और a-z, अंक 0-9, और चार चिह्न हाइफ़न (-), पूर्णविराम (.), अंडरस्कोर (_), और टिल्ड (~)। ये बिना छुए गुज़र जाते हैं क्योंकि इनका कोई संरचनात्मक अर्थ नहीं होता और ये किसी URL में हर जगह वैध हैं।
आरक्षित समूह वह विराम-चिह्न है जो किसी URL के हिस्सों को सीमांकित करता है: सामान्य सीमांकक : / ? # [ ] @ और उप-सीमांकक ! $ और & ' ( ) * + , ; =। ये वर्ण विभाजकों के रूप में वैध हैं, लेकिन जब वे किसी विभाजक के बजाय किसी मान के भीतर आते हैं, तो उन्हें पर्सेंट-एन्कोड करना ज़रूरी है ताकि कोई पार्सर उन्हें ग़लत न पढ़े। उदाहरण के लिए, किसी क्वेरी मान के भीतर एक एम्परसैंड को %26 बनना ही पड़ता है, वरना उसे किसी नए पैरामीटर की शुरुआत के रूप में पढ़ा जाएगा।
UTF-8 बाइट आधार
पर्सेंट-एन्कोडिंग बाइटों पर काम करती है, सीधे वर्णों पर नहीं, और आधुनिक URL बाइट-स्रोत के रूप में UTF-8 इस्तेमाल करते हैं। एक ASCII वर्ण एक अकेला बाइट होता है, इसलिए एक एन्कोड किया ASCII वर्ण एक पर्सेंट-एस्केप होता है। ASCII से बाहर का कोई वर्ण पहले अपने UTF-8 बाइट अनुक्रम के रूप में व्यक्त किया जाता है, और फिर हर बाइट को अलग से पर्सेंट-एन्कोड किया जाता है, जिससे प्रति बाइट एक एस्केप बनता है।
लहजे वाला अक्षर é इसका मानक उदाहरण है। UTF-8 में यह दो बाइट 0xC3 और 0xA9 है, इसलिए यह पर्सेंट-एन्कोड होकर %C3%A9 बन जाता है — एक दृश्य वर्ण के लिए दो एस्केप। यूरो चिह्न, UTF-8 में तीन बाइट, बन जाता है %E2%82%AC। यही वजह है कि ग़ैर-लैटिन पाठ एन्कोड होने पर इतना फैल जाता है: हर वर्ण अपनी UTF-8 लंबाई के अनुसार दो, तीन, या चार पर्सेंट-एस्केप में बदल सकता है।
हल किया हुआ उदाहरण: एक खोज-मान को एन्कोड करना
मान लीजिए आप वाक्यांश "Q&A: cats + dogs" को किसी क्वेरी स्ट्रिंग में रखना चाहते हैं। अक्षर, अंक, और कोलन के आस-पास का पाठ शब्दों के रूप में बने रहते हैं, लेकिन असुरक्षित और आरक्षित वर्ण एस्केप हो जाते हैं। स्पेस बनता है %20, एम्परसैंड बनता है %26, कोलन बनता है %3A, और प्लस चिह्न बनता है %2B, क्योंकि एक शाब्दिक प्लस को अन्यथा फ़ॉर्म डेटा में एक स्पेस के रूप में पढ़ा जाएगा।
परिणाम है Q%26A%3A%20cats%20%2B%20dogs। किसी लिंक में ?q=Q%26A%3A%20cats%20%2B%20dogs के रूप में डाले जाने पर, सर्वर इसे वापस बिल्कुल मूल वाक्यांश में डिकोड कर देता है। ध्यान दीजिए कि हर वह आरक्षित वर्ण जो डेटा के रूप में था, सीमांकक के रूप में नहीं, उसे यात्रा झेलने के लिए एन्कोड करना ही पड़ा।
स्पेस: %20 बनाम प्लस चिह्न
स्पेस की एक प्रसिद्ध विचित्रता है। पथ में और किसी URL के अधिकांश हिस्से में, एक स्पेस %20 के रूप में एन्कोड होता है। लेकिन HTML फ़ॉर्म प्रस्तुतियों और कई क्वेरी स्ट्रिंग द्वारा इस्तेमाल किए जाने वाले application/x-www-form-urlencoded फ़ॉर्मेट में, एक स्पेस परंपरागत रूप से एक प्लस चिह्न (+) के रूप में एन्कोड होता है। दोनों परंपराएँ सक्रिय उपयोग में हैं, जो उलझन का एक बार-बार आने वाला स्रोत है।
व्यावहारिक परिणाम यह है कि फ़ॉर्म-शैली के डेटा में एक शाब्दिक प्लस चिह्न को खुद %2B के रूप में एन्कोड करना ज़रूरी है, ताकि उसे किसी स्पेस के रूप में न समझा जाए। जब आप डिकोड करते हैं, तो आपको पता होना चाहिए कि स्ट्रिंग किस परंपरा से बनी थी: किसी फ़ॉर्म मान में एक प्लस का मतलब है एक स्पेस, जबकि कहीं और एक प्लस का मतलब आमतौर पर एक शाब्दिक प्लस होता है। यह टूल मानक पर्सेंट-एन्कोडिंग संभालता है ताकि आपके मान साफ़-सुथरे ढंग से राउंड-ट्रिप करें।
एक पूरे URL को एन्कोड करना बनाम एक अकेले मान को
JavaScript दो फलन उजागर करता है जो दो अलग कामों से मेल खाते हैं, और ग़लत वाला चुनना एक क्लासिक बग है। encodeURI एक पूरे URL के लिए है: यह संरचनात्मक वर्ण : / ? # & = को बरक़रार रखता है ताकि URL काम करता रहे, और केवल स्पेस जैसे स्पष्ट रूप से अवैध वर्णों को ही एन्कोड करता है। encodeURIComponent डेटा के एक अकेले टुकड़े के लिए है, जैसे एक क्वेरी मान या एक पथ खंड: यह आरक्षित सीमांककों को भी एस्केप करता है, ताकि कोई अंतर्निहित स्लैश या एम्परसैंड आस-पास के URL को न तोड़ सके।
यह टूल कंपोनेंट-शैली की एन्कोडिंग करता है — encodeURIComponent व्यवहार — जो आपके द्वारा नियंत्रित सीमांककों के बीच किसी अविश्वसनीय मान को डालने के लिए सुरक्षित डिफ़ॉल्ट है: यह आरक्षित सीमांककों को भी एस्केप करता है, ताकि कोई अंतर्निहित स्लैश या एम्परसैंड आस-पास के URL को न तोड़ सके। इसका तालमेल यह है कि आपको यहाँ कोई पूरा पता पेस्ट नहीं करना चाहिए, क्योंकि यह संरचनात्मक : / ? # & = वर्णों को भी एस्केप कर देगा और लिंक को बिगाड़ देगा। किसी पूरे URL को एन्कोड करने के लिए, हर अलग-अलग मान या पथ खंड को एन्कोड कीजिए और फिर पूरा पता खुद जोड़िए।
दोहरी-एन्कोडिंग की ग़लती
दोहरी-एन्कोडिंग सबसे आम पर्सेंट-एन्कोडिंग बग है। यह तब होती है जब पहले से एन्कोड किए पाठ को दूसरी बार एन्कोड किया जाता है। इसका कारण खुद पर्सेंट चिह्न है: एक पर्सेंट एक आरक्षित वर्ण है, इसलिए उसे एन्कोड करने से %20 बन जाता है %2520, क्योंकि आगे वाला % बन जाता है %25 और 20 वैसा ही रहता है। एक ऐसा मान जो दो बार एन्कोड हो चुका है, वह इच्छित स्पेस के बजाय अंतिम उपयोगकर्ता को %2520 जैसे शाब्दिक एस्केप अनुक्रम दिखाएगा।
इससे बचने के लिए ठीक एक बार एन्कोड कीजिए, उसी क्षण जब आप URL बनाते हैं, और किसी ऐसी स्ट्रिंग को जिसमें पहले से पर्सेंट-एस्केप हों, एन्कोडर से फिर कभी न चलाइए। अगर आप %25 के बाद कुछ ऐसा देखें जो किसी और एस्केप जैसा लगे, तो आप लगभग निश्चित रूप से दोहरी-एन्कोडेड डेटा देख रहे हैं, और इसका समाधान है उसे एक बार और डिकोड करना या अपने कोड से अतिरिक्त एन्कोडिंग चरण हटाना।
आप इसका उपयोग कहाँ करेंगे
पर्सेंट-एन्कोडिंग हर उस जगह है जहाँ कोई मान किसी URL के भीतर यात्रा करता है। खोज और फ़िल्टर के लिए क्वेरी स्ट्रिंग बनाना, उपयोगकर्ता-दर्ज पाठ वाले लिंक रचना, REST API को पैरामीटर भेजना, किसी return_url पैरामीटर के भीतर रीडायरेक्ट लक्ष्य अंतर्निहित करना, और ऐसे अनुरोधों पर हस्ताक्षर करना जिन्हें बाइट-दर-बाइट मेल खाना चाहिए — ये सब सही एन्कोडिंग पर निर्भर करते हैं। वेब सर्वर और फ़्रेमवर्क आने वाले URL को स्वचालित रूप से डिकोड कर देते हैं, इसलिए एन्कोड किया रूप आमतौर पर वह होता है जिसे आप पढ़ने के बजाय बनाते हैं।
एक उपयोगी आदत यह है कि किसी URL को जोड़ते समय हर गतिशील टुकड़े को अलग से एन्कोड कीजिए, बजाय पूरी स्ट्रिंग को एक ही बार में एन्कोड करने के। यह आपके सीमांककों को बरक़रार रखता है जबकि हर मान को सुरक्षित बनाता है, और यह उस कम-एन्कोडिंग को भी टाल देता है जो लिंक तोड़ती है और उस दोहरी-एन्कोडिंग को भी जो उन्हें भ्रष्ट करती है।
अक्सर पूछे जाने वाले प्रश्न
URL एनकोडिंग असल में क्या करती है?
क्या यह टूल encode और decode दोनों कर सकता है?
क्या यह विशेष अक्षरों और अन्य भाषाओं को संभालता है?
एक पूरे URL को एनकोड करने और एक अकेले मान को एनकोड करने में क्या अंतर है?
क्या मेरा डेटा निजी है और क्या यह टूल मुफ़्त है?
संबंधित टूल्स
इन उपयोगी टूल्स के साथ आगे बढ़ें