डेवलपर टूल · Base64 एनकोडर और डिकोडर
मोजिबेक के बिना Base64 को UTF-8 पर डिकोड करना: एटीओबी प्लस टेक्स्टडिकोडर
· यह काम किस प्रकार करता है
Base64 एन्कोडिंग यूनिकोड
atob() वर्णों के रूप में प्रच्छन्न बाइट्स लौटाता है, यही कारण है कि डिकोडिंग के बाद उच्चारित पाठ टूटा हुआ दिखता है। यह पोस्ट Base64 से बाइट्स से UTF-8 टेक्स्ट तक सही पाइपलाइन दिखाती है, और विफलता पैटर्न को कैसे पहचानें।
API प्रतिक्रिया जो 'कैफ़े' को डिकोड करती है - एक ठोस मोजिबेक लक्षण और दो गलत वर्णों के पीछे दो बाइट्स
एक Base64 स्ट्रिंग Q2Fmw6k= बाइट्स (67, 97, 102, 195, 169) को डिकोड करती है, जो UTF-8 टेक्स्ट कैफे हैं। अनुभवहीन डिकोडर में पेस्ट करें (केवल एटोब और स्ट्रिंग रूपांतरण) और आउटपुट अक्सर कैफ़े होता है, प्रत्येक उच्चारण को दो गलत वर्णों से बदल दिया जाता है। यह मोजिबेक इसलिए होता है क्योंकि atob बाइट्स की स्ट्रिंग लौटाता है (कोड इकाइयां 0–255), न कि UTF-8 टेक्स्ट। बाइट्स 195 और 169 उच्चारण é को UTF-8 में एन्कोड करते हैं।
उन्हें अलग-अलग लैटिन-1 वर्णों के रूप में मानने से मोजिबेक पैटर्न मिलता है। सही पाइपलाइन एटोब है (बाइट्स को स्ट्रिंग के रूप में), फिर टेक्स्टडिकोडर (बाइट्स को UTF-8 के रूप में समझें), और मूल टेक्स्ट वापस आता है। एटोब फ़ंक्शन टूटा नहीं है; यह बाइनरी डेटा के लिए डिज़ाइन किया गया है। इसका नाम ASCII-टू-बाइनरी से आता है, और इसके द्वारा निर्मित बाइनरी स्ट्रिंग कोड इकाइयों 0–255 का अनुक्रम है, प्रत्येक एक बाइट का प्रतिनिधित्व करता है।
atob() वास्तव में क्या लौटाता है - कोड इकाइयों की एक स्ट्रिंग 0–255 जो बाइट्स के लिए है, डिकोड किए गए टेक्स्ट के लिए नहीं
यदि आप इसे Q2Fmw6k= (मानक Base64) खिलाते हैं, तो यह स्ट्रिंग आउटपुट करता है जहां प्रत्येक वर्ण एक बाइट होता है: कोड इकाई 67, फिर 97, फिर 102, फिर 195, फिर 169। यदि उस स्ट्रिंग को सीधे प्रदर्शित करें या लैटिन-1 टेक्स्ट के रूप में व्याख्या करें, तो आपको विकृत आउटपुट दिखाई देगा। गायब चरण कोड इकाइयों को बाइट सरणी में परिवर्तित करना और फिर सरणी को UTF-8 के रूप में डिकोड करना है।
charCodeAt लूप बाइट मान पुनर्प्राप्त करता है: atob आउटपुट में प्रत्येक वर्ण के लिए, कोड यूनिट (नंबर 0–255) प्राप्त करने के लिए charCodeAt को कॉल करें, Uint8Array में स्टोर करें। एक बार बाइट्स की सरणी मौजूद हो जाने पर, charset utf-8 के साथ TextDecoder को पास करें। टेक्स्टडिकोडर बाइट अनुक्रम को पढ़ता है और UTF-8 टेक्स्ट के रूप में व्याख्या करता है, (195, 169) जैसे बाइट अनुक्रमों को é जैसे एकल वर्णों में संयोजित करता है। बाइट्स (67, 97, 102, 195, 169) चार-अक्षर स्ट्रिंग कैफे बन जाते हैं। लूप जानबूझकर उबाऊ है: प्रत्येक लौटाई गई कोड इकाई को charCodeAt के साथ पढ़ें और इसे मिलान Uint8Array स्थिति में असाइन करें। वहां कोई चरित्र-निर्धारण निर्णय नहीं होता. एकमात्र व्याख्या तब आती है जब टेक्स्टडिकोडर उस सरणी को प्राप्त करता है और घातक त्रुटि प्रबंधन के साथ UTF-8 लागू करता है।
उस स्ट्रिंग को Uint8Array में बदलना - charCodeAt लूप और यह एक बाइट कॉपी क्यों है, रूपांतरण नहीं
यह दो-चरणीय प्रक्रिया - बाइट पुनर्प्राप्ति, फिर UTF-8 व्याख्या - वही है जो Base64 एनकोडर और डिकोडर आंतरिक रूप से करता है। मोजिबेक पैटर्न इस त्रुटि का स्पष्ट संकेत है। यदि कैफ़े कैफ़े के रूप में दिखाई देता है, तो आप UTF-8 बाइट्स की लैटिन-1 व्याख्या देख रहे हैं। é के लिए UTF-8 बाइट्स 0xC3 0xA9 (दशमलव 195, 169) हैं। लैटिन में-1, कोड इकाई 195 Ã है, और कोड इकाई 169 © है।
जब UTF-8 बाइट अनुक्रम को ऐसे पढ़ा जाता है जैसे कि प्रत्येक बाइट अलग लैटिन-1 वर्ण हो, तो प्रत्येक मल्टी-बाइट UTF-8 अनुक्रम गलत प्रतिस्थापन वर्ण उत्पन्न करता है। यदि कैफ़े, कैफ़े के रूप में और उसके बाद प्रतिस्थापन वर्ण, या कैफ़े के रूप में प्रकट होता है? या Caf प्लस U+FFFD, आप भिन्न विफलता देख रहे हैं: डिकोडर ने बाइट अनुक्रम को वैध UTF-8 के रूप में नहीं पहचाना। एक ठोस उदाहरण: Base64 SGVsbG8sIOS4lueVjCEg8J-Zgg== निम्नानुसार डिकोड करता है।
टेक्स्टडिकोडर और वर्णसेट निर्णय - UTF-8 के रूप में डिकोडिंग, और वर्णसेट एक अलग तथ्य क्यों है जिसे आपको अवश्य जानना चाहिए
एटोब बाइट्स के साथ बाइनरी स्ट्रिंग उत्पन्न करता है (72, 101, 108, 108, 111, 44, 32, 228, 184, 180, 149, 140, 33, 32, 240, 159, 152, 130). पहले छह बाइट्स हैं ASCII: हेलो हो जाओ,. बाइट्स 228, 184, 180 तीन-बाइट हैं UTF-8 अनुक्रम का प्रतिनिधित्व करना CJK चरित्र। बाइट्स 149, 140 अगले क्रम का हिस्सा हैं. पूर्ण अनुक्रम में चार-बाइट इमोजी अनुक्रम शामिल है (240, 159, 152, 130) अंतिम चरित्र के लिए।
जब TextDecoder के माध्यम से सही ढंग से संसाधित किया जाता है, तो सभी बाइट्स मूल मिश्रित-स्क्रिप्ट टेक्स्ट का उत्पादन करने के लिए संयोजित होते हैं। UTF-8 बाइट अनुक्रमों की अनुमानित लंबाई होती है: 0xxxxxxx से शुरू होने वाला बाइट एकल-बाइट होता है ASCII; 110xxxxxx से शुरू होने वाली बाइट 10xxxxxx (कुल दो बाइट्स) से शुरू होने वाली निम्नलिखित बाइट की अपेक्षा करती है; 1110xxxx से शुरू होने वाली बाइट निम्नलिखित दो बाइट्स (कुल तीन बाइट्स) की अपेक्षा करती है; 11110xxx से शुरू होने वाली बाइट निम्नलिखित तीन बाइट्स (कुल चार बाइट्स) की अपेक्षा करती है। मिश्रित CJK-और-इमोजी नमूने के लिए, बाइट दृश्य विशेष रूप से नैदानिक है क्योंकि ASCII अंतर्ज्ञान अब मदद नहीं करता है। कई बाइट प्रत्येक दृश्यमान प्रतीक से संबंधित होते हैं, और एक-बाइट हटाने से शेष अनुक्रम अमान्य UTF-8 में बदल जाता है। सख्त डिकोडिंग उस बदलाव को संभावित दिखने वाली क्षति के बजाय नामित विफलता में बदल देती है।
व्यावहारिक उदाहरण: CJK और एक इमोजी युक्त Base64 स्ट्रिंग को डिकोड करना - मूल की तुलना में बाइट्स, कोड बिंदु और अंतिम स्ट्रिंग
1111110x से शुरू होने वाला अनुक्रम UTF-8 में अमान्य है (भविष्य के लिए आरक्षित, उपयोग नहीं किया गया)। 10xxxxxx से प्रारंभ होने वाली बाइट कभी भी लीड बाइट के रूप में प्रदर्शित नहीं होनी चाहिए; यह निरंतरता है. यदि बाइट स्ट्रीम नियमों का उल्लंघन करती है, तो यह मान्य नहीं है UTF-8। चारसेट utf-8 के साथ टेक्स्टडिकोडर इन नियमों के अनुसार सरणी की व्याख्या करता है और वैध अनुक्रमों के लिए सफल होता है। अमान्य के लिए, यह त्रुटि रिपोर्ट करता है।
Base64 एनकोडर और डिकोडर सख्त मोड फ़्लैग ट्रू के साथ टेक्स्टडिकोडर का उपयोग करता है। इसका मतलब है कि अमान्य UTF-8 चुपचाप प्रतिस्थापन वर्ण (U+FFFD) डालने के बजाय त्रुटि उत्पन्न करता है। यदि Base64 स्ट्रिंग उन बाइट्स को डिकोड करती है जो वैध UTF-8 नहीं हैं, तो सख्त मोड विकृत पाठ के साथ जारी रखने के बजाय फेंक देगा। यह डिज़ाइन विकल्प है: बाइनरी पेलोड (चित्र, कुंजियाँ, संपीड़ित डेटा) टेक्स्ट नहीं हैं और उन्हें टेक्स्ट के रूप में डिकोड नहीं किया जाना चाहिए।
पैटर्न को पहचानना: Ã, †और � - एक वर्णसेट समस्या से Base64 समस्या को कैसे बताया जाए
यदि JPEG को Base64 के रूप में डिकोड करने का प्रयास किया जाता है, तो बाइट स्ट्रीम वैध UTF-8 का प्रतिनिधित्व नहीं करेगी, और सख्त डिकोडिंग इसे अस्वीकार कर देगी। टूल ऐसे पेलोड के लिए हेक्स व्यू प्रदान करता है: आप कच्चे बाइट्स को बिना यह दिखावा किए देख सकते हैं कि वे टेक्स्ट हैं। UTF-8 डिकोड त्रुटियों को पहचानने में संदर्भ में बाइट्स को देखना शामिल है। क्या वे विषम संख्याएँ हैं जहाँ बहु-बाइट अनुक्रम अपेक्षित है?
क्या संभावित अनुक्रम का पहला बाइट अमान्य है (10xxxxxx से प्रारंभ)? क्या निरंतरता बाइट्स गायब हैं? बाइट-आउटपुट बटन जांच में सबसे साफ कांटा प्रदान करता है। यदि हेक्स प्रकट होता है लेकिन टेक्स्ट डिकोडिंग विफल हो जाती है, तो Base64 पार्सिंग सफल हो जाती है और पेलोड या तो बाइनरी है, क्षतिग्रस्त है, या एक अलग वर्णसेट के साथ एन्कोड किया गया है। सही बाइट्स पहले ही सामने आने के बाद Base64 विराम चिह्न को बदलने से वर्णसेट बेमेल को ठीक नहीं किया जा सकता है।
इसमें क्या शामिल नहीं है - UTF-16 पेलोड, बाइनरी आउटपुट जैसे छवियां और अमान्य-बाइट हैंडलिंग
पैटर्न सुसंगत हैं. एक बाइट 0xFF UTF-8 में कभी भी मान्य नहीं है; यह ASCII बाइट नहीं हो सकता (केवल 0–127 ASCII हैं) और लीड बाइट नहीं हो सकता (लीड बाइट 0xC0–0xFD हैं, 0xFF आरक्षित है)। अकेली सरोगेट्स (UTF-16 अवधारणा) UTF-8 में प्रदर्शित नहीं हो सकतीं; यदि बाइट अनुक्रम 0xED 0xA0 0x80 देखें (जो सरोगेट U+D800 को UTF-8 शैली में एन्कोड करता है), तो यह मान्य UTF-8 नहीं है।
एक ऐतिहासिक समाधान btoa(unescape(encodeURIComponent(text))) है। encodeURIComponent कैफ़े को %C3%A9 (प्रतिशत-एन्कोडिंग UTF-8 बाइट्स) में बदल देता है, अनस्केप कोड इकाइयों के रूप में पुन: पैक करता है, btoa कोड इकाइयों को एनकोड करता है। यह अधिकांश पाठों के लिए काम करता है, लेकिन अकेली सरोगेट्स के लिए नाजुक है और पढ़ने में कठिन है। आधुनिक पाइपलाइन—टेक्स्टएनकोडर से बाइट्स, फिर Base64—स्पष्ट और मानक है। TextEncoder सभी आधुनिक ब्राउज़रों और Node.js में बनाया गया है, जो सही विकल्प बनाता है। UTF-16, लीगेसी सिंगल-बाइट एन्कोडिंग और मनमानी फ़ाइल सामग्री के लिए उन बाइट्स या बाइनरी-अवेयर व्यूअर के लिए चयनित डिकोडर की आवश्यकता होती है। ToolAcre जानबूझकर उनमें से अनुमान नहीं लगाता। अनुमान लगाने से एक अमान्य अनुक्रम भ्रामक पाठ में बदल सकता है, जबकि हेक्स डंप प्रत्येक बाइट को बाद में, सूचित व्याख्या के लिए सुरक्षित रखता है।
टेकअवे: Base64 आपको बाइट्स देता है, UTF-8 आपको टेक्स्ट देता है - Base64 एनकोडर और डिकोडर दोनों चरण कैसे करते हैं ताकि डिकोड किया गया टेक्स्ट इनपुट से सटीक रूप से मेल खाए
जब आपके पास Base64 स्ट्रिंग है और आप UTF-8 टेक्स्ट चाहते हैं, तो पूर्ण चरण हैं: Base64 को बाइट्स में डीकोड करें (एटीओबी या Base64-डिकोडिंग लाइब्रेरी का उपयोग करके), बाइट्स से Uint8Array बनाएं, चारसेट utf-8 के साथ टेक्स्टडिकोडर में एरे पास करें, परिणाम को स्ट्रिंग के रूप में पढ़ें।
यदि इनपुट टेक्स्ट के बजाय बाइनरी डेटा है, तो टेक्स्टडिकोडर को छोड़ें और सीधे बाइट्स की जांच करें। Base64 एनकोडर और डिकोडर एक हेक्साडेसिमल बाइट दृश्य प्रदान करता है, उन मानों को संरक्षित करता है जिन्हें सख्त UTF-8 डिकोडिंग अस्वीकार कर देगा। वह कांटा डायग्नोस्टिक है: सफल बाइट्स और असफल टेक्स्ट का मतलब है कि Base64 पार्सिंग ने काम किया है, जबकि पेलोड बाइनरी है, क्षतिग्रस्त है, या एक वर्णसेट के साथ एन्कोड किया गया है जिसका यह टूल अनुमान नहीं लगाता है।