डेवलपर टूल · Base64 एनकोडर और डिकोडर
Base64 का संक्षिप्त इतिहास: यूएनकोड और PEM से लेकर आज की वर्णमाला तक
· पेजभूमि
Base64 एन्कोडिंग
Base64 की वर्णमाला 1980 के दशक की परिवहन समस्याओं का जीवाश्म रिकॉर्ड है। यह पोस्ट गोपनीयता-उन्नत मेल के माध्यम से uuencode से MIME और RFC 4648 की वंशावली का अनुसरण करती है, और प्रत्येक डिज़ाइन विकल्प की व्याख्या करती है।
वर्णमाला कुछ स्पष्ट क्रम में 0–63 क्यों नहीं है - यह प्रश्न चार दशकों पीछे ले जाता है
Base64 एक मानक के रूप में पूरी तरह से गठित नहीं हुआ। वर्णमाला (ए-जेड, ए-जेड, 0-9, +, /) दशकों के एन्कोडिंग प्रयोगों का एक जीवाश्म रिकॉर्ड है, प्रत्येक एक ही समस्या को हल करने की कोशिश कर रहा है: बाइनरी डेटा को टेक्स्ट के रूप में कैसे प्रस्तुत किया जाए जो 1970 और 1980 के दशक के ईमेल, USENET और Unix टूल्स तक जीवित रहे। कहानी यूएनकोड तक फैली हुई है Unix पर, गोपनीयता-उन्नत मेल (RFC 1421) 1993 में, MIME (RFC 2045) 1996 में, और अंत में RFC 4648 में 2006 सभी वेरिएंट को समेकित कर रहा है।
इस इतिहास को समझने से पता चलता है कि वर्णमाला में कुछ अक्षर क्यों हैं और RFC ने कार्यान्वयनकर्ताओं के लिए कुछ विकल्प क्यों छोड़े हैं। यूएनकोड, Unix-टू-Unix एनकोड का संक्षिप्त रूप, Unix पर 7-बिट ट्रांसपोर्ट समस्या को हल करने वाला पहला टूल था। 1980 में बनाया गया, इसने प्रत्येक 3 bytes (24 bits) को 64-वर्ण वर्णमाला से 4 वर्णों में एन्कोड किया। यूएनकोड वर्णमाला ASCII 32 (स्पेस) से ASCII 95 (अंडरस्कोर और अन्य विराम चिह्न) थी, इसलिए चुना गया क्योंकि वे अक्षर किसी भी टर्मिनल पर प्रिंट करने योग्य हैं। भंडार वर्तमान में लागू वर्णमाला को प्रदर्शित करता है, लेकिन इसमें इस बारे में कोई अभिलेखीय साक्ष्य नहीं है कि उस क्रम को किसने चुना या प्रत्येक वर्ण क्यों जीता। इसलिए शीर्षक को संकुचित कर दिया गया है: वर्तमान लेआउट का सटीक निरीक्षण किया जा सकता है, जबकि उद्देश्यों और तिथियों के लिए प्राथमिक ऐतिहासिक दस्तावेजों की आवश्यकता होती है जिन्हें यहां शामिल नहीं किया गया है।
वर्णमाला ऐतिहासिक क्यों दिखती है - एक सीमा जिसका यह भंडार दस्तावेज़ीकरण नहीं करता है
हालाँकि, एन्कोडिंग कैरेक्टर के रूप में स्पेस समस्याग्रस्त है: टेक्स्ट एडिटर और मेल सिस्टम पिछली जगहों को ट्रिम कर देते हैं, जिससे आउटपुट खराब हो जाता है। वर्णमाला आदर्श नहीं थी, लेकिन Unix-टू-Unix फ़ाइल स्थानांतरण के लिए इसने काफी अच्छा काम किया। गोपनीयता-उन्नत मेल (RFC 1421, 1992) एन्क्रिप्टेड ईमेल को मानकीकृत करने का एक प्रारंभिक प्रयास था। इसमें MIME के लिए अपना स्वयं का Base64 एन्कोडिंग (RFC 1341, शामिल है, जो RFC 1421 विनिर्देश में पहले का है लेकिन अपनाने में पिछड़ गया)।
RFC 1421 Base64 ने वर्णमाला A-Z, a-z, 0-9, +, / (आधुनिक आधार 64 वर्णमाला) का उपयोग किया, और 64 वर्णों पर पंक्तियाँ लपेटीं। इस वर्णमाला में रिक्त स्थान और अन्य समस्याग्रस्त वर्णों से परहेज किया गया; प्रत्येक वर्ण स्पष्ट रूप से मुद्रण योग्य है और नियंत्रण कोड या राष्ट्रीय वर्ण-सेट विविधताओं के साथ भ्रमित नहीं होता है। 64-वर्ण लाइन की लंबाई 1980 के दशक के पेपर टर्मिनलों की चौड़ाई से मेल खाती थी और पठनीयता के लिए एक व्यावहारिक समझौता था। यूएनकोड आसपास के इतिहास से संबंधित है, फिर भी टूल न तो इसकी वर्णमाला को पढ़ता है और न ही लिखता है। इसे विनिमेय Base64 के रूप में मानना एक प्रारूप त्रुटि होगी। यहां उपयोगी तुलना मुद्रण योग्य वर्णों के साथ बाइट्स का प्रतिनिधित्व करने की साझा समस्या तक सीमित है।
संदर्भ के रूप में पहले की एन्कोडिंग, कार्यान्वयन साक्ष्य के रूप में नहीं
RFC 1421 को एन्क्रिप्टेड ईमेल के लिए व्यापक रूप से नहीं अपनाया गया, लेकिन इसका Base64 वर्णमाला बच गया। MIME (बहुउद्देशीय इंटरनेट मेल एक्सटेंशन, RFC 2045, 1996) ने RFC 1421 Base64 वर्णमाला को अपनाया लेकिन लाइन रैप को 64 से 76 वर्णों में बदल दिया। कारण तकनीकी नहीं बल्कि ऐतिहासिक था: PEM (गोपनीयता-उन्नत मेल) ब्लॉक में 64 वर्ण थे, और MIME ने स्वचालित पार्सिंग में PEM के साथ भ्रम से बचने के लिए थोड़ी अलग सीमा चुनी।
MIME Base64 ईमेल अनुलग्नकों के लिए मानक बन गया और आज यह सबसे व्यापक रूप से उपयोग किया जाने वाला Base64 संस्करण है। RFC 2045 ने सामग्री प्रकार के आधार पर मेल सिस्टम विकल्प देते हुए अन्य सामग्री-स्थानांतरण-एनकोडिंग मान (7bit, 8bit, उद्धृत-मुद्रण योग्य) को भी परिभाषित किया। वर्णमाला चयन उन वर्णों से बचता है जो ASCII और EBCDIC (IBM मेनफ्रेम वर्ण एन्कोडिंग) के बीच भिन्न होते हैं। अक्षर A-Z, a-z, 0-9, +, और / दोनों एन्कोडिंग में समान हैं। PEM-शैली ब्लॉक पहचानने योग्य हैं क्योंकि लेबल लिपटे हुए एन्कोडेड सामग्री के चारों ओर होते हैं। ToolAcre उन लेबलों को हटा दिए जाने के बाद निकाले गए Base64 बॉडी को संसाधित कर सकता है। यह स्थापित नहीं कर सकता कि किस अभिलेखीय विनिर्देश ने सबसे पहले किसी दिए गए सम्मेलन का उपयोग किया था, और यह आलेख स्रोत वृक्ष उस प्रश्न का उत्तर नहीं देता है।
PEM-स्टाइल कवच एक आधुनिक अवलोकन योग्य प्रारूप के रूप में, मूल कहानी का दावा किए बिना
ओपन ब्रैकेट और क्लोज़ ब्रैकेट जैसे वर्ण ASCII और EBCDIC के बीच भिन्न होते हैं, इसलिए उन्हें बाहर रखा गया था। यह 1980 और 1990 के दशक की शुरुआत में महत्वपूर्ण था जब मेनफ्रेम-टू-Unix डेटा स्थानांतरण आम था। वर्णमाला बैकस्लैश, सिंगल कोट और डबल कोट से भी बचती है, जिनका सी स्ट्रिंग्स और शेल सिंटैक्स में विशेष अर्थ होता है। Base64 स्ट्रिंग को लगभग हर अक्षर से बचकर बिना C प्रोग्राम या शेल स्क्रिप्ट में एम्बेड किया जा सकता है।
RFC 3548 (2006) समेकित Base64, Base32, और Base16 एनकोडिंग। इसमें कहा गया है कि MIME, PEM, और अन्य एप्लिकेशन सभी समान अवधारणाओं का उपयोग करते हैं लेकिन अलग-अलग पैडिंग नियमों और वर्णमाला के साथ। RFC 4648 (2006, RFC 3548 के साथ प्रकाशित) वर्तमान मानक है, और यह प्रत्येक के लिए परीक्षण वैक्टर के साथ पांच एन्कोडिंग परिवारों को परिभाषित करता है। RFC इतिहास को भी नोट करता है: कौन से दस्तावेज़ परिभाषित करते हैं कि कौन से एन्कोडिंग, संस्करणों के बीच क्या परिवर्तन हुआ, और विकल्प क्यों चुने गए। एनकोडर का 76-कैरेक्टर रैपिंग विकल्प और डिकोडर का व्हाइटस्पेस निष्कासन MIME-आकार के नमूनों को परीक्षण योग्य बनाता है। वे कार्यान्वयन तथ्य मेल मानकों का संपूर्ण इतिहास सिद्ध नहीं करते हैं। वे आधुनिक अनुकूलता व्यवहार दिखाते हैं जिसे पाठक सीधे पैनल और परीक्षणों में पुन: पेश कर सकते हैं।
MIME-एनकोडर विकल्प के रूप में स्टाइल रैपिंग, मानक इतिहास के पुनर्निर्माण के बिना
अधिकांश डेवलपर्स को RFC 4648 में केवल Base64 और Base64url का सामना करना पड़ता है; इतिहास उन लोगों के लिए प्रलेखित है जिन्हें पुराने वेरिएंट को लागू करने की आवश्यकता है। Base64url (RFC 4648 अनुभाग 5) URL-आरक्षित वर्णों से बचने के लिए प्लस को डैश से और स्लैश को अंडरस्कोर से बदल देता है। + और / युक्त Base64 स्ट्रिंग को URL (%2B और %2F) में प्रतिशत-एन्कोड किया जाना चाहिए; Base64url उससे बचता है।
JWT (JSON वेब टोकन) बिना पैडिंग के Base64url का उपयोग करता है। कुछ एप्लिकेशन पैडिंग के साथ Base64url का उपयोग करते हैं। RFC दोनों प्रकारों को परिभाषित करता है; यह एप्लिकेशन पर निर्भर है कि किसे चुनना है। इस भिन्नता के कारण एक JWT डिकोडर और एक ईमेल Base64 डिकोडर एक ही इनपुट स्ट्रिंग के लिए अलग-अलग आउटपुट उत्पन्न कर सकते हैं (एक Base64url की अपेक्षा करता है, दूसरा Base64 की अपेक्षा करता है)। वर्णमाला, पैडिंग नियम और लाइन रैपिंग सभी वास्तविक प्रणालियों की व्यावहारिक बाधाओं से उभरे हैं। पोर्टेबिलिटी को प्रत्येक प्रतीक की सत्यापित जीवनी के बजाय परिवहन वर्णमाला पर एक बाधा के रूप में सबसे अच्छा माना जाता है। अक्षर और अंक सामान्य पाठ प्रणालियों में दृष्टिगत रूप से परिचित रहते हैं, जबकि अंतिम विराम चिह्न URL-सुरक्षित मोड में भिन्न होते हैं। प्राथमिक साक्ष्य के बिना सटीक ऐतिहासिक चयन तर्क को छोड़ दिया गया है।
एक डिज़ाइन बाधा के रूप में पोर्टेबिलिटी, व्यक्तिगत चरित्र विकल्पों का सत्यापित खाता नहीं
64-वर्ण सेट को एन्कोडिंग में प्रतिनिधित्व के लिए चुना गया था; वर्णमाला RFC 1341 और 1421 और MIME द्वारा तय की गई थी; पैडिंग नियम 3-बाइट संरेखण से आया है; और लाइन रैपिंग ईमेल ट्रांसपोर्ट सीमा से आई है। एक कार्यान्वयन जो इस इतिहास को अनदेखा करता है वह एक नई एन्कोडिंग का आविष्कार कर सकता है या एक किनारे के मामले को भूल सकता है। RFC 4648 परीक्षण वैक्टर (फूबार Zm9vYmFy उत्पन्न करता है) यह सत्यापित करने का तरीका है कि कार्यान्वयन मानक का सम्मान करता है।
Base85 (कुछ संदर्भों में प्रयुक्त) जैसे आधुनिक विकल्प मौजूद हैं, लेकिन Base64 ऐतिहासिक गति के कारण प्रभावी बना हुआ है और क्योंकि यह काफी अच्छा है। Base64 सबसे कॉम्पैक्ट एन्कोडिंग नहीं है (Base85 और बेस91 सघन हैं), लेकिन यह सरल, सार्वभौमिक और सिद्ध है। जो बात दृढ़ता से कही जा सकती है वह है अक्षरों की वर्तमान जोड़ी: मानक प्लस और स्लैश में समाप्त होता है; URL-सुरक्षित विकल्प हाइफ़न और अंडरस्कोर। पैडिंग और रैपिंग अलग-अलग विकल्प हैं। परीक्षण दोनों मोड और लापता पैडिंग को कवर करते हैं, जो अनुमानित कालक्रम के बजाय वर्तमान व्यवहार के लिए प्रतिलिपि प्रस्तुत करने योग्य साक्ष्य प्रदान करते हैं।
वर्तमान मानक और URL-सुरक्षित वर्णमाला के बारे में भंडार क्या साबित करता है
33 प्रतिशत आकार का ओवरहेड अधिकांश उपयोगों के लिए स्वीकार्य है। कार्यान्वयन में वर्णमाला स्थिर है। RFC इतना स्पष्ट है कि विचलन आम तौर पर आकस्मिक गलतफहमी के बजाय जानबूझकर (जैसे पैडिंग चूक या व्हाइटस्पेस हैंडलिंग) होते हैं।
Base64 के इतिहास को समझने से पता चलता है कि यह इस तरह क्यों दिखता है। विभिन्न वर्ण एन्कोडिंग में अस्पष्टता से बचने के लिए प्लस और स्लैश वर्ण जानबूझकर चुने गए थे। पैडिंग नियम 3-बाइट ग्रुपिंग से आया है। Base85 और Ascii85 विभिन्न समूह आकारों और अक्षरों का उपयोग करते हैं और कार्यान्वयन से बाहर हैं। उनका उल्लेख करने से यह पेज उनके लिए कन्वर्टर नहीं बन जाता। उनके घनत्व या इतिहास की तुलना करने के लिए इस मॉड्यूल के लिए समीक्षा की गई Base64 फ़ाइलों से परे स्रोतों और परीक्षण वैक्टर की आवश्यकता होगी।
टेकअवे: प्रत्येक वर्ण को एक कारण से चुना गया था - Base64 एनकोडर और डिकोडर मानक वर्णमाला को कैसे लागू करते हैं जिसके परिणामस्वरूप
लाइन रैपिंग ईमेल से आई है। प्रत्येक निर्णय वास्तविक प्रणालियों के साथ वास्तविक समस्या को हल करने के लिए किया गया था। आज, Base64 का उपयोग ज्यादातर संदर्भों (JWT, API, डेटा URIs) में किया जाता है, जहां इतिहास कोई मायने नहीं रखता, लेकिन वर्णमाला और पैडिंग नियम MIME और PEM से RFC 4648 तक विरासत में मिले हैं।
RFC को एक बार पढ़ना और Base64 एनकोडर और डिकोडर टूल में एक परीक्षण स्ट्रिंग को एन्कोड करना वर्तमान मानक को उसकी ऐतिहासिक जड़ों से जोड़ता है। जब भी इनपुट सूचकांक बासठ या तिरसठ तक पहुंचता है तो परिणामी मानक वर्णमाला दिखाई देती है। एक नमूने का उपयोग करें जो उन स्थितियों को उत्पन्न करता है, URL-सुरक्षित मोड को टॉगल करें, और केवल बदले हुए विराम चिह्नों की तुलना करें। वह प्रयोग अपने आविष्कार के बारे में किसी असमर्थित कहानी पर भरोसा किए बिना आज के प्रारूप को प्रदर्शित करता है।