275

विकिपीडिया कहता है

बेस 64 एन्कोडिंग योजनाओं का उपयोग आमतौर पर तब किया जाता है जब द्विआधारी डेटा को एन्कोड करने की आवश्यकता होती है, जिसे मीडिया पर संग्रहीत और स्थानांतरित किया जाना चाहिए जो कि पाठ्य डेटा से निपटने के लिए डिज़ाइन किया गया हो। यह सुनिश्चित करने के लिए है कि परिवहन के दौरान संशोधन के बिना डेटा बरकरार रहे।

लेकिन क्या ऐसा नहीं है कि डेटा को हमेशा बाइनरी में संग्रहीत / प्रेषित किया जाता है क्योंकि हमारी मशीनों में जो मेमोरी होती है वह बाइनरी होती है और यह निर्भर करता है कि आप इसकी व्याख्या कैसे करते हैं? इसलिए, चाहे आप ASCII में या Base64 में बिट पैटर्न 010011010110000101101110को एन्कोड करें, आप अंततः उसी बिट पैटर्न को संग्रहीत करने जा रहे हैं।ManTWFu

यदि अंतिम एन्कोडिंग शून्य और लोगों के संदर्भ में है और हर मशीन और मीडिया उनसे निपट सकते हैं, तो डेटा के ASCII या Base64 के रूप में प्रतिनिधित्व करने से क्या फर्क पड़ता है?

इसका क्या मतलब है "मीडिया जो पाठ्य डेटा से निपटने के लिए डिज़ाइन किया गया है"? वे बाइनरी = से निपट सकते हैं = वे किसी भी चीज़ से निपट सकते हैं।

सभी को धन्यवाद, मुझे लगता है कि मैं अब समझ गया हूं।

जब हम डेटा भेजते हैं, तो हम यह सुनिश्चित नहीं कर सकते हैं कि डेटा की व्याख्या उसी प्रारूप में की जाएगी, जैसा कि हमने किया था। इसलिए, हम कुछ प्रारूप (जैसे आधार 64) में कोड किए गए डेटा को भेजते हैं जो दोनों पक्ष समझते हैं। इस तरह भले ही प्रेषक और रिसीवर समान चीजों की अलग-अलग व्याख्या करते हों, लेकिन क्योंकि वे कोडित प्रारूप पर सहमत होते हैं, इसलिए डेटा को गलत तरीके से व्याख्या नहीं मिलेगी।

से मार्क बायर्स उदाहरण

अगर मुझे भेजना है

Hello
world!

एक तरीका यह है कि इसे एएससीआईआई में भेजा जाए

72 101 108 108 111 10 119 111 114 108 100 33

लेकिन बाइट 10 को दूसरे छोर पर एक नई रेखा के रूप में सही ढंग से व्याख्या नहीं किया जा सकता है। इसलिए, हम ASCII के एक उपसमूह का उपयोग इस तरह से एन्कोड करने के लिए करते हैं

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

सूचना की एक ही राशि के लिए हस्तांतरित किए गए अधिक डेटा की कीमत पर, यह सुनिश्चित करता है कि रिसीवर डेटा को उद्देश्य तरीके से डिकोड कर सकता है, भले ही रिसीवर के बाकी चरित्र सेट के लिए अलग-अलग व्याख्याएं हों।

— Lazer
स्रोत

6

ऐतिहासिक पृष्ठभूमि: ईमेल सर्वर 7-बिट ASCII हुआ करते थे। उनमें से कई उच्च बिट को 0 पर सेट करेंगे, इसलिए आपको केवल 7-बिट मान भेजने होंगे। देख en.wikipedia.org/wiki/Email#Content_encoding

— हेरोल्ड एल

53

हम बेस 64 का उपयोग करते हैं क्योंकि यह पर्ल से अधिक पठनीय है

— मार्टिन

2

@Martin, आप मजाक कर रहे हैं। पर्ल पढ़ना मुश्किल है, लेकिन बेस 64 बिल्कुल भी अपठनीय है।

— पीटर लॉन्ग

1

@ लेज़र आपकी छवि गायब है

— मिक

2

@ लेज़र, "लेकिन बाइट 10 को दूसरे छोर पर एक नई रेखा के रूप में सही ढंग से व्याख्या नहीं किया जा सकता है।" क्यों? दोनों पक्षों ने ASCII पर सहमति व्यक्त की है और उन्हें इसकी सही व्याख्या करनी चाहिए!

— ProgramCpp

298

