सवाल मेरे ईमेल का आकार इसकी संलग्न फाइलों के आकार की तुलना में तीसरे बड़े आकार का क्यों है?


मेरे ईमेल में डेटा संलग्न करते समय, मैंने देखा कि थंडरबर्ड परिणामस्वरूप ईमेल के कुल आकार की गणना करता है जो मैंने संलग्न फाइलों की तुलना में काफी बड़ा है।

यहां एक हालिया उदाहरण दिया गया है: दो छवियां, 13 एमबी पर एक और 3.6 एमबी पर एक कुल में लगभग 17 एमबी होना चाहिए। पाठ की चार पंक्तियां थीं। थंडरबर्ड ने मुझसे पूछा कि क्या मैं वास्तव में 22 एमबी के कुल आकार के साथ एक ईमेल भेजना चाहता हूं।

वह अंतर कहां से आ रहा है? 5 एमबी टेक्स्ट थोड़ा सा लगता है।


112
2017-10-26 20:45


मूल


ध्यान दें कि यह अक्सर अधिकतम आकार की तरह चीजों को प्रभावित करता है। अगर मुझे गलत नहीं लगता है तो Google मेल आमतौर पर 25 एमबी के ईमेल की अनुमति देता है, लेकिन 25 एमबी की गणना की जाती है बाद एन्कोडिंग, इसलिए आप एक ईमेल के साथ 25 एमबी छवि नहीं भेज सकते हैं, क्योंकि जब एन्कोड किया जाता है तो यह वास्तव में बहुत बड़ा होगा। - Bakuriu
@ Bakuriu की टिप्पणी Outlook + Exchange सर्वर पर भी लागू होती है। मेरा सुझाव है कि अंतर्निहित प्रश्न वास्तव में है मेल क्लाइंट क्यों करते हैं (अक्सर - टीबीर्ड फिर से दृष्टिकोण से बेहतर लगता है) केवल स्थानीय फ़ाइल आकार की रिपोर्ट करते हैं जब यह बेस 64-एन्कोडेड आकार है जो मायने रखता है? - Chris H
@ मार्क्स थॉमस मैं सभी ज्ञान आसानी से खोजे जाने के खिलाफ ज्ञान के आसानी से खोजने योग्य स्रोत सहित सभी को शामिल करने की अपील के खिलाफ बहस नहीं करना चाहता हूं। लेकिन क्या यह आवश्यक है? मुझे ऐसा नहीं लगता। - मुझे नहीं लगता कि सवाल बिल्कुल उपयोगी नहीं है, मुझे लगता है कि यह साइट को अनावश्यक प्रश्नों से मुक्त रखने के लिए बुनियादी आवश्यकताओं को पूरा नहीं करता है और वास्तव में महत्वपूर्ण चीजों को ढूंढना कठिन बनाता है, नहीं है कहीं और जवाब दिया। यही वह है जो हमें करना चाहिए! - arc_lupus, क्योंकि मैं केवल इस साइट पर रहना चाहता हूं, आमतौर पर, मेरा डाउनवोट cout नहीं है, अभी तक। लेकिन जैसा कि है, यह खड़ा है। - Alexander Kosubek
से संबंधित: superuser.com/questions/568506/... - glenneroo


जवाब:


आपका डेटा 17 एमआईबी था। एमआईबी में 1024 कीबी हैं। KiB में 1024 बी हैं। एक बाइट में 8 बिट्स हैं। तो यह 142,606,336 बिट्स है।

बेस 64 एन्कोडिंग प्रत्येक छह बिट्स को एक अलग बाइट के रूप में एन्कोड करता है। इसलिए हमें 23,767,722 बाइट्स चाहिए। 1024 बार विभाजित करने से हमें 22.67 एमआईबी मिल जाता है। तो वह जगह है जहां 22 एमआईबी से आता है।

ईमेल एक सुंदर पुरानी तकनीक है और 8-बिट साफ पाइप नहीं मानती है।


214
2017-10-26 20:49



