Base64 डिकोडर

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

शुरुआत में हर चीज़ जो Base64 में एनकोड की गई हो वह टेक्स्ट नहीं होती — इमेज, एन्क्रिप्शन कुंजी और दूसरा बाइनरी डेटा भी टेक्स्ट जैसी ही सुरक्षा वजहों से आमतौर पर Base64 में एनकोड होता है। इनमें से किसी एक को डिकोड करने पर कच्चे बाइट मिलते हैं जो टेक्स्ट के रूप में समझे जाने पर बिगड़े और अपठनीय अक्षरों के रूप में दिखते हैं, जो डिकोडिंग फ़ेल होने के संकेत की बजाय अपेक्षित है: ऑपरेशन ने एनकोडिंग को सही तरीक़े से पलटा, लेकिन अंतर्निहित बाइट पहली जगह कभी UTF-8 टेक्स्ट के रूप में पढ़े जाने के लिए बने ही नहीं थे।

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