Base64 एन्कोडर / डिकोडर

Base64 एन्कोडिंग क्या है?

Base64 एक बाइनरी-से-टेक्स्ट एन्कोडिंग है जो मनमाने डेटा को 64-वर्णों की वर्णमाला (A–Z, a–z, 0–9, + और /) से दर्शाती है। यह बाइनरी सामग्री को उन चैनलों से सुरक्षित रूप से गुज़रने देती है जो टेक्स्ट के लिए बने हैं, जैसे ईमेल, JSON, XML और data: URI।

इस टूल का उपयोग कैसे करें

1. अपना टेक्स्ट इनपुट बॉक्स में पेस्ट करें।
2. इसे बदलने के लिए Base64 में एन्कोड करें पर क्लिक करें, या उलटने के लिए Base64 से डिकोड करें पर।
3. परिणाम लेने के लिए आउटपुट कॉपी करें का उपयोग करें।

यह टूल UTF-8 के ज़रिए एन्कोड करता है, इसलिए Unicode टेक्स्ट और इमोजी सही ढंग से राउंड-ट्रिप होते हैं।

Base64 कहाँ से आया

Base64 का जन्म एक बहुत ख़ास समस्या से हुआ: शुरुआती इंटरनेट मेल को सादे 7-बिट ASCII टेक्स्ट के रूप में भेजता था। मूल Simple Mail Transfer Protocol (SMTP) मानता था कि हर बाइट सात बिट में समा जाती है, और कई मेल रिले आठवें बिट को हटा देते, कंट्रोल वर्णों को बिगाड़ देते, या लाइन-एंडिंग बदल देते। कच्चा बाइनरी — एक छवि, एक प्रोग्राम, एक संपीड़ित संग्रह — उस सफ़र में साबुत नहीं बच पाता। ज़रूरत थी मनमाने बाइट्स को साधारण अक्षरों और अंकों के रूप में छिपाने के एक प्रतिवर्ती (reversible) तरीक़े की।

यह एन्कोडिंग पहली बार Privacy-Enhanced Mail (PEM) में दिखी, जो फ़रवरी 1993 में RFC 1421 के रूप में प्रकाशित हुई, जहाँ इसने एन्क्रिप्टेड संदेश-निकायों को छापने-योग्य टेक्स्ट में लपेटा। यह कहीं बड़े दर्शकों तक MIME (Multipurpose Internet Mail Extensions) के ज़रिए पहुँची, जिसका पहला भाग, RFC 2045, नवंबर 1996 में प्रकाशित हुआ और जिसने Base64 को ईमेल अटैचमेंट के लिए एक मानक Content-Transfer-Encoding के रूप में परिभाषित किया। आधुनिक, समेकित विनिर्देश RFC 4648, "The Base16, Base32, and Base64 Data Encodings" (अक्टूबर 2006) है, जो पुराने RFC 3548 को अप्रचलित करता है और वही दस्तावेज़ है जिसका पालन आज अधिकांश सॉफ़्टवेयर करता है।

Base64 एन्कोडिंग असल में कैसे काम करती है

Base64 इनपुट को एक बार में तीन बाइट के हिसाब से संसाधित करता है। तीन बाइट यानी 24 बिट, और 24, छह-बिट के चार समूहों में समान रूप से बँट जाता है। हर 6-बिट समूह — एक sextet — 0 से 63 तक का मान रखता है, जो एक 64-वर्ण वर्णमाला को इंडेक्स करने के लिए बिलकुल पर्याप्त है। तो हर 3 इनपुट बाइट 4 आउटपुट वर्ण बन जाते हैं, और आउटपुट केवल सुरक्षित, छापने-योग्य प्रतीकों का उपयोग करता है।

64-वर्ण वर्णमाला, क्रम में, यह है:

• A–Z — मान 0–25 के लिए
• a–z — मान 26–51 के लिए
• 0–9 — मान 52–61 के लिए
• + — 62 के लिए और / — 63 के लिए

एक हल किया गया उदाहरण इसे ठोस बनाता है। तीन अक्षर Man बाइट्स 77 97 110 हैं, या बाइनरी में 01001101 01100001 01101110। sextets में फिर से समूहित करने पर यह बनता है 010011 010110 000101 101110 — मान 19 22 5 46 — जो T W F u पर मैप होते हैं। तो Man, TWFu में एन्कोड होता है। डिकोडिंग बस चरणों को उलट देती है: चार वर्ण वापस चार sextets में, 24 बिट में जोड़े गए, फिर वापस मूल तीन बाइट में काटे गए।