आपकी पहली गलती सोच रही है कि ASCII एन्कोडिंग और Base64 एन्कोडिंग विनिमेय हैं। वो नहीं हैं। उनका उपयोग विभिन्न उद्देश्यों के लिए किया जाता है।

जब आप ASCII में पाठ को एनकोड करते हैं, तो आप एक टेक्स्ट स्ट्रिंग से शुरू करते हैं और इसे बाइट्स के अनुक्रम में परिवर्तित करते हैं।
जब आप बेस 64 में डेटा एनकोड करते हैं, तो आप बाइट्स के अनुक्रम से शुरू करते हैं और इसे टेक्स्ट स्ट्रिंग में परिवर्तित करते हैं।

यह समझने के लिए कि पहले आधार पर Base64 आवश्यक क्यों था, हमें कंप्यूटिंग के थोड़ा इतिहास की आवश्यकता है।

कंप्यूटर द्विआधारी - 0s और 1s में संवाद करते हैं - लेकिन लोग आमतौर पर पाठ या छवियों जैसे अधिक समृद्ध रूपों के डेटा के साथ संवाद करना चाहते हैं। कंप्यूटर के बीच इस डेटा को स्थानांतरित करने के लिए पहले इसे 0s और 1s में एन्कोड करना होगा, भेजा जाएगा, फिर दोबारा डिकोड किया जाएगा। एक उदाहरण के रूप में पाठ लेने के लिए - इस एन्कोडिंग को करने के कई अलग-अलग तरीके हैं। यह बहुत सरल होगा यदि हम सभी एक ही एन्कोडिंग पर सहमत हो सकते हैं, लेकिन दुख की बात यह है कि ऐसा नहीं है।

मूल रूप से बहुत सारे अलग-अलग एनकोडिंग बनाए गए थे (जैसे बाउडॉट कोड ) जो प्रति वर्ण की एक अलग संख्या का उपयोग करता था जब तक कि अंततः ASCII 7 बिट्स प्रति चरित्र के साथ एक मानक बन गया। हालाँकि अधिकांश कंप्यूटर बाइट्स में बाइनरी डेटा स्टोर करते हैं, जिसमें से प्रत्येक में 8 बिट्स होते हैं ASCII इस प्रकार के डेटा को ट्रांसफर करने के लिए अनुपयुक्त है। कुछ सिस्टम भी सबसे महत्वपूर्ण बिट मिटा देंगे। इसके अलावा पूरे सिस्टम में एन्कोडिंग लाइन में अंतर का मतलब है कि ASCII वर्ण 10 और 13 को भी कभी-कभी संशोधित किया गया था।

इन समस्याओं को हल करने के लिए Base64 एन्कोडिंग पेश की गई थी। यह आपको बाइट्स के लिए एट्रिब्यूट बाइट्स को एनकोड करने की अनुमति देता है, जो दूषित (एएससीआईआई अल्फ़ान्यूमेरिक वर्ण और प्रतीकों के एक जोड़े) के बिना भेजने के लिए सुरक्षित हैं। नुकसान यह है कि बेस 64 का उपयोग करके संदेश को एन्कोडिंग करने से इसकी लंबाई बढ़ जाती है - हर 3 बाइट डेटा को 4 एएससीआईआई अक्षरों में एन्कोड किया गया है।

पाठ को मज़बूती से भेजने के लिए आप पहले अपनी पसंद के टेक्स्ट एन्कोडिंग (उदाहरण के लिए UTF-8) का उपयोग करके बाइट्स को एन्कोड कर सकते हैं और फिर बाद में बेस 64 परिणामी बाइनरी डेटा को एक टेक्स्ट स्ट्रिंग में एनकोड कर सकते हैं जो कि ASCII के रूप में एन्कोडेड भेजने के लिए सुरक्षित है। मूल संदेश को पुनर्प्राप्त करने के लिए रिसीवर को इस प्रक्रिया को उल्टा करना होगा। इस कोर्स के लिए यह आवश्यक है कि रिसीवर जानता है कि किन एन्कोडिंग का उपयोग किया गया था, और इस जानकारी को अक्सर अलग से भेजने की आवश्यकता होती है।

ऐतिहासिक रूप से इसका उपयोग ईमेल संदेशों में द्विआधारी डेटा को एन्कोड करने के लिए किया गया है जहां ईमेल सर्वर लाइन-एंडिंग को संशोधित कर सकता है। एक अधिक आधुनिक उदाहरण सीधे HTML स्रोत कोड में छवि डेटा एम्बेड करने के लिए Base64 एन्कोडिंग का उपयोग है । यहां टैग के रूप में व्याख्या की जा रही '<' और '>' जैसे पात्रों से बचने के लिए डेटा को एनकोड करना आवश्यक है।

