Base64 कब इस्तेमाल न करें: प्रदर्शन, सुरक्षा और डिज़ाइन के सौदे

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

Base64 को एन्क्रिप्शन की तरह न इस्तेमाल करें

एन्कोड किया डेटा सुरक्षित डेटा नहीं है। Base64 को किसी पासवर्ड या कुंजी की ज़रूरत नहीं, और इसकी वर्णमाला इतनी पहचानी हुई है कि उपकरण इसे प्रायः अपने आप डिकोड कर देते हैं। प्रमाण-पत्र, एक्सेस टोकन, निजी जानकारी और आंतरिक पहचानकर्ता हर उस व्यक्ति के सामने खुले रहते हैं जो एन्कोडेड स्ट्रिंग पढ़ सके।

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

बड़ी फ़ाइल को विशाल JSON स्ट्रिंग में न बदलें

किसी छोटी तस्वीर को JSON रिस्पॉन्स में डालना व्यावहारिक हो सकता है, ख़ासकर जब मान को एक ही आत्मनिर्भर दस्तावेज़ में रहना हो। पर वही काम बड़े दस्तावेज़ों, ऑडियो या वीडियो के साथ करना आम तौर पर ख़राब डिज़ाइन है। Base64 पेलोड का आकार लगभग तैंतीस प्रतिशत बढ़ा देता है। JSON पार्सर को एक लंबी स्ट्रिंग रोककर संसाधित करनी पड़ती है, और आवेदन एन्कोडेड व डिकोडेड दोनों प्रतियों के लिए अतिरिक्त मेमोरी आवंटित कर सकता है।

बाइनरी अपलोड, मल्टीपार्ट फ़ॉर्म, स्ट्रीमिंग रिस्पॉन्स और ऑब्जेक्ट स्टोरेज बड़ी फ़ाइलों के लिए ज़्यादा उपयुक्त हैं। ये क्लाइंट और सर्वर को डेटा धीरे-धीरे संसाधित करने देते हैं, कंटेंट टाइप सुरक्षित रखते हैं और हर बाइट को किसी बीच के टेक्स्ट रूप से गुज़ारने से बचाते हैं। API पूरी फ़ाइल बैठाने के बजाय मेटाडेटा और एक हस्ताक्षरित डाउनलोड URL लौटा सकता है।

जब डेटाबेस बाइनरी डेटा संभाल लेता है तब Base64 न रखें

टेक्स्ट कॉलम लुभाते हैं क्योंकि उन्हें देखना आसान है, पर बाइनरी मानों के लिए वे अक्षम हैं। एन्कोडेड रूप ज़्यादा भंडारण खाता है, बैकअप का आकार बढ़ाता है और टेक्स्ट कोलेशन या इंडेक्सिंग के साथ ख़राब तालमेल बिठा सकता है। डेटाबेस बाइनरी कॉलम प्रकार ठीक इसीलिए देते हैं कि मनमाने बाइट्स बिना टेक्स्ट रूपांतरण के संभाले जा सकें।

बड़ी संपत्तियों के लिए फ़ाइल को रिलेशनल डेटाबेस के बाहर रखना अक्सर और भी बेहतर है। डेटाबेस स्वामित्व, चेकसम, आयाम और स्टोरेज कुंजियाँ रख सकता है जबकि एक समर्पित ऑब्जेक्ट स्टोर बाइट्स संभालता है। सही चुनाव संगति और परिचालन ज़रूरतों पर निर्भर है, पर Base64 इनमें से किसी विकल्प को शायद ही बेहतर बनाता है।

डेटा URL के साथ सावधानी बरतें

एक डेटा URL सामग्री को सीधे किसी पेज या स्टाइलशीट में बैठा देता है, अक्सर Base64 के ज़रिए। इससे एक नेटवर्क अनुरोध बच जाता है और छोटी, अपरिवर्तनीय संपत्तियों के लिए मदद मिल सकती है। पर यह बैठाए गए संसाधन को अलग से कैश होने से रोकता है, उसे समेटे दस्तावेज़ को बड़ा कर देता है और स्रोत फ़ाइलों को पढ़ना कठिन बना देता है। एक आइकन बदलने के लिए पूरे CSS या HTML संसाधन को अमान्य करना पड़ता है।

आधुनिक HTTP कनेक्शन कई छोटे अनुरोध कुशलता से संभालते हैं, इसलिए हर संपत्ति को इनलाइन करने की पुरानी सलाह अब हर जगह सही नहीं रहती। असली पेज व्यवहार नापें। एक बहुत छोटा सजावटी आइकन अच्छा उम्मीदवार हो सकता है; कोई तस्वीर या फ़ॉन्ट परिवार आम तौर पर नहीं।

ट्रांसपोर्ट अनुकूलता को सत्यापन समझने की भूल न करें

Base64 का सफल डिकोडिंग बस इतना साबित करता है कि किसी रूप के तहत स्ट्रिंग को बाइट्स माना जा सकता है। यह यह नहीं साबित करता कि वे बाइट्स कोई सुरक्षित तस्वीर हैं, कोई मान्य सर्टिफ़िकेट हैं, या वही फ़ाइल प्रकार जिसका दावा भेजने वाले ने किया। हमलावर दुर्भावनापूर्ण सामग्री को भी उतनी ही आसानी से एन्कोड कर सकते हैं जितनी आसानी से वैध सामग्री को।

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

ग़लती से दोहरी एन्कोडिंग पर नज़र रखें

परतदार सिस्टम कभी किसी मान को इसलिए एन्कोड करते हैं कि एक घटक टेक्स्ट चाहता है, फिर दोबारा एन्कोड कर देते हैं क्योंकि दूसरे घटक को पता ही नहीं कि पहला रूपांतरण हो चुका है। पाने वाला एक बार डिकोड करता है और मूल डेटा के बजाय एक और Base64 स्ट्रिंग पाता है। दोहरी एन्कोडिंग आकार और बढ़ा देती है और असली अनुबंध को धुँधला कर देती है।

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

जब Base64 ही सही चुनाव रहता है

इनमें से कोई सौदा Base64 को बुरा नहीं बनाता। यह केवल-टेक्स्ट फ़ॉर्मेट में छोटे बाइनरी मानों, ईमेल अटैचमेंट, PEM दस्तावेज़ों, सघन टोकन और उन API के लिए भरोसेमंद रहता है जिनके स्थापित अनुबंध इसकी माँग करते हैं। इसकी सरलता और सार्वभौमिक समर्थन असली लाभ हैं।

डिज़ाइन का सवाल यही है कि पाने वाले सिस्टम को टेक्स्ट चाहिए या बाइट्स। जब उसे बाइट्स चाहिए और वह बाइट्स ले सकता है, तो बाइट्स भेजें। जब कोई केवल-टेक्स्ट चैनल आड़े आ रहा हो, तो Base64 एक व्यावहारिक एडाप्टर है। इसे सोच-समझकर इस्तेमाल करने से इसका अतिरिक्त बोझ दिखता रहता है और एक अनुकूलता-उपकरण किसी अनावश्यक स्थापत्य आदत में नहीं बदलता।