यूआरएल एन्कोडर

यूआरएल एन्कोडर एक मुफ़्त टूल है, जो किसी स्ट्रिंग को उस फॉर्म-एन्कोडेड रूप में बदलता है जिसका इस्तेमाल यूआरएल क्वेरी पैरामीटर और वेब पर मौजूद दूसरे टेक्स्ट-आधारित डेटा में होता है।

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

यूआरएल एन्कोडिंग उन वर्णों को प्रतिशत चिह्न और उसके बाद हेक्साडेसिमल अंकों से बदल देती है जिनका यूआरएल में विशेष अर्थ होता है। इससे टेक्स्ट को ऐसे सिस्टम से गुज़ारा जा सकता है जो केवल सीमित वर्णों को स्वीकार करते हैं।

उदाहरण के लिए, एम्परसैंड क्वेरी पैरामीटर को अलग करता है। इसलिए अगर एम्परसैंड किसी वैल्यू का हिस्सा है, तो उसे %26 के रूप में एन्कोड करना होगा। स्पेस को भी खास तरीके से संभालना पड़ता है। यह टूल PHP के urlencode फ़ंक्शन का इस्तेमाल करता है, जो स्पेस को प्लस चिह्न में बदल देता है।

पहले: tea and cake

बाद में: tea+and+cake

यूआरएल-एन्कोडेड टेक्स्ट आपको इन जगहों पर मिल सकता है:

• वेब फॉर्म से सबमिट की गई क्वेरी स्ट्रिंग में;
• ऐसे टेक्स्ट वाली डेटा URI में जिसे उसके मूल रूप में शामिल नहीं किया जा सकता;
• ईमेल संदेशों में शामिल लिंक में;
• JSON पेलोड में सेव की गई यूआरएल वैल्यू में;
• वेब ऐप्लिकेशन के रीडायरेक्ट और कॉलबैक पैरामीटर में;
• अंतरराष्ट्रीयकृत डोमेन से जुड़े यूआरएल में, हालांकि डोमेन नाम के लिए प्रतिशत एन्कोडिंग के बजाय Punycode की ज़रूरत पड़ सकती है।

यूआरएल एन्कोडिंग, एन्क्रिप्शन नहीं है और इससे जानकारी गोपनीय नहीं होती। प्रतिशत-एन्कोडेड यूआरएल वैल्यू देखने वाला कोई भी व्यक्ति उसे डिकोड कर सकता है।

यूआरएल एन्कोडर का इस्तेमाल कैसे करें?

जिस स्ट्रिंग को एन्कोड करना है उसे दर्ज करें, टूल चलाएं और बदली हुई वैल्यू को URL एन्कोडेड नतीजे वाले फ़ील्ड में देखें। केवल वैल्यू को एन्कोड करें, उसके आसपास के उद्धरण चिह्न या व्याख्या वाले टेक्स्ट को नहीं।

यह प्रक्रिया सर्वर पर होती है। आपका इनपुट HTTPS के ज़रिए सर्वर तक जाता है और सेव नहीं किया जाता। फिर भी, पासवर्ड, सेशन टोकन या निजी व्यक्तिगत डेटा को यूआरएल में डालने से बचें, क्योंकि वेब पते ब्राउज़र इतिहास, एनालिटिक्स सिस्टम और सर्वर लॉग में दिखाई दे सकते हैं।

इस प्रक्रिया को उलटने के लिए यूआरएल डिकोडर का इस्तेमाल करें। अगर दोनों दिशाओं में समान कैरेक्टर एन्कोडिंग और फॉर्म-एन्कोडिंग नियम इस्तेमाल किए गए हों, तो सही ढंग से डिकोड की गई वैल्यू मूल टेक्स्ट से मेल खानी चाहिए।

पूरा यूआरएल एन्कोड करूं या केवल पैरामीटर की वैल्यू?

