Base64 समझें: एन्कोडिंग और डिकोडिंग असल में कैसे काम करती हैं

Base64 असल में क्या है

Base64 किसी भी बाइट को केवल 64 सुरक्षित वर्णों से लिखने का तरीका है। पूरा विचार इतना ही है। यह न एन्क्रिप्शन है, न संपीड़न, न कोई चेकसम। यह एक संकरी समस्या हल करता है: आपके पास बाइनरी डेटा है, और जिस माध्यम से उसे भेजना है वह केवल टेक्स्ट लेता है।

वह माध्यम किसी ईमेल का मुख्य भाग हो सकता है, कोई JSON फ़ील्ड, कोई URL, कोई HTTP हेडर, कोई YAML कॉन्फ़िग या कोई PEM फ़ाइल। कच्चे बाइट भेजिए और रास्ते में कोई चीज़ उन्हें बिगाड़ देगी: एक नल बाइट स्ट्रिंग काट देता है, कोई 0x0D लाइन-एंडिंग बदलाव से फिर लिखा जाता है, कोई ऊँचा बाइट दूसरे वर्ण-सेट में दूसरा अर्थ ले लेता है। Base64 यह सब टाल देता है क्योंकि वह केवल अक्षर, अंक और दो विराम चिह्न इस्तेमाल करता है, और ये सब टेक्स्ट की तरह बरते जाने पर भी बचे रहते हैं।

कीमत है आकार: आउटपुट इनपुट से लगभग एक तिहाई बड़ा होता है। यही सौदा है, और यह लगभग हमेशा फ़ायदे का रहता है, क्योंकि विकल्प है ऐसा डेटा जो बिगड़ा हुआ पहुँचे।

तीन बाइट चार वर्ण कैसे बनते हैं

Base64 तीन-तीन बाइट के समूहों पर काम करता है। तीन बाइट 24 बिट होते हैं, और 24 साफ़-साफ़ छह-छह के चार समूहों में बँट जाता है। हर 6-बिट समूह 64 वर्णों की वर्णमाला में एक जगह बताता है, इसलिए तीन बाइट अंदर जाने पर चार वर्ण बाहर आते हैं।

Man के तीन बाइट लीजिए:

M = 77 = 01001101, a = 97 = 01100001, n = 110 = 01101110

बिट जोड़िए और छह-छह में फिर बाँटिए:

010011 010110 000101 101110 → 19, 22, 5, 46 → T, W, F, u

तो Man का एन्कोड TWFu बनता है। चार वर्ण, पैडिंग की ज़रूरत नहीं, क्योंकि तीन बाइट ठीक-ठीक बँट गए। यही “ठीक-ठीक बँट गए” अगले हिस्से का विषय है।

वे 64 वर्ण

सूचकांक 0–25 हैं A–Z, 26–51 हैं a–z, 52–61 हैं 0–9, और 62 तथा 63 वही दो हैं जो सारी परेशानी खड़ी करते हैं। मानक Base64 में ये + और / होते हैं।

वर्णमाला, और दो क्यों हैं

+ और / किसी ईमेल के मुख्य भाग में पूरी तरह ठीक हैं और किसी URL में सरासर दुश्मन। / पथ का विभाजक है और + क्वेरी स्ट्रिंग में एक स्पेस का अर्थ रखता है, इसलिए URL में चिपकाया गया Base64 मान बदले हुए बाइट के साथ वापस आ सकता है, और कहीं कोई त्रुटि भी नहीं दिखेगी।

इसी से आया base64url, एक रूप जो पहले 62 वर्ण रखता है और आख़िरी दो बदल देता है: + की जगह - और / की जगह _। यही कूटलेखन JSON Web Token इस्तेमाल करते हैं — अगर आपने कभी किसी JWT को हाथ से पढ़ा है, तो आपने base64url पढ़ा है — और वह सब भी जो URL या फ़ाइल नाम में सफ़र करता है।

