Base128 का उपयोग क्यों नहीं किया जाता है? [बन्द है]


90

वेब पर द्विआधारी डेटा प्रसारित करने के लिए उपयोग किए जाने वाले बेस128 के बजाय केवल आधार 64 क्यों है? ASCII वर्ण सेट में 128 वर्ण हैं जो सिद्धांत रूप में आधार 128 का प्रतिनिधित्व कर सकते हैं, लेकिन अधिकांश मामलों में केवल base64 नहीं बल्कि base128 का उपयोग किया जाता है।


60
क्यों नहीं आधार 256?
गुमबो

22
मुझे लगता है कि इस बिंदु पर मुद्रण योग्य वर्ण हैं (हालांकि 64 से अधिक भी हैं ...)
फेलिक्स क्लिंग

29
मुझे लगता है कि कुछ समय पहले बेस 128 हमसे संबंधित हो गया था। गार्ड बेस 64 को सौंपी गई टीम अभी भी बाहर है।
रिच मेल्टन

5
यह प्रश्न विशिष्ट क्यों है? यह वेब में उपयोग की जाने वाली अधिकांश अन्य भाषाओं के लिए भी सही है, है ना?
बेनेडिक्ट वाल्डवोगेल

5
@KenRockot: मैं देख रहा हूँ कि आप पहचानते हैं कि आपके कुछ 15-बिट चार्ट 3 बाइट्स में एन्कोड हो जाएंगे। आपके बेस -2048 एन्कोडिंग का अर्थ है 11 बाइट्स को 2 बाइट्स में पैक करना, जो प्रति बाइट्स में 5.5 बिट्स बनाता है - बेस -64 से आधे से थोड़ा कम।
मातरिनस

जवाबों:


105

समस्या यह है कि ASCII वर्ण सेट के कम से कम 32 अक्षर 'नियंत्रण वर्ण' हैं, जिन्हें प्राप्त टर्मिनल द्वारा व्याख्या किया जा सकता है। उदाहरण के लिए, बीईएल (घंटी) वर्ण है जो प्राप्त टर्मिनल झंकार बनाता है। एसओटी (ट्रांसमिशन की शुरुआत) और ईओटी (ट्रांसमिशन का अंत) अक्षर हैं जो वास्तव में उनके नाम का प्रदर्शन करता है। और सीआर और एलएफ के पात्रों को मत भूलना, जिनके विशेष अर्थ हो सकते हैं कि कैसे डेटा संरचनाओं को धारावाहिक रूप में / चपटा किया जाता है।

Adobe ने AS85II वर्ण सेट में अधिक वर्णों का उपयोग करने के लिए Base85 एन्कोडिंग बनाया , लेकिन AFAIK यह पेटेंट द्वारा संरक्षित है।


7
Base91 एक अच्छे ओपन सोर्स विकल्प की तरह लगता है: Base91.sourceforge.net
Jorge

2
यह विचार करने योग्य है कि 2 की शक्ति बाइट डेटा को अधिक आसानी से फिट करती है, और एन्कोडिंग सरल है। फिर पोर्टेबिलिटी है; हर भाषा में एक बेस 64 एनकोड और / या एक बेस 64 डीकोड होता है।
Lodewijk

5
पुन Base85 और एडोब : इस सवाल का जवाब और अधिक उपयोगी अगर यह पेटेंट संख्या और साल दी उद्धृत किया जा सकता है। अगर पेटेंट एक समस्या है btoa, तो 1990 से जो तारीखें हैं, वे पेटेंट द्वारा अनसुनी हैं, और वे निश्चित रूप से वैसे भी समाप्त हो जाएंगे।
एजी

65

क्योंकि उन 128 वर्णों में से कुछ अनपेक्षित हैं (मुख्यतः वे जो कोडपॉइंट 0x20 से नीचे हैं)। इसलिए, वे मज़बूती से तार पर एक स्ट्रिंग के रूप में प्रेषित नहीं किए जा सकते हैं। और, यदि आप कोडपॉइंट 128 से ऊपर जाते हैं, तो सिस्टम में उपयोग किए गए विभिन्न एन्कोडिंग के कारण आपके पास एन्कोडिंग समस्या हो सकती है।


8
बेस 94 जीथुब में यहां मौजूद है, यह सभी 94 मुद्रण योग्य ASCII वर्णों का उपयोग करता है: gist.github.com/iso2022jp/4054241
intrepidis

15

जैसा कि पहले से ही अन्य उत्तरों में कहा गया है, मुख्य बिंदु मुद्रण योग्य लोगों के लिए निर्धारित चरित्र को कम करना है। एक अधिक कुशल एन्कोडिंग योजना basE91 है क्योंकि यह एक बड़े वर्ण सेट का उपयोग करती है और अभी भी कम ASCII रेंज में नियंत्रण / व्हाट्सएप पात्रों से बचती है। वेबपेज में बाइनरी बनाम बेस 64 बनाम बेस ई 91 एनकोडिंग दक्षता की अच्छी तुलना है ।

