Base64 फ़ॉर्मेट से डिकोड करें

अवलोकन

Base64 एक उलटने योग्य रूप-बदलाव है, और यह टूल इस सफ़र का उल्टा हिस्सा है: यह वह छाप योग्य टेक्स्ट लेता है जो किसी एन्कोडर ने बनाया, और उसे वापस मूल डेटा में बदल देता है। कोई स्ट्रिंग पेस्ट करें, वही सेटिंग्स चुनें जो उसके स्रोत से मेल खाती हों, और डिकोडेड परिणाम पढ़ने या कॉपी करने के लिए तैयार है। जब पेयलॉड इमेज या अर्काइव जैसा बाइनरी हो, तो उसका Base64 टेक्स्ट एक साधारण फ़ाइल में रहता है: इस पेज की फ़ाइल फ़ॉर्म वह फ़ाइल लेती है और मूल बाइनरी को एक डाउनलोड के रूप में वापस सौंपती है। मिलता-जुलता एन्कोडर सिस्टर साइट पर रहता है, एक लिंक दूर।

उन्नत विकल्प

• अक्षर समूह: Base64 बाइट्स हिलाता है, अक्षर नहीं, इसलिए डिकोडेड परिणाम तभी सही पढ़ा जाता है जब आपको पता हो कि एन्कोडिंग से पहले उसे किस अक्षर समूह में सहेजा गया था। वही चुनें जो आपके स्रोत से मेल खाए: आधुनिक टेक्स्ट के लिए UTF-8, पुराने दस्तावेज़ों के लिए Windows-1252 या ISO-8859 वैरिएंट, या AUTO-DETECT, जिससे टूल खुद तय करे (वह जो तय करता है, सूची के ठीक बगल में दिखा देता है, और जब समझ न आए तो UTF-8 मान लेता है)। अगर आउटपुट उलझी-बुलझी अक्षरमाला जैसा दिखे, तो यही पहला पहिया है जो घुमाना है। फ़ाइलें इससे बाहर हैं: बाइनरी डेटा जैसे का वैसा ही डिकोड होता है, कोई कन्वर्ज़न नहीं।
• हर लाइन को अलग-अलग डिकोड करें: डिफ़ॉल्ट में पूरा इनपुट एक लगातार पेयलॉड है: डिकोडिंग से पहले लाइन ब्रेक और स्पेस हटा दिए जाते हैं, इसलिए कोई भी स्ट्रिंग जो लाइनों में बाँधी हुई हो, ईमेल से सीधे कॉपी की गई हो, बस काम कर जाती है, और URL-सेफ़ अक्षर - और _ को + और / की जगह मान लिया जाता है। जब इनपुट स्वतंत्र एंट्री की सूची हो, तो यह बॉक्स टिक करें: तब हर लाइन का डिकोड अलग-अलग होता है, और परिणाम वापस एक-एक लाइन में आते हैं। फ़ाइल फ़ॉर्म में भी वही ऑप्शन मौजूद है।
• लाइव मोड: इसे चालू कीजिए और डिकोडिंग आपके ब्राउज़र में ही होती है, जैसे-जैसे आप टाइप करते हैं, हर की दबते ही दोबारा चलती है, और हमारे सर्वर पर कुछ भेजा नहीं जाता। यह लाइन-वार ऑप्शन का ख़याल रखता है और सिर्फ़ UTF-8 के साथ काम करता है, इसलिए चालू रहने तक अक्षर समूह की सूची लॉक रहती है, और डिकोड बटन तब तक डिसेबल रहता है जब तक आप वापस न बदलें।

सुरक्षित और भरोसेमंद