इनपुट शायद ही कभी तीन बाइट का ठीक गुणज होता है, इसलिए Base64 = वर्ण को पैडिंग के रूप में उपयोग करता है ताकि यह दर्ज हो सके कि अंतिम समूह में कितनी असली बाइट थीं:

• 3 बाइट का पूरा समूह → 4 वर्ण, कोई पैडिंग नहीं।
• 2 बचे हुए बाइट (16 बिट) → 3 वर्ण और एक =।
• 1 बचा हुआ बाइट (8 बिट) → 2 वर्ण और दो ==।

पैडिंग सजावटी नहीं है: यह डिकोडर को बताती है कि अंतिम sextet को भरने के लिए जोड़े गए अतिरिक्त शून्य बिट्स को हटा दे, ताकि मूल बाइट-गणना ठीक-ठीक बहाल हो जाए।

33% आकार-अतिरिक्तता, समझाई गई

चूँकि हर 3 बाइट 4 वर्णों में बदलते हैं, Base64 आउटपुट हमेशा लगभग इनपुट के आकार का चार-तिहाई (4/3) होता है — मोटे तौर पर एक 33% वृद्धि। ठीक आँकड़ा इनपुट की लंबाई पर, तीन से भाग देने पर उसके शेष पर (पैडिंग अंतिम समूह को चार वर्णों तक ऊपर कर देती है), और इस पर निर्भर करता है कि लाइन-ब्रेक डाले गए या नहीं। एक 9 KB फ़ाइल लगभग 12 KB टेक्स्ट बन जाती है; एक 3 MB छवि लगभग 4 MB बन जाती है।

यदि एन्कोडेड टेक्स्ट को लाइनों में लपेटा जाता है — ईमेल में आम — तो हर लाइन-ब्रेक एक या दो और वर्ण जोड़ता है, जो सामान्य MIME आउटपुट में अतिरिक्तता को लगभग एक और 4% बढ़ा देता है। यह केवल 64 छापने-योग्य मानों का उपयोग करके 256 संभव बाइट-मानों को दर्शाने की अपरिहार्य क़ीमत है: उतनी ही बात कहने के लिए आपको बस अधिक प्रतीक चाहिए। यही वजह है कि जब बैंडविड्थ या भंडारण की तंगी हो और चैनल पहले से बाइनरी सीधे ले जा सकता हो, तब Base64 एक ख़राब विकल्प है।

Base64 बनाम Base64URL बनाम Base32 बनाम hex

मानक Base64 + और / का उपयोग करता है, पर दोनों वर्ण कुछ संदर्भों में असुविधाजनक हैं: / एक पथ-विभाजक है और + अक्सर URL और फ़ॉर्म-डेटा में स्पेस का अर्थ रखता है। RFC 4648 §5 एक "URL और फ़ाइलनाम सुरक्षित" वेरिएंट परिभाषित करता है, जिसे आमतौर पर Base64URL कहते हैं, जो उन दो वर्णों को बदल देता है — - (माइनस) स्थिति 62 पर + की जगह लेता है, और _ (अंडरस्कोर) स्थिति 63 पर / की जगह। पैडिंग = को भी अक्सर छोड़ दिया जाता है, क्योंकि उसे भी एस्केप करने की ज़रूरत पड़ सकती है। Base64URL वही है जो आप JSON Web Tokens (JWT) के अंदर, URL क्वेरी पैरामीटर में, और फ़ाइलनामों में देखते हैं।

वही RFC दो सहोदर भी परिभाषित करता है जो एक छोटी, कभी-कभी सुरक्षित वर्णमाला के बदले घनत्व का त्याग करते हैं:

hex का उपयोग तब करें जब आप कुछ ऐसा चाहें जो मानव-पठनीय हो और बाइट्स के साथ आसानी से संरेखित हो (हर बाइट ठीक-ठीक दो hex अंक है)। Base32 का उपयोग तब करें जब टेक्स्ट को केस-असंवेदनशील सिस्टमों में बचना पड़े या ज़ोर से पढ़ा या हाथ से टाइप किया जाना हो। Base64 या Base64URL का उपयोग तब करें जब घनत्व सबसे ज़रूरी हो — वेब पर आम स्थिति।

लाइन-लंबाई की परंपराएँ: 76 और 64

पुराने टेक्स्ट चैनल बहुत लंबी लाइनें पसंद नहीं करते थे, इसलिए दो लाइन-लंबाई परंपराएँ मानक बन गईं। MIME (RFC 2045) Base64 को प्रति लाइन 76 वर्ण तक सीमित करता है, जबकि PEM (RFC 1421) ठीक प्रति लाइन 64 वर्ण का उपयोग करता है — वही रैपिंग जो आप TLS प्रमाणपत्रों और SSH कुंजियों में -----BEGIN----- और -----END----- चिह्नों के बीच छपी देखते हैं। छोटी लाइनें संदेशों को शुरुआती मेल सॉफ़्टवेयर और टर्मिनलों की सीमाओं के भीतर रखती थीं।

