URL डिकोड और एन्कोड करें

URL डिकोड और एन्कोड के बारे में

URL डिकोड और एन्कोड में आपका स्वागत है, आपका अंतिम ऑनलाइन उपकरण जो URL को आसानी से एन्कोड और डिकोड करता है। हमारा प्लेटफ़ॉर्म URL एन्कोडिंग और डिकोडिंग की प्रक्रिया को सरल बनाने के लिए डिज़ाइन किया गया है, जिससे आप डेटा को URL-सुरक्षित प्रारूप में परिवर्तित कर सकते हैं या इसे केवल एक क्लिक से मानव-पठनीय स्थिति में वापस ला सकते हैं।

URL एन्कोडिंग क्या है?

URL एन्कोडिंग, जिसे अक्सर प्रतिशत-एन्कोडिंग कहा जाता है, एक महत्वपूर्ण तंत्र है जो यूनिफॉर्म रिसोर्स आइडेंटिफायर (URIs) के निर्माण में उपयोग होता है। जबकि इसे सामान्यतः URL एन्कोडिंग के रूप में जाना जाता है, यह तकनीक URI ढांचे के भीतर व्यापक रूप से लागू होती है, जिसमें यूनिफॉर्म रिसोर्स लोकेटर्स (URLs) और यूनिफॉर्म रिसोर्स नाम (URNs) दोनों शामिल हैं। यह वर्णों को एक ऐसे प्रारूप में परिवर्तित करता है जिसे इंटरनेट पर प्रसारित किया जा सकता है, जिससे यह वेब अनुप्रयोगों और HTTP अनुरोधों में डेटा सबमिशन के लिए आवश्यक हो जाता है।

विशेषताएँ और उन्नत विकल्प

हमारा उपकरण कई वर्ण सेटों का समर्थन करता है, जिसमें UTF-8, ASCII, और विभिन्न ISO प्रारूप शामिल हैं, जो आपकी आवश्यकताओं के साथ संगतता सुनिश्चित करता है। आप अनुकूलित कर सकते हैं:

• वर्ण सेट: हमारी वेबसाइट आपके इनपुट डेटा को प्रसारित करने के लिए डिफ़ॉल्ट रूप से UTF-8 वर्ण सेट का उपयोग करती है। यदि आपको एन्कोडिंग से पहले अपने डेटा को एक अलग वर्ण सेट में परिवर्तित करने की आवश्यकता है, तो आप इस विकल्प को समायोजित कर सकते हैं। ध्यान दें कि पाठ डेटा के लिए, एन्कोडिंग योजना में वर्ण सेट शामिल नहीं होता है।
• न्यूलाइन विभाजक: Unix और Windows सिस्टम पंक्ति ब्रेक के लिए विभिन्न वर्णों का उपयोग करते हैं। एन्कोडिंग से पहले, आपके डेटा को आपके द्वारा चयनित विकल्प के आधार पर इन वर्णों के स्थान पर समायोजित किया जाएगा। अपने डेटा के लिए उपयुक्त करने के लिए Unix (LF) और Windows (CRLF) पंक्ति ब्रेक के बीच चयन करें।
• प्रत्येक पंक्ति एन्कोडिंग अद्वितीय: न्यूलाइन वर्णों को उनके प्रतिशत-एन्कोडेड समकक्षों में भी परिवर्तित किया जाएगा। यदि आप कई अलग-अलग डेटा प्रविष्टियों को एन्कोड करना चाहते हैं जो पंक्ति ब्रेक द्वारा विभाजित हैं, तो आप इस विकल्प का उपयोग कर सकते हैं।
• पंक्तियों को 76 वर्ण के टुकड़ों में विभाजित करें: एन्कोडेड डेटा बिना किसीWhitespace के एक निरंतर स्ट्रिंग में बदल जाएगा। यदि आप इसे कई पंक्तियों में विभाजित करना चाहते हैं, तो सुनिश्चित करें कि आप इस विकल्प का चयन करें। वर्ण सीमा MIME (RFC 2045) विशिष्टता द्वारा निर्धारित की गई है, जो यह आवश्यक करती है कि प्रत्येक एन्कोडेड पंक्ति 76 वर्णों से अधिक न हो।