यहाँ एक काम कर उदाहरण है:

मैं दो पंक्तियों के साथ एक पाठ संदेश भेजना चाहता हूं:

हैलो
विश्व!

अगर मैं इसे ASCII (या UTF-8) के रूप में भेजता हूं तो यह इस तरह दिखाई देगा:

72 101 108 108 111 10 119 111 114 108 100 33

बाइट 10 कुछ सिस्टम में दूषित है इसलिए हम 64 बाइट्स को बेस 64 स्ट्रिंग के रूप में इनकोडिंग को आधार बना सकते हैं:

SGVsbG8sCndvcmxkIQ ==

जब ASCII का उपयोग कर इनकोडिंग इस तरह दिखता है:

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

यहां सभी बाइट्स सुरक्षित बाइट्स के रूप में जाने जाते हैं, इसलिए बहुत कम संभावना है कि कोई भी सिस्टम इस संदेश को दूषित करेगा। मैं इसे अपने मूल संदेश के बजाय भेज सकता हूं और रिसीवर को मूल संदेश को पुनर्प्राप्त करने के लिए प्रक्रिया को उलटने देता हूं।

— मार्क बायर्स
स्रोत

4

"अधिकांश आधुनिक संचार प्रोटोकॉल भ्रष्ट डेटा नहीं होगा" - हालांकि उदाहरण के लिए, ईमेल एक मेलबॉक्स को संदेश बचाता है, जब एक डिलीवरी एजेंट "\ n> से" के साथ "\ nFrom" वर्णों के स्ट्रिंग की जगह ले सकता है। या HTTP शीर्षलेखों को डेटा में newlines से बचने के लिए कोई प्रतिवर्ती तरीका नहीं बताया गया है (पंक्ति निरंतरता व्हॉट्सएप को बताती है), इसलिए आप मनमाने ढंग से ASCII को उन में डंप नहीं कर सकते। base64 केवल 7-बिट सुरक्षित से बेहतर है , यह अल्फा-न्यूमेरिक-एंड - = + / सुरक्षित है।

— स्टीव जेसोप

1

"नुकसान यह है कि बेस 64 का उपयोग करके संदेश को एन्कोडिंग करने से इसकी लंबाई बढ़ जाती है - हर 3 बाइट डेटा 4 बाइट्स के लिए एन्कोडेड है।" यह 4 बाइट तक कैसे बढ़ता है? यह अभी भी 3 * 8 = 24 बिट नहीं होगा?

— लेज़र

4

@ लेज़र: नहीं। अपने स्वयं के उदाहरण को देखें - "मैन" बेस -64 है जो "TWFu" के रूप में एन्कोडेड है। 3 बाइट्स -> 4 बाइट्स। ऐसा इसलिए है क्योंकि इनपुट को 2 ^ 8 = 256 संभावित बाइट्स में से किसी एक की अनुमति है, जबकि आउटपुट केवल 2 ^ 6 = 64 का उपयोग करता है (और =, डेटा की लंबाई को इंगित करने में मदद करने के लिए)। आउटपुट के चौकड़ी के 8 बिट्स "बर्बाद" होते हैं, ताकि आउटपुट किसी भी "रोमांचक" वर्णों से युक्त हो, भले ही इनपुट करता हो।

— स्टीव जेसोप

2

यह आराम करने में सहायक हो सकता है "जब आप बेस 64 में डेटा एनकोड करते हैं, तो आप बाइट्स के अनुक्रम से शुरू करते हैं और इसे टेक्स्ट स्ट्रिंग में परिवर्तित करते हैं" "जब आप बेस 64 में डेटा एनकोड करते हैं, तो आप बाइट्स के अनुक्रम से शुरू करते हैं और इसे कन्वर्ट करते हैं। बाइट्स के अनुक्रम में केवल ASCII मान शामिल हैं "। केवल ASCII वर्णों से युक्त बाइट्स का एक क्रम SMTP द्वारा आवश्यक है, यही कारण है कि Base64 (और उद्धृत-मुद्रण योग्य) सामग्री-हस्तांतरण-एन्कोडिंग के रूप में उपयोग किया जाता है। बहुत बढ़िया अवलोकन!

— अलेक्सिंटलोस

1

मैं वोट करूंगा, लेकिन 64 वोट हैं। क्षमा करें, यह सही है।

— जेसी कैटरिनक

61

XML में बाइनरी डेटा एनकोडिंग

