FlowingDev

Base64, समझाया गया: बाइनरी डेटा के लिए यूनिवर्सल ट्रांसलेटर

जानें कि कैसे Base64 एन्कोडिंग इमेज और फ़ाइलों जैसे बाइनरी डेटा को प्लेन टेक्स्ट में बदल देती है, जिससे इसे केवल टेक्स्ट के लिए डिज़ाइन किए गए सिस्टम पर भेजना सुरक्षित हो जाता है।

टूल आज़माएँ: Base64 टूल्स

एक वाक्य में

Base64 किसी भी बाइनरी डेटा (जैसे इमेज या ज़िप फ़ाइल) को बोरिंग प्लेन टेक्स्ट का भेष देने का एक चालाक तरीका है ताकि यह उन सिस्टम्स से सुरक्षित रूप से गुज़र सके जो केवल टेक्स्ट समझते हैं।

यह किस समस्या का समाधान करता है

इंटरनेट की शुरुआती दिनों की कल्पना कीजिए। ईमेल (SMTP) और वेब बनाने वाले प्रोटोकॉल जैसे कई कोर सिस्टम, एक सरल धारणा के साथ डिजाइन किए गए थे: वे हमेशा केवल टेक्स्ट ही हैंडल करेंगे। विशेष रूप से, वे 7-बिट ASCII कैरेक्टर सेट के आसपास बनाए गए थे - 128 अक्षर, संख्याएं, और सिंबल जो आप एक स्टैंडर्ड अंग्रेजी कीबोर्ड पर देखते हैं।

मैसेज भेजने के लिए यह ठीक था, लेकिन क्या होता है जब आप कुछ ऐसा भेजना चाहते हैं जो सरल टेक्स्ट नहीं है? एक इमेज, एक साउंड फ़ाइल, एक प्रोग्राम? वह डेटा बाइनरी होता है। यह बाइट्स की एक स्ट्रीम है जहाँ एक बाइट के 256 संभावित मानों में से कोई भी आ सकता है। समस्या यह है कि उन बाइट वैल्यू में से कुछ का उपयोग टेक्स्ट-आधारित सिस्टम में विशेष कंट्रोल कैरेक्टर के रूप में भी किया जाता है। उदाहरण के लिए, एक बाइट 'ट्रांसमिशन का अंत' या 'एक नई लाइन की शुरुआत' का संकेत दे सकता है।

अगर आपने किसी पुराने ईमेल सर्वर के माध्यम से एक रॉ इमेज फ़ाइल भेजने की कोशिश की, तो सर्वर आपके इमेज डेटा के बीच में एक रैंडम बाइट देख सकता है जिसे वह 'ठीक है, मैसेज खत्म!' के रूप में इंटरप्रेट कर सकता है और आपकी बाकी फ़ाइल को काट सकता है। आपकी खूबसूरत बिल्ली की तस्वीर डिजिटल स्टैटिक के एक गड़बड़झाले के रूप में पहुँचती है, अगर वह पहुँचती भी है तो।

यह वह समस्या है जिसे हल करने के लिए Base64 का जन्म हुआ। इसे MIME (मल्टीपर्पज इंटरनेट मेल एक्सटेंशन्स) स्टैंडर्ड के हिस्से के रूप में पेश किया गया था ताकि कैरेक्टर्स का एक 'सुरक्षित' अल्फाबेट बनाया जा सके जिस पर कोई भी टेक्स्ट-हैंडलिंग सिस्टम भरोसा कर सके। बाइनरी डेटा को कैरेक्टर्स के इस सीमित सेट में एनकोड करके, आप अपने नाजुक डेटा को एक मानकीकृत, मजबूत शिपिंग कंटेनर में प्रभावी ढंग से रख सकते हैं, जिसके साथ पोस्टल सिस्टम (टेक्स्ट-आधारित प्रोटोकॉल) कोई छेड़छाड़ नहीं करेगा।

यह अंदर से कैसे काम करता है

