Base64, Base64URL और Base32: एक प्रोटोकॉल चयन चेकलिस्ट

ये तीन नाम संबंधित बाइनरी-टू-टेक्स्ट योजनाओं का वर्णन करते हैं, लेकिन वे विभिन्न बाधाओं को पूरा करते हैं। Base64 और Base64URL छह-बिट समूहों का उपयोग करते हैं। मानक Base32 पांच-बिट समूहों और एक छोटे वर्णमाला का उपयोग करता है। सही विकल्प वह है जिसे आपका परिवहन, भंडारण और प्राप्त करने वाला एप्लिकेशन सटीक रूप से संरक्षित कर सके।

लंबाई से पहले अक्षरों की तुलना करें

मानक Base64 अपरकेस और लोअरकेस अक्षर, अंक, प्लस और स्लैश का उपयोग करता है। Base64URL अंतिम दो वर्णों के लिए डैश और अंडरस्कोर का स्थान लेता है। दोनों केस-संवेदी हैं. मानक RFC Base32 अपरकेस A-Z और अंक 2-7 का उपयोग करता है। एक डिकोडर एक सुविधा के रूप में लोअरकेस को स्वीकार कर सकता है, लेकिन एक प्रोटोकॉल को यह बताना चाहिए कि क्या इसकी अनुमति है और इसके कैनोनिकल आउटपुट को परिभाषित करना चाहिए।

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

साइज़ ट्रेडऑफ़ को समझें

अंतिम आंशिक समूह को नजरअंदाज करते हुए, Base64 को प्रति बाइट लगभग 1.33 वर्ण की आवश्यकता होती है और Base32 को 1.6 की आवश्यकता होती है। मानक गद्देदार Base32 पांच बाइट्स के लिए आठ-वर्ण समूह उत्सर्जित करता है। एफ अक्षर वाले एक बाइट के लिए, सामान्य वेक्टर हैं Zg== Base64 में और MY====== Base32 में। छोटे इनपुट ओवरहेड पैडिंग को बढ़ा देते हैं, इसलिए यथार्थवादी पेलोड लंबाई की तुलना करें।

Payload bytes: 66 (ASCII f)
Base64:        Zg==
Base64URL:     Zg==  (or Zg when the protocol omits padding)
RFC Base32:    MY======

Base32 वेरिएंट को न मिलाएं

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

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

पूरा अनुबंध लिखें

जहां प्रासंगिक हो, वहां इनपुट बाइट क्रम निर्दिष्ट करें, खाली-इनपुट व्यवहार, अग्रणी-शून्य संरक्षण, अधिकतम लंबाई, रिक्त स्थान स्वीकृति और अमान्य-वर्ण हैंडलिंग। उच्च-मूल्य वाले बाइट्स और आंशिक समूहों के साथ परीक्षण वैक्टर शामिल करें। अपने चुने हुए एनकोडर और डिकोडर का उपयोग उन वैक्टरों के विरुद्ध स्वतंत्र रूप से करें, न कि केवल एक-दूसरे के विरुद्ध; मिलान करने वाले बग अन्यथा राउंडट्रिप को पार करते हुए दिखाई दे सकते हैं। मानक प्रपत्र और संदर्भ वेक्टर अंदर हैं RFC 4648.