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

कंटेंट	बाइट	Base64 अक्षर	Padding	उदाहरण
एक ASCII अक्षर (« A »)	1	4	« == »	QQ==
दो अक्षर (« AB »)	2	4	« = »	QUI=
तीन अक्षर (« ABC »)	3	4	कोई नहीं	QUJD
« Hello » (UTF-8)	5	8	« = »	SGVsbG8=
« नमस्ते दुनिया! » (UTF-8)	18	24	कोई नहीं	Qm9uam91ciBsZSBtb25kZSAh
« é » (UTF-8)	2	4	कोई नहीं	w6k=
« 日 » (UTF-8)	3	4	कोई नहीं	5piv
नल बाइट (0x00)	1	4	« == »	AA==

Base64 में « encoder » और « decoder » का क्या अर्थ है?

Base64 में एन्कोडिंग (« encode base64 ») बाइट को — ज़्यादातर UTF-8 में एन्कोड किए गए टेक्स्ट के बाइट को — 64 अनुमत अक्षरों की स्ट्रिंग में बदलता है: 26 बड़े अक्षर, 26 छोटे अक्षर, 10 अंक, फिर + और /. Base64 की डीकोडिंग (« decode base64 ») ठीक विपरीत काम करता है: स्ट्रिंग को 4 अक्षरों के समूह में पढ़ा जाता है, हर अक्षर 6 बिट दर्शाता है, और 24 बिट से 3 बाइट बनते हैं। यही आगे-पीछे का खेल है जो ज़्यादातर लोग तब ढूँढते हैं जब वे « encode and decode base64 » टाइप करते हैं।

Base64 न तो कंप्रेशन है न ही एन्क्रिप्शन: टेक्स्ट लगभग एक-तिहाई लंबा हो जाता है, और कोई भी उसे एक सेकंड में पढ़ सकता है। इसका फ़ायदा यह है कि यह बाइट को उन चैनलों से ले जाता है जो केवल सुरक्षित ASCII अक्षर स्वीकार करते हैं — URL, HTTP हेडर, कॉन्फ़िगरेशन फ़ाइलें, JSON, inline SVG, ईमेल, टेक्स्ट डेटाबेस।

टेक्स्ट को Base64 में कैसे एन्कोड करें

चरण 1: टेक्स्ट को सबसे पहले चुने गए कैरेक्टर सेट के हिसाब से बाइट में एन्कोड किया जाता है — डिफ़ॉल्ट रूप से UTF-8, लेकिन लीगेसी डेटा के लिए Latin-1, Windows-1252, ASCII या UTF-16 भी उपयोगी रहते हैं। चरण 2: बाइट तीन-तीन के हिसाब से पढ़े जाते हैं, यानी 24 बिट। चरण 3: इन 24 बिट को चार 6-बिट ब्लॉक में काटा जाता है और हर ब्लॉक को अल्फ़ाबेट के उसी स्थान के अक्षर से बदला जाता है। चरण 4: अंतिम समूह अधूरा हो तो उसे शून्य बिट से भरा जाता है और स्ट्रिंग एक या दो = (padding)।

चरण-दर-चरण उदाहरण: « AB » दशमलव में 65, फिर 66 है, यानी 01000001 01000010. तीन बाइट padding के साथ: 01000001 01000010 00000000. चारों 6-बिट समूह हैं 010000 010100 001000 000000 → स्थितियाँ 16, 20, 8, 0 → QUI=. एन्कोडर में बस « AB » टाइप करें: कुंजी छोड़ने से पहले ही परिणाम दिख जाता है।

Base64 को टेक्स्ट में कैसे डीकोड करें

डीकोडिंग में लाइन ब्रेक और जो भी स्पेस हों हटाने के बाद स्ट्रिंग को 4 अक्षरों के समूह में पढ़ा जाता है। हर अक्षर को उसके 6-बिट मान से बदला जाता है, चारों मान 24 बिट में जोड़े जाते हैं, फिर उन 24 बिट को 3 बाइट में काटा जाता है। अंत में लगे = बताते हैं कि अंतिम समूह में कितने उपयोगी बाइट हैं: एक = का मतलब 2 बाइट है, दो = का मतलब 1 बाइट।