Base64 कोई जादू नहीं है, और यह निश्चित रूप से एन्क्रिप्शन नहीं है। यह सिर्फ एक सिस्टमैटिक, रिवर्सेबल सब्स्टीट्यूशन सिफर है। यह ट्रांसपोर्ट सुरक्षा के लिए स्टोरेज एफिशिएंसी का सौदा करता है, इस प्रक्रिया में डेटा को लगभग 33% बड़ा बना देता है।

चलिए 'Man' जैसे सरल शब्द को एनकोड करने की प्रक्रिया से गुजरते हैं।

बाइट्स से बिट्स तक

सबसे पहले, हम अपनी इनपुट स्ट्रिंग लेते हैं और उसका बाइनरी रिप्रेजेंटेशन प्राप्त करते हैं। ASCII/UTF-8 में, "Man" तीन बाइट्स है:

कैरेक्टर ASCII कोड 8-बिट बाइनरी
M 77 01001101
a 97 01100001
n 110 01101110

फिर हम इन्हें एक साथ निचोड़कर 24 बिट्स (3 बाइट्स x 8 बिट्स/बाइट) की एक निरंतर स्ट्रीम बनाते हैं: 010011010110000101101110

6-बिट का फेरबदल

यहाँ मुख्य चाल है। इस स्ट्रीम को 8-बिट चंक्स (बाइट्स) में पढ़ने के बजाय, Base64 इसे 6-बिट चंक्स में पढ़ता है। 6 ही क्यों? क्योंकि 2^6 64 होता है, जो हमें प्रत्येक चंक के लिए ठीक 64 अलग-अलग संभावित मान देता है।

तो, हम अपनी 24-बिट स्ट्रीम को फिर से ग्रुप करते हैं: 010011 010110 000101 101110

अब हमारे पास चार 6-बिट चंक्स हैं। हम इनमें से प्रत्येक को वापस एक डेसीमल संख्या में बदल सकते हैं:

6-बिट चंक डेसीमल वैल्यू
010011 19
010110 22
000101 5
101110 46

लुकअप टेबल

अंतिम चरण इन डेसीमल वैल्यूज को Base64 के 64-कैरेक्टर वाले 'सुरक्षित' अल्फाबेट पर मैप करना है। इस अल्फाबेट में A-Z (इंडेक्स 0-25), a-z (इंडेक्स 26-51), 0-9 (इंडेक्स 52-61), और दो विशेष कैरेक्टर, + और / (इंडेक्स 62 और 63) शामिल हैं।

इंडेक्स कैरेक्टर इंडेक्स कैरेक्टर इंडेक्स कैरेक्टर इंडेक्स कैरेक्टर
0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
... ... ... ... ... ... ... ...
19 T 22 W 5 F 46 u
... ... ... ... ... ... ... ...

हमारे डेसीमल वैल्यूज को देखने पर:

  • 19 T पर मैप होता है
  • 22 W पर मैप होता है
  • 5 F पर मैप होता है
  • 46 u पर मैप होता है

तो, "Man" का Base64 एन्कोडिंग TWFu है।

बचे हुए हिस्सों से निपटना (पैडिंग)

यह पूरी तरह से काम कर गया क्योंकि हमारा इनपुट ("Man") 3 बाइट लंबा था, जो 24 बिट्स का एक अच्छा मल्टीपल है। 24, 8 और 6 दोनों से विभाज्य है, इसलिए सब कुछ सही बैठ जाता है। लेकिन क्या होगा अगर इनपुट 3 बाइट्स का मल्टीपल न हो?