सब कुछ एन्क्रिप्टेड HTTPS कनेक्शन पर चलता है, और आपका जो भी सबमिट होता है, वह सहेजा नहीं जाता: अपलोड की गई फ़ाइलें प्रोसेस होते ही हटा दी जाती हैं, और डाउनलोड किया जा सकने वाला परिणाम आपके पहले डाउनलोड की कोशिश या 15 मिनट की निष्क्रियता के ठीक बाद गायब हो जाता है, जो भी पहले आए। आपके भेजे हुए डेटा की जानकारी कभी सहेजी नहीं जाती; कन्वर्ज़न के अलावा एकमात्र प्रोसेसिंग अपलोड की गई फ़ाइलों का सुरक्षा स्कैन है, जो दुर्भावनापूर्ण या अनुचित कंटेंट को रोकने के लिए मौजूद है। लाइव मोड चालू रहने पर आपका टेक्स्ट ब्राउज़र से बाहर कभी नहीं जाता। पूरी जानकारी हमारी निजता नीति में है, जो नीचे फुटर में लिंक है।

बिल्कुल मुफ़्त

इस पेज पर सब कुछ इस्तेमाल करने के लिए मुफ़्त है - पूरी अक्षर समूह सूची, फ़ाइल अपलोड, और लाइव मोड भी। कोई खाता नहीं, कोई इंस्टॉल करने वाला सॉफ़्टवेयर नहीं, कोई शुल्क-दीवार नहीं: इतने छोटे काम के लिए, यही तो होना चाहिए।

Base64 की व्याख्या

कुछ डेटा बस एक केवल-टेक्स्ट मार्ग से नहीं चल सकता: फ़ोटो, अर्काइव, हैश, बाइनरी का कोई टुकड़ा, जो 7-बिट ईमेल कनेक्शन को दम घूटने पर मजबूर कर दे। ऐसे पलों के लिए Base64 अनुवादक है। यह किसी भी बाइट क्रम को साफ़, छाप योग्य टेक्स्ट में दोबारा लिख देता है, ताकि डेटा ईमेल बॉडी, JSON दस्तावेज़, XML फ़ाइल या URL में बैठ सके और बिल्कुल वैसा ही पहुँचे जैसा निकला था। यह अनुवाद पूरी तरह उलटने योग्य है: हर बाइट वापस आता है, उसी क्रम में, बिना रास्ते में कुछ खोए।

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

64 क्यों, और वही अक्षर क्यों

एक बाइट में 8 बिट आते हैं, मगर पुराने टेक्स्ट मार्ग, और सबसे ज़्यादा ईमेल, सिर्फ़ 7-बिट ASCII को ही सुरक्षित ले जा पाते थे। तरकीब यह है कि छाप योग्य अक्षरों की ऐसी अक्षरमाला चुनें जो ऐसे हर सफ़र से बच निकले, और उसका आकार ऐसा रखें कि गणित बिल्कुल साफ़ उतर आए। 64 अक्षरों पर, हर एन्कोडेड अक्षर ठीक 6 बिट ले जाता है, और 24, 8 (बाइट) और 6 (अक्षर) - दोनों से बखूबी बँट जाता है: तीन इनपुट बाइट चार आउटपुट अक्षर बन जाते हैं, बिना एक भी बाकी रहने के। नाम तो सिर्फ़ उस अक्षर-गणित का आधार है, जैसे हमारे अंकों के लिए base 10।

मानक अक्षरमाला है 62 अल्फ़ान्यूमरिक अक्षर: A से Z तक, a से z तक, और 0 से 9 तक, और आखिरी दो जगह + और /। स्पेसिफिकेशन 65वाँ अक्षर, =, जोड़ता है, जो अक्षरमाला में बिल्कुल नहीं है: वह सिर्फ़ अंत में ही दिखता है, पैडिंग की तरह। यह चयन जानबूझकर किया गया था। पूरा सेट छाप योग्य है, वह हर टेक्स्ट सिस्टम में सामान्य है, और MIME स्पेसिफिकेशन नोट करता है कि यह ISO 646 के हर वर्ज़न में, US-ASCII समेत, और EBCDIC के हर वर्ज़न में बिल्कुल एक ही तरह से लिखा जाता है। यही आखिरी ख़ासियत डेटा को सलामत रखती है जब वह इंटरनेट के पुराने 8-बिट-अधुना मशीनरी से गुज़रता है।

एन्कोडिंग, चरण-दर-चरण