बाक़ी मामलों में दोनों रूप एक जैसे हैं, और यही उन्हें मिलाने को ख़तरनाक बनाता है। जिस स्ट्रिंग में +, /, - या _ बिल्कुल न हो वह दोनों में मान्य है और एक ही तरह डिकोड होती है। जिसमें ये हों वह डिकोडर की मानी हुई वर्णमाला के हिसाब से अलग बाइट में डिकोड होती है, और आम तौर पर कोई त्रुटि उठाए बिना। हमारा Base64 एनकोडर और डिकोडर ठीक इसी वजह से बताता है कि उसने कौन-सी वर्णमाला पहचानी।

पैडिंग, और डिकोडर इस पर सहमत क्यों नहीं

इनपुट कम ही तीन बाइट का गुणक होता है। एक बचा हुआ बाइट दो वर्ण देता है, दो बचे बाइट तीन देते हैं, और मानक Base64 उस समूह को = चिह्नों से चार तक भर देता है:

• 3 बाइट → 4 वर्ण, कोई पैडिंग नहीं
• 2 बाइट → 3 वर्ण + =
• 1 बाइट → 2 वर्ण + ==

पैडिंग कोई डेटा नहीं ढोती। वह इसलिए है कि जुड़ी हुई धारा पढ़ने वाला डिकोडर जान सके कि एक एनकोडेड मान कहाँ ख़त्म होता है। अगर आप एक अकेली स्ट्रिंग डिकोड कर रहे हैं तो वह बिल्कुल नहीं चाहिए — इसीलिए base64url उसे आम तौर पर हटा देता है, और इसीलिए = URL में हर हाल में असुविधाजनक है।

व्यावहारिक दिक्कत

कुछ डिकोडर पैडिंग माँगते हैं और उसके बिना स्ट्रिंग सीधे ठुकरा देते हैं। कुछ दोनों रूप स्वीकार करते हैं। यही सबसे आम अकेली वजह है कि एक भाषा में चलने वाला टोकन दूसरी में रूखे “invalid base64” के साथ गिर जाता है। इलाज लगभग हमेशा यही है कि पैडिंग वापस कर दें: = जोड़ते जाएँ जब तक लंबाई चार का गुणक न हो जाए। पैडिंग पर सख़्त डिकोडर ख़राब नहीं है, और उसे छोड़ देने वाला एनकोडर भी नहीं — वे एक ही स्पेसिफ़िकेशन के अलग-अलग आधे हिस्सों का पालन कर रहे हैं।

Base64 एन्क्रिप्शन नहीं है

यह अपने अलग हिस्से का हक़दार है, क्योंकि यह गलती बहुत आम और बहुत महँगी है। Base64 में कोई कुंजी नहीं। वह कुछ नहीं छिपाता। उसे पलटना एक फ़ंक्शन कॉल है, हर भाषा में और इस जैसे हर पेज पर उपलब्ध।

शास्त्रीय उदाहरण HTTP Basic प्रमाणीकरण है। एक Authorization: Basic हेडर इससे ज़्यादा कुछ नहीं कि उपयोगकर्ता:पासवर्ड को Base64 में रख दिया गया हो। वह अपारदर्शी लगता है, और ख़तरा ठीक यही है: जिसने कभी एक डिकोड नहीं किया उसे वह “एन्क्रिप्टेड” पढ़ता है, जबकि हक़ीक़त में जो भी रिक्वेस्ट देख सकता है वह क्रेडेंशियल पढ़ सकता है। इसीलिए Basic केवल HTTPS पर ही स्वीकार्य है — गोपनीयता परिवहन देता है, कूटलेखन कोई नहीं देता।