आम तौर पर हर पैरामीटर की वैल्यू को एन्कोड करें, पूरे यूआरएल को नहीं। पूरे पते को एन्कोड करने पर कोलन, फ़ॉरवर्ड स्लैश, प्रश्न चिह्न और बराबर चिह्न जैसे संरचनात्मक वर्ण भी बदल जाएंगे।

मान लें कि खोज की वैल्यू green tea & coffee है। इसका एन्कोडेड रूप green+tea+%26+coffee होगा, जिसे पैरामीटर के नाम के बाद रखा जा सकता है। पूरा पता एन्कोड करने पर वे विभाजक छिप जाएंगे जिनकी मदद से ब्राउज़र उसकी स्कीम, होस्ट, पाथ और क्वेरी स्ट्रिंग पहचानता है।

इस टूल में इस्तेमाल किया गया urlencode, HTML फॉर्म जैसे क्वेरी पैरामीटर के लिए उपयुक्त है। हालांकि, कुछ API और पाथ सेगमेंट RFC 3986 के नियम अपनाते हैं, जिनमें स्पेस को + के बजाय %20 लिखा जाता है। जांच लें कि डेटा पाने वाला सिस्टम + वाली फॉर्म एन्कोडिंग चाहता है या RFC 3986 शैली वाला %20।

यूआरएल एन्कोडिंग के उदाहरण

ASCII अक्षर और अंक पढ़ने योग्य बने रहते हैं। स्पेस प्लस चिह्न में बदल जाते हैं, जबकि आरक्षित विराम चिह्न और गैर-ASCII टेक्स्ट को एन्कोडेड बाइट के रूप में दिखाया जाता है।

• hello world, hello+world बन जाता है।
• tea & cake, tea+%26+cake बन जाता है।
• email=test@example.com, email%3Dtest%40example.com बन जाता है।
• 100% ready, 100%25+ready बन जाता है।
• अगर मूल टेक्स्ट UTF-8 में है, तो café, caf%C3%A9 बन जाता है।

उच्चारण चिह्न वाले अक्षरों और गैर-लैटिन लिपियों को पहले कैरेक्टर एन्कोडिंग के ज़रिए बाइट में बदला जाता है। वेब पर आम तौर पर UTF-8 इस्तेमाल होता है। इसके बाद अनुमत सेट से बाहर की हर बाइट को अलग प्रतिशत एस्केप मिलता है। इसलिए स्क्रीन पर दिखने वाला एक वर्ण भी % से शुरू होने वाले कई समूह बना सकता है।

अंकों को किसी खास प्रक्रिया की ज़रूरत नहीं होती। खाली इनपुट से कोई एन्कोडेड सामग्री नहीं बनती। बहुत लंबा इनपुट काफ़ी बढ़ सकता है, क्योंकि हर एन्कोडेड बाइट तीन वर्णों की जगह लेती है।

यूआरएल डिकोडिंग नाकाम क्यों होती है या बेतरतीब टेक्स्ट क्यों दिखाती है?

डिकोडिंग आम तौर पर इसलिए नाकाम होती है क्योंकि इनपुट को अलग नियमों के तहत एन्कोड किया गया था, उसे एक से ज़्यादा बार एन्कोड किया गया था या वह अपेक्षित कैरेक्टर सेट में टेक्स्ट नहीं दर्शाता।

• स्पेस को संभालने का अलग तरीका। फॉर्म डिकोडर + को स्पेस मानता है, जबकि सख्त प्रतिशत डिकोडर इसे प्लस चिह्न के रूप में ही छोड़ सकता है।
• डबल एन्कोडिंग। %26 में मौजूद प्रतिशत चिह्न खुद %25 बन सकता है, जिससे %2526 मिलता है। ऐसे में एक बार डिकोड करने पर मूल एम्परसैंड के बजाय %26 मिलता है।
• गलत कैरेक्टर एन्कोडिंग। UTF-8 बाइट को किसी दूसरे कैरेक्टर सेट के रूप में डिकोड करने पर प्रतिस्थापन चिह्न या बिगड़े हुए अक्षर दिखाई दे सकते हैं।
• टेक्स्ट के बजाय बाइनरी डेटा। डिकोड की गई बाइट किसी इमेज, आर्काइव या दूसरी फ़ाइल का हिस्सा हो सकती हैं। उन्हें टेक्स्ट के रूप में दिखाने पर बेतरतीब सामग्री दिखाई देती है।
• गलत फ़ॉर्मेट या अल्फाबेट। URL-safe Base64, standard Base64 और प्रतिशत एन्कोडिंग अलग-अलग फ़ॉर्मेट हैं। Base64 टेक्स्ट पर यूआरएल डिकोडर लगाने से अपेक्षित वैल्यू वापस नहीं मिलेगी।

