Base64 एन्कोडिंग समझाई गई: कब मदद करती है और कब नुकसान

Base64 मनमानी बाइट्स को सादे टेक्स्ट के रूप में लिखने का मानक तरीका है। चौंसठ प्रिंट करने योग्य कैरेक्टर — A–Z, a–z, 0–9, साथ ही + और / — छह-बिट समूहों के प्रतिनिधि हैं, इसलिए इनपुट की हर तीन बाइट आउटपुट के ठीक चार कैरेक्टर बनती हैं। इस मैपिंग में कुछ भी गुप्त नहीं है, और न ही यह मूल से छोटी है।

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

बड़े इनपुट पर Base64 मूल बाइट आकार में लगभग एक-तिहाई जोड़ती है। पैडिंग के साथ कैरेक्टरों की सटीक संख्या 4 × ceil(इनपुट बाइट / 3) है; लाइन ब्रेक और Data URL प्रीफ़िक्स और जोड़ते हैं। इसलिए 900 KB इमेज इन अतिरिक्त हिस्सों से पहले लगभग 1.2 MB Base64 टेक्स्ट बनती है।

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

Base64 मौजूद है क्योंकि कई चैनल सिर्फ़ टेक्स्ट के हैं। ईमेल मानक सात-बिट ASCII के लिए लिखे गए थे, JSON कच्ची बाइट्स नहीं रख सकता, और URL बाइनरी डेटा पर टूट जाते हैं — इसलिए बाइट-सेफ़ टेक्स्ट प्रतिनिधित्व ही पुल है।

इमेज से Base64 कन्वर्टर 4 MiB तक की PNG, JPEG, WebP या GIF से वे दोनों रूप बनाता है जिनकी आपको सचमुच ज़रूरत है: मीडिया-टाइप उपसर्ग सहित पूरा डेटा URL, और उसके नीचे की सादी Base64 पेलोड। कन्वर्शन टैब में होता है, इसलिए आप आकार फुलावट खुद मापते हुए भी इमेज आपके डिवाइस से बाहर नहीं जाती।

• डेटा URLडेटा URL छोटी एसेट को इनलाइन रखते हैं: data:image/png;base64,… किसी आइकन या छोटे प्लेसहोल्डर को CSS या HTML के अंदर ले जाता है, बिना अतिरिक्त अनुरोध के।
• ईमेल और MIMEईमेल अटैचमेंट Base64 पर सवार होते हैं क्योंकि SMTP टेक्स्ट के लिए बना था; MIME बाइनरी हिस्सों को ऐसे एन्कोड करता है कि वे हर रिले से बिना छेड़े बचे रहें।
• टोकन और प्रमाणपत्रटोकन और प्रमाणपत्र — JWT सेगमेंट, PEM फ़ाइलें, HTTP Basic क्रेडेंशियल — Base64 या उसके URL-सेफ़ रूप का इस्तेमाल करते हैं ताकि बाइनरी संरचनाएँ टेक्स्ट प्रोटोकॉल में समा जाएँ।

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

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

• कोई भी पढ़ सकता हैकॉन्फ़िगरेशन फ़ाइल में Base64-एन्कोड किया पासवर्ड अतिरिक्त कदमों वाला सादा-टेक्स्ट पासवर्ड है; जिसके पास पढ़ने की पहुँच है, उसके पास सीक्रेट पहले से है।
• फिर भी क्रेडेंशियलURL, स्क्रीनशॉट और बग रिपोर्ट में एन्कोड किए टोकन भी क्रेडेंशियल ही हैं — उन्हें ठीक वैसे ही साफ़ करें जैसे कच्ची वैल्यू करते हैं।
• असली सुरक्षा लगाएँअसली सुरक्षा का मतलब है कुंजी के साथ एन्क्रिप्शन, सत्यापन के लिए हैशिंग, या बस वैल्यू उजागर ही न करना; एन्कोडिंग इनमें से किसी का विकल्प कभी नहीं बनती।

ज़्यादातर Base64 बग डायलेक्ट के बग होते हैं। क्लासिक अक्षरमाला = पैडिंग के साथ + और / इस्तेमाल करती है; URL-सेफ़ रूप - और _ लगाता है और अक्सर पैडिंग गिरा देता है; MIME लाइनें 76 कैरेक्टर पर लपेटता है। एक डायलेक्ट की उम्मीद वाला डिकोडर दूसरे को ठुकरा देता है, और त्रुटि शायद ही बताती है कि कौन सा डायलेक्ट चाहिए था।

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

• अक्षरमाला बेमेलगलत अक्षरमाला: - या _ वाली URL-सेफ़ स्ट्रिंग सख्त क्लासिक डिकोडर से अस्वीकार होती है, और क्लासिक + और / URL-सेफ़ हैंडलिंग तोड़ देते हैं।
• पैडिंगगायब पैडिंग: पैडेड डायलेक्ट को चार के गुणक वाली लंबाई चाहिए, इसलिए गिराई गई = पूंछ सख्त पार्सर तोड़ देती है, भले ही डेटा सलामत हो।
• अवांछित कैरेक्टरडिकोडरों के नियम अलग हैं: कुछ स्पेस या गायब पैडिंग अस्वीकार करते हैं। Toolars ASCII स्पेस अनदेखा करता है और बिना पैडिंग भी लेता है, लेकिन पेलोड डिकोड करने से पहले Data URL का प्रीफ़िक्स हटाना होगा।

Base64 स्ट्रिंग आमतौर पर किसी संवेदनशील चीज़ के टुकड़े होती हैं: कॉन्फ़िगरेशन फ़ाइल, टोकन, ग्राहक ईमेल के लिए जा रही इमेज। किसी बेमकसद वेबसाइट पर उन्हें डिकोड करना मतलब वह सामग्री किसी और के लॉग में पेस्ट करना।

दोनों Toolars वर्कस्पेस पूरी तरह ब्राउज़र टैब में चलते हैं: टेक्स्ट या इमेज आपके डिवाइस पर पहले से मौजूद कोड से प्रोसेस होती है और ऑपरेशन के हिस्से के रूप में कभी ट्रांसमिट नहीं होती। कन्वर्ट करते समय नेटवर्क मॉनिटर खोलें — कोई अनुरोध आपका कंटेंट नहीं ले जाता।

यही सीमा इन टूलों को असली काम के लिए उपयोगी बनाती है — सहकर्मी के टोकन टुकड़े को डिकोड करना, प्रमाणपत्र ब्लॉक जाँचना, या इनलाइन स्टाइलशीट के लिए प्रोडक्ट इमेज बदलना — बिना किसी त्वरित खोज को प्रकटीकरण में बदले।