Base64 एनकोडर और डिकोडर

Base64 इसलिए मौजूद है क्योंकि टेक्स्ट के इर्द-गिर्द बना ज़्यादातर इंफ्रास्ट्रक्चर — मेल, JSON, XML, URL — मनमाने बाइनरी बाइट भरोसे के साथ नहीं ले जा सकता, जिनमें कंट्रोल कैरेक्टर, नल बाइट, या ऐसे बाइट सीक्वेंस हो सकते हैं जो किसी स्ट्रिंग को समय से पहले ख़त्म कर दें या किसी पार्सर को सीधे तोड़ दें। Base64 मनमाने बाइनरी डेटा के हर तीन बाइट को 64 के एक तय सेट से निकाले गए चार कैरेक्टर पर मैप करता है जिसे कोई भी टेक्स्ट-आधारित सिस्टम सुरक्षित रूप से संभालता है — अक्षर, अंक और दो चिह्न — तो एनकोड किया गया नतीजा JSON में एम्बेड हो सकता है, मेल अटैचमेंट के रूप में भेजा जा सकता है, या किसी दस्तावेज़ में शामिल हो सकता है बिना कि आगे कुछ भी इसे सादे टेक्स्ट से अलग किसी चीज़ के रूप में ग़लत समझे।

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

ब्राउज़र का बिल्ट-इन `btoa` फ़ंक्शन, जिस पर कई तेज़ Base64 इम्प्लीमेंटेशन सीधे निर्भर करते हैं, U+00FF कोड पॉइंट से ऊपर किसी भी कैरेक्टर पर पहुँचते ही एरर देता है — इसमें लगभग हर इमोजी, चीनी, जापानी, कोरियाई, सिरिलिक, ग्रीक और अरबी, साथ ही फ़्रेंच, जर्मन, स्पैनिश और दूसरी भाषाओं में इस्तेमाल होने वाले काफ़ी सारे एक्सेंट वाले लैटिन कैरेक्टर शामिल हैं। यह किसी दुर्लभ इनपुट को प्रभावित करने वाला अस्पष्ट किनारा-मामला नहीं है; यह असली दुनिया के टेक्स्ट के एक बहुत बड़े हिस्से को प्रभावित करता है, और यही वजह है कि हाथ से बनाए इतने सारे Base64 टूल सादे अंग्रेज़ी इनपुट के टेस्ट में बिल्कुल सही काम करते हैं और फिर पहली बार फ़ेल हो जाते हैं जब कोई यूज़र इमोजी या ग़ैर-लैटिन नाम वाला कुछ पेस्ट करता है।

सही उपाय है टेक्स्ट को पहले UTF-8 बाइट के रूप में एनकोड करना, फिर उन बाइट को Base64 में एनकोड करना — यही सही तरीक़े से बने एनकोडर करते हैं और यही यह टूल करता है — बजाय Unicode कोड पॉइंट को सीधे 256 से नीचे के बाइट सीक्वेंस के लिए बनी एनकोडिंग में डालने की कोशिश करने के।

स्टैंडर्ड Base64 के कैरेक्टर सेट में `+` और `/` शामिल हैं, दोनों का किसी URL में अलग मतलब है — `+` कभी-कभी स्पेस के रूप में समझा जाता है, और `/` एक पाथ सेपरेटर है — तो सीधे किसी क्वेरी स्ट्रिंग या फ़ाइल नाम में पेस्ट की गई स्टैंडर्ड Base64 स्ट्रिंग उस URL को पार्स करने वाली किसी भी चीज़ से गुज़रते समय चुपचाप बिगड़ या कट सकती है। Base64URL इन दो कैरेक्टर को `-` और `_` से बदल देता है, जिनमें से किसी का भी URL में कोई ख़ास मतलब नहीं है, और आमतौर पर अंत के `=` पैडिंग कैरेक्टर भी हटा देता है, जो सिर्फ़ लंबाई बताने के लिए मौजूद होते हैं और डिकोडर को पहले से उनकी उम्मीद होने पर ज़रूरी नहीं रहते।

JSON Web Token ठीक इसी वजह से Base64URL इस्तेमाल करते हैं: कोई JWT किसी HTTP Authorization हेडर और कभी-कभी किसी URL के अंदर यात्रा करने के लिए बनाया गया है, और स्टैंडर्ड Base64 के रिज़र्व्ड कैरेक्टर इसे अविश्वसनीय बना देंगे।

यह साफ़ तौर पर कहना ज़रूरी है क्योंकि यह ग़लतफ़हमी अक्सर सामने आती है: Base64 शून्य गोपनीयता देता है। इस प्रोसेस में किसी भी बिंदु पर कोई गुप्त कुंजी शामिल नहीं होती, तो कोई भी जो Base64 स्ट्रिंग पाता है वह इसे किसी भी स्टैंडर्ड लाइब्रेरी कॉल या ठीक इस जैसे किसी टूल का इस्तेमाल करके तुरंत मूल डेटा में वापस डिकोड कर सकता है। किसी पासवर्ड या API कुंजी को स्टोर या ट्रांसमिट करने से पहले Base64 में एनकोड करना बिल्कुल कोई सुरक्षा नहीं देता — यह सिर्फ़ एक सरसरी नज़र से वैल्यू छुपाता है, जो असली सुरक्षा से बिल्कुल अलग गुण है।