एन्कोडर एक चार-चरणों वाली एसेंबली लाइन है। यह इनपुट को तीन-तीन बाइट पढ़ता है और हर तीन का समूह एक ही 24-बिट क्रम में मिला देता है। वह क्रम चार 6-बिट के टुकड़ों में काट दिया जाता है। हर टुकड़ा 0 से 63 तक की एक संख्या है, और हर संख्या ऊपर दी गई तालिका में खोजी जाती है। चार संख्याएँ अंदर, चार अक्षर बाहर।

इसे शब्द foo पर घटते देखें, जो बाइट मान 102, 111 और 111 के रूप में पहुँचता है (हेक्स 66, 6F, 6F)। लगातार रखने पर, 24 बिट हैं 01100110 01101111 01101111। छह-छह में काटने पर, ये हैं 011001, 100110, 111101 और 101111, यानी 25, 38, 61 और 47। तालिका कहती है कि ये हैं Z, m, 9 और v, तो foo का एन्कोड Zm9v है, और दुनिया का कोई भी Base64 डिकोडर इसे वापस मूल तीन बाइट में बदल देगा।

इनपुट का बाकी हिस्सा भी वैसे ही प्रोसेस होता है, त्रिक-दर-त्रिक, तब तक कि कुछ बचा नहीं रहे। सिर्फ़ आखिरी समूह, जब उसमें तीन से कम बाइट हों, को एक ख़ास कदम की ज़रूरत होती है।

पैडिंग: अंत का =

इनपुट हमेशा पूरे बाइट्स की संख्या होता है, मगर तीन हमेशा इसे बराबर-बराबर नहीं बाँट पाता। जब पूँछ में एक या दो बाइट बाकी रह जाएँ, तो एन्कोडर को फिर भी चार अक्षरों का पूरा समूह पूरा करना पड़ता है। वह ग़ायब बिट्स को जीरो से भर देता है, तालिका खोज उसी तरह करता है, और पैडिंग बिट्स से बनने वाले अक्षरों की जगह = चिह्न रख देता है। ठीक तीन अंत संभव हैं:

तो fo, दो बाइट, बन जाता है Zm8=, और अकेला-थकेला f बन जाता है Zg==, जबकि foo को तो पैडिंग की बिल्कुल ज़रूरत नहीं। डिकोडर को ठीक-ठीक पता है कि पैड्स के साथ क्या करना है: हर = का मतलब है आठ और जीरो-बिट, जो फेंक देने हैं। पैड्स सिर्फ़ बिल्कुल अंत में बैठते हैं, और ज़्यादा से ज़्यादा दो। MIME स्पेक इसी को एक ख़ासियत की तरह इस्तेमाल भी करता है: चूँकि = कहीं और नहीं दिख सकता, एक पैडेड पेयलॉड अपने अंत की घोषणा ख़ुद कर देता है, ताकि रिसीवर जान सके कि डेटा रास्ते में अधूरा नहीं कटा गया। और सबसे छोटे मामले के लिए: ख़ाली इनपुट का एन्कोड ख़ाली आउटपुट होता है। भले ही ख़ालीपन को भी एक पक्की राउंड-ट्रिप मिलती है।

डिकोडिंग: उल्टी चली एसेंबली लाइन

डिकोडिंग वही मशीन है उल्टी दिशा में चलती हुई, और उतनी ही मेकैनिकल। चार अक्षर लीजिए, असली अक्षर तालिका में खोजिए (पैड की जगह छह जीरो मानिए), 24 बिट लिखिए, और अगर एक पैड हो तो पहले 16 बिट वापस दीजिए, वरना सब 24। चार अक्षर अंदर, तीन बाइट बाहर; एक पैड पर दो बाइट बाहर; दो पैड पर एक बाइट बाहर। एन्कोडर के जोड़े हुए जीरो-बिट ही एकमात्र चीज़ हैं जो फेंकी जाती हैं, और हर दूसरा बिट बिल्कुल वही है जो डाला गया था। यही तो यहाँ उलटने योग्य का असली मतलब है: फ़ॉर्मेट स्वयं लॉसलेस है, और डेटा को घात पहुँचा सकते हैं सिर्फ़ दो - स्ट्रिंग खराब करने वाला मार्ग, या चुपचाप हार मान लेने वाला डिकोडर।