अहम बात यह है कि लाइन-रैपिंग आसपास के फ़ॉर्मैट का गुण है, स्वयं Base64 का नहीं। RFC 4648 स्पष्ट है कि कार्यान्वयन "MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs" उन्हें ऐसा करने के लिए। एक सादा Base64 स्ट्रिंग — जैसी यह टूल बनाता है — इसलिए एक अकेली अटूट लाइन है। जब आप किसी ईमेल या प्रमाणपत्र से कॉपी किए गए टेक्स्ट को डिकोड करते हैं, तो किसी भी अंतर्निहित न्यूलाइन और स्पेस को पहले हटाना ज़रूरी है; यह टूल यह अपने-आप कर देता है।

Base64 किसके लिए इस्तेमाल होता है

एक बार जब आप किन्हीं भी बाइट्स को सुरक्षित टेक्स्ट में बदल सकते हैं, तो उपयोग बढ़ जाते हैं। सबसे आम हैं:

• ईमेल अटैचमेंट (MIME)। किसी ईमेल से जुड़ी हर छवि, PDF या दस्तावेज़ रास्ते में Base64-एन्कोडेड होती है — वही मूल उद्देश्य जिसने इस फ़ॉर्मैट को सर्वव्यापी बनाया।
• data: URI। एक पूरी फ़ाइल इनलाइन data:[mediatype];base64,<data> के रूप में एम्बेड की जा सकती है, जिससे एक पेज बिना किसी अतिरिक्त HTTP अनुरोध के एक छोटा आइकन, फ़ॉन्ट या छवि साथ ले जा सकता है। समझौते हैं 33% आकार-जुर्माना और अलग कैशिंग का नुक़सान: एक एम्बेडेड एसेट को उस दस्तावेज़ से स्वतंत्र रूप से कैश या पुनः-उपयोग नहीं किया जा सकता जिसमें वह है, इसलिए यह छोटी, कम बदलने वाली फ़ाइलों के लिए सबसे अच्छा रखा जाता है।
• CSS और HTML में एसेट एम्बेड करना। वही data: तरक़ीब बैकग्राउंड छवियों, SVG और वेब फ़ॉन्ट को सीधे स्टाइलशीट के अंदर इनलाइन कर देती है।
• JSON और XML के अंदर बाइनरी। कोई भी फ़ॉर्मैट कच्ची बाइट नहीं रख सकता, इसलिए बाइनरी फ़ील्ड — फ़ाइल अपलोड, थंबनेल, क्रिप्टोग्राफ़िक कुंजियाँ — Base64 स्ट्रिंग के रूप में ले जाई जाती हैं।
• HTTP Basic प्रमाणीकरण। Authorization: Basic हेडर username:password का Base64 ले जाता है। उदाहरण के लिए Aladdin:open sesame बन जाता है QWxhZGRpbjpvcGVuIHNlc2FtZQ== (RFC 7617 में परिभाषित)।
• JSON Web Tokens। किसी JWT के हेडर, पेलोड और सिग्नेचर प्रत्येक Base64URL-एन्कोडेड होते हैं और डॉट्स से जुड़े होते हैं, जिससे एक संक्षिप्त, URL-सुरक्षित टोकन बनता है।

Base64 एन्क्रिप्शन नहीं है — एक आम भ्रांति

समझने की सबसे ज़रूरी बात यही है। Base64 कोई सुरक्षा नहीं देता। यह बिना कुंजी के एक सार्वजनिक, प्रतिवर्ती मैपिंग है — कोई भी किसी भी Base64 स्ट्रिंग को तुरंत डिकोड कर सकता है, ठीक वैसे ही जैसे यह पेज करता है। यह डेटा को छिपाता, गड़बड़ाता या सुरक्षित नहीं करता; यह केवल पहले से ज्ञात बाइट्स के प्रतिनिधित्व को बदलता है।

