डेवलपर टूल · Base64 एनकोडर और डिकोडर
Base64 पैडिंग ने समझाया: = चिह्नों का क्या मतलब है और उनकी आवश्यकता कब होती है
· यह काम किस प्रकार करता है
Base64 एन्कोडिंग डेवलपर-वर्कफ़्लो
Base64 स्ट्रिंग के अंत में = सजावट नहीं है: यह रिकॉर्ड करता है कि अंतिम समूह कितने बाइट्स छोटा था। यह पोस्ट अंकगणित की व्याख्या करती है, क्यों कुछ तारों में कोई नहीं है, और क्यों डिकोडर लापता पैडिंग के बारे में असहमत हैं।
एक टोकन से 'गलत पैडिंग' अपवाद जो ठीक लग रहा था - एक असफल डिकोड और इसके पीछे एक या दो गायब अक्षर
जब Base64 डिकोडर गलत पैडिंग की रिपोर्ट करता है, तो स्ट्रिंग पूर्ण दिखती है लेकिन उसमें संरचनात्मक त्रुटि होती है। समान चिह्न कॉस्मेटिक नहीं हैं: प्रत्येक एनकोड करता है कि अंतिम समूह कितने बाइट्स छोटा था, जिससे डिकोडर को यह पता चल जाता है कि वास्तविक डेटा कब समाप्त हुआ। उन = संकेतों को समझना - और क्यों सख्त डिकोडर उनके बिना स्ट्रिंग को अस्वीकार कर देते हैं - एक रहस्यमय त्रुटि को पूर्वानुमानित अंकगणित में बदल देता है। JWT सेगमेंट में एक =, कोई नहीं, या दो हो सकते हैं। API प्रतिक्रिया बिना किसी पैडिंग के स्पष्ट रूप से समाप्त हो सकती है।
ये जानबूझकर विकल्पों का प्रतिनिधित्व करते हैं, न कि कार्यान्वयन वेरिएंट का। डिकोडिंग प्रक्रिया के लिए यांत्रिक रूप से पैडिंग की आवश्यकता नहीं होती है। आउटपुट को स्पष्ट बनाने के लिए पैडिंग मौजूद है: केवल Base64 स्ट्रिंग दी गई है, जिसमें लंबाई के बारे में कोई मेटाडेटा नहीं है, डिकोडर पैडिंग पढ़ता है और जानता है कि डेटा कहां समाप्त हुआ। Base64 तीन बाइट्स के समूहों को चार वर्णों में एन्कोड करता है। तीन बाइट्स 24 bits हैं, जो पूरी तरह से चार 6-बिट सूचकांकों में पुनर्समूहित होते हैं; प्रत्येक 64 Base64 प्रतीकों में से एक चुनता है। जब इनपुट तीन का गुणज नहीं होता है, तो एनकोडर को बचे हुए का सामना करना पड़ता है: एक या दो बाइट्स तीन से समान रूप से विभाजित नहीं हो सकते हैं।
तीन बाइट्स के समूह, चार वर्णों के ब्लॉक - क्यों इनपुट लंबाई मॉड्यूलो 3 यह तय करता है कि शून्य, एक या दो = चिह्न दिखाई देते हैं या नहीं
एनकोडर बिट्स को पहले सूचकांकों में स्थानांतरित करके उन समूहों को पैड करता है, जिससे फाइनल शून्य हो जाता है। इस इरादे को चिह्नित करने के लिए, यह = चिह्न जोड़ता है: पूर्ण समूहों के लिए शून्य, दो-बाइट फ़ाइनल के लिए एक, एक-बाइट फ़ाइनल के लिए दो। अंकगणित नियतात्मक है: बाइट्स में इनपुट लंबाई जानने से आप तुरंत पैडिंग की गणना कर सकते हैं। एक बाइट दो Base64 अक्षर प्लस दो = उत्पन्न करता है। दो बाइट्स तीन अक्षर प्लस एक = उत्पन्न करते हैं। तीन बाइट्स बिना किसी पैडिंग के चार बाइट्स उत्पन्न करते हैं।
कोई भी इनपुट जो तीन बाइट्स से अधिक न हो, उसमें पैडिंग होगी; कोई भी जो गुणज है वह नहीं होगा। यह विकल्प नहीं है - यह अंकगणित है। बिना पैडिंग वाली एक स्ट्रिंग को तीन बाइट्स का प्रतिनिधित्व करना चाहिए। एक बराबर वाली स्ट्रिंग को दो का प्रतिनिधित्व करना चाहिए। पैडिंग इनपुट लंबाई मॉड्यूलो तीन को एन्कोड करता है। तीन इनपुट के परिवर्तन की जांच करें: सिंगल ए, पेयर एबी, ट्रिपल एबीसी। ASCII a बाइट 0x61 है; Base64 इसे 0x61 00 00 के रूप में एन्कोड करता है, छह-बिट समूहों में पुन: समूहित करता है।
पैडिंग बिट्स में क्या होता है और एक सख्त डिकोडर उनकी जांच क्यों करता है - वे बिट्स जो शून्य होने चाहिए और कैनोनिकल एन्कोडिंग का क्या मतलब है
सूचकांक 24, 4, 0, 0 Y, E, A, A पर मैप करते हैं। क्योंकि दो समूह पैडिंग कर रहे थे, एनकोडर दो = चिह्न जोड़ता है, जिससे YQ== उत्पन्न होता है। एबी के लिए, बाइट्स 0x61 0x62 0x61 0x62 00. Bits बन जाते हैं और इंडेक्स 24, 22, 8, 0, आउटपुट YWI= पर पुनः समूहित हो जाते हैं। एबीसी के लिए, बाइट्स सूचकांकों 24, 22, 9, 35 पर पुन: समूहित होते हैं, बिना किसी पैडिंग के आउटपुट YWJj। पैडिंग मनमानी नहीं है: यह बिट लेआउट से बाहर हो जाती है। जब आप Base64 स्ट्रिंग को डिकोड करते हैं, तो डिकोडर प्रत्येक अक्षर को पढ़ता है, उसके छह-बिट इंडेक्स को देखता है, बिट्स को बाइट्स में पैक करता है।
YQ== के लिए, वर्ण Y, E, A, A को बिट्स में अनपैक करें। आठ-बिट बाइट्स में पुनः समूहित करने पर एक बाइट, 0x61 प्राप्त होता है। डिकोडर पैडिंग बिट्स (शून्य के पीछे) को हटा देता है और एक बाइट की रिपोर्ट करता है। एक सख्त डिकोडर जाँचता है कि पैडिंग बिट्स वास्तव में शून्य हैं; यदि नहीं, तो इनपुट विहित नहीं था, जिसका अर्थ है कि किसी ने अलग-अलग बिट लेआउट और डिकोड का उपयोग करके एन्कोड किया है जो अस्पष्ट है। पैडिंग को पूरी तरह से छोड़ने वाले सिस्टम जानबूझकर व्यापार-बंद करते हैं। JWT सेगमेंट बिना पैडिंग के Base64url का उपयोग करते हैं, उपभोक्ताओं पर अपेक्षित आउटपुट लंबाई जानने या उसका अनुमान लगाने पर निर्भर करते हैं।
व्यावहारिक उदाहरण: 'ए', 'एबी' और 'एबीसी' को हाथ से एन्कोड करना - तीन इनपुट, तीन पैडिंग परिणाम, थोड़ा-थोड़ा करके दिखाया गया
RFC 4648 पैडिंग अनुपस्थित होने की अनुमति देता है लेकिन डिकोडर्स को निर्देश देता है कि यदि मौजूद है तो इसे स्वीकार करें। कोड लाइब्रेरी अलग-अलग हैं: कुछ गायब पैडिंग को पुनर्स्थापित करेंगे और आगे बढ़ेंगे; अन्य असफल हो जायेंगे. जब आपको ऐसे टोकन मिलते हैं जो डिकोडिंग में विफल हो जाते हैं, तो सही संख्या में = चिह्न जोड़ने से अक्सर यह ठीक हो जाता है। आवश्यक = संकेत हमेशा शून्य, एक या दो होते हैं, जो स्ट्रिंग की लंबाई मॉड्यूलो चार पर निर्भर करता है। यदि Base64 स्ट्रिंग की लंबाई चार की गुणज नहीं है, तो पैडिंग निश्चित रूप से गायब है या दूषित है।
5 की लंबाई वैध Base64 नहीं हो सकती: प्रत्येक पूर्ण वर्ण छह बिट्स को एन्कोड करता है, इसलिए चार वर्ण 24 bits (तीन बाइट्स) को एन्कोड करते हैं, और पांच अक्षर 30 bits को एन्कोड करते हैं, जो आठ का गुणक नहीं है और बाइट्स नहीं बन सकते हैं। डिकोडर को या तो इसे अस्वीकार करना होगा या पैडिंग जोड़ना होगा। यदि लंबाई 2 मॉड्यूल 4 है, तो दो = जोड़ें। यदि 3 मॉड्यूल 4 है, तो एक = जोड़ें। यदि 0 मॉड्यूल 4 है, तो कोई नहीं जोड़ें। 3 लंबाई की एक स्ट्रिंग में इसकी कमी है = इसकी आवश्यकता है; एक जोड़ें और यह डिकोडिंग से पहले वैध हो जाता है।
क्यों कुछ सिस्टम पैडिंग को पूरी तरह से हटा देते हैं - JWT सेगमेंट और URL-सुरक्षित टोकन जो छोड़ देते हैं = और इसे लंबाई से कैसे पुनर्स्थापित करें
यदि पैडिंग जगह पर छोड़ दी गई तो दो गद्देदार Base64 तार टूट गए। दो अलग-अलग एन्कोड सीधे जुड़ने से भटके हुए पैडिंग वर्ण उत्पन्न होते हैं जो डिकोडिंग वर्णमाला को तोड़ देते हैं। यही कारण है कि कुछ सिस्टम संयोजन से पहले पैडिंग को हटा देते हैं: बिंदुओं से जुड़े तीन Base64url खंडों से बने टोकन में खंडों के भीतर कोई पैडिंग नहीं होती है, जिससे संयोजन सरल हो जाता है। यदि भागों से Base64 मान का निर्माण किया जा रहा है, तो सत्यापित करें कि क्या प्रत्येक भाग गद्देदार है और किसी भी ऑपरेशन से पहले लगातार पट्टी या पैडिंग जोड़ें।
Base64 एनकोडर और डिकोडर RFC 4648 लागू होता है, जिसके लिए डिफ़ॉल्ट रूप से पैडिंग की आवश्यकता होती है। जब आप टेक्स्ट दर्ज करते हैं और Base64 आउटपुट का अनुरोध करते हैं, तो टूल एक गद्देदार परिणाम उत्पन्न करता है: कैनोनिकल फॉर्म। यदि आप Base64 को बिना पैडिंग के देखते हैं और इसे डिकोड करना चाहते हैं, तो जांचें कि क्या आपका डिकोडर गायब पैडिंग को स्वीकार करता है। टूल पैडेड और अनपैडेड दोनों इनपुट स्वीकार करता है और मूल बाइट्स को सही ढंग से पुनर्प्राप्त करता है। डिबगिंग के लिए, लंबाई मॉड्यूलो चार की गिनती आपको बताती है कि क्या पैडिंग हटा दी गई थी, और सूत्र बताता है कि कौन सी पैडिंग मौजूद होनी चाहिए।
सामान्य गलतियाँ: ट्रिमिंग = जैसे कि यह रिक्त स्थान हो, या दो गद्देदार तारों को जोड़ना - कैसे प्रत्येक डिकोड को दूषित करता है
Base32 और Base16 (हेक्साडेसिमल) में RFC 4648 अनुभाग 6 और 7 में परिभाषित अलग-अलग पैडिंग नियम हैं। Base32 = का उपयोग करता है लेकिन अंतिम समूह इनपुट लंबाई मोडुलो पांच के आधार पर 2, 4, 5, 7, या 8 वर्ण हो सकता है। हेक्साडेसिमल को किसी पैडिंग की आवश्यकता नहीं है; यह हमेशा एक बाइट को दो अक्षरों में मैप करता है, कोई शेष नहीं। MIME Base64 रैपिंग पैडिंग को छूती है: एक 76-कॉलम लपेटी गई स्ट्रिंग में अभी भी बहुत अंत में पैडिंग है, केवल कुछ पंक्तियों के बाद।
Base64 के लिए पैडिंग को समझना बिट लेआउट और इनपुट लंबाई मॉड्यूलो तीन को समझने के बारे में है; एक बार जब आप अंकगणित देख लेते हैं, तो पैडिंग एक प्रत्यक्ष परिणाम बन जाता है, याद रखने का नियम नहीं। पैडिंग व्युत्पन्न है, जादुई नहीं।
इसमें क्या शामिल नहीं है - Base32 और Base16 पैडिंग नियम, और MIME लाइन-लंबाई कन्वेंशन
किसी भी लंबाई की Base64 स्ट्रिंग को देखते हुए, आप वर्ण गणना को चार से विभाजित करके, शेष लेकर, और = चिह्नों की संबंधित संख्या जोड़कर विहित गद्देदार फॉर्म को पुनर्स्थापित कर सकते हैं। यही कारण है कि missing = को ठीक किया जा सकता है और क्यों सख्त डिकोडर्स को माफ किया जा सकता है: पैडिंग में जानकारी होती है (आपका इनपुट तीन मामलों की किस शाखा में आया), लेकिन उस जानकारी की गणना अकेले लंबाई से की जा सकती है।
Base64 एनकोडर और डिकोडर पैडेड आउटपुट तुरंत दिखाता है ताकि आप डिकोड किए गए बाइट्स की तुलना मूल टेक्स्ट से कर सकें और सत्यापित कर सकें कि राउंड ट्रिप काम कर रही है। Base64 और संबंधित एन्कोडिंग बिट्स को विभिन्न वर्ण चौड़ाई में पुन: समूहित करने के सिद्धांत का विस्तार करते हैं। RFC 4648 तीनों को निर्दिष्ट करता है, और एक को समझना दूसरों को अवधारणात्मक रूप से सरल बनाता है। मुख्य अंतर्दृष्टि यह है कि एन्कोडिंग शुद्ध बिट हेरफेर है: अपना वर्णमाला आकार चुनें, अपने बिट्स को तदनुसार समूहित करें, प्रत्येक समूह को एक तालिका में देखें।
टेकअवे: पैडिंग व्युत्पन्न है, इसलिए एक गायब = ठीक करने योग्य है - कैसे Base64 एनकोडर और डिकोडर आपको एन्कोड किए गए किसी भी टेक्स्ट का पैडेड कैनोनिकल फॉर्म दिखाता है
डिकोडिंग रिवर्स: प्रत्येक अक्षर को देखें, बिट्स निकालें, उन्हें पुनः समूहित करें, बाइट्स लिखें। यह नियतात्मक दो-तरफा मैपिंग है जिसके कारण Base64 सभी प्लेटफार्मों और भाषाओं में विश्वसनीय रूप से काम करता है। एन्कोडिंग और डिकोडिंग में त्रुटियां अक्सर गलतफहमी पैडिंग या वर्णमाला अंतर का पता लगाती हैं। यदि डिकोड पैडिंग त्रुटियों के साथ विफल हो जाता है, तो जांचें कि क्या डिकोडर कैनोनिकल Base64 (कड़ाई से पैडेड) की अपेक्षा करता है या वेरिएंट स्वीकार करता है। यदि यह वर्ण त्रुटियों के साथ विफल रहता है, तो जांचें कि क्या इनपुट Base64url है और डिकोडर मानक Base64 की अपेक्षा करता है।
Base64 एनकोडर और डिकोडर दोनों अक्षरों को स्वीकार करता है और पैडिंग को लगातार मान्य करता है, इसलिए किसी भी हाथ से गणना किए गए उदाहरण को तुरंत सत्यापित किया जा सकता है। एन्कोडिंग को वापस डिकोड करके उसका परीक्षण करना गलतियों को पकड़ने का सबसे अच्छा तरीका है, इससे पहले कि वे उत्पादन में समस्याएँ पैदा करें।