परिचय
पेश है, यूआरएल डिकोड ऐंड एन्कोड। यह एक आसान ऑनलाइन टूल है, जिसका काम इसके नाम से ही पता चल जाता है। यह यूआरएल एन्कोडिंग से डिकोड करने के साथ-साथ उसमें जल्दी और आसानी से एन्कोड करता है। यूआरएल बिना किसी परेशानी के आपके डेटा को एन्कोड करता है या उसे ऐसे फ़ॉर्मेट में डिकोड करता है जिसे इंसान पढ़ सकें।
यूआरएल एन्कोडिंग, जिसे "पर्सेंट-एन्कोडिंग" भी कहते हैं, यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (यूआरआई) में जानकारी को एन्कोड करने का एक तरीका है। हालाँकि इसे यूआरएल एन्कोडिंग कहते हैं, लेकिन असल में, इसे आमतौर पर यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (यूआरआई) सेट में ज़्यादा इस्तेमाल किया जाता है, जिसमें यूनिफ़ॉर्म रिसोर्स लोकेटर (यूआरएल) और यूनिफ़ॉर्म रिसोर्स नेम (यूआरएन), दोनों शामिल होते हैं। वैसे तो इसका इस्तेमाल "application/x-www-form-urlencoded" मीडिया टाइप का डेटा तैयार करने में भी किया जाता है, मगर अक्सर इसका इस्तेमाल HTTP रिक्वेस्ट में HTML फ़ॉर्म का डेटा सबमिट करने में भी किया जाता है।
एडवांस विकल्प
(*) इन विकल्पों को एक साथ चालू नहीं किया जा सकता, क्योंकि उससे मिलने वाला आउटपुट ज़्यादातर ऐप्लिकेशन के लिए मान्य नहीं होगा।यूआरएल एन्कोडिंग, जिसे "पर्सेंट-एन्कोडिंग" भी कहते हैं, यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (यूआरआई) में जानकारी को एन्कोड करने का एक तरीका है। हालाँकि इसे यूआरएल एन्कोडिंग कहते हैं, लेकिन असल में, इसे आमतौर पर यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (यूआरआई) सेट में ज़्यादा इस्तेमाल किया जाता है, जिसमें यूनिफ़ॉर्म रिसोर्स लोकेटर (यूआरएल) और यूनिफ़ॉर्म रिसोर्स नेम (यूआरएन), दोनों शामिल होते हैं। वैसे तो इसका इस्तेमाल "application/x-www-form-urlencoded" मीडिया टाइप का डेटा तैयार करने में भी किया जाता है, मगर अक्सर इसका इस्तेमाल HTTP रिक्वेस्ट में HTML फ़ॉर्म का डेटा सबमिट करने में भी किया जाता है।
एडवांस विकल्प
- कैरेक्टर सेट: हमारी वेबसाइट UTF-8 कैरेक्टर सेट का इस्तेमाल करती है, इसलिए आपका इनपुट डेटा उसी फ़ॉर्मेट में भेजा जाता है। अगर आप एन्कोडिंग से पहले, डेटा को किसी अन्य कैरेक्टर सेट में बदलना चाहते हैं, तो इस विकल्प को बदलें। ध्यान दें कि टेक्स्ट डेटा के मामले में, एन्कोडिंग स्कीम में कैरेक्टर सेट नहीं होता है, इसलिए आपको डिकोडिंग प्रक्रिया के दौरान सही सेट बताना पड़ सकता है। फ़ाइलों के लिए बाइनरी विकल्प डिफ़ॉल्ट होता है, जिसे किसी भी फ़ॉर्म में कन्वर्ट नहीं किया जाएगा। सादे टेक्स्ट डॉक्यूमेंट को छोड़कर, हर चीज़ के लिए यह विकल्प ज़रूरी है।
- न्यूलाइन सेपरेटर: Unix और Window सिस्टम अलग-अलग लाइन ब्रेक कैरेक्टर का इस्तेमाल करते हैं, इसलिए एन्कोडिंग से पहले, आपके डेटा में मौजूद किसी एक वैरिएंट को चुने गए विकल्प से बदल दिया जाएगा। फ़ाइल सेक्शन के लिए, यह कुछ हद तक मायने नहीं रखता है, क्योंकि फ़ाइलों में पहले से ही उनके हिसाब से सेपरेटर होते हैं। हालाँकि, आप तय कर सकते हैं कि "हर लाइन को अलग से एन्कोड करें" और "लाइनों को टुकड़ों में बाँटें" फ़ंक्शन के लिए कौन-सा सेपरेटर इस्तेमाल करना है।
- हर लाइन को अलग से एन्कोड करें: यहाँ तक कि न्यूलाइन कैरेक्टर भी अपने पर्सेंट-एन्कोडिंग वाले फ़ॉर्म में बदल जाते हैं। अगर आप लाइन ब्रेक से अलग की गई कई अलग-अलग डेटा एंट्री को एन्कोड करना चाहते हैं, तो इस विकल्प का इस्तेमाल करें। (*)
- लाइनों को टुकड़ों में बाँटें: एन्कोड किया गया डेटा बिना किसी व्हाइटस्पेस वाला टेक्स्ट बन जाएगा, इसलिए अगर आप उसे कई लाइनों में बाँटना चाहते हैं, तो यह विकल्प चुनें। लागू की गई कैरेक्टर लिमिट, MIME (RFC 2045) स्पेसिफ़िकेशन में दी गई है। इसमें कहा गया है कि एन्कोड की गई लाइनें 76 कैरेक्टर से ज़्यादा लंबी नहीं होनी चाहिए। (*)
- लाइव मोड: इस विकल्प को चालू करने पर, आपके ब्राउज़र के बिल्ट-इन JavaScript फ़ंक्शंस की मदद से, डाला गया डेटा तुरंत एन्कोड हो जाता है। इसके लिए हमारे सर्वर पर कोई जानकारी नहीं भेजी जाती। फ़िलहाल, यह मोड सिर्फ़ UTF-8 कैरेक्टर सेट को सपोर्ट करता है।
पूरी तरह सुरक्षित
हमारे सर्वर के साथ होने वाले सभी संचार सुरक्षित SSL एन्क्रिप्टेड कनेक्शन (https) के ज़रिए आते हैं। हम अपलोड की गई फ़ाइलें प्रोसेस होने के तुरंत बाद, उन्हें अपने सर्वर से हटा देते हैं। इसके अलावा, डाउनलोड करने की पहली कोशिश या 15 मिनट तक कोई ऐक्टिविटी न होने (इनमें से जो भी कम हो) के तुरंत बाद, डाउनलोड की जा सकने वाली फ़ाइल हटा दी जाती है। हम सबमिट किए गए डेटा या अपलोड की गई फ़ाइलों के कॉन्टेंट को न तो किसी भी तरह अपने पास रखते हैं, न ही उनकी जाँच करते हैं। ज़्यादा जानकारी के लिए, नीचे दी गई हमारी निजता नीति पढ़ें।
बिल्कुल मुफ़्त
हमारा टूल मुफ़्त में इस्तेमाल किया जा सकता है। अब से, आपको ऐसे आसान कामों के लिए कोई सॉफ़्टवेयर डाउनलोड करने की ज़रूरत नहीं है।
यूआरएल एन्कोडिंग की जानकारी
यूआरआई कैरेक्टर के टाइप
यूआरआई में या तो रिज़र्व्ड कैरेक्टर या फिर अनरिज़र्व्ड कैरेक्टर (या पर्सेंट-एन्कोडिंग के हिस्से के रूप में पर्सेंट कैरेक्टर) इस्तेमाल किए जा सकते हैं। रिज़र्व्ड कैरेक्टर वे कैरेक्टर होते हैं जिनका कभी-कभी खास मतलब होता है। उदाहरण के लिए, फ़ॉरवर्ड स्लैश कैरेक्टर का इस्तेमाल यूआरएल (या आमतौर पर, यूआरआई) के अलग-अलग हिस्सों को अलग करने के लिए किया जाता है। अनरिज़र्व्ड कैरेक्टर का ऐसा कोई खास मतलब नहीं होता है। पर्सेंट-एन्कोडिंग का इस्तेमाल करते हुए, रिज़र्व्ड कैरेक्टर को स्पेशल कैरेक्टर सिक्वेंस इस्तेमाल करके दिखाया जाता है। यूआरआई और यूआरआई स्कीम से जुड़े स्पेसिफ़िकेशन के हर नए रिवीज़न के साथ, रिज़र्व्ड और अनरिज़र्व्ड कैरेक्टर के सेट थोड़ा बदल गए हैं। साथ ही, वे परिस्थितियाँ भी थोड़ी बदल गई हैं जिनमें कुछ रिज़र्व्ड कैरेक्टर का खास मतलब होता है।
| RFC 3986 सेक्शन 2.2 रिज़र्व्ड कैरेक्टर (जनवरी 2005) | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
! |
* |
' |
( |
) |
; |
: |
@ |
& |
= |
+ |
$ |
, |
/ |
? |
# |
[ |
] |
| RFC 3986 सेक्शन 2.3 अनरिज़र्व्ड कैरेक्टर (जनवरी 2005) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
A |
B |
C |
D |
E |
F |
G |
H |
I |
J |
K |
L |
M |
N |
O |
P |
Q |
R |
S |
T |
U |
V |
W |
X |
Y |
Z |
a |
b |
c |
d |
e |
f |
g |
h |
i |
j |
k |
l |
m |
n |
o |
p |
q |
r |
s |
t |
u |
v |
w |
x |
y |
z |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
- |
_ |
. |
~ |
||||||||||||
यूआरआई में अन्य कैरेक्टर पर्सेंट-एन्कोडेड होने चाहिए।
रिज़र्व्ड कैरेक्टर की पर्सेंट-एन्कोडिंग करना
जब किसी खास संदर्भ में, रिज़र्व्ड सेट के किसी कैरेक्टर ("रिज़र्व्ड कैरेक्टर") का खास मतलब ("खास उद्देश्य") हो और यूआरआई स्कीम में लिखा हो कि उस कैरेक्टर का इस्तेमाल किसी अन्य उद्देश्य के लिए करना ज़रूरी है, तो वह कैरेक्टर पर्सेंट-एन्कोडेड होना चाहिए। रिज़र्व्ड कैरेक्टर की पर्सेंट-एन्कोडिंग करने का मतलब है कि कैरेक्टर को ASCII में उससे जुड़ी बाइट वैल्यू में कन्वर्ट करना और फिर, उस वैल्यू को हेक्साडेसिमल अंकों की जोड़ी की तरह लिखना। उसके बाद, पर्सेंट साइन ("%") से शुरू होने वाले अंकों को यूआरआई में रिज़र्व्ड कैरेक्टर की जगह इस्तेमाल किया जाता है। (नॉन-ASCII कैरेक्टर को आमतौर पर UTF-8 में उसके बाइट सीक्वेंस में कन्वर्ट किया जाता है और फिर, हर बाइट वैल्यू को ऊपर बताए गए तरीके से लिखा जाता है।)
जैसे, अगर रिज़र्व्ड कैरेक्टर "/" को किसी यूआरआई के "पाथ" कॉम्पोनेंट में इस्तेमाल किया जाता है, तो उसका खास मतलब यह है कि वह पाथ सेगमेंट्स के बीच का डीलिमिटर है। अगर, दी गई यूआरआई स्कीम के मुताबिक, पाथ सेगमेंट में "/" होना चाहिए, तो सेगमेंट में "/" के बजाय तीन कैरेक्टर "%2F" (या "%2f") का इस्तेमाल किया जाना चाहिए।
| पर्सेंट-एन्कोडिंग के बाद रिज़र्व्ड कैरेक्टर | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
! |
# |
$ |
& |
' |
( |
) |
* |
+ |
, |
/ |
: |
; |
= |
? |
@ |
[ |
] |
%21 |
%23 |
%24 |
%26 |
%27 |
%28 |
%29 |
%2A |
%2B |
%2C |
%2F |
%3A |
%3B |
%3D |
%3F |
%40 |
%5B |
%5D |
ऐसे रिज़र्व्ड कैरेक्टर, जिनका किसी खास संदर्भ में कोई खास उद्देश्य नहीं है, वे भी पर्सेंट-एन्कोडेड हो सकते हैं, लेकिन अर्थ की दृष्टि से अन्य कैरेक्टर से अलग नहीं होते हैं।
उदाहरण के लिए, यूआरआई के "क्वेरी" कॉम्पोनेंट ("?" कैरेक्टर के बाद के हिस्से) में, "/" को अब भी रिज़र्व्ड कैरेक्टर माना जाता है, लेकिन आमतौर पर इसका कोई खास उद्देश्य नहीं होता है (जब तक कि किसी यूआरआई स्कीम में कुछ और न लिखा हो)। जब कैरेक्टर का कोई खास उद्देश्य नहीं होता है, तो उसे पर्सेंट-एन्कोड करने की ज़रूरत नहीं होती है।
जो यूआरआई सिर्फ़ इस मामले में अलग होते हैं कि रिज़र्व्ड कैरेक्टर पर्सेंट-एन्कोडेड है या नहीं, उन्हें आमतौर पर बराबर (एक ही रिसोर्स को दर्शाने वाला) नहीं माना जाता है। उन्हें बराबर तभी माना जाता है, जब उस रिज़र्व्ड कैरेक्टर का कोई खास उद्देश्य न हो। यह फ़ैसला अलग-अलग यूआरआई स्कीम में रिज़र्व्ड कैरेक्टर के लिए बनाए गए नियमों पर निर्भर करता है।
अनरिज़र्व्ड कैरेक्टर की पर्सेंट-एन्कोडिंग करना
अनरिज़र्व्ड सेट के कैरेक्टर को कभी भी पर्सेंट-एन्कोड करने की ज़रूरत नहीं होती है।
जो यूआरआई सिर्फ़ इस मामले में अलग होते हैं कि अनरिज़र्व्ड कैरेक्टर पर्सेंट-एन्कोडेड है या नहीं, वे परिभाषा के मुताबिक बराबर होते हैं, लेकिन, हो सकता है कि यूआरआई प्रोसेसर असल में उन्हें हमेशा बराबर न मानें। उदाहरण के लिए, यूआरआई कंज़्यूमर को "%41" को "A" से अलग नहीं मानना चाहिए ("%41" "A" की पर्सेंट-एन्कोडिंग है) या "%7E" को "~" से अलग नहीं मानना चाहिए, लेकिन कुछ ऐसा करते हैं। इसलिए, ज़्यादा से ज़्यादा इंटरऑपरेबिलिटी के लिए, यूआरआई प्रोड्यूसर को अनरिज़र्व्ड कैरेक्टर की पर्सेंट-एन्कोडिंग करने से मना किया जाता है।
पर्सेंट कैरेक्टर की पर्सेंट-एन्कोडिंग करना
चूँकि पर्सेंट ("%") कैरेक्टर पर्सेंट-एन्कोडेड ऑक्टेट के इंडिकेटर के तौर पर काम करता है, इसलिए उसकी पर्सेंट-एन्कोडिंग "%25" होनी चाहिए, ताकि उस ऑक्टेट को यूआरआई के अंदर डेटा की तरह इस्तेमाल किया जा सके।
आर्बिट्रेरी डेटा की पर्सेंट-एन्कोडिंग करना
ज़्यादातर यूआरआई स्कीम में आर्बिट्रेरी डेटा, जैसे आईपी एड्रेस या फ़ाइल सिस्टम पाथ, को यूआरआई के कॉम्पोनेंट के तौर पर दिखाना शामिल होता है। यूआरआई स्कीम के स्पेसिफ़िकेशन में, यूआरआई कैरेक्टर और उन कैरेक्टर की सभी संभावित डेटा वैल्यू के बीच की मैपिंग साफ़ तौर पर बताई जानी चाहिए, लेकिन ऐसा अक्सर नहीं होता।
बाइनरी डेटा
1994 में RFC 1738 के प्रकाशन के बाद से, यह तय किया गया है कि जो स्कीम यूआरआई में बाइनरी डेटा दिखाने के लिए कहती हैं, उन्हें डेटा को 8-बिट बाइट्स में बाँटना होगा और हर बाइट को ऊपर बताए गए तरीके से पर्सेंट-एन्कोड करना होगा। उदाहरण के लिए, बाइट वैल्यू 0F (हेक्साडेसिमल) को "%0F" लिखा जाना चाहिए, लेकिन बाइट वैल्यू 41 (हेक्साडेसिमल) को "A" या "%41" लिखा जा सकता है। अल्फ़ान्यूमेरिक और अन्य अनरिज़र्व्ड कैरेक्टर के लिए आमतौर पर अनएन्कोडेड कैरेक्टर इस्तेमाल किए जाते हैं, क्योंकि इससे यूआरएल छोटे हो जाते हैं।
कैरेक्टर डेटा
बाइनरी डेटा की पर्सेंट-एन्कोडिंग प्रक्रिया को अक्सर एक्स्ट्रापोलेट करके, कभी-कभी गलत तरीके से या पूरी तरह से बताए बिना, कैरेक्टर-आधारित डेटा पर लागू कर दिया जाता है। वर्ल्ड वाइड वेब के शुरुआती सालों में, ASCII रेंज में मौजूद डेटा कैरेक्टर पर काम करते समय और ASCII में उनके बाइट्स के आधार पर पर्सेंट-एन्कोडेड सीक्वेंस तय करते समय, ऐसा करने में कोई नुकसान नहीं था। कई लोगों ने यह मान लिया कि कैरेक्टर और बाइट्स की वन-टू-वन मैपिंग की गई है और उन्हें एक-दूसरे की जगह इस्तेमाल किया जा सकता है। हालाँकि, ASCII रेंज के बाहर के कैरेक्टर दिखाने की ज़रूरत तेज़ी से बढ़ी और यूआरआई स्कीम और प्रोटोकॉल अक्सर कैरेक्टर डेटा को यूआरआई में शामिल करने के लिए तैयार करने के मानक नियम देने में नाकाम रहे। इसका नतीजा यह हुआ कि सभी वेब ऐप्लिकेशन ने पर्सेंट-एन्कोडिंग के आधार के तौर पर अलग-अलग मल्टी-बाइट, स्टेटफ़ुल और अन्य नॉन-ASCII-कंपैटिबल एन्कोडिंग का इस्तेमाल करना शुरू कर दिया। इस वजह से, अस्पष्टता आई और साथ ही, यूआरआई को भरोसेमंद तरीके से इंटरप्रेट करना मुश्किल हो गया।
उदाहरण के लिए, RFC 1738 और 2396 पर आधारित कई यूआरआई स्कीम और प्रोटोकॉल में यह माना जाता है कि डेटा कैरेक्टर को किसी अज्ञात कैरेक्टर एन्कोडिंग के मुताबिक बाइट्स में कनवर्ट कर दिया जाएगा। उसके बाद ही, वे यूआरआई में अनरिज़र्व्ड कैरेक्टर या पर्सेंट-एन्कोडेड बाइट्स के तौर पर दिखेंगे। अगर स्कीम के तहत यूआरआई इस बात का संकेत नहीं दे सकता कि किस एन्कोडिंग का इस्तेमाल किया गया था या अगर एन्कोडिंग में, रिज़र्व्ड और अनरिज़र्व्ड कैरेक्टर को पर्सेंट-एन्कोड करने के लिए ASCII का इस्तेमाल नहीं किया गया है, तो यूआरआई को भरोसेमंद तरीके से इंटरप्रेट नहीं किया जा सकता। कुछ स्कीम एन्कोडिंग का बिल्कुल भी हिसाब नहीं लगा पाती हैं। इसके बजाय, वे सिर्फ़ यह सुझाव देती हैं कि डेटा कैरेक्टर की मैपिंग सीधे यूआरआई कैरेक्टर से हो। इस वजह से, यह फ़ैसला यूज़र को करना होता है कि वे ऐसे डेटा कैरेक्टर को पर्सेंट-एन्कोड करना चाहते हैं या नहीं, जो न तो रिज़र्व्ड सेट में हैं और न ही अनरिज़र्व्ड सेट में हैं। अगर वे ऐसा करना चाहें, तो इसे कैसे करें।
| पर्सेंट-एन्कोडिंग के बाद कॉमन कैरेक्टर (ASCII या UTF-8 पर आधारित) | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| न्यूलाइन | स्पेस | " |
% |
- |
. |
< |
> |
\ |
^ |
_ |
` |
{ |
| |
} |
~ |
%0A या %0D या %0D%0A |
%20 |
%22 |
%25 |
%2D |
%2E |
%3C |
%3E |
%5C |
%5E |
%5F |
%60 |
%7B |
%7C |
%7D |
%7E |
आर्बिट्रेरी कैरेक्टर डेटा को कभी-कभी पर्सेंट-एन्कोड किया जाता है और नॉन-यूआरआई स्थितियों में इस्तेमाल किया जाता है, जैसे पासवर्ड को अस्पष्ट बनाने के प्रोग्राम या अन्य सिस्टम-स्पेसिफ़िक ट्रांसलेशन प्रोटोकॉल के लिए।