इसीलिए स्टैंडर्ड एक चीज़ पर सख़्त है: अक्षरमाला से बाहर के अक्षर। RFC 4648 कहता है कि कोई भी पेयलॉड जिसमें 64 की अक्षरमाला से बाहर का कोई अक्षर हो, उसे डिकोडर को ज़रूर अस्वीकार करना चाहिए, जब तक कि आस-पास का स्पेसिफिकेशन उसे खुलकर न मान ले। कारण व्यावहारिक है, पिटलू-पिटली का नहीं। एक ऐसा डिकोडर, जो बेगाने अक्षर चुपचाप गटक ले, उसका घुटमा हो सकता है: चुपके से भेजे गए अक्षर एक छुपे हुए साइड-चैनल बन जाते हैं, और इसी तड़के से डेटा को फ़िल्टरों से छुपाया जा चुका है और डिकोडर के बग को चुसकाया गया है। मशहूर अपवाद खुद MIME है, जो इस स्टैंडर्ड से पहले से है और बिल्कुल उल्टा कहता है: अक्षरमाला से बाहर का हर अक्षर नज़रअंदाज़ कर दो, और यही तरीका है जिससे लाइन ब्रेक एक ईमेल अटैचमेंट के अंदर से बच निकलते हैं। जब आप ख़ुद इनपुट की जाँच करते हैं, तो आधुनिक नियम ही सही है: अगर आपकी स्ट्रिंग में @, कोई स्पेस, या तालिका में न होने वाला कुछ और है, तो यह साफ़ Base64 नहीं है।

लाइन ब्रेक और 76-अक्षर नियम

आप अक्सर Base64 को लाइनों में बाँधे हुए मिलेंगे, और यह आदत आई है ईमेल की वजह से। पुरानी SMTP मशीनरी में लाइन की लंबाई की सीमा थी, इसलिए MIME पेयलॉड को हर लाइन में 76 अक्षरों पर, CRLF ब्रेक के साथ, बाँध देता है, और पुराना PEM फ़ॉर्मेट, जो सर्टिफिकेट और की ले जाता है, 64 पर बाँधता है। RFC 4648 का नए कोड के लिए नियम बिल्कुल उल्टा है: कोई लाइन ब्रेक मत डालें, जब तक कि आप जो फ़ॉर्मेट बना रहे हैं वह न कहता हो। असल में, डिकोडर को इसका ख़याल नहीं। लाइन ब्रेक तो सिर्फ़ अक्षरमाला से बाहर का एक अक्षर है, इसलिए MIME-बाँधे पेयलॉड, PEM ब्लॉक, और एक लंबी बिना-टूटी स्ट्रिंग - तीनों का डिकोड वही बाइट्स देता है। जहाँ से भी आप Base64 पेस्ट करें, पहले लाइन ब्रेक हटा लीजिए और ख़त्म।

बाँधने की एक छोटी कीमत है, और वह साइज़ के हिसाब में दिखती है। बिना लाइन ब्रेक, Base64 मूल का ठीक चार-तिहाई होता है, लगभग 33 प्रतिशत बड़ा। 76 अक्षरों पर CRLF ब्रेक के साथ बाँधने पर, यह लगभग 37 प्रतिशत बड़ा होता है, इसीलिए एक फ़ाइल जो 100 KB की थी, अक्सर लगभग 137 KB टेक्स्ट के रूप में पहुँचती है। गणित हमेशा मेल खाता है।

Base64URL: URL-सेफ़ जुड़वाँ

मानक अक्षरमाला में दो ऐसे अक्षर हैं जो URL के साथ अच्छे नहीं बैठते। क्वेरी स्ट्रिंग में + को पारंपरिक रूप से एक स्पेस माना जाता है, और / एक पथ सपैरेटर है, इसलिए URL में एक असली Base64 स्ट्रिंग को दोनों के लिए पर्सेंट-एस्केपिंग की ज़रूरत होती है, और साथ में = पैड की भी। RFC 4648 का अनुभाग 5 सुधार तय करता है: URL और फ़ाइल-नाम सेफ़ अक्षरमाला, जहाँ + बन जाता है - और / बन जाता है _। पैड आमतौर पर भी गायब हो जाते हैं, क्योंकि ग़ायब पैड की कमी लंबाई से निपटाई जा सकती है। RFC साफ़ कहता है कि इसे सादा Base64 कहना नहीं चाहिए: यह एक अलग एन्कोडिंग है, आमतौर पर base64url लिखा जाता है।

