Base64 बनाम Base64URL: मिलते-जुलते एन्कोडिंग, पर अलग-अलग काम

मानक Base64 और Base64URL दोनों एक ही मूल विधि से बाइट्स को एन्कोड करते हैं। दोनों बाइनरी डेटा पढ़ते हैं, उसके बिट्स को छह-बिट मानों में फिर से बाँटते हैं और उन मानों को एक चौंसठ-वर्ण वर्णमाला से जोड़ देते हैं। इनका आउटपुट अक्सर लगभग एक जैसा होता है। फ़र्क़ बस तीन वर्णों में सिमटा है, पर वही तीन वर्ण तय करते हैं कि परिणाम किसी URL के भीतर सुरक्षित रहेगा या नहीं।

मानक Base64 URL में क्यों अटपटा हो जाता है

मानक वर्णमाला में + और / शामिल हैं, और पैडिंग के लिए = का प्रयोग होता है। इनमें से कोई भी वर्ण अपने आप में अमान्य नहीं है, पर हर एक की वेब के सामान्य व्याकरण में पहले से कोई भूमिका है। स्लैश पाथ के हिस्सों को अलग करता है। प्लस को फ़ॉर्म-शैली के क्वेरी पार्सर स्पेस मान सकते हैं। बराबर चिह्न पैरामीटर के नाम को उसके मान से अलग करता है। ऐसे में बिना अतिरिक्त एस्केपिंग के मानक Base64 को URL में डालने से मान, आवेदन तक पहुँचने से पहले ही बदल सकता है।

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

दोनों वर्णमालाएँ आमने-सामने

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

यह समानता उपयोगी है, पर बग छिपा भी सकती है। कोई डेवलपर ऐसे मान से परीक्षण कर ले जिसमें केवल साझा वर्ण हों, और मान बैठे कि कोई भी डिकोडर चल जाएगा। ख़राबी बाद में, उत्पादन में सामने आती है, जब कोई इनपुट आख़िरकार स्लैश या प्लस बना देता है। एन्कोडिंग की सीमाओं के परीक्षण में जान-बूझकर ऐसे मान शामिल करने चाहिए जो भिन्न चिह्नों और पैडिंग नियमों को परखें।

JWT, Base64URL का सबसे जाना-पहचाना उदाहरण

एक JSON Web Token में बिंदु से अलग किए गए तीन हिस्से होते हैं — हेडर, पेलोड और हस्ताक्षर। हर हिस्सा Base64URL का प्रयोग करता है क्योंकि टोकन आम तौर पर HTTP ऑथराइज़ेशन हेडर, कुकी और लिंक में सफ़र करते हैं। किसी हेडर या पेलोड के लिए मानक Base64 एन्कोडर चलता दिख सकता है, पर वह ग़लत फ़ॉर्मेट है और असंगत टोकन बना सकता है।

Base64URL, JWT के दावों को निजी नहीं बनाता। जिसके पास टोकन है वह हेडर और पेलोड को डिकोड कर सकता है। हस्ताक्षर ही सर्वर को छेड़छाड़ पकड़ने देता है, और जब दावे गोपनीय रखने हों तो एन्क्रिप्शन ज़रूरी है। URL-सुरक्षित एन्कोडिंग बस टोकन के हिस्सों को आसानी से ले जाने योग्य बनाती है।

पैडिंग एक नीति का चुनाव है, कोई रहस्य नहीं

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

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

सही रूप कैसे चुनें

मानक Base64 तब इस्तेमाल करें जब आसपास का फ़ॉर्मेट साफ़तौर पर उसी की अपेक्षा करता हो। MIME ईमेल अटैचमेंट, PEM ब्लॉक और कई मौजूदा API मानक Base64 तय करते हैं और इन्हें चुपचाप बदलना नहीं चाहिए। Base64URL तब इस्तेमाल करें जब एन्कोडेड डेटा सीधे किसी URL, फ़ाइल नाम, कुकी मान या ऐसे टोकन फ़ॉर्मेट में आना हो जो URL-सुरक्षित वर्णमाला तय करता है।

सिर्फ़ इसलिए Base64URL न चुनें कि आवेदन वेब पर चलता है। कोई JSON API फ़ील्ड मानक Base64 तय कर सकती है, भले ही अनुरोध HTTP पर सफ़र करे। फ़ील्ड का अनुबंध, पूरे अनुरोध के ट्रांसपोर्ट से ज़्यादा मायने रखता है।

आपसी अनुकूलता की वे आदतें जो हैरानी रोकती हैं

हर एन्कोडेड फ़ील्ड के पास अपेक्षित वर्णमाला और पैडिंग व्यवहार दर्ज करें। सहायक फ़ंक्शनों को सटीक नाम दें — encodeBase64Url किसी आम encode से ज़्यादा बात कह देता है। अनपेक्षित वर्णों को चुपचाप गिराने के बजाय ख़राब इनपुट अस्वीकार करें। राउंड-ट्रिप परीक्षण और संबंधित विनिर्देश के ज्ञात उदाहरण शामिल करें।

किसी ख़राबी की जाँच करते समय हर सीमा से पहले और बाद की स्ट्रिंग देखें। क्वेरी पार्सिंग, URL डिकोडिंग, फ़ॉर्म हैंडलिंग और फ़्रेमवर्क मिडलवेयर, आवेदन कोड चलने से पहले ही किसी प्लस या परसेंट एस्केप को बदल सकते हैं। दोनों छोरों पर ठीक-ठीक बाइट्स की तुलना आम तौर पर बता देती है कि समस्या Base64 की है, URL पार्सिंग की, या किसी असंगत अनुबंध की।

छोटा फ़र्क़, साफ़ मक़सद

Base64URL, मानक Base64 का कोई ज़्यादा मज़बूत या आधुनिक विकल्प नहीं है। यह वही बाइनरी-से-टेक्स्ट रणनीति है जो एक अलग वर्ण-वातावरण के अनुरूप ढाली गई है। मानक Base64 अपने इर्द-गिर्द बने फ़ॉर्मेट में सही रहता है; Base64URL वहाँ सही है जहाँ URL व्याकरण वरना अड़चन डालता।

सबसे सुरक्षित तरीक़ा यही है कि इन्हें दो अलग नामित एन्कोडिंग माना जाए, न कि एक ही चीज़ की दो वर्तनियाँ। जैसे ही रूप और पैडिंग नीति साफ़ हो जाती है, दोनों सरल, अनुमेय और व्यापक रूप से समर्थित बन जाते हैं।