डेवलपर टूल · Base64 एनकोडर और डिकोडर
एटोब और बीटीओए का क्या अर्थ है, और वे केवल लैटिन ही क्यों समझते हैं-1
· पेजभूमि
Base64 जावास्क्रिप्ट यूनिकोड
नेटस्केप से एटीओबी और बीटीओए दिनांक और नामों का अर्थ है 'ASCII से बाइनरी' और 'बाइनरी से ASCII'। इस पोस्ट में बताया गया है कि वे कहां से आए, WHATWG मानक उन्हें कैसे परिभाषित करते हैं, और उन्होंने कभी यूनिकोड क्यों नहीं सीखा।
एक फ़ंक्शन नाम जो टाइपो की तरह पढ़ता है - नामों के कारण होने वाला भ्रम और एक-पंक्ति वाला उत्तर
एटोब और बीटीओए JavaScript अंतर्निहित फ़ंक्शन हैं जिन्हें 1990 के दशक में नेटस्केप में पेश किया गया था। नाम संक्षिप्त हैं: btoa का अर्थ बाइनरी से ASCII है और atob का अर्थ ASCII से बाइनरी है। नाम उनकी उम्र और डिज़ाइन को दर्शाते हैं: वे तब बनाए गए थे जब बाइनरी का मतलब अधिक आधुनिक Uint8Array या बफर के बजाय बाइट मानों की एक स्ट्रिंग (0-255) था। नामों के लिए अक्सर दिया जाने वाला स्मरणीय अवलोकन योग्य अनुबंध से कम महत्वपूर्ण होता है: एक फ़ंक्शन बाइनरी स्ट्रिंग को Base64 पर मैप करता है और दूसरा इसे उलट देता है। यह भंडार मूल नामकरण निर्णय का दस्तावेजीकरण नहीं करता है, इसलिए लेख लोककथाओं को स्रोत ब्राउज़र इतिहास के रूप में प्रस्तुत करने से बचता है।
फ़ंक्शंस एक बाइनरी स्ट्रिंग की अपेक्षा करते हैं: प्रत्येक वर्ण की कोड इकाई एक बाइट का प्रतिनिधित्व करते हुए 0-255 की सीमा में होनी चाहिए। यदि आप 255 (जैसे इमोजी या लैटिन के बाहर से एक उच्चारण अक्षर-1) के ऊपर एक कोड इकाई के साथ एक वर्ण पास करते हैं, तो फ़ंक्शन अमान्यCharacterError फेंकता है या चुपचाप गलत आउटपुट उत्पन्न करता है। btoa (बाइनरी से ASCII) एक बाइनरी स्ट्रिंग को Base64 पर एन्कोड करता है।
नाम क्या सुझाते हैं और बाइट-स्ट्रिंग अनुबंध वास्तव में क्या साबित करता है
इनपुट एक स्ट्रिंग होना चाहिए जहां प्रत्येक वर्ण एक बाइट है (कोड इकाई 0-255)। btoa(hello) ASCII बाइट्स को Base64 के रूप में एन्कोड करता है और aGVsbG8= लौटाता है। e-acute अक्षर वाला btoa काम करता प्रतीत होता है क्योंकि पूर्वनिर्मित लैटिन-1 अक्षर e-acute (U+00E9) में 233 की एक कोड इकाई है, जो 0-255 के भीतर है। हालाँकि, btoa इसे एक बाइट, 0xE9 के रूप में एनकोड करता है, न कि UTF-8 बाइट्स 0xC3 0xA9 के रूप में जिसे e-acute को उत्पादित करना चाहिए। टाइप किए गए ऐरे के सामान्य बाइट कंटेनर बनने से पहले, JavaScript APआई स्ट्रिंग्स का उपयोग करते थे जिनकी कोड इकाइयाँ बाइट्स के लिए होती थीं। वह मॉडल दृश्यमान रहता है क्योंकि btoa 255 से ऊपर की कोड इकाइयों को अस्वीकार कर देता है। इन फ़ाइलों द्वारा सटीक उत्पाद कालक्रम स्थापित नहीं किया गया है; विफलता सीमा निष्पादन योग्य परीक्षणों द्वारा स्थापित की जाती है।
यह मौन भ्रष्टाचार किसी त्रुटि से भी अधिक खतरनाक है: परिणाम तो ठीक दिखता है लेकिन गलत होता है। एटोब (ASCII से बाइनरी) Base64 को वापस बाइनरी स्ट्रिंग में डिकोड करता है। atob(aGVsbG8=) नमस्ते लौटाता है। आउटपुट एक बाइनरी स्ट्रिंग है जहां प्रत्येक वर्ण की कोड इकाई 0-255 है, जो एक बाइट का प्रतिनिधित्व करती है। यदि आप इसे उचित यूनिकोड टेक्स्ट में परिवर्तित करना चाहते हैं, तो आपको बाइट्स को UTF-8 के रूप में समझना होगा और उन्हें टेक्स्टडिकोडर के साथ डीकोड करना होगा।
लीगेसी बाइनरी-स्ट्रिंग मॉडल - असत्यापित ब्राउज़र-इतिहास दावे के बिना देखने योग्य व्यवहार
ASCII के लिए, यह अतिरिक्त चरण अनावश्यक है (ASCII UTF-8 का एक उपसमूह है), लेकिन किसी भी गैर-ASCII बाइट्स के लिए, यह आवश्यक है। एटोब वह व्याख्या नहीं करता है; यह कच्चे बाइट्स को बाइनरी स्ट्रिंग के रूप में लौटाता है।
WHATWG मानक (वेब APआई के लिए जीवन स्तर) HTML विनिर्देश में एटीओबी और बीटीओए को परिभाषित करते हैं। परिभाषा में एटोब के लिए एक क्षमा-Base64 डिकोड एल्गोरिदम शामिल है: यह व्हाइटस्पेस को छोड़ देता है और लापता पैडिंग को स्वीकार करता है, जिससे वास्तविक दुनिया Base64 (लाइन ब्रेक के साथ MIME-लिपटे Base64 सहित) को डिकोड करने योग्य बनाता है। ToolAcre ब्राउज़र डिकोडर को कॉल करने से पहले व्हाइटस्पेस, URL-सुरक्षित विराम चिह्न और गायब पैडिंग को सामान्य करता है। इसके बाद यह लौटाई गई कोड इकाइयों को Uint8Array में कॉपी करता है और एक घातक UTF-8 डिकोडर लागू करता है। वह संयोजन क्षमाशील Base64 सिंटैक्स को सख्त पाठ व्याख्या से अलग करता है।
इस कार्यान्वयन में वर्तमान व्यवहार - क्षमाशील वर्णमाला सामान्यीकरण और सख्त UTF-8 टेक्स्ट डिकोडिंग
फ़ंक्शन हस्ताक्षर नहीं बदला है, लेकिन मानक परिभाषा फ़ंक्शन क्या करता है इसके लिए प्राधिकारी है। एटोब और बीटीओए केवल लैटिन-1 को ही क्यों स्वीकार करते हैं? क्योंकि जब उन्हें 1990 के दशक में डिज़ाइन किया गया था, तो JavaScript के पास सीधे बाइट्स का प्रतिनिधित्व करने का कोई तरीका नहीं था (कोई Uint8Array या ArrayBuffer नहीं)। किसी फ़ंक्शन में बाइट्स पास करने का एकमात्र तरीका एक स्ट्रिंग के रूप में था जहां प्रत्येक वर्ण एक बाइट का प्रतिनिधित्व करता है।
इसे बाइनरी स्ट्रिंग कहा जाता है और आधुनिक मानकों के अनुसार यह भ्रमित करने वाला है। JavaScript स्ट्रिंग यूनिकोड टेक्स्ट है, बाइट्स का अनुक्रम नहीं। डिज़ाइन ने दोनों को मिला दिया: एक स्ट्रिंग जहां प्रत्येक कोड इकाई 0-255 है, एक बाइनरी स्ट्रिंग है। नामकरण युग को दर्शाता है: btoa में ASCII का शाब्दिक अर्थ ASCII पाठ के लिए सात बिट्स है, लेकिन कार्यान्वयन किसी भी बाइट (0-255) को स्वीकार करता है। यूनिकोड मोड को सीधे बीटीओए में जोड़ने से इसके लंबे समय से चले आ रहे बाइट-स्ट्रिंग अनुबंध और जोखिम अनुकूलता में बदलाव आएगा। इसके बजाय समीक्षा किया गया स्रोत एन्कोडिंग से पहले TextEncoder बनाता है। यह आलेख उस रचना को सत्यापित कर सकता है; यह भंडार में दर्ज नहीं किए गए मानक-समिति के उद्देश्यों के बारे में दावों को छोड़ देता है।
काम किया गया उदाहरण: रिक्त स्थान और लापता पैडिंग के साथ एक स्ट्रिंग पर क्षमा-Base64 का पता लगाना - एटीओबी क्या स्वीकार करता है जिसे एक सख्त डिकोडर अस्वीकार करता है
आधुनिक विकल्प बाइनरी स्ट्रिंग मॉडल से बचते हैं। एन्कोडिंग API टेक्स्ट को UTF-8 बाइट्स में बदलने के लिए TextEncoder प्रदान करता है, और UTF-8 बाइट्स को वापस टेक्स्ट में बदलने के लिए TextDecoder प्रदान करता है।
Base64 एन्कोडिंग और डिकोडिंग अब दोनों स्ट्रिंग्स (एटीओबी और बीटीओए) और टाइप किए गए एरे के लिए HTML स्पेक में निर्दिष्ट है। Base64 एनकोडर और डिकोडर टूल एटोब और बीटीओए के आसपास टेक्स्टएनकोडर और टेक्स्टडिकोडर का उपयोग करता है, ताकि आप लैटिन-1 सीमाओं के बिना यूनिकोड टेक्स्ट को सुरक्षित रूप से एनकोड और डीकोड कर सकें। एक स्पेस या अनपैडेड मान सफल होता है क्योंकि सामान्यीकरण व्हाइटस्पेस को हटा देता है और आवश्यक ब्लॉक लंबाई को पुनर्स्थापित करता है। वह मान जिसकी साफ़ लंबाई में एक शेष बचता है, एटोब से पहले अस्वीकार कर दिया जाता है। यह अंतर दिखाता है कि यहां "क्षमा करना" का क्या अर्थ है: पुनर्प्राप्ति योग्य स्वरूपण स्वीकार किया जाता है, संरचनात्मक रूप से असंभव इनपुट नहीं।
नए मानक टाइप किए गए सरणियों के लिए Base64 पर काम करते हैं - गुणात्मक रूप से वर्णित, वर्तमान ब्राउज़र समर्थन की जांच करने के लिए एक नोट के साथ
यूनिकोड को btoa के साथ संभालने के लिए पहले टेक्स्ट को UTF-8 बाइट्स में एन्कोड करने की आवश्यकता होती है। पुराना समाधान btoa(unescape(encodeURIComponent(text))) था, जो भ्रमित करने वाला है लेकिन काम करता है: encodeURIComponent प्रतिशत-एनकोड UTF-8 बाइट्स, unescape ट्रिपलेट्स को वापस वर्णों में परिवर्तित करता है, और btoa परिणामी बाइनरी स्ट्रिंग को एनकोड करता है। यह काम करता है लेकिन अप्रचलित कार्यों पर निर्भर करता है और इसे पढ़ना कठिन है। आधुनिक कोड को TextEncoder(text).map(byte => String.fromCharCode(byte)) के बाद btoa का उपयोग करना चाहिए, या बेहतर होगा, सीधे Uint8Array में कन्वर्ट करें और एन्कोडिंग API का उपयोग करें।
एटोब आपको स्वचालित रूप से टेक्स्ट नहीं देता है; यह आपको बाइनरी देता है। atob(Y2Fmw6kg8J+YgA==) एक बाइनरी स्ट्रिंग लौटाता है जिसमें कैफ-एक्सेंट और इमोजी के साथ UTF-8-एन्कोडेड टेक्स्ट के बाइट्स होते हैं। टेक्स्ट को पुनर्प्राप्त करने के लिए, बाइनरी स्ट्रिंग को Uint8Array में बदलें और इसे TextDecoder(utf-8) पर पास करें। Base64 एनकोडर और डिकोडर टूल यह स्वचालित रूप से करता है: आप टेक्स्ट पेस्ट करते हैं, यह उसे UTF-8 बाइट्स में एनकोड करता है, फिर Base64 में। टाइप-एरे Base64 APआई सभी ब्राउज़रों में विकसित हो रहे हैं, लेकिन यह स्रोत उनका उपयोग नहीं करता है। किCAक के आधार पर वर्तमान संगतता जांच और फ़ॉलबैक योजना की आवश्यकता होती है। ToolAcre का स्पष्ट बाइट-सरणी रूपांतरण निरीक्षण योग्य रहता है और इसके वर्तमान परीक्षण सूट द्वारा कवर किया जाता है।
टाइप-एरे विकल्प विकसित हो रहे हैं - उन पर निर्भर होने से पहले वर्तमान ब्राउज़र समर्थन को सत्यापित करें
आप Base64 पेस्ट करते हैं, यह UTF-8 बाइट्स में डिकोड होता है, फिर टेक्स्ट में। मध्यवर्ती बाइनरी-स्ट्रिंग चरण छिपा हुआ है क्योंकि यह 1990 के दशक के API का कार्यान्वयन विवरण है। एटीओबी और बीटीओए को समझना विरासत कोड को डीबग करने या पुराने APआई के साथ काम करने के लिए उपयोगी है जो आपको बाइनरी स्ट्रिंग प्रदान करते हैं। अधिकांश नए कोड को बाइनरी स्ट्रिंग मॉडल से पूरी तरह बचना चाहिए।
यदि आपको Base64 को एनकोड या डीकोड करने की आवश्यकता है, तो Base64 एनकोडर और डिकोडर टूल यूनिकोड को सही ढंग से संभालता है। यदि आप API का निर्माण कर रहे हैं, तो Uint8Array या टाइप किए गए ऐरे दृश्य को स्वीकार करें, या स्पष्ट रूप से दस्तावेज़ करें कि आपका आधार 64 UTF-8 है या लैटिन-1 है। TextEncoder के बिना गैर-ASCII टेक्स्ट के साथ btoa का उपयोग करने वाले कोड की समीक्षा करते समय, यह एक बग है: आउटपुट गलत बाइट्स को एन्कोड करता है। नोड बफ़र और गैर-ब्राउज़र रनटाइम अलग-अलग APआई और स्वीकृति नियमों को परिभाषित करते हैं। उन्हें जानबूझकर बाहर रखा गया है. इस आलेख में दावे ब्राउज़र प्रिमिटिव और ऐप्स/dev, में कार्यान्वित रैपर से संबंधित हैं, न कि प्रत्येक वातावरण में एटोब या बीटीओए नामक प्रत्येक फ़ंक्शन से।
टेकअवे: बाइट-स्ट्रिंग अनुबंध के साथ 1990 के दशक के दो कार्य - कैसे Base64 एनकोडर और डिकोडर UTF-8 को उनके चारों ओर ले जाता है, इसलिए उच्चारण, CJK और इमोजी राउंड-ट्रिप
एटोब और बीटीओए नाम 1990 के दशक की कंप्यूटिंग की अनोखी कलाकृतियाँ हैं। आधुनिक नामकरण Base64एनकोड और Base64डीकोड होगा, और APआई स्पष्ट एन्कोडिंग घोषणाओं के साथ Uint8Array या स्ट्रिंग्स को स्वीकार करेंगे। लेकिन एटीओबी और बीटीओए बैकवर्ड संगतता के लिए ब्राउज़र में बने रहते हैं। यह समझना कि उनका क्या मतलब है (और वे क्या नहीं कर सकते हैं) आपको यूनिकोड टेक्स्ट को एन्कोड करते समय मौन भ्रष्टाचार से बचने में मदद करता है।
Base64 एनकोडर और डिकोडर टूल अंतर को पाटता है: यह UTF-8 और Base64 भाषाएं बोलता है जिनकी आधुनिक कोड को आवश्यकता होती है। मजबूत पैटर्न रचनात्मक है: टेक्स्ट को UTF-8 बाइट्स में एन्कोड करें, बाइट्स को बाइनरी-स्ट्रिंग कॉन्ट्रैक्ट में बदलें, फिर btoa को कॉल करें; एटोब के चारों ओर उन चरणों को उलट दें। एक उच्चारण, CJK अक्षर और इमोजी आज़माएं, फिर प्रत्येक मूल कोड बिंदु से मेल खाने के लिए डिकोड किए गए टेक्स्ट की आवश्यकता करें।