मैंने एक बार जावा कार्यान्वयन को साफ किया था। अगर लोगों की दिलचस्पी है तो मैं इसे GitHub पर आगे बढ़ा सकता हूं।

अद्यतन : यह अब GitHub पर है


मुझे जावा संस्करण में दिलचस्पी होगी
माइकल डियरडफ


12

यह कि पहले 32 वर्ण नियंत्रण वर्ण हैं, इसकी कोई प्रासंगिकता नहीं है, क्योंकि आपको 128 वर्ण प्राप्त करने के लिए इनका उपयोग नहीं करना है। हमारे पास चुनने के लिए 256 वर्ण हैं, और केवल पहले 32 नियंत्रण वर्ण हैं। यह 192 वर्णों को छोड़ देता है, और इसलिए नियंत्रण पात्रों का उपयोग किए बिना 128 पूरी तरह से संभव है।

यहां कारण है: यह कुछ ऐसा होना चाहिए जो समान दिखाई देगा, और यह कि आप कॉपी और पेस्ट कर सकते हैं, चाहे कोई भी जगह हो। इसके लिए ऐसे वर्ण होना चाहिए जो किसी भी मंच, चैट, ईमेल और इसी तरह प्रदर्शित होंगे। इसका मतलब है कि हम वर्णों का उपयोग नहीं कर सकते हैं, कि एक मंच / चैट / ईमेल क्लाइंट आमतौर पर स्वरूपण या उपेक्षा के लिए उपयोग कर सकते हैं। इसमें फ़ॉन्ट, भाषा और क्षेत्रीय सेटिंग्स की परवाह किए बिना वर्ण समान होने चाहिए।

यह कारण है!


7
नियंत्रण वर्ण प्रासंगिक हैं क्योंकि बहुत अधिक हर कोई आपकी बात पहले से ही मान रहा था कि यह कोडपेज / एन्कोडिंग जितना संभव हो सके तटस्थ होना चाहिए। यह आवश्यक रूप से आपको केवल (7-बिट) ASCII के लिए प्रतिबंधित करता है जो कि अधिकांश प्रासंगिक एन्कोडिंग्स का सबसेट है। इसके अलावा सभी इंटरनेट 8-बिट साफ नहीं है, और इसका अधिकांश भाग ASCII है। आपकी बात हालांकि बनाने लायक है।
टिम सेग्विन

7
बस जोड़ने के लिए: ASCII केवल 128 वर्णों को परिभाषित करता है। ASCII में वर्ण # 128 से # 255 परिभाषित नहीं हैं । चूंकि प्रश्न स्पष्ट रूप से एएससीआईआई का संदर्भ देता है और "कोई 8-बिट एन्कोडिंग" नहीं है, इसलिए सभी उत्तर एएससीआईआई सेट के 128 वर्णों तक खुद को सीमित करते हैं।
पेपोलुआन

एक उदाहरण के रूप में सबसे आम UTF-8 एन्कोडिंग का उपयोग करना: 128 से 196 पर बाइट्स तुरंत UTF8 डिकोडिंग त्रुटियों में परिणाम होगा; 196 से 256 पर बाइट्स का अर्थ यह होगा कि अगली बाइट भी उसी वर्ण की है, लेकिन तब यदि अगली बाइट 128 से नीचे है, तो यह फिर से UTF8 डिकोडिंग त्रुटियों का परिणाम होगा। हालाँकि, लगभग सभी चरित्र-एन्कोडिंग-संवेदनशील भाषाओं में बेस 64 लाइब्रेरी बेस 64 स्ट्रिंग्स को UTF8- सुरक्षित स्ट्रिंग्स के रूप में लेना होगा। आधार को128 के साथ नहीं किया जा सकता क्योंकि इसे UTF8- सुरक्षित स्ट्रिंग के रूप में एन्कोड नहीं किया जा सकता है।
SOFe

10

बेस 64 आम है क्योंकि यह विभिन्न मुद्दों को हल करता है (लगभग हर जगह काम करता है जिसके बारे में आप सोच सकते हैं)

  • आपको यह चिंता करने की आवश्यकता नहीं है कि परिवहन 8-बिट साफ है या नहीं।

  • एन्कोडिंग के सभी वर्ण मुद्रण योग्य हैं। आप उन्हें देख सकते हैं । आप उन्हें कॉपी और पेस्ट कर सकते हैं। आप उन्हें URL (विशेष प्रकार के) में उपयोग कर सकते हैं। आदि।

  • फिक्स्ड एन्कोडिंग आकार। आप जानते हैं कि mबाइट्स हमेशा बाइट्स को एनकोड कर सकते हैं n

  • हर किसी ने इसके बारे में सुना है - यह व्यापक रूप से समर्थित है, बहुत सारे पुस्तकालय, इसके साथ हस्तक्षेप करना आसान है।

