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

Base64 क्या है?#

Base64 मनमाने बाइट्स को केवल 64 प्रिंट करने योग्य ASCII कैरेक्टरों (A-Z, a-z, 0-9, +, /, पैडिंग के लिए = के साथ) का उपयोग करके लिखने का एक तरीका है। यह इसलिए मौजूद है क्योंकि कंप्यूटिंग दुनिया के विशाल हिस्से टेक्स्ट के लिए डिज़ाइन किए गए थे — ईमेल बॉडीज़, JSON फ़ील्ड्स, HTTP हेडर, data-URI प्रीफ़िक्स — और वे कच्चे बाइट्स पर अटक जाते हैं, विशेष रूप से उच्च बिट सेट या उनमें जड़ित कंट्रोल कोड वाले बाइट्स पर। Base64 वह लिंगुआ फ़्रैंका है जिसका सहारा आप तब लेते हैं जब आपको बाइनरी-आकार के डेटा को एक केवल-टेक्स्ट चैनल में जीवित रहना हो।

हर तीन इनपुट बाइट्स (24 बिट्स) चार base64 कैरेक्टर्स (प्रत्येक 6 बिट एन्कोड करता है) बन जाते हैं। यही कारण है कि base64 आउटपुट हमेशा चार कैरेक्टरों का गुणज होता है, और यह मूल बाइट्स से लगभग 33% बड़ा होता है — वह अतिरेक प्रिंट करने योग्यता की कीमत है। जब इनपुट लंबाई तीन का गुणज नहीं होती, तो अंत में एक या दो = पैडिंग कैरेक्टर दिखते हैं।

यह पेज base64 को UTF-8 के साथ सुरक्षित ढंग से एन्कोड और डिकोड करता है। एक जाल जिसमें लोग लगातार फँसते हैं: किसी स्ट्रिंग को सीधे btoa() में देना जैसे ही उसमें कोई नॉन-ASCII कैरेक्टर (é, 中文, इमोज़ी) होता है InvalidCharacterError फेंकता है। समाधान है टेक्स्ट को पहले UTF-8 बाइट्स में एन्कोड करना, फिर base64 — यही यह औज़ार करता है, इसलिए café सही ढंग से राउंड-ट्रिप होता है फेंकने के बजाय।

इसका उपयोग कैसे करें#

1. टूलबार के ऊपर-बाईं ओर एन्कोड / डिकोड टॉगल से दिशा चुनें।
2. बाईं ओर इनपुट पैनल में टाइप करें या चिपकाएँ।
   • एन्कोड मोड में इनपुट को UTF-8 टेक्स्ट माना जाता है।
   • डिकोड मोड में इनपुट एक base64 स्ट्रिंग होना चाहिए। व्हाइटस्पेस बर्दाश्त किया जाता है।
3. URL-सेफ़ टिक करें यदि आपको base64url वर्णमाला (+ और / के बजाय - और _, पैडिंग हटाई गई) चाहिए। यही JWT और कई साइन्ड-URL योजनाएँ अपेक्षा करती हैं।
4. परिणाम दाईं ओर आउटपुट पैनल में लाइव दिखाई देता है। उसे लेने के लिए कॉपी पर क्लिक करें।
5. एक प्रदर्शन जोड़ा डालने के लिए नमूना, और दोनों पैनलों को रीसेट करने के लिए साफ़ करें का उपयोग करें।

प्रमुख विशेषताएँ#

• दोनों दिशाओं में UTF-8 सुरक्षित। एन्कोडिंग टेक्स्ट को पहले TextEncoder से गुज़ारती है, इसलिए मल्टीबाइट कैरेक्टर कभी नहीं फटते; डिकोडिंग बाइट्स को TextDecoder से गुज़ारती है ताकि मूल टेक्स्ट बिलकुल वैसे ही बहाल हो।
• मानक और URL-सेफ़ वर्णमाला। एक चेकबॉक्स क्लासिक base64 (+/=) और base64url (-_ बिना पैडिंग) के बीच स्विच करता है, डिकोड पर सही ढंग से पुनः-पैडिंग के साथ।
• शुद्ध क्लाइंट-साइड। कन्वर्सन केवल आपके ब्राउज़र में चलता है — न कोई बैकएंड और न कोई नेटवर्क रिक्वेस्ट। यहाँ कोई संवेदनशील टोकन चिपकाना उसे कहीं नहीं भेजता।
• लाइव स्थिति पट्टी। पैनलों के नीचे की पट्टी एन्कोड/डिकोड त्रुटियाँ (जैसे कोई %-आकार या कटा हुआ इनपुट) चुपचाप कचरा पैदा करने के बजाय बताती है।

कार्य उदाहरण#