दो रोज़मर्रा के उदाहरण इस बात को साबित करते हैं। HTTP Basic प्रमाणीकरण आपका पासवर्ड Base64 के रूप में भेजता है, यही वजह है कि RFC 7617 ज़ोर देता है कि यह "does not provide confidentiality" और हमेशा HTTPS/TLS पर चलना चाहिए — Base64 को कनेक्शन देख रहे किसी भी व्यक्ति द्वारा आसानी से डिकोड किया जा सकता है। इसी तरह, किसी हस्ताक्षरित JWT के दावे Base64URL-एन्कोडेड होते हैं, एन्क्रिप्टेड नहीं: बीच वाले खंड को किसी भी डिकोडर में पेस्ट करें और आप हर फ़ील्ड पढ़ सकते हैं। एक JWT सिग्नेचर साबित करता है कि टोकन के साथ छेड़छाड़ नहीं हुई, पर यह सामग्री को गुप्त रखने के लिए कुछ नहीं करता।

और संपीड़न के विपरीत, Base64 डेटा को बड़ा बनाता है, छोटा नहीं। यदि आपको गोपनीयता चाहिए, तो डेटा को एन्क्रिप्ट करें (फिर आप ट्रांसपोर्ट के लिए साइफ़रटेक्स्ट को Base64 कर सकते हैं)। यदि आपको छोटा पेलोड चाहिए, तो उसे संपीड़ित करें। Base64 केवल टेक्स्ट-मात्र चैनलों से सुरक्षित ट्रांसपोर्ट के बारे में है — इससे ज़्यादा कुछ नहीं।

एन्कोड और डिकोड करते समय आम ग़लतियाँ

• ग़ैर-ASCII टेक्स्ट के लिए UTF-8 भूल जाना। ब्राउज़र में, चिरपरिचित btoa() फ़ंक्शन बाइट-दर-बाइट काम करता है और किसी भी ऐसे वर्ण पर एरर देता है जिसका कोड-पॉइंट 0xFF से अधिक है — तो एक इमोजी या उच्चारण-चिह्न वाला अक्षर भोले कोड को तोड़ देता है। हल यह है कि स्ट्रिंग को पहले उसके UTF-8 बाइट्स में बदलें, फिर उन बाइट्स को Base64 करें। यह टूल ठीक यही करता है, इसलिए उच्चारण-चिह्न, ग़ैर-लैटिन लिपियाँ और इमोजी सही ढंग से राउंड-ट्रिप होते हैं।
• डिकोड करते समय खाली जगह और न्यूलाइन। ईमेल, प्रमाणपत्रों या कॉन्फ़िग फ़ाइलों से कॉपी किया गया Base64 अक्सर लाइन-ब्रेक और स्पेस रखता है, और कई डिकोडर उन्हें अस्वीकार कर देते हैं। डिकोड करने से पहले सारी खाली जगह हटा दें (यह टूल इसे अपने-आप हटा देता है)।
• पैडिंग छूटी या ग़लत होना। कुछ स्रोत, ख़ासकर Base64URL, अंतिम = वर्णों को गिरा देते हैं। तब सख़्त डिकोडर विफल हो सकते हैं, जबकि उदार डिकोडर स्ट्रिंग की लंबाई से निहित पैडिंग फिर से जोड़ देते हैं। यदि कोई डिकोड विफल हो, तो जाँचें कि वर्ण-गणना चार का गुणज है।
• दोनों वर्णमालाओं को मिला देना। Base64URL (- और _) को मानक Base64 डिकोडर में डालना — या उल्टा — परिणाम को बिगाड़ देता है। डिकोड करने से पहले - को + में और _ को / में बदलें (या इसके विपरीत)।
• इसे सुरक्षा मानना। जैसा ऊपर बताया, किसी रहस्य को "छिपाने" के लिए कभी Base64 का उपयोग न करें। यह एन्कोडिंग है, एन्क्रिप्शन नहीं।

अक्सर पूछे जाने वाले सवाल

क्या मेरा डेटा कहीं अपलोड होता है?

नहीं। एन्कोडिंग और डिकोडिंग पूरी तरह आपके ब्राउज़र में JavaScript से होती है। आपका टेक्स्ट कभी आपके डिवाइस से बाहर नहीं जाता।

क्या यह Unicode और इमोजी सपोर्ट करता है?

हाँ। यह टूल टेक्स्ट को पहले UTF-8 के रूप में एन्कोड करता है, इसलिए उच्चारण-चिह्न वाले वर्ण, ग़ैर-लैटिन लिपियाँ और इमोजी सभी सही ढंग से एन्कोड और डिकोड होते हैं।

Base64 किसके लिए इस्तेमाल होता है?

Base64 बाइनरी डेटा को ASCII टेक्स्ट के रूप में दर्शाता है ताकि वह टेक्स्ट के लिए बने सिस्टमों — ईमेल (MIME), JSON, XML, data URI और HTTP हेडर — से सुरक्षित रूप से गुज़र सके।