अगर स्ट्रिंग में - या _, तो यह URL-safe वेरिएंट है: टूल इन्हें अपने आप + और / से पहले डीकोड किया जाता है। अगर padding गायब हो तो « padding ठीक करें » बटन उसे वापस ला देता है। अल्फ़ाबेट से बाहर का अक्षर, गलत जगह पर टैब या लंबाई 4 का गुणनखंड न होने पर, त्रुटि सिर्फ़ « अमान्य » के बजाय सटीक कारण के साथ दिखाई जाती है।

URL-safe वेरिएंट (RFC 4648 §5)

मानक Base64 उपयोग करता है + और /, दो अक्षर जो URL में समस्या पैदा करते हैं: + को अधिकांश सर्वर स्पेस मान लेते हैं, और / पाथ सेपरेटर समझा जा सकता है। URL-safe वेरिएंट इन्हें बदल देता है - और _, जिन्हें किसी एस्केपिंग की ज़रूरत नहीं। यह इनमें अनिवार्य है: JWT (टोकन के तीनों सेगमेंट बिना padding के एन्कोड होते हैं), cookies, पहचानकर्ते और URL पैरामीटर में।

Padding « = » : किस काम आता है

Base64 4 अक्षरों के समूह में काम करता है, लेकिन किसी फ़ाइल का साइज़ शायद ही कभी 3 बाइट का गुणनखंड होता है। padding अपेक्षित लंबाई बहाल करता है: 1 बाइट शेष रहने पर ==, 2 बाइट शेष रहने पर =। कुछ सिस्टम इसे हटा देते हैं (कुछ API, Base64URL); कुछ इसे माँगते हैं (PHP, पुराने डीकोडर)। एन्कोडर का « बिना padding » विकल्प और डीकोडर का « padding ठीक करें » बटन दोनों ही स्थितियाँ कवर करते हैं।

कैरेक्टर एन्कोडिंग: UTF-8, Latin-1, UTF-16

Base64 को अक्षरों की नहीं, केवल बाइट की जानकारी है। इसलिए अहम सवाल यह है कि Base64 में भेजने से पहले टेक्स्ट को किस कैरेक्टर एन्कोडिंग में बदला जाता है ? जैसे UTF-8 में « é » 2 बाइट का है और « 日 » 3 बाइट का; Latin-1 में « é » 1 बाइट में समा जाता है लेकिन « 日 » संभव नहीं होता। Latin-1 में एन्कोड की गई स्ट्रिंग का UTF-8 डीकोड करने पर गलत अक्षर बनते हैं (« mojibake »)। अगर आप किसी ऑनलाइन टूल से पूछें और परिणाम समझ में न आए, तो लगभग हमेशा शुरुआती एन्कोडिंग अलग होती है — इसीलिए यहाँ छह विकल्प दिए गए हैं।

फ़ाइल, data URI और Base64 में इमेज

एक data URI का रूप होता है data:<MIME टाइप>;base64,<डेटा>। यह सीधे CSS, HTML या JSON में इमेज एम्बेड करने देती है: background-image:url(data:image/png;base64,iVBOR…)। डीकोड करने के लिए, पूरी स्ट्रिंग « फ़ाइल ⇄ Base64 » टैब में चिपकाएँ: MIME टाइप निकाला जाता है, नाम सुझाया जाता है, फिर फ़ाइल फिर से बनकर डाउनलोड के लिए तैयार हो जाती है। साइज़ का ध्यान रखें: Base64 लगभग 33 % बड़ा कर देता है और data URI कभी अलग से कैश नहीं होती।

Base64, URL-encoding और इन्हें मिलाना क्यों नहीं चाहिए

यह percent-encoding (%20, %C3%A9) हर गैर-अनुमत बाइट को प्रतिशत से बदल देता है: यह Base64 से दो से तीन गुना लंबा होता है लेकिन मूल टेक्स्ट को दिखने में ज्यों का त्यों रखता है। Base64 एक छोटी-सी और एकसमान स्ट्रिंग बनाता है, blobs के लिए बढ़िया, लेकिन पढ़ने लायक नहीं। « URL & data URI » टैब दोनों कन्वर्ज़न साथ-साथ देता है, ताकि वह क्लासिक गलती न हो जब URL को एस्केप करना होता है और उसे Base64 में एन्कोड कर दिया जाता है — या उल्टा।