मान लीजिए आप एक XML दस्तावेज़ के भीतर कुछ छवियों को एम्बेड करना चाहते हैं। छवियाँ बाइनरी डेटा हैं, जबकि XML दस्तावेज़ पाठ है। लेकिन XML एम्बेडेड बाइनरी डेटा को संभाल नहीं सकता है। तो आप इसे कैसे करते हैं?

एक विकल्प बेस 64 में छवियों को एनकोड करना है, बाइनरी डेटा को टेक्स्ट में बदलना जो एक्सएमएल को संभाल सकता है।

के बजाय:

<images>
  <image name="Sally">{binary gibberish that breaks XML parsers}</image>
  <image name="Bobby">{binary gibberish that breaks XML parsers}</image>
</images>

तुम करो:

<images>
  <image name="Sally" encoding="base64">j23894uaiAJSD3234kljasjkSD...</image>
  <image name="Bobby" encoding="base64">Ja3k23JKasil3452AsdfjlksKsasKD...</image>
</images>

और XML पार्सर एक्सएमएल दस्तावेज़ को सही ढंग से पार्स करने और छवि डेटा को निकालने में सक्षम होगा।

— yfeldblum
स्रोत

यह हो सकता है कि Microsoft का पुराना .mhtप्रारूप कैसे काम करता हो (HTML file + images एक ही फाइल में)।

— श्रीधर सरनोबत

38

उस RFC को क्यों नहीं देखा गया जो वर्तमान में Base64 को परिभाषित करता है ?

डेटा के बेस एन्कोडिंग का उपयोग कई स्थितियों में डेटा को स्टोर करने या स्थानांतरित करने के लिए किया जाता
है, जो कि शायद विरासत के कारणों के लिए, US-ASCII [1] डेटा तक सीमित हैं ।बेस एन्कोडिंग का उपयोग उन नए अनुप्रयोगों में भी किया जा सकता है जिनमें विरासत प्रतिबंध नहीं हैं, सिर्फ इसलिए कि यह पाठ संपादकों के साथ वस्तुओं में हेरफेर करना संभव बनाता है।

अतीत में, विभिन्न अनुप्रयोगों की अलग-अलग आवश्यकताएं होती हैं और इस तरह कभी-कभी थोड़े अलग तरीकों से आधार एन्कोडिंग को लागू किया जाता है। आज, प्रोटोकॉल विनिर्देश कभी-कभी सटीक विवरण या संदर्भ के बिना, सामान्य रूप से आधार एन्कोडिंग का उपयोग करते हैं, और विशेष रूप से "बेस 64"। बहुउद्देशीय इंटरनेट मेल एक्सटेंशन (MIME) [4] अक्सर लाइन-रैपिंग या गैर-वर्णमाला वर्णों के परिणामों पर विचार किए बिना बेस 64 के लिए संदर्भ के रूप में उपयोग किया जाता है। इस विनिर्देश का उद्देश्य सामान्य वर्णमाला और एन्कोडिंग विचार स्थापित करना है। इससे अन्य दस्तावेजों में अस्पष्टता कम हो जाएगी, जिससे बेहतर अंतर पैदा होगा।

बेस 64 को मूल रूप से बहुउद्देशीय इंटरनेट मेल एक्सटेंशन के एक भाग के रूप में ईमेल में संलग्न होने के लिए बाइनरी डेटा को अनुमति देने के तरीके के रूप में तैयार किया गया था।

— बिली ओनली
स्रोत

26

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

Base64 एन्कोडिंग द्विआधारी डेटा को उन मानों के रूप में एन्कोड करता है, जिन्हें केवल टेक्स्ट मीडिया में पाठ के रूप में व्याख्या किया जा सकता है, और किसी भी विशेष वर्ण और / या नियंत्रण वर्णों से मुक्त है, ताकि डेटा को टेक्स्ट मीडिया में भी संरक्षित किया जा सके।

— Håvard एस
स्रोत

बेस 64 के साथ इसकी तरह, ज्यादातर स्रोत और गंतव्य दोनों डेटा को एक ही तरह से व्याख्या करेंगे, क्योंकि अधिकांश शायद वे इन 64 वर्णों की उसी तरह व्याख्या करेंगे, भले ही वे विभिन्न तरीकों से नियंत्रण वर्णों की व्याख्या करें। क्या वह सही है?

— लेज़र

6

