डेवलपर टूल · Base64 एनकोडर और डिकोडर
Base64 बनाम हेक्स बनाम Base32: बाइट्स को टेक्स्ट के रूप में लिखने के तीन तरीकों की तुलना करना
· पेजभूमि
Base64 एन्कोडिंग
हेक्स, Base32 और Base64 आकार, पठनीयता और सुरक्षा में अलग-अलग ट्रेड-ऑफ के साथ एक ही समस्या का समाधान करते हैं। यह पोस्ट घनत्व, केस संवेदनशीलता, URL सुरक्षा और मानवीय त्रुटि पर उनकी तुलना करती है।
API कुंजी जो l, 1, I और O के कारण गलत टाइप की गई थी - एक ठोस पठनीयता विफलता जो हेक्स के पास नहीं होती
बाइट्स को टेक्स्ट के रूप में दर्शाने के तीन सामान्य तरीके हेक्स, Base32 और Base64 हैं। वे सभी एक ही समस्या का समाधान करते हैं (प्रिंट करने योग्य ASCII में मनमाने बाइट्स व्यक्त करते हैं) लेकिन आकार, पठनीयता और त्रुटि लचीलेपन में अलग-अलग ट्रेड-ऑफ के साथ। हेक्स प्रति बाइट 2 वर्ण है (F3 A2 B1 ...), इसलिए 16 bytes 32 वर्ण बन जाते हैं। Base32 प्रति बाइट 1.6 वर्ण है (लगभग 3 bytes प्रति 5 वर्ण), इसलिए 16 bytes 26 वर्ण बन जाते हैं।
Base64 प्रति बाइट 1.33 वर्ण है (बिल्कुल 4 वर्ण प्रति 3 bytes), इसलिए 16 bytes 24 वर्ण या उससे कम हो जाते हैं। यदि फ़ाइल का आकार मायने रखता है, तो Base64 सबसे कॉम्पैक्ट है। यदि मानव प्रतिलेखन मायने रखता है, तो हेक्स और Base32 अधिक सुरक्षित हैं। जब कोई मान टाइप किया जाता है, कॉपी किया जाता है या बोला जाता है तो पठनीयता में अंतर महत्वपूर्ण होता है। हेक्स 0-9 और a-f (अधिकांश संदर्भों में केस-असंवेदनशील) का उपयोग करता है। एक प्रतिलेखन चैनल निर्णय को बदल देता है क्योंकि मशीनों के लिए अनुकूलित प्रतिनिधित्व लोगों के लिए अजीब हो सकता है। Base64 केस-संवेदी है और दो विराम चिह्नों का उपयोग करता है; हेक्स छोटी दृश्य शब्दावली का उपयोग करता है। यहां कार्यान्वयन सटीक स्ट्रिंग्स का परीक्षण करता है, मानव-त्रुटि दर का नहीं, इसलिए कोई आविष्कृत संभावना संलग्न नहीं है।
घनत्व: 2×, 1.6× और 1.33× - प्रत्येक एन्कोडिंग को प्रति बाइट कितने वर्णों की आवश्यकता है और क्यों
Base32 A-Z और 2-7 का उपयोग करता है, 0, 1, O और I से बचता है जो कागज पर आसानी से भ्रमित हो जाते हैं। Base64 अपरकेस और लोअरकेस दोनों सहित A-Z, a-z, 0-9, + और /, का उपयोग करता है, जो इसे केस-संवेदी बनाता है और समान दिखने वाले अंकों को मिलाता है (0 बनाम O, 1 बनाम I बनाम लोअरकेस l)। हेक्स में एक API कुंजी f3a2b1e4 हो सकती है; Base64 में समान बाइट्स 86KrvE== (पैडिंग के साथ), या Base32 में 6VEV7FI= (पैडिंग के साथ) हो सकते हैं।
यदि उपयोगकर्ता को मान हाथ से टाइप करना है, तो हेक्स या Base32, Base64 से अधिक सुरक्षित है। URL में आरक्षित अक्षर मायने रखते हैं। हेक्स और Base32 URL के लिए सुरक्षित हैं; दोनों केवल अल्फ़ान्यूमेरिक वर्णों का उपयोग करते हैं (हेक्स भी 0-9 का उपयोग करता है, Base32 भी 2-7 का उपयोग करता है)। Base64 प्लस और स्लैश का उपयोग करता है जो URL-आरक्षित हैं (प्लस फॉर्म-एन्कोडेड डेटा में एक स्थान का प्रतिनिधित्व करता है, स्लैश एक पथ विभाजक है)। Base64 घनत्व प्रति आउटपुट प्रतीक छह उपयोगी बिट्स और पैडिंग से चार-वर्ण ब्लॉक तक सीधे अनुसरण करता है। हेक्स प्रति प्रतीक चार बिट रखता है, जिससे प्रति बाइट दो अक्षर बनते हैं। Base32 की चर्चा तुलनात्मक संदर्भ के रूप में केवल इसलिए की जाती है क्योंकि यह रिपॉजिटरी आउटपुट को सत्यापित करने के लिए न तो इसकी वर्णमाला और न ही कोई एनकोडर प्रदान करता है।
बिट चौड़ाई से घनत्व - सटीक Base64 और हेक्स अंकगणित, Base32 को तुलनात्मक संदर्भ के रूप में माना जाता है
URL पैरामीटर में Base64 स्ट्रिंग को प्रतिशत-एनकोडेड होना चाहिए (प्लस %2B हो जाता है, स्लैश %2F हो जाता है), प्रत्येक घटना के लिए 4 अतिरिक्त वर्ण जोड़ना चाहिए। Base64url (RFC 4648 सेक्शन 5) प्लस को डैश से और स्लैश को अंडरस्कोर से बदल देता है, जिससे यह URL-प्रतिशत-एन्कोडिंग के बिना सुरक्षित हो जाता है। अधिकांश APआई जो URL में Base64 का उपयोग करते हैं वे वास्तव में Base64url का उपयोग करते हैं, लेकिन दस्तावेज़ीकरण में अंतर अक्सर स्पष्ट नहीं होता है।
TOTP रहस्य (प्रमाणक ऐप्स द्वारा उपयोग किए गए कोड) आमतौर पर Base32 के रूप में वितरित किए जाते हैं। TOTP नामांकन स्क्रीन Base32 रहस्य दिखाती है क्योंकि Base64 या हेक्स में समान बाइट्स की तुलना में इसे टाइप करना और ट्रांसक्राइब करना आसान है। SHA हैश डाइजेस्ट को अक्सर हेक्स में प्रदर्शित किया जाता है क्योंकि यह पारंपरिक प्रारूप है और क्योंकि हेक्स केस-असंवेदनशील है, जिससे टाइपो की संभावना कम हो जाती है। केस संवेदनशीलता तब मायने रखती है जब कोई किसी मान को जोर से पढ़ता है या उसे दोबारा टाइप करता है, क्योंकि एक अक्षर का केस बदलने से उसका सूचकांक बदल जाता है। ToolAcre केस को सटीक रूप से सुरक्षित रखता है और परिणामी विभिन्न बाइट्स को बिना यह जाने डिकोड कर देगा कि किसी मानव ने ट्रांसक्रिप्शन त्रुटि की है। प्रतिनिधित्व में स्वयं कोई चेकसम नहीं है।
आरक्षित वर्ण और URL सुरक्षा - जहां + और / बाइट, और कैसे Base32 और हेक्स समस्या से बचते हैं
JWTs Base64url का उपयोग करते हैं। फ़ाइल चेकसम हेक्स या Base64 हो सकते हैं; दोनों आम हैं. चुनाव ऐतिहासिक परिपाटी है, तकनीकी आवश्यकता नहीं। त्रुटि लचीलापन एक सूक्ष्म लेकिन महत्वपूर्ण अंतर है। Base32 अंकों 0, 1, 8, और 9 (जो अक्षरों की तरह दिखते हैं) से बचता है, जिससे प्रतिलेखन त्रुटियां कम हो जाती हैं। Base64 में सभी अंक शामिल हैं, जो 1 को अस्पष्ट बनाता है (क्या यह अक्षर I, लोअरकेस l, या अंक 1 है?)।
हेक्स और भी अधिक त्रुटि-प्रवण है: 0 O जैसा दिखता है, l 1 जैसा दिखता है। एक चेकसम जिसे टाइप किया जाना चाहिए या प्रिंटआउट से पढ़ा जाना चाहिए, Base32 में सुरक्षित है। एक API कुंजी जो सीधे कंप्यूटर से चिपकाई जाती है, किसी भी प्रारूप में सुरक्षित है; पठनीयता तभी मायने रखती है जब इसमें मानवीय आंखें शामिल हों। बाइट्स समान हैं, लेकिन एन्कोडिंग अलग है: 16-बाइट अनुक्रम [0xf3, 0xa2, 0xb1, ...] f3a2b1 बन जाता है... मानक Base64 के प्लस और स्लैश को चैनल-जागरूक हैंडलिंग की आवश्यकता होती है; URL-सुरक्षित मोड उन्हें हाइफ़न और अंडरस्कोर से बदल देता है। हेक्स केवल अंकों और अक्षरों का उपयोग करके उन विभाजकों से बचता है। Base32 परंपराएं अलग-अलग होती हैं, इसलिए यह आलेख आशाजनक सुरक्षा गुणों से बचता है जिन्हें रिपॉजिटरी लागू या परीक्षण नहीं करती है।
कार्यान्वित उदाहरण: सभी तीन एन्कोडिंग में समान 16 bytes - तुलना की गई लंबाई और दृश्य निरीक्षण
हेक्स में, 6VEV7FI=... Base32 में, और 86KrvE== Base64 में। इनमें से कोई भी तार विनिमेय नहीं है। f3a2b1... प्राप्त करने वाला एक एप्लिकेशन हेक्स की अपेक्षा करता है और इसे हेक्स के रूप में पार्स करने का प्रयास करेगा। यदि एप्लिकेशन हेक्स की अपेक्षा करता है तो 86KrvE== प्राप्त करना विफल हो जाएगा। एन्कोडिंग प्रारूप डेटा के अनुबंध का हिस्सा है: प्रेषक और रिसीवर को इस बात पर सहमत होना होगा कि किस एन्कोडिंग का उपयोग किया जाता है। पैडिंग एक और अंतर है.
हेक्स पैडिंग का उपयोग नहीं करता है (4 bytes हमेशा 8 हेक्स वर्ण होते हैं, कोई अपवाद नहीं)। Base32 और Base64 दोनों आउटपुट को कई वर्णों में संरेखित करने के लिए समान पैडिंग का उपयोग करते हैं (Base32 के लिए 8, Base64 के लिए 4)। पैडिंग गणितीय रूप से आवश्यक है; यह सुनिश्चित करता है कि प्रत्येक एन-बाइट इनपुट एक नियतात्मक वर्ण गणना उत्पन्न करता है। पैडिंग नियम अलग-अलग होते हैं: कुछ अनुप्रयोगों के लिए पैडिंग की आवश्यकता होती है, अन्य इसे छोड़ने की अनुमति देते हैं। काम की गई तुलना एक निश्चित बाइट अनुक्रम का उपयोग करती है और Base64 और हेक्स की यांत्रिक रूप से गणना करती है। इसकी Base32 लंबाई पर पांच-बिट समूहन से चर्चा की जा सकती है, लेकिन सटीक Base32 पाठ मान को छोड़ दिया गया है क्योंकि किसी भी समीक्षा किए गए कार्यान्वयन ने इसे उत्पन्न नहीं किया है। लंबाई अंकगणित और आउटपुट सत्यापन को अलग रखा जाता है।
जहां प्रत्येक पारंपरिक है - हेक्स में हैश, Base32 में TOTP रहस्य, जेडब्ल्यूटी और डेटा: Base64 में यूआरआई
पैडिंग के बिना Base32 या Base64 मान चिपकाते समय, डिकोडर कार्यान्वयन के आधार पर इसे स्वीकार या अस्वीकार कर सकते हैं। क्रिप्टोग्राफ़िक कुंजियाँ और टोकन एन्कोडिंग अंतर दिखाते हैं।
एक HMAC कुंजी 32 bytes है, जो 64 हेक्स वर्ण, 52 Base32 वर्ण (पैडिंग के साथ), या 44 Base64 वर्ण (पैडिंग के साथ) बन जाती है। कुंजी वितरित करते समय, एन्कोडिंग का दस्तावेजीकरण किया जाना चाहिए। यदि दस्तावेज़ कहता है कि कुंजी 44 Base64 वर्ण है, लेकिन आपको 52 वर्ण प्राप्त होते हैं, तो कुछ गलत है। कन्वेंशन पाठकों का मार्गदर्शन तो कर सकता है लेकिन उपयुक्तता सिद्ध नहीं करता। हैश डाइजेस्ट आमतौर पर हेक्स के रूप में प्रदर्शित होते हैं, जबकि JWT सेगमेंट Base64url का उपयोग करते हैं। सही विकल्प अभी भी चैनल नियमों पर निर्भर करता है, कि क्या लोग मूल्य की प्रतिलिपि बनाते हैं, और क्या किसी अन्य प्रोटोकॉल ने पहले से ही प्रतिनिधित्व तय कर लिया है।
इसमें क्या शामिल नहीं है - Base58, Base85 और चेकसमड एन्कोडिंग
छोटा Base64 एन्कोडिंग टोकन को वर्ण सीमा (जैसे QR कोड या URL) वाले सिस्टम में फिट करना थोड़ा आसान बनाता है। किसी मान के लिए एन्कोडिंग का विकल्प उस पारिस्थितिकी तंत्र द्वारा निर्धारित किया जाता है जहां से वह आया है। वेब APआई अक्सर Base64url का उपयोग करते हैं। क्रिप्टोग्राफ़िक दस्तावेज़ीकरण अक्सर हेक्स का उपयोग करता है। प्रमाणक ऐप्स Base32 का उपयोग करते हैं। सिस्टम बनाते समय, एक एन्कोडिंग चुनें, उसे स्पष्ट रूप से दस्तावेज़ित करें और उस पर कायम रहें।
एनकोडिंग को मिलाने से (Base64 या Base32 कहकर) भ्रम पैदा होता है। डिबगिंग करते समय, पहला कदम यह पहचानना है कि मान किस एन्कोडिंग का उपयोग करता है; Base64 एनकोडर और डिकोडर टूल इसे कई तरीकों से डिकोड करने का प्रयास करके और यह देखकर मदद कर सकता है कि कौन सा समझदार आउटपुट उत्पन्न करता है। कोई भी एन्कोडिंग सार्वभौमिक रूप से बेहतर नहीं है। Base64 कच्चे भंडारण के लिए सबसे कॉम्पैक्ट है। हेक्स क्रिप्टोग्राफरों के लिए सबसे अधिक परिचित है और छोटे अनुक्रमों के लिए सबसे अधिक मानव-पठनीय है। Base58, Base85 और चेकसम्ड एन्कोडिंग अलग-अलग ट्रेड-ऑफ़ बनाते हैं और ToolAcre के Base64 पैनल से अनुपस्थित हैं। उनके अक्षर, अस्पष्टता नियम और चेकसम का मूल्यांकन इस टूल के परीक्षण किए गए व्यवहार से निकालने के बजाय समर्पित स्रोतों और कार्यान्वयन के साथ किया जाना चाहिए।
टेकअवे: चैनल और रीडर के लिए एन्कोडिंग चुनें - Base64 एनकोडर और डिकोडर ब्राउज़र में Base64 केस को कैसे कवर करते हैं, उसी उत्पाद में SHA हैश कैलकुलेटर के साथ
Base32 प्रतिलेखन त्रुटियों के प्रति सबसे अधिक लचीला है। चुनाव संदर्भ पर निर्भर करता है: मूल्य कहाँ रहता है, इसे कैसे साझा किया जाता है, और कौन सी प्रणालियाँ इसका उपभोग करेंगी।
ट्रेड-ऑफ़ को समझने से आपको API या सिस्टम डिज़ाइन करते समय बुद्धिमानी से चयन करने में मदद मिलती है। Base64 एनकोडर और डिकोडर टूल Base64 एन्कोडिंग को प्रदर्शित करता है; हेक्स या Base32 टूल के साथ इसका उपयोग करने से आप तीनों प्रारूपों में समान बाइट्स देख सकते हैं और उनके आकार और पठनीयता अंतर को समझ सकते हैं। Base64 मामले के लिए, एक नमूना एनकोड करें, सटीक UTF-8-बाइट और आउटपुट-कैरेक्टर गिनती नोट करें, और मानक बनाम URL-सुरक्षित विराम चिह्न का परीक्षण करें। डाइजेस्ट कार्य के लिए, अलग SHA पैनल का उपयोग करें। उन परिचालनों को अलग रखने से एन्कोडिंग विकल्प को हैशिंग या अखंडता सुरक्षा के लिए गलत होने से रोका जा सकता है।