Base64 encoding कैसे काम करती है (और यह encryption क्यों नहीं है)
Base64 encoding binary data को 3-byte (24-bit) chunks में समूहित करके काम करती है और हर chunk को चार 6-bit values के रूप में फिर से व्यक्त करती है, हर value को 64 printable ASCII characters में से एक पर मैप करते हुए। चूँकि 4 output characters सिर्फ़ 3 input bytes को दर्शाते हैं, Base64 data को लगभग 33% फुला देता है, और चूँकि mapping एक तय, सार्वजनिक alphabet है, कोई भी इसे तुरंत पलट सकता है। यह guide सतह से नीचे उतरकर असली bit गणित, = padding का अर्थ, +/ characters, Base64URL variant, और यह बताती है कि यह format कब सही औज़ार है और कब गलत।
bit स्तर पर Base64 असल में क्या करता है
Base64 input के 3 bytes को 4 output characters में बदलता है, 24 bits को 6-6 bits के चार समूहों में फिर से काटकर। एक byte में 8 bits होते हैं, इसलिए तीन bytes 24 bits देते हैं; 24, 6 से पूरी तरह बँटता है, और 0 से 63 तक की चार 6-bit संख्याएँ बनती हैं। इनमें से हर संख्या एक 64-character alphabet में index करती है: A-Z (0-25), a-z (26-51), 0-9 (52-61), और 62 व 63 के लिए दो चिह्न।
"Man" के तीन ASCII bytes लें: M=77, a=97, n=110, जो binary में 01001101 01100001 01101110 हैं। जोड़ने पर वह 24-bit string फिर से 010011 010110 000101 101110, यानी दशमलव values 19, 22, 5, 46 में समूहित होती है। alphabet में index करने पर T, W, F, u मिलते हैं, इसलिए "Man" "TWFu" में encode होता है। यह बदलाव पूरी तरह यांत्रिक और lossless है।
33% overhead इस format का परिभाषित आँकड़ा है: हर 3 input bytes के लिए 4 output bytes एक 4/3 अनुपात है, यानी किसी line-break padding से पहले ही 33.3% की बढ़त। मानक MIME encoding हर 76 characters पर एक line break डालकर एक और छोटा जुर्माना जोड़ता है, जो असल-दुनिया overhead को 33% से थोड़ा ऊपर धकेल देता है।
Base64 encryption या security क्यों नहीं है
Base64 एक encoding है, encryption नहीं, क्योंकि यह कोई key इस्तेमाल नहीं करता और एक सार्वजनिक, मानकीकृत algorithm से कोई भी इसे तुरंत decode कर सकता है। Encryption data को ऐसे बदलती है कि सिर्फ़ सही key रखने वाला ही उसे वापस पा सके; Base64 data को ऐसे बदलता है कि धरती का हर device उसे वापस पा सके, जो बिल्कुल उल्टा लक्ष्य है। किसी Base64 string को secret मानना एक classic security गलती है।
यह भ्रम इसलिए पैदा होता है क्योंकि Base64 output इंसानों को अपठनीय दिखता है, सारे अक्षर और अंक, बीच-बीच में +, /, या =। पर इंसान-को-अपठनीय होना protected होने जैसा नहीं है। command line पर एक ही command जैसे `base64 -d`, या किसी भी भाषा में दो-line का snippet, बिना किसी credential के असली bytes लौटा देता है।
याद रखने वाला नियम: passwords, API keys, tokens, या personal data को Base64 में इस यकीन से कभी store न करें कि यह कुछ छिपाता है। Base64 binary data को text-only channels से transport करने लायक बनाता है; यह किसी चीज़ को चुभती नज़रों से safe नहीं बनाता। अगर आपको privacy चाहिए, तो आपको असली encryption जैसे AES चाहिए, जो transport के लिए ciphertext को Base64-encode करने से पहले लगाई जाती है।
= padding, +/ characters, और Base64URL variant
= character वह padding है जो बताता है कि आख़िरी समूह कितने bytes कम था, और यह Base64 string के बिल्कुल अंत में ही दिखता है। जब input की लंबाई 3 का गुणज न हो, तो आख़िरी समूह में 3 के बजाय 1 या 2 bytes होते हैं; encoder गायब bits को zeros से भर देता है और एक = (2-byte बचत के लिए) या दो == (1-byte बचत के लिए) जोड़ देता है ताकि output की लंबाई साफ़-सुथरे 4 के गुणज पर बनी रहे।
मानक Base64, values 62 और 63 के लिए + और / इस्तेमाल करता है, पर वे characters URLs और filenames में असुरक्षित हैं: + को query strings में space समझा जा सकता है, और / एक path separator है। Base64URL, जो RFC 4648 में परिभाषित है, उन्हें क्रमशः - और _ से बदलता है, और आमतौर पर = padding छोड़ देता है, ताकि एक token किसी URL या filename के अंदर बिना छेड़छाड़ के सफ़र कर सके। JSON Web Tokens ठीक इसी वजह से Base64URL इस्तेमाल करते हैं।
नीचे दी table व्यवहार में मिलने वाले तीन variants की तुलना करती है।
| Variant | Chars 62 और 63 | Padding | कहाँ इस्तेमाल होता है |
|---|---|---|---|
| Standard (RFC 4648 §4) | + और / | हाँ (=) | Data URIs, सामान्य encoding, ज़्यादातर APIs |
| Base64URL (RFC 4648 §5) | - और _ | आमतौर पर छोड़ा जाता है | JWTs, URL params, filenames, cookies |
| MIME (RFC 2045) | + और / | हाँ (=) | Email attachments, 76 chars/line पर wrap |
Base64 कब इस्तेमाल करें और कब नहीं
Base64 तब इस्तेमाल करें जब binary data को ऐसे channel से गुज़रना हो जो भरोसे से सिर्फ़ text ही ले जाता है: CSS या HTML में data URIs के रूप में inline images, JSON payloads में embedded binary blobs, email attachments, और JSON Web Tokens के encoded segments। हर मामले में विकल्प — raw bytes भेजना — उन systems से corrupt या अस्वीकृत हो जाएगा जो text मान लेती हैं।
बड़ी files के लिए Base64 से बचें, क्योंकि 33% size जुर्माना हर byte पर चुकाना पड़ता है। एक 10 MB image को encode करने पर लगभग 13.3 MB text बनता है, जिसे फिर transfer, parse, और decode करना होता है। किसी भी बड़ी चीज़ के लिए, raw file को binary-safe transport जैसे सामान्य multipart upload या signed URL पर भेजें, और Base64 को छोटे assets, icons, और metadata के लिए रखें।
दूसरी कीमत CPU और memory है: बड़ी strings को encode और decode करना मुफ़्त नहीं है, और बड़ी data URIs को inline करना browser caching रोक देता है, क्योंकि bytes हर उस page के साथ दोबारा download होते हैं जो उन्हें embed करती है, बजाय एक अलग file के रूप में एक बार cache होने के।
क्या browser में files को privately encode करना सुरक्षित है?
हाँ, किसी आधुनिक web tool में Base64 encoding पूरी तरह आपके browser में local रूप से होती है, इसलिए आपकी file के bytes कभी किसी server पर upload नहीं होते। encoding शुद्ध गणित है, `btoa()` और FileReader API आपके अपने device पर चलते हैं, जिसका मतलब है कि एक client-side tool किसी document या image को बिना network round trip के Base64 में बदल सकता है।
यह तब मायने रखता है जब input संवेदनशील हो — एक private key, एक internal document, एक customer image — क्योंकि एक पूरी तरह client-side encoder आपको web interface की सुविधा offline command-line tool की privacy के साथ देता है। जिस machine पर आप काम कर रहे हैं, उससे कुछ भी बाहर नहीं जाता।
अक्सर पूछे जाने वाले सवाल
क्या Base64 encryption है?
नहीं। Base64 बिना key वाली एक reversible encoding है, और एक public algorithm से कोई भी इसे तुरंत decode कर सकता है। Encryption को पलटने के लिए एक secret key चाहिए; Base64 को कुछ नहीं चाहिए। secrets की रक्षा के लिए इसे कभी इस्तेमाल न करें।
Base64 data को बड़ा क्यों कर देता है?
क्योंकि यह हर 3 bytes को 4 ASCII characters से दर्शाता है, यानी 4-से-3 अनुपात जो लगभग 33% overhead जोड़ता है। MIME line breaks असल-दुनिया output को थोड़ा और ऊपर धकेल देते हैं।
Base64 string के अंत में = का क्या मतलब है?
यह padding है जो output की लंबाई को 4 का गुणज बनाए रखता है। एक = का मतलब आख़िरी समूह में 2 bytes थे; दो == का मतलब उसमें 1 byte था। यह खुद कोई data नहीं रखता।
Base64 और Base64URL में क्या फ़र्क है?
Base64URL, + और / characters को - और _ से बदलता है और आमतौर पर = padding हटा देता है, ताकि string URLs, filenames, और cookies में सुरक्षित रखी जा सके। JWTs Base64URL इस्तेमाल करते हैं।
क्या मैं बिना किसी tool के Base64 decode कर सकता हूँ?
हाँ। किसी भी भाषा की standard library इसे decode करती है, और `base64 -d` जैसी command-line utilities इसे एक ही कदम में कर देती हैं। यही आसानी ठीक वह वजह है कि Base64 कोई security नहीं देता।