वे डेटा पारगमन में भी नष्ट हो सकते हैं। उदाहरण के लिए, कई एफ़टीपी प्रोग्राम 13,10 से 10 या लाइन के माध्यम से लाइन एंडिंग्स को फिर से लिखते हैं यदि सर्वर और क्लाइंट का ऑपरेटिंग सिस्टम मेल नहीं खाता है और ट्रांसफर को टेक्स्ट मोड के रूप में चिह्नित किया जाता है। एफ़टीपी केवल पहला उदाहरण है जो मेरे दिमाग में आया था, यह एक अच्छा नहीं है क्योंकि एफ़टीपी बाइनरी मोड का समर्थन करता है।

— हेंड्रिक ब्रम्मनमैन

@nhnb: मुझे लगता है कि एफ़टीपी एक अच्छा उदाहरण है क्योंकि यह दर्शाता है कि बाइनरी डेटा चाहते हैं उन चीजों के लिए पाठ-मोड अनुपयुक्त है।

— jamesdlin

एक पाठ मीडिया क्या है?

— कोरे तुगे

18

यह अधिक है कि मीडिया मान्य करता है स्ट्रिंग एन्कोडिंग को करता है, इसलिए हम यह सुनिश्चित करना चाहते हैं कि डेटा एक हैंडलिंग एप्लिकेशन द्वारा स्वीकार्य है (और उदाहरण के लिए ईओएल का प्रतिनिधित्व करने वाला एक द्विआधारी अनुक्रम नहीं है)

कल्पना कीजिए कि आप यूटीएफ -8 को एन्कोडिंग के साथ एक ईमेल में बाइनरी डेटा भेजना चाहते हैं - ईमेल सही ढंग से प्रदर्शित नहीं हो सकता है अगर लोगों और शून्य की धारा एक अनुक्रम बनाती है। जो UTF-8 एन्कोडिंग में मान्य यूनिकोड नहीं है।

URL में उसी प्रकार की बात होती है जब हम URL में ही URL के लिए मान्य वर्णों को एनकोड करना चाहते हैं:

http://www.foo.com/hello मेरे दोस्त -> http://www.foo.com/hello%20my%20friend

ऐसा इसलिए है क्योंकि हम एक सिस्टम के ऊपर एक स्पेस भेजना चाहते हैं जो अंतरिक्ष को बदबूदार समझेगा।

हम यह सुनिश्चित कर रहे हैं कि बिट्स के दूसरे शाब्दिक अनुक्रम के लिए बिट्स के एक ज्ञात अच्छे, स्वीकार्य और गैर-हानिकारक अनुक्रम के बीच 1 से 1 मैपिंग है, और यह कि हैंडलिंग एप्लिकेशन एन्कोडिंग को अलग नहीं करता है ।

आपके उदाहरण में, manपहले रूप में मान्य ASCII हो सकता है; लेकिन अक्सर आप उन मूल्यों को प्रसारित करना चाहते हैं जो यादृच्छिक बाइनरी हैं (यानी ईमेल में एक छवि भेजना):

MIME- संस्करण: 1.0
सामग्री-विवरण: "Base64 एनकोड ऑफ a.gif"
सामग्री-प्रकार: छवि / gif; name = "a.gif"
सामग्री-अंतरण-एन्कोडिंग: Base64
सामग्री-विवाद: लगाव; फ़ाइल नाम = "a.gif"

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

— Aiden बेल
स्रोत

1

यह कमाल है - इस स्पष्टीकरण ने इसे क्लिक किया। यह डेटा को बाधित या संपीड़ित करने के लिए नहीं है, लेकिन केवल विशेष अनुक्रमों का उपयोग करने से बचने के लिए जिन्हें प्रोटोकॉल के रूप में व्याख्या किया जा सकता है।

— पैट्रिक

13

बेस 64 विशेष पात्रों से बचने के बजाय

मैं आपको एक बहुत अलग लेकिन वास्तविक उदाहरण दूंगा: मैं एक ब्राउज़र में चलाने के लिए जावास्क्रिप्ट कोड लिखता हूं। HTML टैग में ID मान होते हैं, लेकिन एक ID में कौन से वर्ण मान्य हैं, इस पर अड़चनें हैं।

लेकिन मैं चाहता हूं कि मेरी आईडी दोषरहित रूप से मेरे फाइल सिस्टम की फाइलों को देखें। वास्तविकता में फाइलें विस्मयादिबोधक चिह्न, उच्चारण पात्रों, टिल्ड, यहां तक कि इमोजी से उनमें अजीब और अद्भुत पात्रों के सभी तरीके हो सकते हैं! मैं ये नहीं कर सकता:

<div id="/path/to/my_strangely_named_file!@().jpg">
    <img src="http://myserver.com/path/to/my_strangely_named_file!@().jpg">
    Here's a pic I took in Moscow.