सुरक्षा और सुरक्षा

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

पूर्णतः मुफ्त और उपयोगकर्ता-मित्रवत

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

URL एन्कोडिंग का विवरण

URI वर्णों के प्रकार
URI में, वर्ण दो श्रेणियों में आते हैं: आरक्षित और गैर-आरक्षित, साथ ही एन्कोडिंग के लिए उपयोग किए जाने वाले प्रतिशत वर्ण। आरक्षित वर्णों का विशेष अर्थ हो सकता है; उदाहरण के लिए, फॉरवर्ड स्लैश का उपयोग एक URL (या व्यापक रूप से, एक URI) के विभिन्न भागों को अलग करने के लिए किया जाता है। दूसरी ओर, गैर-आरक्षित वर्णों का कोई विशेष महत्व नहीं होता। प्रतिशत-एन्कोडिंग का उपयोग करते समय, आरक्षित वर्णों को विशिष्ट अनुक्रमों द्वारा प्रदर्शित किया जाता है। आरक्षित और गैर-आरक्षित वर्णों की परिभाषाएँ, साथ ही जिन संदर्भों में कुछ आरक्षित वर्ण महत्वपूर्ण होते हैं, प्रत्येक संशोधन के साथ विकसित हुई हैं जो URIs और URI योजनाओं को नियंत्रित करती हैं।

RFC 3986 खंड 2.2 आरक्षित वर्ण (जनवरी 2005)

!	*	'	(	)	;	:	@	&	=	+	$	,	/	?	#	[	]

RFC 3986 खंड 2.3 गैर-आरक्षित वर्ण (जनवरी 2005)

A

B

C

D

E

F

G

F

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

-

_

.

~

प्रतिशत-एन्कोडेड आरक्षित वर्ण

जब आरक्षित सेट से किसी वर्ण का किसी विशेष संदर्भ में एक विशेष अर्थ होता है, तो यदि एक URI योजना इसे किसी अन्य उद्देश्य के लिए आवश्यक बनाती है, तो इसे प्रतिशत-एन्कोड किया जाना चाहिए। प्रतिशत-एन्कोडिंग में उस वर्ण को उसके संबंधित ASCII बाइट मान में परिवर्तित करना और फिर उस मान को दो हेक्साडेसिमल अंकों के रूप में व्यक्त करना शामिल है, जिसके पहले प्रतिशत चिह्न ('%') होता है। गैर-ASCII वर्णों के लिए, उस वर्ण को आमतौर पर इसके UTF-8 बाइट अनुक्रम में परिवर्तित किया जाता है, जिसमें प्रत्येक बाइट को उसी तरह से प्रदर्शित किया जाता है।

उदाहरण के लिए, आरक्षित वर्ण '/' URI के 'path' घटक में एक विभाजक के रूप में कार्य करता है। यदि एक URI योजना निर्दिष्ट करती है कि '/' को एक पथ खंड में शामिल किया जाना चाहिए, तो इसे उस खंड में सीधे वर्ण का उपयोग करने के बजाय '%2F' (या '%2f') से प्रतिस्थापित किया जाना चाहिए।

प्रतिशत-एन्कोडेड आरक्षित वर्ण

!

#

$

&

'

(

)

*

+

,

/

:

;

=

?

@

[

]

%21

%23

%24

%26

%27

%28

%29

%2A

%2B

%2C

%2F

%3A

%3B

%3D

%3F

%40

%5B

%5D

आरक्षित वर्ण जो दिए गए संदर्भ में विशेष उद्देश्य नहीं रखते हैं, उन्हें भी प्रतिशत-एन्कोड किया जा सकता है, लेकिन उन्हें अर्थ के संदर्भ में अन्य वर्णों के समान माना जाता है।

उदाहरण के लिए, URI के 'query' घटक में ('?' वर्ण के बाद का भाग), '/' वर्ण को आरक्षित के रूप में वर्गीकृत किया गया है लेकिन आमतौर पर इसका कोई विशेष कार्य नहीं होता जब तक कि इसे किसी विशेष URI योजना द्वारा निर्दिष्ट नहीं किया जाता। इसलिए, जब इसका कोई आरक्षित उद्देश्य न हो, तो इसे प्रतिशत-एन्कोड करने की आवश्यकता नहीं है।

