डेवलपमेंट · 4 मिनट में पढ़ें ·
Base64 आसान भाषा में: यह किस काम आता है, और एन्क्रिप्शन क्यों नहीं है
Base64 ईमेल, data URI, API हेडर और JWT में दिखता है। यह कैसे काम करता है, डेटा एक-तिहाई क्यों बढ़ जाता है, और यह कभी कुछ क्यों नहीं छिपाता।

Base64 सॉफ़्टवेयर में हर जगह है: ईमेल अटैचमेंट, CSS में जड़ी इमेज, HTTP Basic auth का Authorization हेडर और JWT के हिस्से। इसका काम एक ही है: बाइनरी बाइट्स समेत किसी भी डेटा को सिर्फ़ सुरक्षित टेक्स्ट कैरेक्टर से लिखना।
यह कैसे काम करता है
Base64 डेटा को एक बार में तीन बाइट (24 बिट) लेकर 6-6 बिट के चार समूहों में बाँटता है। हर समूह 0 से 63 के बीच की संख्या है, जो 64 कैरेक्टर में से एक से जुड़ी है: A-Z, a-z, 0-9, + और /। जब इनपुट तीन-तीन में नहीं बँटता, तो आख़िर में = चिह्न भरे जाते हैं।
टेक्स्ट M a n
बाइट 01001101 01100001 01101110
6 बिट 010011 010110 000101 101110
Base64 T W F u → TWFu
यह क्यों बना
कई पुराने सिस्टम, ख़ासकर ईमेल, टेक्स्ट के लिए बने थे और मनमाने बाइट्स को बिगाड़ सकते थे। Base64 हर चीज़ को साधारण कैरेक्टर में बदल देता है जो इन रास्तों से बिना बदले गुज़र जाते हैं। क़ीमत है साइज़: हर 3 बाइट 4 कैरेक्टर बन जाते हैं, इसलिए एन्कोड किया डेटा लगभग 33% बड़ा होता है।
यह एन्क्रिप्शन नहीं है
कोई की नहीं होती। कोई भी Base64 को तुरंत डिकोड कर सकता है, इसलिए यह कुछ नहीं छिपाता। Basic auth हेडर में पासवर्ड (dXNlcjpwYXNz बस user:pass है) उतना ही खुला है जितना सादा टेक्स्ट। राज़ों को HTTPS और असली एन्क्रिप्शन से बचाएँ, और Base64 को कभी सुरक्षा उपाय न समझें।
जो रूप आपको मिलेंगे
Base64url में + और / की जगह - और _ होते हैं और आम तौर पर पैडिंग हटा दी जाती है, ताकि नतीजा URL और फ़ाइल नामों में सुरक्षित रहे; JWT इसी का इस्तेमाल करते हैं। data URI एन्कोड किए डेटा को सीधे कोड में रखते हैं, जैसे data:image/png;base64,iVBOR…, जिससे बहुत छोटी इमेज के लिए एक रिक्वेस्ट बचती है पर बड़ी इमेज भारी हो जाती हैं।
साइज़ अंकों में
n बाइट के लिए एन्कोडेड लंबाई 4 × ceil(n / 3) कैरेक्टर होती है, यानी लगभग 33% की बढ़ोतरी, और अगर एन्कोडर लाइन ब्रेक जोड़ता है तो वे अलग से।
100 KB की इमेज → लगभग 133 KB Base64
1 MB का अटैचमेंट → लगभग 1.33 MB (ईमेल में लाइन ब्रेक अलग से)
डिकोडिंग क्यों फ़ेल होती है
- पैडिंग गायब: कुछ सिस्टम आख़िर के = चिह्न हटा देते हैं, और सख़्त डिकोडर फिर इनपुट अस्वीकार कर देते हैं। लंबाई 4 से भाग होने तक = जोड़ें।
- गलत अक्षरमाला: Base64url में + और / की जगह - और _ होते हैं। इसे Base64url डिकोडर से डिकोड करें, या पहले कैरेक्टर वापस बदलें।
- लाइन ब्रेक और स्पेस: ईमेल (MIME) Base64 को हर 76 कैरेक्टर पर तोड़ता है। ज़्यादातर डिकोडर इन ब्रेक को नज़रअंदाज़ करते हैं, पर सब नहीं।
- गलत एन्कोडिंग में टेक्स्ट: डिकोड करने पर बाइट मिलते हैं। अगर वे UTF-8 टेक्स्ट थे लेकिन Latin-1 की तरह पढ़े गए, तो हिंदी, हिब्रू और एक्सेंट वाले अक्षर बेतुके कैरेक्टर बन जाते हैं।
JavaScript में btoa का जाल
ब्राउज़र का बिल्ट-इन btoa() सिर्फ़ Latin-1 के कैरेक्टर लेता है और हिंदी, हिब्रू, चीनी या इमोजी पर एरर देता है। पहले टेक्स्ट को UTF-8 बाइट में एन्कोड करें, जैसे TextEncoder से, और फिर Base64 में।
कब इस्तेमाल करें, और कब नहीं
Base64 सही टूल है जब बाइनरी डेटा को टेक्स्ट के लिए बने चैनल से गुज़रना हो: JSON और XML पेलोड, ईमेल, data URI और HTTP हेडर। डेटा छिपाने, उसे छोटा करने (वह हमेशा बढ़ता है) और बड़ी फ़ाइलें डेटाबेस में रखने के लिए यह गलत टूल है, जहाँ बाइनरी कॉलम या ऑब्जेक्ट स्टोरेज छोटा और तेज़ होता है। अगर पाने वाला पक्ष कच्चे बाइट स्वीकार करता है, तो कच्चे बाइट ही भेजें।
आज़माकर देखें
4Dev का Base64 एन्कोडर टाइप करते-करते टेक्स्ट को Base64 में बदलता है। यह UTF-8 इस्तेमाल करता है, इसलिए हिंदी, इमोजी और कोई भी गैर-अंग्रेज़ी टेक्स्ट सही एन्कोड होता है। उल्टी दिशा के लिए Base64 डिकोडर इस्तेमाल करें।