Base64URL दो वर्णमाला वर्ण बदलता है: मानक Base64 का प्लस डैश बन जाता है, और स्लैश अंडरस्कोर बन जाता है। एन्कोडेड जानकारी अपरिवर्तित है. वैरिएंट तब मदद करता है जब आसपास का प्रोटोकॉल प्लस या स्लैश को विशेष अर्थ देता है, लेकिन यह प्रत्येक URL या एप्लिकेशन नियम से मान को छूट नहीं देता है।
एक वेक्टर का उपयोग करें जो अंतर को उजागर करता है
बाइट्स एफबी एफएफ के रूप में एन्कोड करते हैं +/8= मानक Base64 में और -_8= Base64URL में। हेलो जैसा परीक्षण केवल साझा वर्णमाला वर्ण उत्पन्न करता है, इसलिए यह प्रकट नहीं कर सकता कि URL-सुरक्षित रूपांतरण काम कर रहा है या नहीं।
const standard = btoa(String.fromCharCode(251, 255));
const urlSafe = standard.replace(/\+/g, '-').replace(/\//g, '_');
console.log(standard); // +/8=
console.log(urlSafe); // -_8=पैडिंग एक अलग समझौता है
कई टोकन प्रारूप अंत के बराबर चिह्न हटा देते हैं, जबकि अन्य प्रणालियाँ उन्हें रखती हैं। वर्णमाला बदलना और पैडिंग हटाना अलग-अलग विकल्प हैं। बिना पैडिंग वाले इनपुट की लंबाई को 4 से भाग देने पर शेषफल 2 हो, तो दो बराबर चिह्न जोड़ने होंगे; शेषफल 3 हो, तो एक चिह्न जोड़ना होगा। शेषफल 1 वाले इनपुट को केवल पैडिंग जोड़कर ठीक नहीं किया जा सकता, क्योंकि छह बिट का एक वर्ण पूरे बाइट को व्यक्त करने के लिए पर्याप्त नहीं है।
सत्यापन करते समय, अंतिम वर्ण में अप्रयुक्त बिट्स की भी जाँच करें। एक डिकोडर जो उन्हें अनदेखा करता है वह एक ही बाइट अनुक्रम के लिए कई स्ट्रिंग स्वीकार कर सकता है। वह अस्पष्टता तब मायने रख सकती है जब कोई एप्लिकेशन डिकोडेड बाइट्स के बजाय एन्कोडेड स्ट्रिंग्स की तुलना करता है। एक विहित निर्माता को एक सहमत प्रतिनिधित्व प्रस्तुत करना चाहिए।
क्वेरी पार्सिंग को Base64 डिकोडिंग के साथ भ्रमित न करें
फॉर्म-शैली क्वेरी पार्सिंग एक शाब्दिक प्लस को एक स्थान के रूप में व्याख्या करती है। एक मानक Base64 मान को क्वेरी में बिना छिपाए चिपकाया गया है, इसलिए इसे डिकोडर द्वारा देखे जाने से पहले ही दूषित किया जा सकता है। के साथ क्वेरी का निर्माण करें URLSearchParams, या यदि प्राप्तकर्ता प्रोटोकॉल इसे निर्दिष्ट करता है तो Base64URL वैरिएंट का उपयोग करें।
const query = new URLSearchParams({ payload: '+/8=' });
console.log(query.toString()); // payload=%2B%2F8%3D
console.log(query.get('payload')); // +/8=प्रत्येक स्थान को स्वचालित रूप से प्लस से न बदलें: एक स्थान वास्तविक स्वरूपण या किसी अन्य त्रुटि का प्रमाण हो सकता है। स्रोत को सुरक्षित रखें, उस परिवहन परत की पहचान करें जिसने इसे बदल दिया, और एक जानबूझकर सुधार लागू करें। JWT सेगमेंट के लिए, सामान्य मरम्मत नीति का आविष्कार करने के बजाय टोकन प्रारूप के Base64URL नियमों का उपयोग करें।
मानक और URL-सुरक्षित अक्षरों का वर्णन किया गया है RFC 4648. आपके एकीकरण को अभी भी पैडिंग, व्हाइटस्पेस स्वीकृति और अधिकतम लंबाई के लिए स्पष्ट विकल्पों की आवश्यकता है।