उस अंतिम पंक्ति को डीकोड करने के लिए थोड़ा: बेस -64 "गारंटीकृत सुरक्षित पात्रों" के सीमित सेट का उपयोग करके अनुलग्नकों को एन्कोड करने का एक तरीका है जो कुछ मध्यवर्ती उपकरणों जैसे कि ए-जेड, ए-जेड, 0-9 द्वारा गड़बड़ नहीं किया जाएगा - Yorik
और, जब आप डेविड के उत्कृष्ट उत्तर में गणित को समझ लेते हैं, तो आप भेजे गए मेल संदेश का आकार प्राप्त करने के लिए अनुलग्नकों के आकार को 4/3 तक गुणा कर सकते हैं (साथ ही वास्तविक पाठ)। - Kent
यहां तक ​​कि यदि ईमेल जानता था कि इसमें पूर्ण 8 बिट पाइप है, तो उसे एन्कोडिंग करना होगा क्योंकि यह मूल रूप से एक टेक्स्ट स्ट्रीम है - कुछ वर्ण नियंत्रण कार्यों की सेवा करते हैं और इस प्रकार आपके डेटा में नहीं होना चाहिए। ऐसा कहा जा रहा है कि बेहतर एन्कोडिंग तकनीकें हैं लेकिन उन्हें अपनाया नहीं गया है। - Loren Pechtel
@LorenPechtel आप खुशी से एक एमआईएमई संदेश में एक आवेदन / ऑक्टेट-स्ट्रीम भाग कर सकते हैं। आपको बस इतना करना है कि वह सीमा चुनें जो डेटा में नहीं होती है। - OrangeDog
क्या बेस 64 वास्तव में करता है, हर 3 मूल बाइट्स के लिए 4 बाइट्स का उपयोग कर रहा है। हालांकि यह समान लगता है, यह महत्वपूर्ण है क्योंकि लंबाई हमेशा 4 में से एक है, और इसलिए भी क्योंकि बिट स्तर का कोई कारण नहीं है। - njzk2


ईमेल बड़ा क्यों है?

क्योंकि डेटा एन्कोड किया गया है base64 जो चार प्रिंट करने योग्य ASCII वर्णों के समूह के रूप में तीन बाइट्स के समूहों को एन्कोड करता है। आमतौर पर, प्रिंट करने योग्य पात्रों के इन समूहों को फिर लाइनों में विभाजित किया जाता है।

नतीजा यह है कि एन्कोडेड डेटा मूल डेटा के आकार से 1 गुना अधिक है।

बेस 64 का उपयोग क्यों किया जाता है?

ईमेल का एक लंबा इतिहास है और मूल रूप से पाठ ले जाने के लिए डिज़ाइन किया गया था। एएससीआईआई प्रिंट करने योग्य पात्रों का प्रतिनिधित्व करने वाले केवल बाइट मान विश्वसनीय रूप से ग्रह पर विभिन्न प्रकार के ईमेल सिस्टम से गुज़र सकते हैं।

इसलिए एमआईएमई ने एएससीआईआईआई पाठ के रूप में अन्य डेटा एन्कोडिंग के लिए दो योजनाएं विभाजित की - "उद्धृत-प्रिंट करने योग्य" कुछ अन्य बिट्स के साथ ज्यादातर ASCII पाठ के लिए डिज़ाइन की गई, और मनमाने ढंग से बाइनरी डेटा के लिए "BASE64"।

इन प्रतिबंधों को आजमाने और हटाने के लिए SMTP प्रोटोकॉल में एक्सटेंशन रहे हैं। सबसे पहले, 1 99 4 में 8 बीआईटीएमआईएम, जिसने उच्च ऑक्टेट मानों की अनुमति दी लेकिन दुर्भाग्य से लाइन लम्बाई और रेखा समाप्ति से संबंधित सीमाएं नहीं हटाईं, इसलिए मनमाने ढंग से बाइनरी डेटा के लिए उपयुक्त नहीं था; और फिर 1995 में BINARYMIME, जिसने मनमाने ढंग से बाइनरी डेटा वाले संदेशों के हस्तांतरण की अनुमति दी।

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


50
2017-10-28 02:59



मुझे आश्चर्य है कि दूसरी तरफ, वाईएनएनसी यूयूईएन को विस्थापित करने में यूज़नेट में काफी सफल रही थी। शायद इसलिए कि बाइनरी न्यूज़ ग्रुप ने कभी-कभी द्विआधारी ईमेल की तुलना में आईएसपी पर बहुत अधिक दबाव डाला है? - igorsk
@igorsk: प्लस यूज़नेट / एनएन को हानिकारक के रूप में प्रस्तुत और समझा गया था, जहां आप एक लेख प्रकाशित कर सकते थे और सभी सर्वरों पर सभी ग्राहकों को यह आवश्यक नहीं होगा। पिछले लेख (ओं) के अनुवर्ती 'पर्याप्त' में उद्धरण के बारे में सीमाएं (और काफी हद तक बनी हुई हैं) कि आपके अनुवर्ती किसी के द्वारा समझा जा सकता है पिछले लेख को कौन नहीं मिला। इसके विपरीत अधिकांश (nonspammer) ईमेल प्रेषकों को उम्मीद है कि 'सिस्टम' को उनके संदेश नामित प्राप्तकर्ता (ओं) को मिलेगा, हालांकि कभी-कभी घंटों या दिनों के बाद; आज लोग भी छोटी देरी के बारे में शिकायत करते हैं। - dave_thompson_085