</div>

मान लीजिए कि मैं इस तरह से कुछ कोड चलाना चाहता हूं:

# ERROR
document.getElementById("/path/to/my_strangely_named_file!@().jpg");

मुझे लगता है कि निष्पादित होने पर यह कोड विफल हो जाएगा।

Base64 के साथ, मैं इस बात की चिंता किए बिना कुछ जटिल कर सकता हूं कि कौन सी भाषा विशेष पात्रों की अनुमति देती है और जिनसे बचने की आवश्यकता है:

document.getElementById("18GerPD8fY4iTbNpC9hHNXNHyrDMampPLA");

MD5 या कुछ अन्य हैशिंग फ़ंक्शन का उपयोग करने के विपरीत, आप यह पता लगाने के लिए एन्कोडिंग को उलट सकते हैं कि वास्तव में डेटा क्या उपयोगी था।

काश मैं बेस64 साल पहले के बारे में जानता। मैं ' encodeURIComponent' और ' ' के साथ अपने बालों को फाड़ने से बचतीstr.replace(‘\n’,’\\n’)

पाठ का SSH स्थानांतरण:

यदि आप ssh पर जटिल डेटा पास करने की कोशिश कर रहे हैं (उदाहरण के लिए एक dotfile ताकि आप अपने शेल वैयक्तिकरण प्राप्त कर सकें), तो आधार 64 के बिना इसे करना सौभाग्य है। यह है कि आप इसे आधार 64 के साथ कैसे करेंगे (मुझे पता है कि आप एससीपी का उपयोग कर सकते हैं, लेकिन यह कई आज्ञाओं को ले जाएगा - जो एक सर्वर में sshing के लिए महत्वपूर्ण बाइंडिंग को जटिल करता है):

https://superuser.com/a/1376076/114723

— श्रीधर सरनोबत
स्रोत

12

जब मुझे यह सुविधाजनक लगा, तो इसका एक उदाहरण XML में बाइनरी डेटा एम्बेड करने का प्रयास था । कुछ द्विआधारी डेटा को एसएएक्स पार्सर द्वारा गलत रूप से व्याख्या किया जा रहा था क्योंकि यह डेटा एक्सएमएल विशेष वर्णों सहित शाब्दिक रूप से कुछ भी हो सकता है। Base64 डेटा को ट्रांसमिटिंग एंड पर एन्कोडिंग करता है और रिसीविंग एंड पर डिकोड करने पर उस समस्या को ठीक करता है।

— छिपकली का बिल
स्रोत

1

+1 - लेकिन यह किसी भी तरह से SAX विशिष्ट नहीं है। यह किसी भी XML पार्सर यानी DOM या XLINQ के साथ होता है।

— बिली ओनेल

1

@ बिली: हाँ, बिल्कुल। मैं बस उस अनुप्रयोग के लिए एक SAX पार्सर का उपयोग कर रहा था।

— छिपकली

विभिन्न इंजन, उदाहरण के लिए SAX पार्सर ASCII के कुछ मूल्यों की अलग-अलग तरीकों से व्याख्या कर सकते हैं (अलग-अलग नियंत्रण वर्ण)। तो, यहाँ विचार ASCII के सबसेट का उपयोग करना है जिसका सार्वभौमिक अर्थ है। सही?

— लेज़र

1

@ लेज़र: सही है। जब आप इसे ASCII के रूप में व्याख्या करने का प्रयास करते हैं, तो अनएन्कोडेड बाइनरी डेटा में इसमें वर्णों को नियंत्रित किया जाएगा (जो इस मामले में ऐसा नहीं था)।

— छिपकली

10

अधिकांश कंप्यूटर 8-बिट बाइनरी प्रारूप में डेटा संग्रहीत करते हैं, लेकिन यह एक आवश्यकता नहीं है। कुछ मशीनें और ट्रांसमिशन मीडिया एक समय में केवल 7 बिट्स (या शायद कम भी) को संभाल सकते हैं। ऐसा माध्यम 7 बिट्स के गुणकों में स्ट्रीम की व्याख्या करेगा, इसलिए यदि आप 8-बिट डेटा भेजने के लिए थे, तो आपको वह नहीं मिलेगा जो आप दूसरी तरफ की अपेक्षा करते हैं। बेस -64 इस समस्या को हल करने का सिर्फ एक तरीका है: आप इनपुट को 6-बिट फॉर्मेट में एनकोड करते हैं, इसे अपने माध्यम से भेजें और रिसीविंग एंड पर इसे 8-बिट फॉर्मेट में वापस डिकोड करें।

