Base64
7 टूल्स
एन्कोडिंग क्या है?
एन्कोडिंग वह प्रक्रिया है जिसमें डेटा को एक रूप से दूसरे रूप में बदला जाता है। वेब विकास में, एन्कोडिंग का उपयोग उन माध्यमों से डेटा को सुरक्षित रूप से संचारित करने के लिए किया जाता है जो सीमित वर्ण समूह के लिए बनाए गए थे — उदाहरण के लिए, बाइनरी डेटा को पाठ-आधारित प्रोटोकॉल के माध्यम से भेजना, या URL में विशेष वर्ण शामिल करना।
वर्ण एन्कोडिंग यह परिभाषित करती है कि पाठ के वर्ण बाइट्स से कैसे संबद्ध होते हैं। Base64 एन्कोडिंग बाइनरी डेटा को ASCII पाठ में बदलती है। URL एन्कोडिंग किसी भी पाठ को URL में उपयोग के लिए सुरक्षित बनाती है। एन्कोडिंग की इन तीन परतों को समझने से सूक्ष्म त्रुटियाँ और सुरक्षा कमजोरियाँ टाली जा सकती हैं।
वर्ण एन्कोडिंग का इतिहास
वर्ण एन्कोडिंग वर्णों (अक्षरों, प्रतीकों) और उनके बाइनरी प्रतिनिधित्वों के बीच का संबंध है। ASCII से Unicode तक का विकास वेब के वैश्विक होने को दर्शाता है:
7-बिट अमेरिकी मानक कोड। 128 वर्ण: अंग्रेज़ी अक्षर, अंक, विराम चिह्न और नियंत्रण कोड। वह मूलभूत एन्कोडिंग जिस पर अन्य सभी आधारित हैं।
पश्चिमी यूरोपीय भाषाओं के लिए विस्तारित ASCII। 128 अतिरिक्त वर्ण जोड़े गए (उच्चारण चिह्न वाले अक्षर, प्रतीक)। गैर-लैटिन लिपियों के लिए अनुपयुक्त।
विश्व की सभी लेखन प्रणालियों को समाहित करने वाली सार्वभौमिक वर्ण सेट। 161 लिपियों में 1,49,000 से अधिक वर्णों के लिए कोड पॉइंट परिभाषित करती है। एन्कोडिंग परिभाषित नहीं करती — वह कार्य UTF-8/16/32 का है।
Unicode की परिवर्तनशील-चौड़ाई एन्कोडिंग, प्रति वर्ण 1–4 बाइट्स उपयोग करती है। ASCII-अनुकूल (पहले 128 कोड पॉइंट एकल बाइट हैं)। वेब पर प्रमुख एन्कोडिंग — 98% से अधिक वेबसाइटें इसका उपयोग करती हैं।
परिवर्तनशील-चौड़ाई एन्कोडिंग, प्रति वर्ण 2 या 4 बाइट्स उपयोग करती है। Windows, Java और JavaScript स्ट्रिंग्स में आंतरिक रूप से उपयोग होती है। ASCII-अनुकूल नहीं।
निश्चित-चौड़ाई एन्कोडिंग: प्रति वर्ण हमेशा 4 बाइट्स। सरल है, परंतु स्थान बर्बाद करती है। कुछ डेटाबेस की आंतरिक संरचना में उपयोग होती है। वेब पर बहुत कम देखी जाती है।
UTF-8 क्यों प्रमुख बनी
UTF-8 प्रमुख एन्कोडिंग बनी क्योंकि यह ASCII के साथ पश्चगामी-अनुकूल है (पहले 128 वर्ण एकसमान एन्कोड होते हैं), स्व-समकालिक है (स्कैन करके वर्ण सीमाएँ ज्ञात की जा सकती हैं), और लैटिन पाठ के लिए स्थान-कुशल है। कोई भी ASCII दस्तावेज़ वैध UTF-8 दस्तावेज़ भी है। इससे स्थानांतरण सहज हो गया।
Base64 एन्कोडिंग
Base64 बाइनरी डेटा को केवल 64 प्रिंट करने योग्य ASCII वर्णों का उपयोग करके पाठ रूप में बदलता है: A-Z, a-z, 0-9, + और /। यह आवश्यक है जब बाइनरी डेटा को ऐसे माध्यमों से गुजरना हो जो केवल पाठ संभालते हैं — ईमेल संलग्नक, data URI, JWT टोकन और HTTP Basic Auth सभी Base64 का उपयोग करते हैं।
यह कैसे काम करता है
Base64 इनपुट बाइट्स को 3-बाइट (24-बिट) खंडों में विभाजित करता है और प्रत्येक खंड को 4 Base64 वर्णों (प्रत्येक 6 बिट) के रूप में एन्कोड करता है। यदि इनपुट 3 बाइट का गुणज नहीं है, तो अंतिम समूह पूरा करने के लिए = पैडिंग वर्ण जोड़े जाते हैं:
| इनपुट | हेक्स बाइट्स | Base64 |
|---|---|---|
| "Man" | 77 61 6E | TWFu |
| "Ma" | 4D 61 | TWE= |
| "M" | 4D | TQ== |
अंत में आने वाले = पैडिंग वर्ण यह दर्शाते हैं कि अंतिम 3-बाइट समूह पूरा करने के लिए कितने बाइट कम थे। एक = का अर्थ है एक बाइट की पैडिंग आवश्यक थी; == का अर्थ है दो बाइट आवश्यक थे। मानक Base64 हमेशा ऐसा आउटपुट देता है जिसकी लंबाई 4 का गुणज होती है।
URL एन्कोडिंग
URL में केवल सीमित सुरक्षित ASCII वर्ण ही हो सकते हैं। उस सेट से बाहर के किसी भी वर्ण — जिसमें रिक्त स्थान, विराम चिह्न, गैर-ASCII वर्ण और URL के विशेष वर्ण जैसे &, = और # शामिल हैं — को URL में रखने से पहले प्रतिशत-एन्कोड (URL-encoded) करना आवश्यक है।
प्रतिशत एन्कोडिंग प्रत्येक असुरक्षित बाइट को % और उसके बाद उस बाइट के मान को दर्शाने वाले दो षोडशाधारी (हेक्साडेसिमल) अंकों से प्रतिस्थापित करती है। रिक्त स्थान %20 बन जाता है, एम्परसैंड %26 बन जाता है, और इसी तरह आगे भी।
सामान्यतः एन्कोड किए जाने वाले वर्ण
| वर्ण | एन्कोडेड | टिप्पणियाँ |
|---|---|---|
| Space | %20 | सर्वाधिक सामान्य; application/x-www-form-urlencoded में फॉर्म सबमिशन में + के रूप में उपयोग होता है |
| & | %26 | क्वेरी स्ट्रिंग विभाजक; शाब्दिक मान के रूप में उपयोग होने पर एन्कोड करना आवश्यक |
| = | %3D | क्वेरी स्ट्रिंग में की-वैल्यू विभाजक; डेटा के रूप में उपयोग होने पर एन्कोड करें |
| + | %2B | application/x-www-form-urlencoded में रिक्त स्थान के रूप में व्याख्यायित; शाब्दिक + संरक्षित रखने के लिए एन्कोड करें |
| # | %23 | फ्रैगमेंट पहचानकर्ता; पथ या क्वेरी में शाब्दिक डेटा के रूप में उपयोग होने पर एन्कोड करें |
| / | %2F | पथ खंड विभाजक; शाब्दिक डेटा के रूप में उपयोग होने पर एन्कोड करें, पथ सीमांकक के रूप में नहीं |
| : | %3A | स्कीम विभाजक; पथ और क्वेरी संदर्भों में एन्कोड करें |
| @ | %40 | mailto: और प्रमाणीकरण में उपयोग होता है; शाब्दिक डेटा के रूप में उपयोग होने पर एन्कोड करें |
encodeURI vs encodeURIComponent
JavaScript दो एन्कोडिंग फ़ंक्शन प्रदान करता है जिनके दायरे अलग-अलग हैं। encodeURI एक पूर्ण URL को एन्कोड करता है — यह URL में अर्थपूर्ण वर्णों (:, /, ?, #, @) को एन्कोड नहीं करता। encodeURIComponent एक URL घटक (एकल क्वेरी पैरामीटर मान या पथ खंड) को एन्कोड करता है — यह A-Z, a-z, 0-9, -, _, ., ~ को छोड़कर सभी वर्णों को एन्कोड करता है। व्यक्तिगत मानों के लिए हमेशा encodeURIComponent और पूर्ण URL के लिए encodeURI का उपयोग करें।
वेब विकास में एन्कोडिंग के उपयोग के संदर्भ
Authorization: Basic हेडर क्रेडेंशियल को Base64(username:password) के रूप में एन्कोड करता है। यह परिवहन सुविधा के लिए एन्कोडिंग है, सुरक्षा के लिए नहीं — Base64 आसानी से उलटा किया जा सकता है। Basic Auth के साथ हमेशा HTTPS का उपयोग करें।
Data URIs फ़ाइल सामग्री को सीधे HTML या CSS में समाहित करते हैं: data:image/png;base64,.... छवियों और फ़ॉन्ट को इनलाइन Base64-एन्कोड करने से HTTP अनुरोध समाप्त होते हैं, परंतु दस्तावेज़ का आकार बढ़ता है (~33% ओवरहेड)।
ईमेल को 7-बिट ASCII के लिए डिज़ाइन किया गया था। बाइनरी संलग्नक (छवियाँ, PDF) प्रेषण से पहले MIME द्वारा Base64-एन्कोड किए जाते हैं। ईमेल प्रदर्शित करते समय आपका ईमेल क्लाइंट उन्हें स्वचालित रूप से डीकोड कर देता है।
JWT टोकन अपने तीनों भागों (हेडर, पेलोड, सिग्नेचर) के लिए Base64url एन्कोडिंग (एक रूपांतर जो + को - और / को _ से बदलता है, बिना पैडिंग के) का उपयोग करते हैं। इससे टोकन अतिरिक्त प्रतिशत-एन्कोडिंग के बिना URL-सुरक्षित बन जाते हैं।
URL क्वेरी स्ट्रिंग में उपयोगकर्ता द्वारा प्रदत्त किसी भी डेटा को प्रतिशत-एन्कोड करना आवश्यक है। किसी मान में & या = एन्कोड न करने पर क्वेरी स्ट्रिंग पार्सिंग चुपचाप दूषित हो जाती है। व्यक्तिगत मानों पर हमेशा encodeURIComponent का उपयोग करें।
गैर-ASCII डोमेन नाम (जैसे münchen.de) DNS प्रणाली के साथ अनुकूलता के लिए Punycode (xn-- उपसर्ग) का उपयोग करके एन्कोड किए जाते हैं। ब्राउज़र Unicode रूप प्रदर्शित करता है, परंतु DNS रिज़ॉल्वर को Punycode रूप भेजता है।
अक्सर पूछे जाने वाले प्रश्न
नहीं। Base64 एन्कोडिंग है, एन्क्रिप्शन नहीं। यह बिना किसी गोपनीय कुंजी के एक उत्क्रमणीय रूपांतरण है। जो भी Base64 स्ट्रिंग देखता है, वह उसे तुरंत डीकोड कर सकता है। Base64 को कभी भी सुरक्षा उपाय के रूप में उपयोग न करें।
Base64 इनपुट को 3-बाइट समूहों में संसाधित करता है। यदि इनपुट 3 बाइट का गुणज नहीं है, तो अंतिम समूह पूरा करने के लिए = पैडिंग जोड़ी जाती है। एक = का अर्थ है एक बाइट की पैडिंग; == का अर्थ है दो बाइट। कुछ कार्यान्वयन पैडिंग छोड़ देते हैं (JWT के लिए Base64url)।
Base64url, Base64 का URL-सुरक्षित रूपांतर है जो + को - और / को _ से बदलता है, और सामान्यतः = पैडिंग छोड़ देता है। इससे यह URL और HTTP हेडर में प्रतिशत-एन्कोडिंग के बिना उपयोग के लिए सुरक्षित हो जाता है। JWT अपने तीनों भागों के लिए Base64url का उपयोग करते हैं।
व्यक्तिगत मानों (क्वेरी पैरामीटर मान, पथ खंड मान) के लिए encodeURIComponent का उपयोग करें। पूर्ण URL स्ट्रिंग के लिए encodeURI का उपयोग करें जहाँ आप URL संरचना वर्णों (/, :, ?, #) को सुरक्षित रखना चाहते हैं। संदेह होने पर encodeURIComponent का उपयोग करें।
UTF-8, ASCII-अनुकूल है और लैटिन पाठ के लिए स्थान-कुशल है (अधिकांश URL, HTML टैग और कोड ASCII हैं)। UTF-16 ASCII सामग्री के लिए स्थान बर्बाद करती है और पश्चगामी-अनुकूल नहीं है। HTTP और HTML का डिफ़ॉल्ट UTF-8 है।
प्रतिशत एन्कोडिंग (URL एन्कोडिंग) वर्णों को % और उसके बाद उनके दो-अंकीय षोडशाधारी बाइट मान के रूप में दर्शाती है। उदाहरण के लिए, रिक्त स्थान %20 है (दशमलव 32, हेक्स 20)। बहु-बाइट UTF-8 वर्ण प्रत्येक बाइट को अलग-अलग एन्कोड करते हैं: é है %C3%A9।
Base64 डेटा का आकार लगभग 33% बढ़ा देता है और एन्कोडिंग/डीकोडिंग CPU ओवरहेड जोड़ता है। उच्च-थ्रूपुट प्रणालियों के लिए बाइनरी प्रोटोकॉल को प्राथमिकता दें। URL एन्कोडिंग न्यूनतम ओवरहेड जोड़ती है, परंतु कई विशेष वर्णों के साथ URL को काफी लंबा बना सकती है।
Punycode, Unicode वर्णों को ASCII-अनुकूल DNS प्रणाली में दर्शाने के लिए एक एन्कोडिंग है। münchen.de जैसे अंतर्राष्ट्रीयकृत डोमेन नाम DNS क्वेरी में xn--mnchen-3ya.de के रूप में एन्कोड किए जाते हैं। ब्राउज़र Unicode रूप प्रदर्शित करता है, परंतु आंतरिक रूप से Punycode का उपयोग करता है।