यूआरएल एन्कोडिंग में पैडिंग वर्ण नहीं होते। अगर डिकोडर पैडिंग न होने की त्रुटि दिखाता है, तो इनपुट शायद प्रतिशत-एन्कोडेड टेक्स्ट के बजाय Base64 या किसी दूसरे पैडिंग वाले फ़ॉर्मेट में है।

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

क्या अपरकेस और लोअरकेस प्रतिशत एस्केप एक जैसे होते हैं?

हां। प्रतिशत एस्केप में हेक्साडेसिमल अक्षरों के अपरकेस या लोअरकेस होने से कोई फ़र्क नहीं पड़ता। इसलिए %2F और %2f, दोनों फ़ॉरवर्ड स्लैश को दर्शाते हैं। एक जैसा रूप बनाए रखने के लिए अपरकेस हेक्साडेसिमल अंकों का इस्तेमाल करने की सलाह दी जाती है।

क्या यूआरएल एन्कोडिंग किसी अंतरराष्ट्रीय डोमेन नाम को बदल सकती है?

नहीं। é जैसे वर्ण वाले नाम के डोमेन लेबल के लिए आम तौर पर Internationalised Domain Name प्रोसेसिंग और xn-- से शुरू होने वाले ASCII Punycode रूप की ज़रूरत होती है। प्रतिशत एन्कोडिंग यूआरएल के दूसरे हिस्सों के लिए इस्तेमाल होती है और इसे उस रूपांतरण का विकल्प नहीं मानना चाहिए।

लाइन ब्रेक और टैब का क्या होता है?

टैब और लाइन ब्रेक की बाइट को प्रतिशत एन्कोड किया जाता है, क्योंकि वे किसी पारंपरिक यूआरएल वैल्यू में मूल रूप से शामिल नहीं हो सकतीं। टैब को आम तौर पर %09 के रूप में दिखाया जाता है, जबकि लाइन के अंत का रूप इस बात पर निर्भर करता है कि मूल सामग्री में LF वर्ण हैं या CRLF।

एन्कोडेड यूआरएल किसी ऐप्लिकेशन में पेस्ट करने पर भी काम क्यों नहीं करता?

ऐप्लिकेशन को कच्ची वैल्यू चाहिए हो सकती है और वह खुद उसे एन्कोड कर सकता है, जिससे डबल एन्कोडिंग हो जाती है। वह पूरे यूआरएल की लंबाई सीमा पार होने पर या पते के संरचनात्मक हिस्से में किसी आरक्षित वर्ण को एन्कोड किए जाने पर भी यूआरएल अस्वीकार कर सकता है। एन्कोड करने से पहले जांच लें कि ऐप्लिकेशन किस खास हिस्से की मांग कर रहा है।

क्या एन्कोडेड क्वेरी स्ट्रिंग का डेटा साझा करना सुरक्षित है?

नहीं। यूआरएल प्रतिशत एन्कोडिंग केवल डेटा का रूप बदलती है। ब्राउज़र और डेवलपर टूल मूल वैल्यू दिखा सकते हैं। लिंक साझा करने से पहले उसके क्वेरी पैरामीटर में ईमेल पते, अकाउंट संदर्भ, एक्सेस टोकन और ऐसी दूसरी जानकारी जांच लें जिसे सार्वजनिक नहीं किया जाना चाहिए।