— कैसाब्लांका
स्रोत

3

अगर 7 बिट्स के बाद धारा बाधित होती है तो यह एक समस्या क्यों है। अंत में, दूसरी मशीन में स्ट्रीम पर प्राप्त सभी डेटा होंगे, यह प्रदर्शित करने के लिए 8 बिट्स प्रारूप चुन सकता है? मेरे दिमाग में क्या खराबी है!

— मलौदीन

6

अन्य (कुछ लंबा) उत्तर के अलावा: यहां तक कि पुरानी प्रणालियों की अनदेखी करना जो केवल 7-बिट एएससीआईआई का समर्थन करते हैं, पाठ-मोड में बाइनरी डेटा की आपूर्ति के साथ बुनियादी समस्याएं हैं:

आमतौर पर टेक्स्ट-मोड में न्यूलाइन्स को बदल दिया जाता है।
एक टेक्स्ट स्ट्रिंग के अंत के रूप में एक एनयूएल बाइट का इलाज न करने के लिए सावधान रहना चाहिए, जो कि सी वंश के साथ किसी भी कार्यक्रम में करना बहुत आसान है।

— jamesdlin
स्रोत

नियंत्रण वर्ण जैसे ^ C, ^ D, और ^ Z भी हैं, जिन्हें कुछ प्लेटफार्मों पर अंत-फ़ाइल के रूप में व्याख्या की जाती है।

— dan04

5

इसका क्या मतलब है "मीडिया जो पाठ्य डेटा से निपटने के लिए डिज़ाइन किया गया है"?

उन प्रोटोकॉल को बाइनरी डेटा (जैसे .png और .jpg चित्र) के बजाय पाठ (अक्सर, केवल अंग्रेजी पाठ) को संभालने के लिए डिज़ाइन किया गया था ।

वे बाइनरी से निपट सकते हैं => वे किसी भी चीज़ से निपट सकते हैं।

लेकिन विश्वास सच नहीं है। पाठ को दर्शाने के लिए डिज़ाइन किया गया एक प्रोटोकॉल, बाइनरी डेटा को शामिल करने के लिए अनुचित तरीके से व्यवहार कर सकता है:

बाइट्स 0x0A और 0x0D, लाइन एंडिंग के लिए उपयोग किया जाता है, जो प्लेटफ़ॉर्म से भिन्न होता है।
अन्य नियंत्रण वर्ण जैसे 0x00 (NULL = C स्ट्रिंग टर्मिनेटर), 0x03 (END OF TEXT), 0x04 (END OF TRANSMISSION), या 0x1A (डॉस एंड-ऑफ़-फ़ाइल) जो समय से पहले डेटा के अंत का संकेत देते हैं।
0x7F से ऊपर बाइट्स (यदि प्रोटोकॉल जो ASCII के लिए डिज़ाइन किया गया था)।
बाइट अनुक्रम जो अमान्य UTF-8 हैं।

इसलिए आप केवल पाठ-आधारित प्रोटोकॉल पर बाइनरी डेटा नहीं भेज सकते। आप उन बाइट्स तक सीमित हैं जो गैर-अंतरिक्ष गैर-नियंत्रण ASCII वर्णों का प्रतिनिधित्व करते हैं, जिनमें से 94 हैं। बेस 64 को चुना गया कारण यह था कि दो की शक्तियों के साथ काम करना तेज है, और 64 सबसे बड़ा है जो काम करता है ।

हालांकि एक सवाल। यह कैसे है कि सिस्टम अभी भी इतने आम यूटीएफ -8 जैसी आम एन्कोडिंग तकनीक पर सहमत नहीं है?

वेब पर, कम से कम, उनके पास ज्यादातर है। अधिकांश साइटें UTF-8 का उपयोग करती हैं ।

पश्चिम में समस्या यह है कि बहुत सारे पुराने सॉफ्टवेयर हैं जो ass-u-me-s कि 1 बाइट = 1 वर्ण है और UTF-8 के साथ काम नहीं कर सकते हैं।

पूर्व में समस्या GB2312 और Shift_JIS जैसे एनकोडिंग के प्रति उनका लगाव है।

और तथ्य यह है कि Microsoft अभी भी गलत UTF एन्कोडिंग उठाया है पर नहीं मिला है लगता है। यदि आप Windows API या Microsoft C रनटाइम लाइब्रेरी का उपयोग करना चाहते हैं, तो आप UTF-16 या लोकेल के "ANSI" एन्कोडिंग तक सीमित हैं। यह UTF-8 का उपयोग करने के लिए दर्दनाक बनाता है क्योंकि आपको हर समय परिवर्तित करना होगा।

