डेवलपर टूल · Base64 एनकोडर और डिकोडर
RFC 4648 ने समझाया: वह मानक जो Base64, Base32 और Base16 को परिभाषित करता है
· पेजभूमि
Base64 एन्कोडिंग
RFC 4648 प्रत्येक Base64 कार्यान्वयन के पीछे संक्षिप्त, पठनीय दस्तावेज़ है। यह पोस्ट बताती है कि यह क्या निर्दिष्ट करती है, यह जानबूझकर क्या खुला छोड़ती है, और कार्यान्वयन अभी भी भिन्न क्यों हैं।
दो पुस्तकालय, एक ही स्ट्रिंग के लिए दो उत्तर - एक वास्तविक अंतर-संचालनीयता पहेली जिसे केवल मानक ही सुलझाता है
दो JavaScript लाइब्रेरी एक ही स्ट्रिंग के लिए अलग-अलग Base64 लौटा सकते हैं, प्रत्येक शुद्धता का दावा करता है। RFC 4648 एक पठनीय बारह पेज का दस्तावेज़ है जिसे ऐसी असहमतियों का निपटारा करना चाहिए, फिर भी कार्यान्वयन अभी भी भिन्न हैं क्योंकि RFC जानबूझकर कुछ निर्णय अनुप्रयोगों पर छोड़ देता है। यह आलेख बताता है कि RFC 4648 क्या निर्दिष्ट करता है, यह जानबूझकर कॉल करने वालों को क्या सौंपता है, और मानक को एक बार पढ़ने से अधिकांश वास्तविक अंतरसंचालनीयता पहेलियों का समाधान क्यों हो जाता है। Base64 एनकोडर और डिकोडर टूल में RFC 4648 परीक्षण वैक्टर शामिल हैं ताकि आप आधिकारिक उदाहरणों के विरुद्ध कार्यान्वयन को सत्यापित कर सकें।
RFC 4648 ने कई पुराने दस्तावेज़ों को प्रतिस्थापित और समेकित किया: MIME से Base64 (RFC 2045), गोपनीयता-उन्नत मेल से Base64 (RFC 1421), S/MIME से Base32 (RFC 2630) और आधार16 विभिन्न स्रोतों से। समेकन आवश्यक था क्योंकि MIME और PEM प्रत्येक की अपनी वर्णमाला और नियम थे, और MIME लाइन रैपिंग PEM के 64-कॉलम ब्लॉक के साथ विरोधाभासी थी। RFC 4648 पांच एन्कोडिंग परिवारों को एक ही स्थान पर परिभाषित करता है: Base64, Base64url, Base32, Base32हेक्स और Base16, प्रत्येक की अपनी वर्णमाला, पैडिंग नियम और उदाहरण परीक्षण वैक्टर हैं। Base64 वर्णमाला A-Z, a-z, 0-9, प्लस और स्लैश, उस क्रम में है।
कार्यान्वयन और परीक्षण वैक्टर क्या स्थापित करते हैं - मानक और URL-सुरक्षित अक्षर, पैडिंग और व्हाइटस्पेस हैंडलिंग
प्रत्येक वर्ण 6 bits का प्रतिनिधित्व करता है; तीन इनपुट बाइट्स (24 bits) चार आउटपुट वर्णों को मैप करते हैं। वर्णमाला मनमानी नहीं है: यह उन वर्णों से बचती है जो EBCDIC और ASCII के बीच भिन्न होते हैं, नियंत्रण वर्णों, उद्धरणों और बैकस्लैश से बचते हैं जिन्हें C स्ट्रिंग शाब्दिक में भागने की आवश्यकता होती है। URL और फ़ाइल नामों में आरक्षित वर्णों से बचने के लिए Base64url संस्करण प्लस को डैश से और स्लैश को अंडरस्कोर से बदल देता है। दोनों प्रकार समान रूप से मान्य हैं; RFC 4648 अनुभाग 2 Base64 निर्दिष्ट करता है, अनुभाग 5 Base64url निर्दिष्ट करता है, और एक एप्लिकेशन को यह बताना होगा कि वह किसका उपयोग करता है।
समान वर्णों के साथ पैडिंग करने से आउटपुट चार वर्णों के गुणज में आ जाता है। यदि इनपुट 1 byte (8 bits) है, तो आउटपुट दो अक्षर और दो बराबर चिह्न है। यदि इनपुट 2 bytes (16 bits) है, तो आउटपुट तीन अक्षर और एक बराबर चिह्न है। यदि इनपुट 3 bytes का गुणज है, तो किसी पैडिंग की आवश्यकता नहीं है। कुछ एप्लिकेशन डिकोड पर पैडिंग को छोड़ देते हैं या गायब पैडिंग की अनुमति देते हैं; RFC 4648 अनुभाग 3.2 कैनोनिकल एन्कोडिंग को हमेशा गद्देदार के रूप में परिभाषित करता है, लेकिन अनुभाग 3.3 नोट करता है कि डिकोडर संगतता के लिए लापता पैडिंग को स्वीकार कर सकते हैं।
यह टूल जिन अक्षरों को लागू करता है - मानक Base64 और Base64url; अन्य आधार इसके दायरे से बाहर रहते हैं
पैडिंग भेद के कारण कार्यान्वयन असहमत है: एक सख्त डिकोडर लापता बराबर को अस्वीकार कर देता है, जबकि एक उदार डिकोडर इसे स्वीकार करता है। RFC 4648 स्पष्ट रूप से कहता है: URL में उपयोग किए जाने पर पैड कैरेक्टर इक्वल्स आम तौर पर प्रतिशत-एन्कोडेड होता है, इसलिए यदि Base64url आउटपुट सीधे URL पैरामीटर में उपयोग किया जाता है, तो पैडिंग की आवश्यकता नहीं होती है और इसे छोड़ दिया जाना चाहिए। यह वाक्य एक कारण है URL-सुरक्षित मोड और पैडिंग चूक को अक्सर जोड़ा जाता है, हालांकि वे स्वतंत्र विकल्प हैं। अनुभाग 5 (Base64url) पैडिंग को प्रतिबंधित नहीं करता है; यह केवल सामान्य प्रथा को नोट करता है।
Base64url चुनने वाले कॉलर को यह तय करना होगा कि प्राप्तकर्ता सिस्टम के लिए पैडिंग आवश्यक है या नहीं। इनपुट में गैर-वर्णमाला वर्णों को अलग-अलग डिकोडर्स द्वारा अलग-अलग तरीके से नियंत्रित किया जाता है। RFC 4648 अनुभाग 3.1 कहता है: कार्यान्वयन MUST एन्कोडिंग को अस्वीकार कर देता है यदि इसमें आधार वर्णमाला के बाहर वर्ण शामिल हैं। हालाँकि, अनुभाग 3.3 नोट करता है कि MIME Base64 (RFC 2045) 76-कैरेक्टर रैपिंग के लिए लाइन ब्रेक की अनुमति देता है, और MIME के लिए डिकोडर्स को व्हाइटस्पेस छोड़ना होगा। RFC सख्त डिकोडिंग (सभी गैर-वर्णमाला को अस्वीकार करें) और MIME-संगत डिकोडिंग (व्हाट्सएप छोड़ें, अन्य वर्णों को अस्वीकार करें) के बीच अंतर करता है।
पैडिंग, गैर-वर्णमाला वर्ण और विहित एन्कोडिंग - वे अनुभाग जो अधिकांश डिकोडर असहमति की व्याख्या करते हैं
किCAप्लिकेशन को यह चुनना होगा कि किस नियम का पालन करना है; मानक दोनों को परिभाषित करता है। Base32 A-Z और 2-7 (कुल 32 वर्ण) का उपयोग करता है, पांच इनपुट बाइट्स (40 bits) को आठ आउटपुट वर्णों में एन्कोड करता है। Base32hex वर्णमाला वर्णों के लिए 0-9 और a-v को प्रतिस्थापित करता है, जो उन संदर्भों में उपयोगी है जहां छोटे अक्षरों को प्राथमिकता दी जाती है।
Base16 हेक्साडेसिमल है: 0-9 और a-f. Base32 और Base32hex के अनुभाग 6 और 7 में अपने स्वयं के पैडिंग नियम हैं, और RFC प्रत्येक वर्णमाला के लिए अलग-अलग परीक्षण वेक्टर प्रदान करता है। अधिकांश डेवलपर्स को केवल Base64 और Base64url की आवश्यकता होती है; पूर्णता के लिए और TOTP रहस्य (RFC 4226) और DNS एन्कोडिंग जैसे अनुप्रयोगों के लिए Base32, Base32हेक्स और Base16 को RFC में शामिल किया गया है।
इस कार्यान्वयन में दिखाई देने वाले एप्लिकेशन विकल्प - लाइन रैपिंग, सख्त टेक्स्ट डिकोडिंग और त्रुटि प्रबंधन
RFC 4648 में परीक्षण वेक्टर किसी कार्यान्वयन की जाँच के लिए जमीनी सच्चाई हैं। स्ट्रिंग्स f, fo, foo, foob, fooba और foobar को एन्कोड करने से विशिष्ट Base64 आउटपुट उत्पन्न होता है: Zg==, Zm8=, Zm9v, Zm9vYg==, Zm9vYmE= और Zm9vYmFy। एक कार्यान्वयन जो इन स्ट्रिंग्स के लिए अलग-अलग आउटपुट उत्पन्न करता है वह गलत है। RFC Base32, Base32हेक्स और Base16 के लिए समकक्ष परीक्षण वैक्टर प्रदान करता है। Base64 एनकोडर और डिकोडर टूल में ये वैक्टर शामिल हैं ताकि आप मानक के विरुद्ध इसके आउटपुट को सत्यापित कर सकें। लाइन रैपिंग एक MIME चिंता है, Base64 चिंता नहीं।
RFC 2045 76-वर्ण पंक्तियाँ निर्दिष्ट करता है; RFC 4648 अनुभाग 3.1 इसे MIME के संदर्भ में नोट करता है लेकिन इसे Base64 की आवश्यकता नहीं बनाता है। कुछ एप्लिकेशन 64 वर्ण (मूल PEM मानक) में लपेटे जाते हैं; अन्य बिल्कुल भी लपेटते नहीं हैं। एक सख्त RFC 4648 Base64 डिकोडर केवल वर्णमाला और पैडिंग पर काम करता है। एक MIME-संगत डिकोडर को लाइन ब्रेक (CR, LF, CRLF) छोड़ना होगा। MIME के बाहर Base64 का उपयोग करने वाले एप्लिकेशन को तब तक लाइन ब्रेक नहीं जोड़ना चाहिए जब तक कि प्राप्तकर्ता सिस्टम को उनकी आवश्यकता न हो; RFC Base64 के भाग के रूप में लाइन रैपिंग को परिभाषित नहीं करता है।
कार्यान्वित उदाहरण: RFC के स्वयं के परीक्षण वैक्टर - 'फूबार' उपसर्गों को एन्कोड करना और उन्हें ब्राउज़र में जांचना
व्हाइटस्पेस हैंडलिंग कार्यान्वयन भिन्नता का एक और बिंदु है। RFC 4648 का कहना है कि सख्त डिकोडर्स को गैर-वर्णमाला वर्णों को अस्वीकार करना चाहिए। MIME-रैप्ड Base64 (RFC 2045 Base64) फ़ॉर्मेटिंग के लिए रिक्त स्थान की अनुमति देता है। दोनों मानक इस बात पर सहमत हैं कि आउटपुट बाइट्स क्या होनी चाहिए लेकिन कौन सा इनपुट मान्य है इस पर भिन्न हैं। अधिकांश JavaScript कार्यान्वयन MIME संगतता चुनते हैं और रिक्त स्थान छोड़ देते हैं; ब्राउज़रों में सख्त नियम का उपयोग शायद ही कभी किया जाता है। Base64 एनकोडर और डिकोडर व्हाइटस्पेस-युक्त (MIME) और सख्त इनपुट दोनों को स्वीकार करता है, जिससे अंतर स्पष्ट हो जाता है। विहित बनाम क्षमाशील डिकोडिंग अंतिम प्रमुख भिन्नता है।
कैनोनिकल डिकोडिंग RFC 4648 अनुभाग 3.2 का अनुसरण करती है: विकृत पैडिंग को अस्वीकार करें, लुप्त पैडिंग को अस्वीकार करें, गैर-वर्णमाला वर्णों को अस्वीकार करें। वेब मानकों में उपयोग किया जाने वाला क्षमा डिकोडिंग (HTML स्पेक इसे क्षमा-Base64 कहता है), नियम जोड़ता है: व्हाइटस्पेस को अनदेखा करें, लापता पैडिंग को स्वीकार करें, डैश और अंडरस्कोर को मानक Base64 मोड में भी प्लस स्लैश समकक्ष के रूप में अनुमति दें। JavaScript का एटोब() क्षमाशील है; एक सख्त RFC 4648 डिकोडर अधिक सख्त होता है। न तो गलत है; वे विभिन्न संदर्भ प्रस्तुत करते हैं। किसी उपयोगकर्ता या नेटवर्क से डेटा पढ़ने वाले एप्लिकेशन को पता होना चाहिए कि दूसरा पक्ष किस नियम की अपेक्षा करता है।
इसमें क्या शामिल नहीं है - MIME और PEM दस्तावेज़ स्वयं, और भाषा-विशिष्ट APआई
RFC एप्लिकेशन के लिए नौ विकल्प छोड़ता है: पांच में से कौन सा अक्षर, पैडिंग की आवश्यकता है या अनुमति है, क्या व्हाइटस्पेस की आवश्यकता है या अनुमति है, क्या डैश अंडरस्कोर को प्लस स्लैश समकक्ष के रूप में माना जाता है, त्रुटियों की रिपोर्ट कैसे करें, इनपुट के अंत को कैसे संभालना है, क्या लापता पैडिंग को स्वीकार करना है, कितने आउटपुट बाइट आवंटित करना है, और आकार सीमा का संकेत कैसे देना है। ये विकल्प बताते हैं कि क्यों दो RFC 4648 कार्यान्वयन एक ही इनपुट पर असहमत हो सकते हैं। RFC को एक बार पढ़ें; इसके परीक्षण वैक्टर के विरुद्ध अपने कार्यान्वयन की जाँच करें; बताएं कि आपका एप्लिकेशन किन विकल्पों का उपयोग करता है; वास्तविक सहकर्मी के साथ अंतरसंचालनीयता का परीक्षण करें, मान्यताओं का नहीं।
RFC 4648 को समझने से अधिकांश Base64 विवाद सुलझ जाते हैं क्योंकि असहमति आमतौर पर RFC के बारे में नहीं होती है, बल्कि इस बारे में होती है कि प्रत्येक पक्ष ने कौन सा विकल्प चुना है। RFC इतना संक्षिप्त है कि एक घंटे में शुरू से अंत तक पढ़ा जा सकता है। मानक वर्णमाला को परिभाषित करता है, परीक्षण वेक्टर प्रदान करता है, और चेतावनी देता है कि कार्यान्वयन को कहां निर्णय लेना चाहिए। Base64 एनकोडर और डिकोडर टूल आपको परीक्षण वैक्टर के साथ प्रयोग करने और मानक वर्णमाला को क्रियान्वित होते देखने की सुविधा देता है। अधिकांश रोजमर्रा के Base64 उपयोग के लिए गहन RFC ज्ञान की आवश्यकता नहीं होती है; लेकिन जब डिबगिंग एन्कोडिंग बेमेल हो जाती है या किसी अपरिचित API के साथ एकीकृत हो जाती है, तो मानक को एक बार पढ़ने से अनुमान हटा दिया जाता है।
टेकअवे: मानक को एक बार पढ़ें - कैसे Base64 एनकोडर और डिकोडर आपको मानक वर्णमाला के परीक्षण वैक्टर की जांच करने का एक त्वरित तरीका देता है
RFC 4648 दशकों के तदर्थ आधार एन्कोडिंग अभ्यास का एक पठनीय विनिर्देश में समेकन है। यह परिभाषित नहीं करता है कि Base64 का उपयोग कब करना है (MIME, PEM, JWT, डेटा URI, आदि प्रत्येक की अपनी विशिष्टताएँ हैं); यह परिभाषित करता है कि Base64 क्या है। पांच एन्कोडिंग परिवारों को परिभाषित करके और यह नोट करके कि कौन से विकल्प विहित हैं, RFC यह जांचना संभव बनाता है कि कोई कार्यान्वयन सही है या नहीं। आधिकारिक परीक्षण वैक्टर शुरुआती बिंदु हैं: यदि आपका कार्यान्वयन foobar को एन्कोड करता है और Zm9vYmFy के अलावा कुछ भी उत्पन्न करता है, तो RFC कहता है कि कार्यान्वयन गलत है।
सत्यापन जांच बिंदु के रूप में उस प्राधिकरण का उपयोग करें: प्रत्येक RFC परीक्षण वेक्टर को एन्कोड करें, सटीक वर्णों की तुलना करें, और फिर परिणाम को डीकोड करके पुष्टि करें कि मूल बाइट्स अपरिवर्तित हैं। यह ब्राउज़र-आधारित जांच किसी वर्णमाला या पैडिंग गलती को एकीकरण में कहीं और किसी समस्या से अलग करती है, जबकि मानक को लाइब्रेरी लेबल पर निर्भर रहने के बजाय संदर्भ के रूप में रखती है।