समान बाइट, अलग वर्णमाला

RFC 4648 में मानक Base64 मान 62 और 63 के लिए + और / इस्तेमाल करता है; Base64url - और _ इस्तेमाल करता है। ??? टेक्स्ट मानक प्रारूप में Pz8/ और URL प्रारूप में Pz8_ बनता है। >>> से Pj4+ और Pj4- मिलते हैं। Moyoutil का टेक्स्ट Base64 टूल मानक स्ट्रिंग वापस पढ़ता है, लेकिन - या _ वाली स्ट्रिंग पर प्रारूप त्रुटि देता है। नीचे का Node.js कोड दोनों प्रारूपों को अलग से दोहराता है।

for (const text of ["???", ">>>"]) {
  const bytes = Buffer.from(text, "utf8");
  console.log(bytes.toString("base64"),
              bytes.toString("base64url"));
}
// Pz8/ Pz8_
// Pj4+ Pj4-
मान 62 और 63 के Base64 और Base64url वर्ण, दो टेक्स्ट उदाहरणों के साथ
स्वनिर्मित वर्णमाला तुलना चित्र। नीचे की पंक्तियाँ काल्पनिक इनपुट के वास्तविक एन्कोडिंग परिणाम हैं।

RFC 4648 §5: Base64url alphabet

केवल दिखावट से प्रारूप तय न करें

foo दोनों प्रारूपों में Zm9v बनता है। +, /, - और _ न होने से स्ट्रिंग का मानक Base64 होना सिद्ध नहीं होता। उसे बनाने वाले सिस्टम का प्रारूप विनिर्देश देखें। पैडिंग एक अलग नियम है: RFC 4648 इसे आवश्यक मानता है, जब तक संदर्भ देने वाला विनिर्देश अन्यथा न कहे; RFC 7515 में JWS Base64url के अंत के = हटा दिए जाते हैं। उदाहरण के लिए, f मानक प्रारूप में Zg== और बिना पैडिंग वाले URL प्रारूप में Zg बनता है।

for (const text of ["foo", "f"]) {
  const bytes = Buffer.from(text, "utf8");
  console.log(bytes.toString("base64"),
              bytes.toString("base64url"));
}
// Zm9v Zm9v
// Zg== Zg

Moyoutil Base64url को अपने आप परिवर्तित नहीं करता और JWS हस्ताक्षर सत्यापित नहीं करता। यह कोड प्रारूपों की तुलना करता है। पढ़ने योग्य टेक्स्ट मिलना हस्ताक्षर की वैधता सिद्ध नहीं करता। JWS हस्ताक्षर इनपुट में मूल एन्कोड किया हुआ हेडर और पेलोड होते हैं; सत्यापन इनपुट को फिर से एन्कोड करके न बदलें।

RFC 7515 §2–3: Base64url and JWS signing input

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

क्या डिकोड करने के लिए - और _ हटा सकते हैं?

उन्हें न हटाएँ। ये मान 62 और 63 दर्शाने वाले डेटा वर्ण हैं। इन्हें हटाने से मूल डेटा बदल सकता है। इस टूल द्वारा स्वीकार किया जाने वाला मानक Base64 चाहिए तो मूल सिस्टम से उसी प्रारूप में निर्यात करें।