Base64 एन्कोड / डिकोड
अपने ब्राउज़र में टेक्स्ट को Base64 में बदलें और वापस डिकोड करें। UTF-8 सुरक्षित, वैकल्पिक URL-safe वैरिएंट के साथ — कोई भी डेटा कभी सर्वर पर अपलोड नहीं होता।
इनपुट
0 पंक्तियाँ · 0 अक्षर
मोड
URL-safe
Base64 एन्कोड / डिकोड का उपयोग कैसे करें
- 1
Encode या Decode चुनें
टेक्स्ट को Base64 में बदलने के लिए Mode को Encode पर सेट करें, या किसी Base64 स्ट्रिंग को वापस पढ़ने योग्य टेक्स्ट में बदलने के लिए Decode चुनें।
- 2
अपना इनपुट दर्ज करें
अपना टेक्स्ट या Base64 इनपुट पैनल में टाइप करें या पेस्ट करें, और चाहें तो URL- व फ़ाइलनाम-अनुकूल वर्णमाला के लिए URL-safe चालू करें।
- 3
कन्वर्ट करें
इनपुट को आपके ब्राउज़र में ही पूरे UTF-8 और इमोजी सपोर्ट के साथ प्रोसेस करने के लिए Convert पर क्लिक करें।
- 4
कॉपी करें या स्वैप करें
नतीजा कॉपी करें, या जल्दी राउंड ट्रिप के लिए Swap का इस्तेमाल करके आउटपुट को वापस इनपुट में ले जाएँ और मोड पलट दें।
Base64 एन्कोडिंग की संपूर्ण मार्गदर्शिका
Base64 असल में है क्या
Base64 एक बाइनरी-से-टेक्स्ट एन्कोडिंग योजना है: यह किसी भी मनमाने बाइनरी डेटा को केवल 64 प्रिंट करने योग्य ASCII वर्णों से दर्शाता है, जो सादा-पाठ के लिए बने तंत्रों से होकर गुज़रने में सुरक्षित रहते हैं। RFC 4648 में परिभाषित मानक वर्णमाला में 26 बड़े अक्षर A-Z, 26 छोटे अक्षर a-z, दस अंक 0-9, और दो चिह्न + तथा / होते हैं। यह कुल 64 चिह्न हैं, जो हर वर्ण में डेटा के छह बिट दर्शाने के लिए ठीक उतने ही पर्याप्त हैं, क्योंकि दो की छठी घात 64 होती है।
इसका नाम शब्दशः है। जैसे base 10 दस अंक-चिह्नों का और base 16 (hex) सोलह का उपयोग करता है, वैसे ही base 64 चौंसठ का उपयोग करता है। यह एन्कोडिंग पूरी तरह उत्क्रमणीय और बिना हानि वाली है: जो भी बाइट आप एन्कोड करते हैं, डिकोड करने पर वे ठीक बाइट-दर-बाइट वैसे ही वापस आते हैं, और यही इसका पूरा उद्देश्य है।
Base64 क्यों मौजूद है
कई चैनल टेक्स्ट ले जाने के लिए बनाए गए थे, कच्चे बाइट के लिए नहीं, और वे प्रिंट करने योग्य ASCII सीमा से बाहर की हर चीज़ को बिगाड़ देते हैं। ईमेल इसका क्लासिक उदाहरण है: मूल SMTP मानक एक सात-बिट प्रोटोकॉल था जो बाइनरी डेटा के सबसे ऊँचे बिट को भ्रष्ट या हटा सकता था, इसलिए MIME छवि और फ़ाइल अनुलग्नकों को सुरक्षित भेजने के लिए Base64 का उपयोग करता है। यही समस्या हर बार सामने आती है जब बाइनरी को किसी पाठ-आधारित चीज़ के भीतर सवार होकर जाना होता है।
आप बिना ध्यान दिए लगातार Base64 से सामना करते हैं। Data URI छवियों को सीधे HTML और CSS में data:image/png;base64,iVBORw0K... के रूप में अंतर्निहित कर देते हैं, ताकि किसी छोटे आइकन के लिए अलग अनुरोध की ज़रूरत न पड़े। JSON Web Token (JWT) बिंदुओं से जुड़े तीन Base64url खंड होते हैं। HTTP Basic प्रमाणीकरण username:password का Base64 भेजता है। ब्राउज़र इसे अंतर्निर्मित btoa और atob फलनों के ज़रिए उपलब्ध कराते हैं, और बाइनरी पेलोड को JSON, XML या किसी URL में भरने का यह मानक तरीका है।
3-बाइट से 4-वर्ण की मैपिंग कैसे काम करती है
Base64 इनपुट को एक बार में तीन बाइट के हिसाब से संसाधित करता है। तीन बाइट यानी 24 बिट, और 24 ठीक-ठीक छह-छह बिट के चार समूहों में बँट जाता है। हर छह-बिट समूह 0 से 63 तक की एक संख्या होता है, जो वर्णमाला से एक वर्ण बन जाता है। इसलिए इनपुट के हर 3 बाइट से हमेशा ठीक 4 आउटपुट वर्ण बनते हैं, और यही वजह है कि Base64 डेटा को लगभग एक तिहाई फुला देता है: एन्कोड किया रूप मूल का लगभग 133% आकार का होता है।
वर्णमाला में स्थिति ही मायने रखती है। इंडेक्स 0 है A, इंडेक्स 25 है Z, इंडेक्स 26 है a, इंडेक्स 51 है z, इंडेक्स 52 है 0, इंडेक्स 61 है 9, इंडेक्स 62 है +, और इंडेक्स 63 है /। किसी एन्कोड की हुई स्ट्रिंग को हाथ से पढ़ने के लिए, आप हर वर्ण को वापस उसके इंडेक्स पर मैप करते हैं, उस इंडेक्स को छह बिट के रूप में लिखते हैं, सभी बिटों को जोड़ते हैं, और उस धारा को वापस आठ-बिट बाइटों में काट लेते हैं।
एक हल किया हुआ उदाहरण: "Man" को एन्कोड करना
तीन अक्षर M, a, n लीजिए। इनके ASCII बाइट मान 77, 97 और 110 हैं, जो बाइनरी में 01001101, 01100001 और 01101110 हैं। इन 24 बिटों को एक धारा में जोड़िए: 010011010110000101101110। अब इसे छह-छह बिट के चार समूहों में काटिए: 010011, 010110, 000101, 101110।
ये समूह संख्याएँ 19, 22, 5 और 46 हैं। वर्णमाला में हर एक को देखने पर मिलता है T (इंडेक्स 19), W (इंडेक्स 22), F (इंडेक्स 5), और u (इंडेक्स 46)। इसलिए "Man" एन्कोड होकर "TWFu" बन जाता है — बिना किसी पैडिंग की ज़रूरत के एक साफ़-सुथरा तीन-बाइट-से-चार-वर्ण रूपांतरण। डिकोडिंग बस इन्हीं चरणों को उल्टे क्रम में चलाती है।
पैडिंग और बराबर का चिह्न
इनपुट हमेशा तीन बाइट का गुणक नहीं होता, इसलिए Base64 को शेष बचे को दर्शाने का कोई तरीका चाहिए। जब एक बाइट बच जाता है, तो वह दो वर्णों के बाद दो पैडिंग चिह्नों (==) में एन्कोड होता है; जब दो बाइट बचते हैं, तो वे तीन वर्णों के बाद एक पैडिंग चिह्न (=) में एन्कोड होते हैं। पैडिंग वर्ण कोई डेटा नहीं रखता; यह केवल डिकोडर को बताता है कि अंतिम समूह कितने असली बाइट दर्शाता है।
उदाहरण के लिए, अकेला अक्षर "M" (बाइट 77, बाइनरी 01001101) छह बिट के रूप में 010011 और 010000 के तौर पर पैड होता है, जिससे T और Q बनते हैं, और फिर == के साथ पूरा होकर "TQ==" बनता है। शब्द "Ma" (दो बाइट) एक अकेले पीछे लगे बराबर के चिह्न के साथ "TWE=" में एन्कोड होता है। किसी भी Base64 स्ट्रिंग के अंत में बराबर के चिह्न गिनने पर पता चल जाता है कि मूल लंबाई तीन का गुणक थी या नहीं।
URL-सुरक्षित संस्करण
मानक + और / वर्ण उन जगहों पर समस्या पैदा करते हैं जहाँ इनका पहले से कोई अर्थ होता है। एक स्लैश URL में पथ खंडों को बाँटता है, और एक प्लस चिह्न को फ़ॉर्म-एन्कोडेड क्वेरी स्ट्रिंग में स्पेस के रूप में पढ़ा जाता है, इसलिए किसी सामान्य Base64 मान को किसी लिंक या फ़ाइल नाम में डालने पर वह टूट सकता है। URL-सुरक्षित वर्णमाला, जो RFC 4648 से ही आती है, इसे + के बदले - (हाइफ़न) और / के बदले _ (अंडरस्कोर) रखकर ठीक कर देती है।
इस टूल में URL-सुरक्षित विकल्प चालू करने पर वह संस्करण बनता है और साथ ही पीछे लगी = पैडिंग भी हट जाती है, क्योंकि बराबर के चिह्नों को भी URL में एस्केप करना पड़ता है। परिणाम सीधे क्वेरी पैरामीटर, पथ खंडों, कुकीज़ और फ़ाइल नामों में फिट हो जाता है। यही एन्कोडिंग JWT और कई वेब API इस्तेमाल करते हैं। बस याद रखिए कि URL-सुरक्षित इनपुट को किसी URL-सुरक्षित डिकोडर से ही डिकोड करें, क्योंकि - और _ वर्ण मानक वर्णमाला में मान्य नहीं हैं।
Base64 एन्कोडिंग है, एन्क्रिप्शन नहीं
यह Base64 के बारे में सबसे महत्वपूर्ण और सबसे ग़लत समझा जाने वाला तथ्य है। एन्कोडिंग डेटा को केवल नंगी आँखों से छिपाती है; यह शून्य गोपनीयता देती है। यहाँ न कोई कुंजी है और न कोई रहस्य, इसलिए कोई भी किसी Base64 स्ट्रिंग को किसी भी टूल से — इस वाले समेत — पलक झपकते डिकोड कर सकता है। Base64 को पासवर्ड, API कुंजियाँ या व्यक्तिगत डेटा छिपाने का तरीका मानना एक गंभीर सुरक्षा भूल है।
Base64 एक परिवहन समस्या हल करता है, गोपनीयता समस्या नहीं: यह बाइनरी को केवल-पाठ वाले चैनलों से होकर गुज़रने में सुरक्षित बनाता है। अगर आपको असल सुरक्षा चाहिए, तो डेटा को पहले AES जैसे किसी असली एल्गोरिदम से एन्क्रिप्ट कीजिए, और तभी सिफरटेक्स्ट को Base64-एन्कोड कीजिए यदि आपको उसे पाठ के रूप में भी भेजना हो। एन्कोडिंग और एन्क्रिप्शन अलग-अलग काम हैं।
आम ग़लतियाँ और व्यावहारिक सुझाव
सबसे बार-बार होने वाली ग़लती कैरेक्टर-सेट की उलझन है। Base64 खुद केवल बाइट जानता है, इसलिए पाठ को एन्कोड करने से पहले आपको तय करना होगा कि वह पाठ बाइट कैसे बनता है। यह टूल UTF-8 का उपयोग करता है, यही वजह है कि लहजे वाले अक्षर और इमोजी सही-सलामत राउंड-ट्रिप करते हैं; उसी स्ट्रिंग को कहीं और किसी दूसरे कैरेक्टर-सेट के रूप में एन्कोड करने पर अलग Base64 मिलता है। दूसरा आम जाल व्हाइटस्पेस है: कुछ एन्कोडर द्वारा डाली गई लाइन ब्रेक (MIME 76 वर्णों पर लपेटता है) डेटा का हिस्सा नहीं होतीं और डिकोड करने से पहले हटा देनी चाहिए, हालाँकि सख्त डिकोडर उन्हें अस्वीकार भी कर सकते हैं।
अन्य फँसाने वाली बातों में शामिल हैं मानक और URL-सुरक्षित वर्णमालाओं को आपस में मिला देना, यह भूल जाना कि किसी बिना-पैडिंग वाली स्ट्रिंग को किसी सख्त डिकोडर द्वारा स्वीकार किए जाने से पहले उसकी पैडिंग बहाल करनी पड़ सकती है, और यह मान बैठना कि Base64 जगह बचाता है — यह कभी नहीं बचाता, यह हमेशा पेलोड को लगभग एक तिहाई बढ़ा देता है। जब यहाँ कोई डिकोड विफल हो, तो पहले किसी भटके हुए स्पेस, किसी छूटे हुए बराबर के चिह्न, या किसी - या _ की जाँच कीजिए जो URL-सुरक्षित वर्णमाला का हो।
अक्सर पूछे जाने वाले प्रश्न
यहाँ Encode और Decode में क्या अंतर है?
URL-safe विकल्प क्या करता है?
क्या यह इमोजी और गैर-अंग्रेज़ी अक्षरों को संभालता है?
डिकोड करते समय अगर मैं अमान्य Base64 पेस्ट कर दूँ तो क्या होगा?
क्या मेरा डेटा कहीं भेजा जाता है?
संबंधित टूल्स
इन उपयोगी टूल्स के साथ आगे बढ़ें