यह वह जगह है जहाँ = पैडिंग कैरेक्टर काम आता है। Base64 की आवश्यकता है कि अंतिम एनकोडेड स्ट्रिंग 3-बाइट इनपुट ग्रुप की एक पूरी संख्या का प्रतिनिधित्व करे। यदि मूल डेटा 3-बाइट सीमा पर समाप्त नहीं होता है, तो पैडिंग आउटपुट में जोड़ी जाती है ताकि इसकी लंबाई सही हो सके।

  • यदि आपके इनपुट में एक बाइट है: उदा., "M" (01001101)। हम 8 बिट्स लेते हैं, पहले 6 को पकड़ते हैं (010011, जो T है), और 2 बिट्स (01) के साथ रह जाते हैं। Base64 कहता है कि आपको इन 2 बिट्स को चार 0 के साथ पैड करना होगा ताकि एक पूरा 6-बिट चंक बन सके (010000, जो Q है)। चूँकि हमें पैडिंग बिट्स जोड़ने की आवश्यकता थी, हम अंतिम स्ट्रिंग में पैडिंग कैरेक्टर भी जोड़ते हैं। नियम यह है कि = तब तक जोड़ते रहें जब तक कि आउटपुट स्ट्रिंग की लंबाई 4 का मल्टीपल न हो जाए। तो, "M" TQ== बन जाता है।
  • यदि आपके इनपुट में दो बाइट्स हैं: उदा., "Ma" (0100110101100001)। हमारे पास 16 बिट्स हैं। हम दो पूरे 6-बिट चंक्स बना सकते हैं (010011 -> T, 010110 -> W)। हमारे पास 4 बिट्स (0001) बचते हैं। हम उन्हें दो 0 के साथ पैड करके 000100 बनाते हैं, जो E है। हम आउटपुट में एक = जोड़ते हैं ताकि इसकी लंबाई 4 का मल्टीपल हो जाए। तो, "Ma" TWE= बन जाता है।

= पैडिंग किसी वास्तविक डेटा का प्रतिनिधित्व नहीं करती है, लेकिन यह डिकोडर्स के लिए मूल बाइनरी को सही ढंग से फिर से बनाने के लिए महत्वपूर्ण है।

वास्तविक दुनिया की कहानियाँ

एक आत्मनिर्भर वेब पेज

एक UX डिजाइनर एक क्लाइंट के साथ साझा करने के लिए एक वेबपेज का एक सरल, सिंगल-फ़ाइल प्रोटोटाइप बनाना चाहता है। पेज को सही दिखने के लिए कंपनी के लोगो और एक विशेष ब्रांड फ़ॉन्ट की आवश्यकता है। आम तौर पर, इसका मतलब होगा एक HTML फ़ाइल, एक इमेज फ़ाइल (logo.png), और एक फ़ॉन्ट फ़ाइल (brand-font.woff2) बनाना, फिर उन सभी को ज़िप करना।

इसके बजाय, डिजाइनर लोगो और फ़ॉन्ट को Base64-एनकोड करने के लिए एक ऑनलाइन टूल का उपयोग करता है। वे परिणामी टेक्स्ट स्ट्रिंग्स को data: URIs का उपयोग करके सीधे स्टाइलशीट में एम्बेड करते हैं:

.logo {
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...");
}

@font-face {
  font-family: 'BrandFont';
  src: url("data:font/woff2;base64,d09GMgABAAAAAAbwAA...") format('woff2');
}

अब, वे क्लाइंट को एक सिंगल .html फ़ाइल भेज सकते हैं। जब क्लाइंट इसे अपने ब्राउज़र में खोलता है, तो पेज लोगो और कस्टम फ़ॉन्ट के साथ पूरी तरह से रेंडर होता है, किसी अतिरिक्त फ़ाइल या वेब सर्वर की आवश्यकता नहीं है।

सबक: Base64 छोटे बाइनरी एसेट्स (इमेज, फ़ॉन्ट्स, आइकॉन) को सीधे HTML, CSS, या SVG जैसी टेक्स्ट फ़ाइलों में बंडल करने, पोर्टेबल, सेल्फ-कन्टेन्ड डॉक्यूमेंट बनाने और HTTP रिक्वेस्ट्स को कम करने के लिए एकदम सही है।

वह API जो केवल JSON बोलती है

एक बैकएंड सर्विस ग्राहकों के लिए PDF इनवॉइस जेनरेट करती है। फ्रंटएंड वेब एप्लिकेशन को इस इनवॉइस को प्राप्त करना है और उपयोगकर्ता को इसे डाउनलोड करने देना है। समस्या यह है कि बैकएंड और फ्रंटएंड को जोड़ने वाली API एक आधुनिक REST API है जो विशेष रूप से JSON में संचार करती है। JSON स्ट्रिंग्स, नंबर्स और बूलियन के साथ बहुत अच्छा है, लेकिन इसमें एक रॉ PDF फ़ाइल को दर्शाने का कोई नेटिव तरीका नहीं है।