URIs जो केवल इस आधार पर भिन्न होते हैं कि क्या एक आरक्षित वर्ण प्रतिशत-एन्कोड किया गया है, आमतौर पर उन्हें समान नहीं माना जाता है, जिसका अर्थ है कि वे एक ही संसाधन की ओर इशारा नहीं करते। हालाँकि, यह केवल तब लागू होता है जब प्रश्न में आरक्षित वर्णों का कोई निर्दिष्ट उद्देश्य न हो। आरक्षित वर्णों के संबंध में विशिष्ट नियम व्यक्तिगत URI योजनाओं द्वारा परिभाषित किए जाते हैं।

प्रतिशत-एन्कोडेड गैर-आरक्षित वर्ण

गैर-आरक्षित सेट में वर्णों को प्रतिशत-एन्कोडिंग की आवश्यकता नहीं होती।

URIs जो केवल इस आधार पर भिन्न होते हैं कि क्या एक गैर-आरक्षित वर्ण प्रतिशत-एन्कोड किया गया है, उन्हें परिभाषा के अनुसार समान माना जाता है। हालाँकि, व्यवहार में, URI प्रोसेसर हमेशा उन्हें एक ही तरीके से संभाल नहीं सकते। उदाहरण के लिए, '%41' को 'A' के समान माना जाना चाहिए (क्योंकि '%41' 'A' के लिए प्रतिशत-एन्कोडिंग है), और '%7E' को '~' के समान होना चाहिए। इसके बावजूद, कुछ सिस्टम उनके बीच अंतर कर सकते हैं। अधिकतम संगतता सुनिश्चित करने के लिए, यह अनुशंसा की जाती है कि URI उत्पादक गैर-आरक्षित वर्णों को प्रतिशत-एन्कोडिंग से बचें।

प्रतिशत-एन्कोडेड (%) प्रतिशत वर्ण

प्रतिशत ('%') वर्ण का उपयोग प्रतिशत-एन्कोडेड ऑक्टेट्स को इंगीत करने के लिए किया जाता है, इसलिए जब आपको इसे URI में डेटा के रूप में शामिल करने की आवश्यकता होती है, तो इसे '%25' के रूप में प्रतिशत-एन्कोड किया जाना चाहिए।

प्रतिशत-एन्कोडेड मनमाना डेटा

कई URI योजनाएँ विभिन्न प्रकार के मनमाने डेटा, जैसे कि IP पते या फ़ाइल प्रणाली पथ, को URI के भागों के रूप में प्रदर्शित करने की आवश्यकता होती हैं। जबकि URI योजनाओं की विशिष्टताएँ आदर्श रूप से URI वर्णों और सभी संभावित डेटा मानों के बीच स्पष्ट मैपिंग प्रदान करती हैं, यह अक्सर ऐसा नहीं होता।

बाइनरी डेटा

RFC 1738 के 1994 में प्रकाशन के बाद, यह स्थापित किया गया कि URI में बाइनरी डेटा प्रतिनिधित्व की अनुमति देने वाली योजनाएँ डेटा को 8-बिट बाइट्स में विभाजित करना और प्रत्येक बाइट को तदनुसार प्रतिशत-एन्कोड करना चाहिए। उदाहरण के लिए, बाइट मान 0F (हैक्साडेसिमल में) को '%0F' के रूप में प्रदर्शित किया जाना चाहिए, जबकि बाइट मान 41 को 'A' या '%41' के रूप में प्रदर्शित किया जा सकता है। सामान्यतः, अल्फ़ान्यूमेरिक वर्णों और अन्य गैर-आरक्षित वर्णों के लिए अनकोडेड वर्णों का उपयोग करना पसंद किया जाता है क्योंकि इससे छोटे URLs बनते हैं।

वर्ण डेटा

