題 為什麼我的電子郵件的大小比其附加文件的大小大三分之一?


將數據附加到我的電子郵件時,我注意到Thunderbird計算的結果電子郵件的總大小比我附加的文件大得多。

這是最近的一個例子:兩個圖像,一個13MB,一個3.6MB,總共約17MB。有四行文字。然後Thunderbird問我是否真的想發送總大小為22MB的電子郵件。

這種差異來自哪裡? 5MB的文字聽起來有點多。


112
2017-10-26 20:45


起源


請注意,這通常會影響最大尺寸等內容。如果我沒弄錯,谷歌郵件通常允許最多25MB的電子郵件,但計算25MB 後 編碼,所以你不能用電子郵件發送25MB的圖像,因為編碼時實際上太大了。 - Bakuriu
@ Bakuriu的評論也適用於Outlook + Exchange服務器。我認為根本問題實際上是 為什麼郵件客戶端(通常是Tbird似乎比outlook更好)僅報告本地文件大小,因為它是base64編碼的大小? - Chris H
@MarcksThomas我不想反對擁有一個包括易於搜索的知識來源的吸引力,而不僅僅是讓所有知識都易於搜索。但是有必要嗎?我不這麼認為。 - 我認為這個問題根本沒用,我認為它不符合保持網站免於不必要問題的基本要求,並且更難找到真正重要的東西, 不 在其他地方回答。這就是我們應該做的! - arc_lupus,因為我只潛伏在這個網站上,通常,我的downvote還沒有cout。但事實並非如此。 - Alexander Kosubek
相關: superuser.com/questions/568506/... - glenneroo


答案:


您的數據是17 MiB。 MiB中有1024 KiB。 KiB中有1024 B。一個字節有8位。那是142,606,336位。

Base 64編碼將每6位編碼為單獨的字節。所以我們需要大約23,767,722個字節。除以1024兩次得到22.67 MiB。這就是22 MiB的來源。

電子郵件是一項非常古老的技術,不會假設8位乾淨的管道。


214
2017-10-26 20:49



要稍微解碼最後一行:base-64是一種使用一組有限的“保證安全字符”將附件編碼為文本的方法,這些字符不會被某些中間設備弄亂,例如a-z,A-Z,0-9 - Yorik
而且,一旦你理解了David的優秀答案中的數學,你就可以將附件的大小乘以4/3來獲得將要發送的郵件大小(加上實際文本)。 - Kent
即使電子郵件知道它有一個完整的8位管道,也必須進行編碼,因為它基本上是一個文本流 - 一些字符提供控制功能,因此不得出現在您的數據中。話雖如此,有更好的編碼技術,但它們尚未被採用。 - Loren Pechtel
@LorenPechtel你可以愉快地在MIME消息中有一個application / octet-stream部分。您所要做的就是選擇數據中沒有出現的邊界。 - OrangeDog
什麼base64 其實 是,每3個原始字節使用4個字節。雖然這聽起來很相似,但它很重要,因為長度總是4的倍數,也因為沒有理由比特級別。 - njzk2


為什麼電子郵件更大?

因為數據是在中編碼的 base64 它將最多三個字節的組編碼為四個可打印ASCII字符的組。通常,這些可打印字符組然後被分成行。

結果是編碼數據剛好超過原始數據的1倍。

為什麼使用base64?

電子郵件歷史悠久,最初設計用於攜帶文本。只有表示ASCII可打印字符的字節值才能可靠地通過地球上各種各樣的電子郵件系統。

所以MIME分為兩種方案,用於將其他數據編碼為ASCII文本 - “quoted-printable”設計用於主要是帶有一些其他位的ASCII文本,而“BASE64”用於任意二進制數據。

已經有SMTP協議的擴展來嘗試刪除這些限制。首先,1994年的8BITMIME允許更高的八位字節值但遺憾的是沒有刪除與行長度和行結尾相關的限制,因此不適合任意二進制數據;然後是1995年的BINARYMIME,它允許傳輸包含任意二進制數據的消息。

但是,這些標準尚未得到廣泛採用。一個問題是,如果郵件鏈中的一跳支持它們但下一跳不支持會發生什麼?然後,郵件服務器無法按原樣發送郵件,它必須拒絕它作為無法傳遞並將其退回(用戶不太可能接受),或轉換它(這需要郵件服務器中的大量額外代碼) 。關於不在多部分類型上使用內容傳輸編碼的MIME規則使轉換特別痛苦。


50
2017-10-28 02:59



我想知道為什麼yEnc在Usenet取代UUE方面非常成功。可能是因為二元新聞組對ISP的壓力要大於偶爾的二進制郵件? - igorsk
@igorsk:加上Usenet / NN被呈現並被理解為有損,您可以在其中發布文章而不是所有服務器上的所有訂閱者都必須接收它。在前一篇文章的“足夠”的後續內容中引用了(並且基本上仍然存在)習俗,以至於某人可以理解您的後續行為 誰沒有得到上一篇文章。相比之下,大多數(非主持人)電子郵件發件人都希望“系統”能夠將信息發送給指定的收件人,儘管有時會在數小時或數天之後;今天人們抱怨甚至短暫的延誤。 - dave_thompson_085