— dan04
स्रोत

5

क्यों / हम Base64 एन्कोडिंग का उपयोग कैसे करते हैं?

बेस64 75% दक्षता वाले बाइनरी-टू-टेक्स्ट एन्कोडिंग योजना में से एक है। इसका उपयोग इसलिए किया जाता है ताकि विशिष्ट बाइनरी डेटा (जैसे चित्र) को सुरक्षित रूप से विरासत में "8-बिट क्लीन" चैनलों पर भेजा जा सके। पहले के ईमेल नेटवर्क (1990 के दशक तक) में, अधिकांश ईमेल संदेश 7-बिट US-ASCII वर्ण सेट में सादा पाठ थे। तो कई शुरुआती कॉम प्रोटोकॉल मानकों को "7-बिट" कम लिंक "8-बिट क्लीन" पर काम करने के लिए डिज़ाइन किया गया था। योजना दक्षता इनपुट में बिट्स की संख्या और एन्कोडेड आउटपुट में बिट्स की संख्या के बीच का अनुपात है। हेक्साडेसिमल (बेस 16) 50% दक्षता के साथ बाइनरी-टू-टेक्स्ट एन्कोडिंग योजना में से एक है।

Base64 एन्कोडिंग चरण (सरलीकृत):

बाइनरी डेटा को 24 बिट्स (3 बाइट्स) में से प्रत्येक के निरंतर भाग में व्यवस्थित किया जाता है।
प्रत्येक 24 बिट्स चंक को 6 बिट के चार भागों में बांटा गया है।
प्रत्येक 6 बिट समूह को उनके संबंधित बेस 64 वर्ण मानों में परिवर्तित किया जाता है, अर्थात बेस 64 एन्कोडिंग तीन ऑक्टेट को चार एन्कोडेड वर्णों में परिवर्तित करता है। इनपुट बाइट्स के आउटपुट बाइट्स का अनुपात 4: 3 (33% ओवरहेड) है।
दिलचस्प बात यह है कि एक ही वर्णों को तीन-ऑक्टेट समूह के भीतर उनकी स्थिति के आधार पर अलग-अलग एन्कोड किया जाएगा जो कि चार वर्णों का निर्माण करने के लिए एन्कोडेड है।
मूल संदेश को पुनर्प्राप्त करने के लिए रिसीवर को इस प्रक्रिया को उल्टा करना होगा।

— मुश्ताक हुसैन
स्रोत

3

इसका क्या मतलब है "मीडिया जो पाठ्य डेटा से निपटने के लिए डिज़ाइन किया गया है"?

उस दिन जब एएससीआईआई ने गैर-एएससीआईआई मूल्यों के साथ काम करने वाले दुनिया पर शासन किया था, सिरदर्द था। लोगों को बिना जानकारी खोए तार पर स्थानांतरित करने के लिए सभी प्रकार के हुप्स के माध्यम से कूद गए।

— dirkgently
स्रोत

3

वास्तव में, दिन में वापस, ASCII भी हर जगह इस्तेमाल नहीं किया गया था। कई प्रोटोकॉल में डेटा ट्रांसफर करने के लिए एक अलग टेक्स्ट-मोड और बाइनरी-मोड था, दुर्भाग्य से ईमेल फिर वापस नहीं आया। टेक्स्ट-मोड आवश्यक रूप से ठीक है क्योंकि किसी एक टेक्स्ट एन्कोडिंग ने दुनिया पर शासन नहीं किया है, एएससीआईआई ने नहीं; हर कंप्यूटर नेटवर्क की अपनी पसंदीदा एन्कोडिंग होती है, इसलिए ऐसे गेटवे होते हैं जिनका काम एक्सचेंज किए गए टेक्स्ट को स्थानीय एन्कोडिंग में बदलना है ताकि एक जापानी कंपनी बिना किसी मोजिबेक के अमेरिकी व्यापार सलाहकार को ईमेल भेज सके। बाइनरी डेटा भेजते समय यह रूपांतरण, जाहिर है, अवांछनीय है।

— रेयान

हम Base64 का उपयोग क्यों करते हैं?

XML में बाइनरी डेटा एनकोडिंग

बेस 64 विशेष पात्रों से बचने के बजाय

पाठ का SSH स्थानांतरण:

क्यों / हम Base64 एन्कोडिंग का उपयोग कैसे करते हैं?

Base64 एन्कोडिंग चरण (सरलीकृत):