Base64 एन्कोडिंग क्या है और इसका उपयोग कब करें
अगर आप API, ईमेल सिस्टम या वेब डेवलपमेंट के साथ काम करते हैं, तो आप Base64 से मिल चुके हैं, भले ही पहचान न पाए हों। ईमेल अटैचमेंट की शुरुआत, CSS में data: URL, या JWT टोकन का बीच का खंड में जो लंबे अक्षरों और संख्याओं की धाराएँ बेमतलब-सी लगती हैं? वह Base64 है। यह इंटरनेट की पाइपलाइन का सबसे पुराने और चुपचाप भार-वहन करने वाले टुकड़ों में से एक है, और जो भी सॉफ़्टवेयर आप उपयोग करते हैं, लगभग हर एक कहीं-न-कहीं इस पर टिका है।
Base64 का संक्षिप्त इतिहास
Base64 «radix-64» या «प्रिंट करने योग्य एन्कोडिंग» नामक एक परिवार का हिस्सा है, जिसका काम है मनमाने बाइट्स को केवल उन वर्णों के छोटे वर्णमाला से दर्शाना जिन्हें कोई पाठ-आधारित सिस्टम बिना बदले गुज़ारने की गारंटी देता है। सबसे पहले व्यापक रूप से उपयोग किया गया सदस्य uuencode है, जिसे Mary Ann Horton ने UC Berkeley में लगभग 1980 में लिखा था, ताकि उस ज़माने में जब Usenet और ईमेल 7-बिट ASCII से ऊपर की हर चीज़ बिगाड़ देते थे, बायनरी फ़ाइलें भेजी जा सकें।
Base64 की वर्णमाला स्वयं पहली बार RFC 989 (1987) में Privacy-Enhanced Mail (PEM) के लिए मानक की गई थी, जो हस्ताक्षरित और एन्क्रिप्ट किए ईमेल का एक शुरुआती प्रयास था। PEM समाप्त हो गया, पर इसकी एन्कोडिंग योजना बच गई और RFC 1421 (1993) तथा फिर MIME विशिष्टता (1993 में RFC 1521 और 1522, 1996 में संशोधित RFC 2045-2049) में मान्य कर दी गई। MIME ने Base64 को ईमेल से बायनरी फ़ाइल जोड़ने का डिफ़ॉल्ट तरीक़ा बना दिया, और वहाँ से एन्कोडिंग इंटरनेट के लगभग हर पाठ-केवल वहन माध्यम तक फैल गई।
2006 में, IETF ने बिखरी हुई Base64 परिभाषाओं को RFC 4648 में समेकित किया, जो Base64, Base32 और Base16 को एक ही दस्तावेज़ में परिभाषित करती है। RFC 4648 ने धारा 5 में URL-सुरक्षित संस्करण भी परिभाषित किया, जिसने URL के अनुकूल नहीं वाले दो वर्ण (+ और /) को - और _ से बदल दिया। JSON Web Token (RFC 7519, 2015) ने पैडिंग हटाए हुए URL-सुरक्षित Base64 पर मानकीकरण किया। आज, हर ईमेल अटैचमेंट, हर PEM-एन्कोडेड प्रमाणपत्र, हर data: URL, हर JWT, और हर multipart अपलोड सीमा Base64 पर निर्भर है।
Base64 कैसे काम करता है: गणित
Base64 तीन इनपुट बाइट (24 बिट) लेता है और उन्हें चार आउटपुट वर्ण (6 बिट प्रत्येक) के रूप में फिर से लिखता है, 64-प्रतीक वर्णमाला से। मैपिंग स्थिर है:
| सूचकांक श्रेणी | वर्ण |
|---|---|
| 0-25 | A-Z |
| 26-51 | a-z |
| 52-61 | 0-9 |
| 62 | + (मानक) या - (URL-सुरक्षित) |
| 63 | / (मानक) या _ (URL-सुरक्षित) |
तो Hello बन जाता है:
- ASCII बाइट:
0x48 0x65 0x6C 0x6C 0x6F(5 बाइट) - बायनरी:
01001000 01100101 01101100 01101100 01101111 - 6-बिट समूहों में पुनः-समूहीकृत:
010010 000110 010101 101100 011011 000110 1111 - अंतिम समूह छोटा है, शून्य बिट्स से भरा गया:
010010 000110 010101 101100 011011 000110 111100 - लुकअप:
S G V s b G 8(6 बिट के 6 समूहों = 36 बिट से केवल 7 वर्ण, छूटे 4 के लिए पैडिंग) - पैडिंग:
=जोड़कर आउटपुट को 4 के गुणक तक गोल करें:SGVsbG8=
आउटपुट हमेशा 4 वर्णों का गुणक होता है। यदि इनपुट लंबाई मॉड 3 = 1 है, तो आपको दो = पैडिंग वर्ण मिलते हैं; यदि 2 है तो एक; यदि 0 है तो कोई नहीं। पैडिंग कभी-कभी हटाई जाती है (विशेष रूप से JWT और URL टुकड़ों में) और डिकोडर्स से अपेक्षा है कि वे इसे सहन करें।
33 % आकार ओवरहेड इस 3-से-4 विस्तार से आता है: हर 3 इनपुट बाइट 4 आउटपुट वर्ण बन जाते हैं, एक-तिहाई की वृद्धि। वर्णमाला बदले बिना इसे कम करने का कोई तरीक़ा नहीं (Base85 / Ascii85 केवल 25 % विस्तार करता है, 85 प्रिंट करने योग्य वर्ण के साथ, अधिक जटिल एन्कोडर की क़ीमत पर)।
सामान्य उपयोग के मामले
ईमेल अटैचमेंट। SMTP, जो प्रोटोकॉल सर्वरों के बीच 95 % ईमेल वहन करता है, 1982 (RFC 821) में 7-बिट ASCII के लिए डिज़ाइन किया गया था। आप जो भी बायनरी अटैचमेंट भेजते हैं (एक छवि, एक PDF, एक ZIP) उसे आपके मेल क्लाइंट संचरण से पहले Base64 में एन्कोड करते हैं और प्राप्तकर्ता के क्लाइंट डिकोड करते हैं। ईमेल में MIME हेडर प्राप्तकर्ता को बताते हैं कि कौन-से हिस्से Base64 हैं और कौन-से सादे टेक्स्ट।
HTML और CSS में डेटा URL। data:image/png;base64,iVBORw0KGgo... जैसी URL एक बायनरी फ़ाइल को सीधे दस्तावेज़ में एम्बेड करती है। 1-2 KB के नीचे छोटे आइकनों के लिए उपयोगी, जहाँ बचाई गई HTTP अनुरोध 33 % ओवरहेड और कैशिंग के नुक़सान से ज़्यादा होती है।
API पेलोड। जब JSON या XML API को कोई बायनरी मान स्वीकार करना होता है (अपलोड की गई फ़ाइल, हस्ताक्षर, प्रोफ़ाइल फ़ोटो), तो मानक पैटर्न है बाइट्स को Base64 में एन्कोड करके स्ट्रिंग फ़ील्ड के रूप में भेजना। प्राप्तकर्ता उन्हें सर्वर साइड पर डिकोड करता है। OpenAI का इमेज इनपुट इसी तरह काम करता है, Stripe फ़ाइल अपलोड ऐसे ही प्राप्त करता है, और अधिकांश क्लाउड फ़ंक्शन बायनरी इनपुट इसी तरह स्वीकार करते हैं।
HTTP Basic प्रमाणीकरण। Authorization: Basic <token> हेडर Base64 में एन्कोडेड username:password जोड़ी ले जाता है (RFC 7617)। यह एन्कोडिंग है, एन्क्रिप्शन नहीं: जो भी हेडर देखता है, वह पासवर्ड देखता है। इसी कारण Basic Auth HTTPS की माँग करता है।
प्रमाणपत्र और कुंजियाँ। PEM फ़ाइलें (-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----) DER-एन्कोडेड ASN.1 बाइट्स का एक Base64-एन्कोडेड ब्लॉब लपेटती हैं। हर TLS प्रमाणपत्र, हर SSH कुंजी फ़ाइल, हर कोड-साइनिंग प्रमाणपत्र PEM लिफ़ाफ़े के अंदर Base64 है।
JWT टोकन। JWT तीन URL-सुरक्षित Base64 खंड हैं जिन्हें बिंदुओं से अलग किया गया है: <header>.<payload>.<signature>। Base64 एन्कोडिंग JWT को हेडर, URL और कुकीज़ में सुरक्षित रूप से यात्रा करने देती है।
कैसे एन्कोड और डिकोड करें
- एन्कोड या डिकोड चुनें: रूपांतरण की दिशा का चयन करें।
- टेक्स्ट चिपकाएँ या फ़ाइल अपलोड करें: सीधे टेक्स्ट दर्ज करें या एक फ़ाइल खींचकर छोड़ें (ब्राउज़र-साइड एन्कोडिंग के लिए 5 MB तक)।
- संस्करण चुनें: ईमेल और प्रमाणपत्रों के लिए मानक Base64, JWT और URL टुकड़ों के लिए URL-सुरक्षित। टूल डिफ़ॉल्ट रूप से मानक है।
- परिणाम कॉपी करें: आउटपुट तुरंत अपडेट होता है। अपने क्लिपबोर्ड पर कॉपी करें, या लंबे आउटपुट के लिए डाउनलोड बटन उपयोग करें।
Base64 के संस्करण
विशिष्ट स्थितियों के लिए कई Base64-जैसी एन्कोडिंग मौजूद हैं:
| संस्करण | अंतर | कहाँ उपयोग |
|---|---|---|
| मानक (RFC 4648 §4) | A-Z, a-z, 0-9, +, /, = पैडिंग | ईमेल (MIME), PEM, सामान्य बायनरी-से-टेक्स्ट |
| URL-सुरक्षित (RFC 4648 §5) | + बन जाता है -, / बन जाता है _ | JWT, URL टुकड़े, फ़ाइल नाम |
| MIME (RFC 2045) | हर 76 वर्णों पर पंक्ति विराम | ईमेल बॉडी, मेल हेडर (=?utf-8?B?...?= के साथ) |
| crypt(3) / htpasswd | अलग वर्णमाला (./0-9A-Za-z) | पुराने Unix पासवर्ड हैश (DES-आधारित) |
| बिना पैडिंग Base64Url | URL-सुरक्षित बिना अंत के = | JWT (RFC 7515 के अनुसार) |
| Base32 (RFC 4648 §6) | 32-वर्ण वर्णमाला, केस-असंवेदनशील | TOTP रहस्य, Onion पते |
| Base58 | 58-वर्ण वर्णमाला (0, O, I, l नहीं) | Bitcoin पते, IPFS CID |
| Ascii85 / Base85 | 85-वर्ण वर्णमाला, 25 % ओवरहेड | PDF, PostScript |
अधिकांश समय आप मानक या URL-सुरक्षित Base64 चाहते हैं। बाक़ी विशिष्ट प्रोटोकॉल में आती हैं।
Base64 कब उपयोग करें
इसका उपयोग करें जब:
- आपको HTML या CSS में सीधे एक छोटी छवि (5 KB से नीचे) एम्बेड करनी हो, एक HTTP अनुरोध बचाते हुए।
- कोई API JSON या XML पेलोड में बायनरी डेटा को टेक्स्ट स्ट्रिंग के रूप में चाहती हो।
- आप ऐसे सिस्टम से बायनरी डेटा गुज़ार रहे हों जो केवल टेक्स्ट का समर्थन करता है (ईमेल, लॉग प्रविष्टियाँ, क्वेरी पैरामीटर)।
- आप JWT, प्रमाणपत्र, कुंजी, या किसी संरचित बायनरी ब्लॉब को एन्कोड कर रहे हों।
- आपको एक नियतात्मक, स्व-निहित स्ट्रिंग प्रतिनिधित्व चाहिए जिसे कोई भी भाषा डिकोड कर सके।
इसका उपयोग न करें जब:
- फ़ाइल बड़ी है। Base64 33 % ओवरहेड जोड़ता है, ब्राउज़र को बायनरी को अलग संसाधन के रूप में कैश करने से रोकता है, और पूरे ब्लॉब को पृष्ठ पार्सर से गुज़ारता है।
- आपको सुरक्षा चाहिए। Base64 एन्क्रिप्शन नहीं है; यह सामान्य रूप से उलटा जा सकता है।
- आप फ़ाइल को सामान्य रूप से परोस सकते हैं। कुछ KB से ऊपर की किसी भी चीज़ के लिए सादा
<img src="photo.jpg">Base64 डेटा URL से अधिक कुशल है। - आपको कॉम्पैक्ट प्रतिनिधित्व चाहिए। अगर आकार मायने नहीं रखता तो Hex सरल है; अगर रखता है तो Base85 अधिक घना है।
आम जाल
- एन्कोडिंग को एन्क्रिप्शन से भ्रमित करना। Base64 मिलीसेकंडों में किसी के द्वारा भी उलटा जा सकता है। किसी «रहस्य» को Base64 से गुज़ारना उसे केवल कंधे के ऊपर से एक नज़र के अलावा किसी से नहीं बचाता।
- 33 % आकार दंड। 1 MB की छवि 1.33 MB स्ट्रिंग बन जाती है, और इनलाइन डेटा URL हर भ्रमण पर पैरेंट HTML के साथ डाउनलोड होते हैं, बिना अलग कैश के।
- MIME Base64 में पंक्ति विराम। MIME संस्करण हर 76 वर्णों पर
\r\nडालता है। यदि आप MIME Base64 को JSON मान या URL में चिपकाते हैं, तो यह विफल होगा; पहले नई पंक्तियाँ हटाएँ। - JWT में पैडिंग छीनना। JWT URL-सुरक्षित Base64 का उपयोग करता है जिसमें
=पैडिंग हटा दी गई है। एक लाइब्रेरी जो सख़्ती से पैडिंग माँगती है, वैध JWT को अस्वीकार करेगी; एक जो पैडिंग नहीं देती, ऐसे टोकन बनाएगी जिन्हें अन्य लाइब्रेरी अस्वीकार करती हैं। RFC 7515 JWS मानक के लिए «कोई पैडिंग नहीं» अनिवार्य करता है। - URL-सुरक्षित बनाम मानक उलझन। URL-सुरक्षित स्ट्रिंग को मानक डिकोडर से डिकोड करना
-और_वर्णों पर विफल होता है; मानक स्ट्रिंग को URL-सुरक्षित डिकोडर से डिकोड करना+और/पर विफल होता है। - Unicode इनपुट प्रबंधन। Base64 बाइट्स पर काम करता है, वर्णों पर नहीं। अगर आप UTF-8 इमोजी की स्ट्रिंग Base64 में एन्कोड करते हैं, तो पहले बाइट एन्कोडिंग तय करनी होगी (लगभग हमेशा UTF-8)। अलग-अलग रनटाइम के अलग-अलग डिफ़ॉल्ट हैं; स्पष्ट रूप से निर्दिष्ट करें।
- आंशिक स्ट्रीमिंग डिकोडर। सही ढंग से लागू किया गया Base64 स्ट्रीम डिकोडर 3 आउटपुट बाइट उत्सर्जित करने से पहले 4 इनपुट वर्णों के समूहों की प्रतीक्षा करता है। एक-एक वर्ण डिकोड करने वाले भोले कार्यान्वयन कचरा उत्पन्न करते हैं।
- पिछले श्वेत-स्थान और BOM। कुछ संपादक जब आप सहेजते हैं तो एक नई पंक्ति या UTF-8 BOM जोड़ते हैं। वह अतिरिक्त बाइट Base64 आउटपुट बदल देता है। अप्रत्याशित मिसमैच देखें तो अपने एन्कोडेड परिणाम की एक अपस्ट्रीम स्रोत से तुलना करें।
- URL में
+को स्पेस के रूप में व्याख्या। मानक Base64 का+URL पार्सर द्वारा परसेंट-डिकोड करने पर ` ` (स्पेस) बन जाता है। ठीक इसी कारण URL-सुरक्षित Base64 अस्तित्व में है।
विकल्प और समीप एन्कोडिंग
Base64 डिफ़ॉल्ट है, एकमात्र विकल्प नहीं। सही चुनाव चैनल और आकार बजट पर निर्भर करता है।
| एन्कोडिंग | ओवरहेड | ताक़त | सबसे अच्छा उपयोग |
|---|---|---|---|
| Hex (Base16) | 100 % | पढ़ने में आसान, हर बाइट दो वर्ण | डिबग आउटपुट, छोटे पहचानकर्ता, रंग कोड |
| Base32 (RFC 4648) | 60 % | केस-असंवेदनशील, कोई समान वर्ण नहीं | TOTP रहस्य, Onion पते, आवाज़ श्रुतलेख |
| Base64 मानक | 33 % | सार्वभौमिक, हर भाषा में है | ईमेल, PEM, सामान्य परिवहन |
| Base64 URL-सुरक्षित | 33 % | URL- और फ़ाइलनाम-सुरक्षित | JWT, URL टुकड़े |
| Base58 | ~37 % | 0/O/I/l भ्रम नहीं, कोई विशेष वर्ण नहीं | Bitcoin पते, IPFS CID |
| Ascii85 / Base85 | 25 % | Base64 से सघन | PDF, PostScript |
| Base91 | ~22 % | और भी सघन, अधिक जटिल | दुर्लभ, निच संकोचन संदर्भ |
| Multipart अपलोड | 0 % | HTTP पर देशी बायनरी परिवहन | फ़ाइल अपलोड (ब्राउज़र आपके लिए करते हैं) |
| gzip + Base64 | परिवर्तनशील | कभी-कभी कच्चे Base64 से छोटा | पूर्व-संपीड़ित पेलोड |
अधिकांश रोज़मर्रा के काम के लिए, उत्तर Base64 है (मानक या URL-सुरक्षित)। HTTP पर बायनरी फ़ाइल अपलोड के लिए, सही उत्तर आम तौर पर multipart/form-data है, जो बिल्कुल एन्कोड नहीं करता।
गोपनीयता और एन्कोडर
Base64 एन्कोडर और डिकोडर पूरी तरह आपके ब्राउज़र में चलता है। आप जो टेक्स्ट या फ़ाइल इनपुट करते हैं उसे आपके डिवाइस पर JavaScript प्रोसेस करता है, परिणाम पृष्ठ पर रेंडर होता है, और कुछ भी सर्वर पर नहीं भेजा जाता। कुछ भी लॉग नहीं होता, कुछ भी पृष्ठ से बाहर निकलने के बाद संग्रहीत नहीं होता, और कोई एनालिटिक्स टैग सामग्री नहीं देखता। ऐसी चीज़ों के लिए जिन्हें आप Base64 में एन्कोड कर सकते हैं (PEM प्रमाणपत्र, निजी कुंजियाँ, उत्पादन सिस्टम के JWT पेलोड, असली ग्राहक डेटा के साथ API अनुरोधों के मसौदे), यह सख़्ती से स्थानीय प्रवाह सही डिफ़ॉल्ट है। पूरा टूल पृष्ठ लोड होने के बाद ऑफ़लाइन चल सकता है, जिसे आप नेटवर्क बंद करके और वही इनपुट फिर से एन्कोड करके सत्यापित कर सकते हैं।
अक्सर पूछे जाने वाले प्रश्न
क्या Base64 मेरे डेटा को एन्क्रिप्ट करता है?
नहीं। Base64 एक एन्कोडिंग है, एन्क्रिप्शन नहीं। कोई भी Base64 स्ट्रिंग को डीकोड कर सकता है, यह कोई सुरक्षा नहीं लाता। यदि आप डेटा की सुरक्षा करना चाहते हैं, तो वास्तविक एन्क्रिप्शन (AES, RSA, आदि) का उपयोग करें।
Base64 फ़ाइलों को भारी क्यों बनाता है?
Base64 एन्कोडिंग डेटा के आकार को लगभग 33% बढ़ा देती है। तीन बाइनरी बाइट्स चार Base64 वर्ण बन जाते हैं। यह ओवरहेड बाइनरी को टेक्स्ट के रूप में सुरक्षित रूप से प्रसारित करने की कीमत है।
क्या मैं केवल टेक्स्ट नहीं, फ़ाइलें भी एन्कोड कर सकता हूँ?
हाँ। कोई भी फ़ाइल (छवियाँ, PDF, ऑडियो) Base64 में एन्कोड की जा सकती है। इसका उपयोग आमतौर पर छोटी छवियों को Data URL के रूप में सीधे HTML या CSS में एम्बेड करने के लिए किया जाता है।
Base64 का उपयोग कब नहीं करें?
बड़ी फ़ाइलों के लिए इसका उपयोग न करें। 1 MB की एक छवि Base64 टेक्स्ट में 1.33 MB बन जाती है, और ब्राउज़र इसे अलग से कैश नहीं कर सकता। कुछ KB से अधिक किसी भी चीज़ के लिए, फ़ाइल को सामान्य रूप से सर्व करना अधिक कुशल है।
What is the difference between standard Base64 and URL-safe Base64?
Standard Base64 (RFC 4648 section 4) uses the characters A-Z, a-z, 0-9, +, / with = padding. URL-safe Base64 (RFC 4648 section 5) swaps + for - and / for _ so the string is safe to drop into a URL or a filename without percent-encoding. JWT tokens use the URL-safe variant.
Why does Base64 sometimes have one or two = signs at the end?
The = is padding. Base64 encodes input in 3-byte groups; if the input length is not a multiple of 3, the last group is padded with zero bits and one or two = characters mark the missing bytes. One = means one missing byte, two = means two missing bytes.