यही बात JWT की पेलोड पर, किसी कॉन्फ़िग फ़ाइल में पड़े Base64 ब्लॉक पर, और उस API कुंजी पर लागू होती है जिसे किसी ने कमिट करने से पहले “छिपा” दिया था। अगर किसी हमलावर और आपके राज़ के बीच सिर्फ़ Base64 है, तो किसी हमलावर और आपके राज़ के बीच कुछ भी नहीं है। हमारी JSON Web Token डिकोड और डीबग करने की गाइड इस बात को टोकन के संदर्भ में और आगे ले जाती है।

Base64 असल में कहाँ मिलता है

एक बार शक्ल पहचान लें, तो वह हर जगह दिखता है:

• ईमेल अटैचमेंट। MIME नब्बे के दशक की शुरुआत से बाइनरी इसी तरह ढो रहा है, हर पंक्ति 76 वर्णों पर टूटी हुई।
• data: URI। CSS या HTML में data:image/png;base64,… के रूप में जड़ी छोटी तस्वीर, जिसमें एक HTTP रिक्वेस्ट के बदले एक तिहाई ज़्यादा बाइट चुकाए जाते हैं।
• PEM फ़ाइलें। -----BEGIN… चिह्नों के बीच के प्रमाणपत्र और कुंजियाँ नीचे पड़े DER का Base64 हैं, 64 वर्णों पर टूटा हुआ।
• JWT। हेडर और पेलोड base64url में JSON हैं; सिग्नेचर कच्चे बाइट का base64url है।
• Basic auth और कुछ API क्रेडेंशियल। ऊपर जैसा ही, और उसी चेतावनी के साथ।
• JSON के अंदर बाइनरी। JSON में बाइट नाम का कोई प्रकार नहीं, इसलिए बाइट Base64 स्ट्रिंग बनकर सफ़र करते हैं।

कुछ Base64 में पंक्ति-विराम क्यों होते हैं

MIME 76 वर्णों पर और PEM 64 वर्णों पर तोड़ता है, क्योंकि जिन प्रारूपों में वे रहते हैं वे लंबी पंक्तियों से पुराने हैं। ये विराम डेटा का हिस्सा नहीं हैं और डिकोडर को इन्हें नज़रअंदाज़ करना चाहिए। ज़्यादातर करते हैं; कुछ नहीं करते, और इसीलिए टूटे हुए PEM भाग को सख़्त डिकोडर में चिपकाना कभी-कभी तब तक नहीं चलता जब तक आप पंक्ति-विराम हटा न दें।

आकार की कीमत, और कब मायने रखती है

तीन बाइट पर चार वर्ण यानी 4/3 का फैलाव — लगभग 33 % — पैडिंग और पंक्ति-विराम से पहले ही। किसी एक बार के कॉन्फ़िग मान के लिए यह बेमानी है। किसी गर्म रास्ते पर पड़ी चीज़ के लिए नहीं।

data: URI के रूप में जड़ी 10 KB की तस्वीर करीब 13.3 KB HTML की पड़ती है, और असली तस्वीर के उलट उसे अलग से कैश नहीं किया जा सकता और आलस से लोड भी नहीं। हर API कॉल के साथ भेजा गया टोकन हर रिक्वेस्ट पर अपना अतिरिक्त बोझ ढोता है। और संपीड़न आपको नहीं बचाएगा: Base64 आउटपुट मूल बाइट से कहीं ख़राब संपीड़ित होता है, क्योंकि कूटलेखन उन बाइट-स्तरीय पैटर्न को मिटा देता है जिन्हें कंप्रेसर खोजता है। पहले संपीड़ित करें, फिर एनकोड — उल्टा कभी नहीं।

टेक्स्ट एनकोड करने का मतलब बाइट एनकोड करना है

Base64 बाइट एनकोड करता है। उसके पास वर्ण की कोई धारणा नहीं, इसलिए “इस स्ट्रिंग को Base64 में एनकोड करो” हमेशा इसका छोटा रूप है कि “इस स्ट्रिंग को बाइट बनाओ, फिर उन बाइट को एनकोड करो”। बीच का यही कदम है जहाँ चीज़ें बिगड़ती हैं, क्योंकि उसे एक वर्ण-कूटलेखन चाहिए और स्पेसिफ़िकेशन आपके लिए कोई नहीं चुनती।