असल में, दोनों के बीच एक ही बदलाव का फ़ासला है, और ख़तरनाक दिशा में। base64url स्ट्रिंग को मानक डिकोडर में डाली तो गड़बड़ हो जाती है, क्योंकि - और _ मानक अक्षरमाला में नहीं हैं: ढीला डिकोडर इन्हें फेंक देता है और वापस एक छोटी, ग़लत बाइट स्ट्रिंग देता है; अगर बचा हुआ हिस्सा अकेला खड़ा न रह सके, तो एरर। जबकि सख़्त डिकोडर पूरा पेयलॉड अस्वीकार कर देता है। सही नृत्य यह है: पहले - को वापस + में बदलें और _ को वापस / में, ग़ायब पैड भरें, और तभी डिकोड करें। यही वह वैरिएंट है जो आप JSON Web Tokens (JWT), OAuth स्टेट स्ट्रिंग्स, और एक बहुत बड़ी वीडियो साइट के ID में देखते हैं।

एक त्वरित फ़ील्ड गाइड

टूल खोजने से पहले, आप ख़ुद स्ट्रिंग की खूब जाँच-पड़ताल कर सकते हैं। कुछ जाँचें यह बता देती हैं कि पेयलॉड Base64 भी है या नहीं, और वह क्या छुपा रहा है:

• अक्षर देखिए। मानक Base64 सिर्फ़ A से Z तक, a से z तक, 0 से 9 तक, + और / इस्तेमाल करता है; URL-सेफ़ जुड़वाँ उन दोनों की जगह - और _ रखता है। कोई और चिह्न, या एक अनावश्यक स्पेस, इसका मतलब है कि यह साफ़ Base64 नहीं है।
• पैड की जाँच कीजिए। = चिह्न, अगर हों, तो बस बिल्कुल अंत में बैठते हैं, और ज़्यादा से ज़्यादा दो। स्ट्रिंग के बीच में पैड हो तो यह लाल झंडा है।
• लंबाई गिनें। पैड होने पर, लंबाई हमेशा 4 का गुणज होती है। पैड के बिना, लंबाई को 4 से बाँटने पर शेष 0, 2 या 3 रहता है। शेष 1 असम्भव है, क्योंकि एक अक्षर सिर्फ़ 6 बिट ले जाता है और एक बाइट को 8 चाहिए।
• साइज़ का अनुमान लगाएँ। 4 अक्षरों का हर समूह 3 बाइट रखता है, हर = चिह्न पर एक बाइट घटकर। तो Zm9vYmFy, बिना पैड के आठ अक्षर, 6 बाइट है, और Zm9vYg==, दो पैड के आठ अक्षर, 4।

एक आखिरी फ़ील्ड तड़का, और सबसे कारगर। एन्कोडर को पैडिंग बिट्स को जीरो करना पड़ता है, मगर ढीला डिकोडर इन्हें जाँचता नहीं। पेयलॉड Zg== का डिकोड एक ही बाइट f होता है, Zh== का भी: आखिरी अक्षर के निचले बिट दोनों मामलों में पैडिंग हैं, इसलिए दोनों एक ही बाइट बोलते हैं। स्टैंडर्ड जीरो-बिट वाले संस्करण को कैनोनिकल फ़ॉर्म कहता है, और इसीसे सख़्त डिकोडर दूसरी को अस्वीकार कर पाते हैं। दो स्ट्रिंग, एक पेयलॉड। अगर दो सिस्टम किसी Base64 मान पर मतभेद में हों, तो पैड बिट्स खोज शुरू करने की अच्छी जगह है।

Base64 क्या नहीं है