एन्कोड और मानक (URL-सेफ़ नहीं) मोड में, ASCII टेक्स्ट Hello, World! बन जाता है:

SGVsbG8sIFdvcmxkIQ==

दो अनुगामी = दिखाते हैं कि 13-बाइट इनपुट तीन का गुणज नहीं था — यह अपेक्षित है, गलती नहीं।

UTF-8 हैंडलिंग का महत्व तैसे ही सामने आता है जैसे ही आप ASCII छोड़ते हैं। café को एन्कोड करना (जहाँ é दो UTF-8 बाइट्स हैं, c3 a9) देता है:

Y2Fmw6k=

यदि आप कंसोल में सीधे btoa("café") कॉल करते, तो वह फेंकता। यह औज़ार नहीं करता, क्योंकि यह पहले UTF-8 बाइट्स एन्कोड करता है।

URL-सेफ़ मोड वर्णमाला दोबारा लिखता है ताकि आउटपुट कभी ऐसे कैरेक्टर न ढोता जिन्हें URL गलत पढ़े: + - हो जाता है, / _ हो जाता है, और अनुगामी = पैडिंग हटा दी जाती है (डिकोड पर स्वतः फिर से जोड़ी जाती है)। ऊपर से मानक आउटपुट लें, SGVsbG8sIFdvcmxkIQ== — URL-सेफ़ मोड में दो पैडिंग = हटा दिए जाते हैं, जो SGVsbG8sIFdvcmxkIQ देता है। +// → -/_ अदला-बदली तभी कुछ बदलती है जब वे कैरेक्टर वास्तव में आउटपुट में दिखें, जो बाइनरी पेलोड जैसे हैश डाइजेस्ट या यादृच्छिक टोकन में होना झुकता है — ठीक उस तरह का डेटा जिसे आप बिना और एस्केप किए URL पाथ या क्वेरी पैरामीटर में घुसाते हैं।

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

मेरा डिकोड किया टेक्स्ट मोजिबाके के रूप में दिखता है। क्या हुआ?#

लगभग हमेशा, जो base64 आपने डिकोड किया वह किसी अन्य कैरेक्टर सेट (अक्सर Latin-1 या Windows-1252) में बाइट्स का एन्कोडिंग था, UTF-8 नहीं। यह औज़ार बाइट्स को UTF-8 के रूप में डिकोड करता है, इसलिए Latin-1-एन्कोडेड é (0xe9, एक अकेला बाइट) वैध UTF-8 नहीं है और गलत दिखता है। पता करें कि दूसरे सिरे ने मूल टेक्स्ट कैसे एन्कोड किया, या पहले उसे UTF-8 के रूप में दोबारा एन्कोड करें।

मानक base64 या base64url — मुझे कौन सा चाहिए?#

मानक (+/=) उस हर चीज़ के लिए डिफ़ॉल्ट है जो URL में नहीं जा रही: ईमेल अटैचमेंट, data: URI, बाइनरी ढोते JSON फ़ील्ड्स। जब आउटपुट URL पाथ, क्वेरी स्ट्रिंग, या एक JWT सेगमेंट में बैठेगा तब URL-सेफ़ चालू करें, जहाँ +, /, और = या तो पार्सिंग तोड़ते हैं या ट्रांसपोर्ट द्वारा बिगड़ जाते हैं। किसी भी रूप को डिकोड करना स्वतः स्वीकार किया जाता है।

एन्कोडेड आउटपुट मेरे इनपुट से लंबा क्यों है?#

वह अंतर्निहित है, बग नहीं। Base64 प्रति कैरेक्टर 8 के बजाय 6 बिट्स पैक करता है, इसलिए आउटपुट इनपुट के आकार का लगभग 4/3 होता है — लगभग 33% ओवरहेड। बहुत छोटे इनपुट्स के लिए यह मूल के सापेक्ष और भी बड़ा दिख सकता है, क्योंकि नियत संरचना हावी हो जाती है।

क्या यह किसी base64 स्ट्रिंग को डिक्रिप्ट या क्रैक कर सकता है?#

नहीं — base64 एक एन्कोडिंग है, एन्क्रिप्शन नहीं। यह डिज़ाइन द्वारा पूरी तरह उलटा हो सकता है और कोई कुंजी नहीं रखता। स्ट्रिंग रखने वाला कोई भी व्यक्ति इसे डिकोड कर सकता है। यदि आपको सच में गोपनीयता चाहिए, तो पहले एन्क्रिप्ट करें (उदाहरण के लिए एक प्रमाणीकृत-एन्क्रिप्शन योजना के साथ) और फिर ट्रांज़िट के लिए साइफरटेक्स्ट को base64-एन्कोड करें।