व्यवहार में उत्तर UTF-8 है, और आधुनिक API उसी को डिफ़ॉल्ट रखते हैं। लेकिन अगर एक तरफ़ टेक्स्ट UTF-16 या Latin-1 में एनकोड हो और दूसरी तरफ़ UTF-8 मानकर डिकोड हो, तो Base64 पूरी तरह मान्य रहेगा और बाहर आने वाला टेक्स्ट कूड़ा होगा। पहचान यह है कि गैर-ASCII वर्ण बुरी तरह बिगड़ते हैं जबकि सादा ASCII ठीक रहता है, क्योंकि ASCII, UTF-8 का उपसमुच्चय है।

आने-जाने की जाँच

अगर आपको शक है कि कोई पाइपलाइन टेक्स्ट ठीक से सँभालती है या नहीं, तो किसी मात्रा और किसी गैर-लातीनी वर्ण वाली स्ट्रिंग एनकोड करें, फिर डिकोड करें और मिलाएँ। जो भी José या किसी इमोजी को बिगाड़े, वह बाइट में बदलने के किसी चरण में जानकारी खो रहा है, Base64 में नहीं।

जब डिकोडिंग बिगड़ जाए

चार निदान लगभग हर मामला ढक लेते हैं:

• “अमान्य वर्ण”। वर्णमाला से बाहर की कोई चीज़ अंदर घुस गई — अक्सर कोई भटका हुआ स्पेस, स्ट्रिंग के साथ कॉपी हुआ कोई उद्धरण चिह्न, या आगे छूटा हुआ data:image/png;base64, उपसर्ग।
• “अमान्य लंबाई”। खाली जगह हटाने के बाद लंबाई चार से भाग देने पर 1 बचती है, जो कोई भी मान्य Base64 पैदा नहीं कर सकता। रास्ते में एक वर्ण खो गया।
• डिकोड होता है, पर कूड़े में। या तो वर्णमालाएँ मेल नहीं खा रहीं (base64url को मानक मानकर डिकोड किया गया, या उल्टा), या ऊपर बताए अनुसार टेक्स्ट कूटलेखन मेल नहीं खा रहा।
• ऐसे बाइट में डिकोड होता है जो टेक्स्ट ही नहीं। यह त्रुटि नहीं है। बहुत सा Base64 कोई तस्वीर, कुंजी या क्रमबद्ध संरचना रखता है; अच्छा डिकोडर नतीजे को स्ट्रिंग बताने के बजाय आपको हेक्स दृश्य दिखाता है।

इन बिंदुओं को इसी क्रम में देखना — वर्ण, लंबाई, वर्णमाला, कूटलेखन — लगभग सब सुलझा देता है। और जब कोई मान कहीं भी डिकोड ही न हो, तो सबसे संभावित व्याख्या सबसे नीरस होती है: वह कटा हुआ था। Base64 में अखंडता जाँच नहीं होती, इसलिए जिस स्ट्रिंग की पूँछ खो गई वह ठीक उसी जैसी दिखती है जिसकी कभी थी ही नहीं।

संबंधित टूल और गाइड:

• Base64 एनकोडर और डिकोडर — टेक्स्ट को Base64 में बदलें या वापस डिकोड करें, URL-safe आउटपुट और सही UTF-8 के साथ।
• JWT डिकोडर — कोई JSON Web Token डिकोड करें और उसका हेडर, पेलोड, क्लेम और समाप्ति पढ़ें।
• JWT समझें: JSON Web Token को डिकोड और डीबग कैसे करें — JSON Web Token में क्या होता है

अक्सर पूछे जाने वाले प्रश्न