Base128 में वे सभी फायदे नहीं हैं।

ऐसा लगता है कि यह 8-बिट साफ है - लेकिन याद रखें कि base64 65 प्रतीकों का उपयोग करता है। एक आउट-ऑफ-बैंड चरित्र के बिना आपको निश्चित एन्कोडिंग आकार के लाभ नहीं हो सकते। यदि आप एक आउट-ऑफ-बैंड कैरेक्टर का उपयोग करते हैं, तो आप 8-बिट क्लीन नहीं कर सकते हैं।

हालांकि यह सब नकारात्मक नहीं है।

  • base128 को base64 की तुलना में एनकोड / डिकोड करना ज्यादा आसान है - आप सिर्फ शिफ्ट और मास्क का उपयोग करते हैं। एम्बेडेड कार्यान्वयन के लिए महत्वपूर्ण हो सकता है

  • base128 उपलब्ध बिट्स के अधिक उपयोग से base64 की तुलना में परिवहन का थोड़ा अधिक कुशल उपयोग करता है।

लोग आधार का उपयोग करते हैं - मैं अभी कुछ के लिए इसका उपयोग कर रहा हूं। यह सिर्फ आम नहीं है।


यह भी याद रखें कि मेल / समाचार प्रणाली और उनके ilk (और XML भी) हमेशा पहले 32 कोडपॉइंट्स के लिए दयालु नहीं होते हैं (उदाहरण के लिए CR LF बनाम LF पर विचार करें), लेकिन अन्यथा आपका उत्तर बहुत अच्छा लगता है।
सैमब

"वह बेस 64 65 प्रतीकों का उपयोग करता है।" => टाइपो या मुझे कुछ याद आया?
किकिवा

@Kikiwa, विकिपीडिया पर इस जावा के नमूने को देखेंCODESचर की लंबाई की जाँच करें ।
जॉन ला रोय

अरे हाँ, पैडिंग कैरेक्टर '=' केवल एन्कोडिंग पेलोड के अंत में, आप सही हैं, धन्यवाद।
किकिवा

4

निश्चित नहीं है, लेकिन मुझे लगता है कि निचले मान (नियंत्रण कोड या कुछ का प्रतिनिधित्व करते हुए) मज़बूती से एचटीटीपी / अनुरोध / प्रतिक्रियाओं के अंदर पाठ / पात्रों के रूप में हस्तांतरित नहीं किए जाते हैं, और 127 से ऊपर के मान स्थानीय / कोडपेज / जो कुछ भी विशिष्ट हो सकते हैं, इसलिए नहीं हैं 128 विभिन्न वर्ण जिन्हें सभी ब्राउज़रों / प्लेटफार्मों पर काम करने की उम्मीद की जा सकती है।


3

esaji सही है। Base64 का उपयोग एक प्रोटोकॉल का उपयोग करके ट्रांसमिशन के लिए द्विआधारी डेटा को एनकोड करने के लिए किया जाता है जो केवल पाठ की अपेक्षा करता है। यह विकी एंट्री में सही है ।


2

Base128 PHP-Class चेकआउट करें। आईएसओ 8859-1 चारसेट के साथ एन्कोडिंग और डिकोडिंग।

GoogleCode PHP-Class Base128


1
काश इसके बजाय utf-8 का इस्तेमाल किया जाता ...
Janus Troelsen

1
बेस एन्कोडिंग का अंतर्निहित डेटा से कोई लेना-देना नहीं है। आप अपने टेक्स्ट / डेटा को एनकोड करने की इच्छा रखने वाले किसी भी टेक्स्ट एन्कोडिंग का उपयोग कर सकते हैं। उसका मतलब है कि बेस ## इंडेक्स टेबल अनुवाद के रूप में ISO 8859-1 ASCII चारसेट का उपयोग करता है।
चाड

1
पाठ में आधार-एनकोडेड बाइनरी डेटा को एम्बेड करने का प्रयास करते ही इसका अंतर्निहित डेटा के साथ कुछ करना है । यदि वह पाठ किसी अन्य एन्कोडिंग में एन्कोडेड है, तो आपको समस्याएँ होंगी।
स्टिजन डे विट

"ISO 8859-1 ASCII" वर्ण सेट जैसी कोई चीज़ नहीं है। कार्यक्रम 128 विभिन्न मुद्रण योग्य आईएसओ 8859-1 वर्णों का उपयोग करके डेटा को एन्कोड करता है। यह किसी भी तरह से, आकार या रूप में ASCII का उपयोग नहीं करता है
निस्से इंगस्ट्रम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.