बैकएंड डेवलपर इसका समाधान बाइनरी PDF डेटा को लेकर, उसे Base64-एनकोड करके, और परिणामी विशाल स्ट्रिंग को एक JSON ऑब्जेक्ट के अंदर रखकर करता है:

{
  "invoiceId": "INV-2024-00123",
  "customer": "ACME Corp",
  "fileData": "JVBERi0xLjcKJeLjz9MKMSAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFn..."
}

जब फ्रंटएंड इस JSON को प्राप्त करता है, तो यह fileData स्ट्रिंग को पढ़ता है, इसे Base64 से वापस मूल बाइनरी PDF डेटा में डिकोड करता है, और उपयोगकर्ता के लिए फ़ाइल डाउनलोड ट्रिगर करने के लिए ब्राउज़र API का उपयोग करता है।

सबक: Base64, JSON और XML जैसे केवल-टेक्स्ट फॉर्मेट के माध्यम से बाइनरी डेटा को टनल करने के लिए लिंगुआ फ्रांका (lingua franca) है। यह APIs के माध्यम से फ़ाइल अपलोड/डाउनलोड को संभालने का स्टैंडर्ड तरीका है।

URL में अल्पकालिक सीक्रेट

आपने उन्हें लाखों बार देखा होगा: पासवर्ड रीसेट लिंक। एक सामान्य लिंक https://example.com/reset?token=... जैसा दिख सकता है। उस टोकन को अक्सर कई जानकारी ले जानी पड़ती है: उपयोगकर्ता की आईडी, एक एक्सपायरी टाइमस्टैम्प, और छेड़छाड़ को रोकने के लिए एक क्रिप्टोग्राफ़िक सिग्नेचर।

इन टुकड़ों को मिलाने से बाइनरी डेटा की एक स्ट्रिंग बन सकती है। आप सीधे URL में रॉ बाइनरी डेटा नहीं डाल सकते; यह गड़बड़ हो जाएगा या रिजेक्ट कर दिया जाएगा। इसका समाधान बाइनरी टोकन को Base64-एनकोड करना है। यह वही है जो JWT (JSON वेब टोकन) जैसे स्टैंडर्ड करते हैं। एक JWT डॉट्स से जुड़े तीन Base64-एनकोडेड भागों से बना होता है।

लेकिन इसमें एक पेंच है! स्टैंडर्ड Base64 अल्फाबेट में + और / शामिल हैं। इन कैरेक्टर्स का URLs में विशेष अर्थ होता है और यह रूटिंग को तोड़ सकते हैं। इससे 'URL-safe' Base64 वैरिएंट का निर्माण हुआ, जो + को - से और / को _ से बदल देता है।

सबक: Base64 बाइनरी डेटा को URLs के लिए सुरक्षित बनाता है, लेकिन आपको आरक्षित कैरेक्टर्स के साथ टकराव से बचने के लिए URL-safe वैरिएंट का उपयोग करना चाहिए।