बाइनरी डेटा के प्रतिशत-एन्कोडिंग की विधि को अक्सर बिना स्पष्ट दिशानिर्देशों के वर्ण-आधारित डेटा पर अनुपयुक्त रूप से विस्तारित किया गया है। विश्वव्यापी वेब के प्रारंभिक दिनों में, जब ASCII सेट के वर्णों के साथ काम किया जा रहा था, यह सामान्यतः माना जाता था कि वर्ण और उनके संबंधित बाइट मानों को प्रतिशत-एन्कोडिंग के लिए परस्पर रूप से व्यवहार किया जा सकता है। यह धारणा उस समय ज्यादातर हानिरहित थी। हालाँकि, जैसे-जैसे ASCII रेंज से परे वर्णों का प्रतिनिधित्व करने की आवश्यकता बढ़ी, URI योजनाएँ और प्रोटोकॉल अक्सर URIs के लिए वर्ण डेटा तैयार करने के लिए मानकीकृत नियमों की कमी रखते थे।

इसके परिणामस्वरूप, वेब अनुप्रयोगों ने प्रतिशत-एन्कोडिंग के लिए विभिन्न मल्टी-बाइट और गैर-ASCII-संगत एन्कोडिंग का उपयोग करना शुरू कर दिया, जिसने अस्पष्टताओं को पेश किया और URIs को विश्वसनीय रूप से व्याख्या करना कठिन बना दिया।

उदाहरण के लिए, RFC 1738 और 2396 पर आधारित कई URI योजनाएँ और प्रोटोकॉल मानते हैं कि डेटा वर्णों को बिना किसी निर्दिष्ट एन्कोडिंग का उपयोग करते हुए बाइट्स में परिवर्तित किया जाएगा, इससे पहले कि उन्हें URI में गैर-आरक्षित वर्णों या प्रतिशत-एन्कोडेड बाइट्स के रूप में प्रदर्शित किया जाए। यदि कोई योजना उपयोग की गई एन्कोडिंग को निर्दिष्ट नहीं करती है या आरक्षित और गैर-आरक्षित वर्णों की ASCII-आधारित प्रतिशत-एन्कोडिंग के साथ संघर्ष करती है, तो URI को सही ढंग से व्याख्या करना कठिन हो जाता है। कुछ योजनाएँ एन्कोडिंग को पूरी तरह से संबोधित करने की अनदेखी करती हैं, यह सुझाव देते हुए कि डेटा वर्णों को सीधे URI वर्णों पर मैप किया जाना चाहिए। यह उपयोगकर्ताओं को उन वर्णों को प्रतिशत-एन्कोड करने का तरीका निर्धारित करने के लिए छोड़ देता है जो आरक्षित या गैर-आरक्षित श्रेणियों में नहीं आते हैं।

प्रतिशत-एन्कोडिंग के बाद सामान्य वर्ण (ASCII या UTF-8 आधारित)

newline

space

"

%

-

.

<

>

\

^

_

`

{

|

}

~

%0A or %0D or %0D%0A

%20

%22

%25

%2D

%2E

%3C

%3E

%5C

%5E

%5F

%60

%7B

%7C

%7D

%7E

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

URL एन्कोडिंग की जड़ें इंटरनेट के प्रारंभिक दिनों में हैं, जिसे 1994 में RFC 1738 के प्रकाशन के साथ औपचारिक रूप दिया गया। इस विशिष्टता ने मनमाने डेटा को URIs के लिए उपयुक्त प्रारूप में एन्कोड करने की आधारशिला रखी, विशेष वर्णों के प्रतिनिधित्व को सक्षम किया और यह सुनिश्चित किया कि डेटा सही ढंग से प्रसारित हो। वर्षों के दौरान, जैसे-जैसे वेब मानक विकसित हुए, प्रतिशत-एन्कोडिंग के चारों ओर के अभ्यास भी विकसित हुए, जिसमें विशेष रूप से गैर-ASCII वर्णों और मल्टी-बाइट एन्कोडिंग के उदय के साथ एक व्यापक श्रृंखला के वर्णों और एन्कोडिंग योजनाओं को शामिल किया गया। यह विकास URL एन्कोडिंग को वेब डेवलपर्स के लिए एक आवश्यक कौशल बना चुका है, यह सुनिश्चित करते हुए कि डेटा बरकरार रहे और विभिन्न प्लेटफार्मों और प्रोटोकॉल में सही ढंग से व्याख्या की जाए।