रोज़मर्रा के फ़ॉर्मेट में Base64

Base64 हर जगह है: एक JWT, एट्रिब्यूट src वाली inline SVG इमेज का, फ़ील्ड cert वाले PDF का, attachments वाले ईमेल के MIME (RFC 2045), Authorization: Basic वाले API के (उपयोगकर्ता:पासवर्ड), फ़ाइलें .pem और SSH कुंजियाँ, इनका कंटेंट .docx और .xlsx (ZIP), क्लाइंट स्टोरेज में अवतार, और data- attributes ऑटोमेटेड टेस्ट के। जल्दी से एन्कोड और डीकोड करना आने पर एक स्ट्रिंग के लिए सिर्फ़ टर्मिनल खोलना नहीं पड़ता।

Base64 क्या नहीं है

Base64 कुछ भी एन्क्रिप्ट नहीं करता: एन्कोड की गई स्ट्रिंग एक लाइन कोड में वापस मिल जाती है। इसे कभी पासवर्ड, API कुंजी या निजी डेटा की सुरक्षा के लिए इस्तेमाल न करें। यह कंप्रेशन भी नहीं है: हमेशा 33 % अतिरिक्त साइज़ का इंतज़ाम करें। और अंत में, पहले से घने कंप्रेस्ड बाइनरी (PNG, ZIP) के लिए कुछ मेगाबाइट से अधिक पर Base64 उपयुक्त नहीं है, जहाँ मेमोरी लागत भारी पड़ने लगती है।

परफ़ॉर्मेंस और बेस्ट प्रैक्टिस

ब्राउज़र में, TextEncoder और TextDecoder प्रति सेकंड कई मेगाबाइट प्रोसेस करते हैं; खुद Base64 एल्गोरिदम लीनियर है, न कोई रिकर्शन, न प्रति-अक्षर एलोकेशन। 5 MB से बड़ी फ़ाइलें इंटरफ़ेस को धीमा कर सकती हैं: बड़े बैच के लिए Web Worker या सर्वर-साइड प्रोसेसिंग बेहतर रहेगी। स्ट्रिंग के साथ हमेशा मूल एन्कोडिंग दर्ज रखें, और कोई परिणाम डेटाबेस में सहेजने से पहले राउंड-ट्रिप (एन्कोड फिर डीकोड) ज़रूर आज़माएँ।

किसके लिए अनुशंसित

back-end और front-end डेवलपर (टोकन, data URI, HTTP हेडर), इंटीग्रेटर और तकनीकी लेखक (inline SVG, बैकग्राउंड इमेज), सिस्टम एडमिन और DevOps (प्रमाणपत्र, कुंजियाँ, डंप), टेस्टर और पेंटेस्टर (Authorization Basic, पैरामीटर फ़ज़िंग), छात्र (बाइट, ASCII और UTF-8 को समझने के लिए), और हर उस व्यक्ति को जिसे एक चाहिए base64 encoder decoder online तेज़, पूर्ण और निजी।

100 % लोकल Base64 एन्कोडर डीकोडर: आपका डेटा कभी आपके कंप्यूटर से बाहर नहीं जाता

पारंपरिक ऑनलाइन Base64 एन्कोडर के विपरीत, कोई स्ट्रिंग नहीं भेजी जाती: एन्कोडिंग, डीकोडिंग और फ़ाइल कन्वर्ज़न पूरी तरह आपके ब्राउज़र में चलते हैं। इसी की वजह से आप पासवर्ड, टोकन, प्रमाणपत्र या आंतरिक कोड स्निपेट बेफ़िक्र एन्कोड कर सकते हैं, चाहे एयरप्लेन मोड में हों या पब्लिक नेटवर्क पर। इतिहास और आपकी आख़िरी इनपुट लोकल (localStorage) में रहती है और आपके डिवाइस पर ही बनी रहती है।

लाइसेंस Volade Premium वैकल्पिक, एन्क्रिप्टेड क्लाउड सिंक जोड़ता है जो टूल से स्वतंत्र है — बाकी सब कुछ मुफ़्त और असीमित रहता है, बिना पंजीकरण के।