आम गलतियाँ और जाल

  • "यह एन्क्रिप्शन है!" नहीं, यह नहीं है। यह नंबर एक गलतफहमी है। Base64 एक एन्कोडिंग है, एन्क्रिप्शन नहीं। यह शून्य गोपनीयता प्रदान करता है। यह पिग लैटिन में एक संदेश लिखने जैसा है - जो कोई भी सरल नियम जानता है वह इसे तुरंत उलट सकता है। सीक्रेट्स छिपाने के लिए कभी भी Base64 का उपयोग न करें; उसके लिए वास्तविक क्रिप्टोग्राफी का उपयोग करें।
  • अपने डेटा को फुलाना। Base64 एन्कोडिंग डेटा का आकार लगभग 33% बढ़ा देती है (क्योंकि इनपुट के हर 3 बाइट्स आउटपुट के 4 बाइट्स बन जाते हैं)। छोटे आइकॉन या टोकन के लिए, यह नगण्य है। 10 MB की वीडियो फ़ाइल के लिए, आप 3 MB से अधिक का ओवरहेड जोड़ रहे हैं। यह API प्रतिक्रियाओं को धीमा कर सकता है और बैंडविड्थ लागत बढ़ा सकता है।
  • URL-असुरक्षित कैरेक्टर्स के बारे में भूल जाना। यदि आप Base64-एनकोडेड डेटा को URL क्वेरी पैरामीटर या पाथ सेगमेंट में डाल रहे हैं, तो आपको अनिवार्य रूप से URL-safe वैरिएंट (जो + और / को बदलता है) का उपयोग करना चाहिए या अन्यथा आउटपुट को URL-एनकोड करें। एक आवारा + को स्पेस के रूप में गलत समझा जा सकता है, और एक / को पाथ डेलीमिटर के रूप में देखा जा सकता है, जिससे टूटे हुए लिंक और 404 एरर हो सकते हैं।
  • पैडिंग को गलत तरीके से संभालना। हालांकि कई आधुनिक डिकोडर गुम = पैडिंग के बारे में उदार हैं, स्पेसिफिकेशन इसे शुद्धता के लिए आवश्यक बताता है। पैडिंग को हटाने या गलत तरीके से गणना करने से सख्त डिकोडर फेल हो सकते हैं। पैडिंग को एनकोडेड स्ट्रिंग का हिस्सा मानना सबसे अच्छा है।

यह आपके रडार पर क्यों होना चाहिए

आपको Base64 के बारे में कभी भी सोचना चाहिए जब आप इस मुख्य दुविधा का सामना कर रहे हों: "मेरे पास यहाँ बाइनरी डेटा है, लेकिन मुझे इसे एक ऐसे चैनल के माध्यम से भेजना है जो केवल टेक्स्ट बोलता है।" यह डेटा ट्रांसपोर्ट और कम्पैटिबिलिटी के लिए एक मौलिक टूल है।

इसका उपयोग तब करें जब आपको आवश्यकता हो:

  • छोटी इमेज, SVG, या फ़ॉन्ट्स को सीधे HTML/CSS में एम्बेड करें।
  • JSON या XML पेलोड के भीतर एक फ़ाइल (PDF, इमेज, आदि) भेजें।
  • URL या कुकी में उपयोग के लिए बाइनरी डेटा को एनकोड करें।
  • JWTs जैसे स्टैंडर्ड्स के साथ काम करें, जो Base64 को एक बिल्डिंग ब्लॉक के रूप में उपयोग करते हैं।

यह कुछ ऐसा नहीं है जिसका आप हर दिन उपयोग करते हैं, लेकिन यह जानना कि यह क्या है और इसका उपयोग कब करना है, आपको गड़बड़ डेटा और रहस्यमय ट्रांसमिशन एरर्स को डीबग करने के अनगिनत घंटों से बचाएगा।

और गहराई में जाएं

  • RFC 4648: Base16, Base32, और Base64 डेटा एन्कोडिंग के लिए आधिकारिक IETF स्पेसिफिकेशन। यह कैनोनिकल स्रोत है। https://datatracker.ietf.org/doc/html/rfc4648
  • MDN Web Docs: Data URLs: वेब डेवलपमेंट में data: URIs का उपयोग कैसे करें, इस पर एक व्यापक गाइड, जो Base64 का एक प्राथमिक उपयोग मामला है। https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs
  • MDN Web Docs: btoa() and atob(): स्ट्रिंग्स को Base64 एनकोड और डीकोड करने के लिए बिल्ट-इन ब्राउज़र फ़ंक्शंस के लिए डॉक्यूमेंटेशन। https://developer.mozilla.org/en-US/docs/Web/API/btoa
  • Wikipedia: Base64: Base64 के इतिहास, वेरिएंट्स और अनुप्रयोगों का एक शानदार हाई-लेवल ओवरव्यू। https://en.wikipedia.org/wiki/Base64

थ्योरी हो गई। अब हाथ आज़माइए — 100% आपके ब्राउज़र में।

टूल आज़माएँ: Base64 टूल्स