• एन्क्रिप्शन नहीं। न कोई की है, न कोई सीक्रेट; कोई भी एक सेकंड में Base64 स्ट्रिंग को वापस बाइट्स में बदल सकता है। RFC तक असली घटनाओं का ज़िक्र करता है: लोग ऐसी प्रोटोकॉल-वार्ता का हवाला देते रहे जिनमें एक "एन्कोडेड" पासवर्ड शामिल था, और वे यकीन कर रहे थे कि एन्कोडिंग उसे छुपा रही है। अगर डेटा संवेदनशील है, तो उसे एन्कोड करने से पहले असली क्रिप्टोग्राफी से बचाएँ, बाद में नहीं।
• कॉम्प्रेशन नहीं। यह बिल्कुल उल्टा करता है: परिणाम इनपुट से लगभग 33 प्रतिशत बड़ा होता है, और लाइन ब्रेक जोड़ने पर और भी बड़ा। Base64 आपको टेक्स्ट-सुरक्षा बेचता है, और उसकी कीमत साइज़ में वसूल करता है।
• अक्षर समूह नहीं। Base64 बाइट्स हिलाता है, अक्षर नहीं। उसे न पता होता है न ख़याल कि वे बाइट्स UTF-8 टेक्स्ट हैं, कोई पुराना एक-बाइट एन्कोडिंग, या JPEG। "यह कौन-सा अक्षर समूह है?" का सवाल एन्कोडिंग से पहले और डिकोडिंग के बाद का है, कभी भीतर का नहीं।
• एक ही एन्कोडिंग नहीं। यह नाम एक पूरा ख़ानदान ढकता है: मानक अक्षरमाला, URL-सेफ़ जुड़वाँ, 76 या 64 अक्षरों पर बाँधे पेयलॉड, पैड छोड़ने वाले वैरिएंट, और कुछ-चंद अजीबोगरीब (IMAP, उदाहरण के लिए, अंतरराष्ट्रीय मेलबॉक्स नाम एन्कोड करते समय अक्षरमाला के / की जगह कॉमा इस्तेमाल करता है)। जब दो सिस्टम किसी पेयलॉड पर मतभेद में हों, तो अक्सर दोषी वैरिएंट के अंतर हैं।

बारीक लिखी बातें

प्राथमिक स्रोत छोटे और पढ़ने लायक हैं। RFC 4648, Base16, Base32, और Base64 डेटा एन्कोडिंग्स (2006), वर्तमान स्टैंडर्ड है: दोनों अक्षरमालाएँ, पैडिंग और लाइन-ब्रेक नियम, सख़्ती के नियम, और एक आधिकारिक टेस्ट वेक्टरों का सेट, जैसे foo का Zm9v बनना, जिससे इम्प्लीमेंटेशन ख़ुद को मापते हैं। इसके पीछे खड़ा है RFC 2045, 1996 की MIME स्पेसिफिकेशन, जहाँ से 76-अक्षर लाइन नियम और अनावश्यक अक्षरों को नज़रअंदाज़ करने का ढीलापन आया है, और RFC 1421, बहिष्कृत Privacy Enhanced Mail स्पेक, जिसने 64-अक्षर लाइनों से यह ख़ानदान शुरू किया। पहले एक एकीकरण प्रयास, RFC 3548, को RFC 4648 ने बदल दिया।

यह पूरी कहानी है: 64 अक्षर, तीन बाइट अंदर और चार अक्षर बाहर, पूँछ ख़त्म करने के लिए =, और एक पक्की राउंड-ट्रिप। हर टूल, लाइब्रेरी, और ऑनलाइन कन्वर्टर जो आप कभी मिलेंगे, इसका बस एक दरवाज़ा है। जब आप किसी Base64 स्ट्रिंग को देखकर उसके पीछे खड़े बाइट्स देख सकें, तो फ़ॉर्मेट के बारे में अब कुछ भी आपको हैरान नहीं करता। और जब आप ख़ुद डिकोडर लिखने के लिए तैयार हों, तो इस सेक्शन के ठीक नीचे दिए प्रोग्रामिंग-लैंग्वेज आर्टिकल आपको वही 64 अक्षर चलने वाले कोड के रूप में सौंपते हैं: हर लैंग्वेज के लिए एक पूरा गाइड।