为什么我的电子邮件的大小比附件的大小大三分之一?


111

将数据附加到电子邮件中时,我注意到Thunderbird计算出的电子邮件总大小比我附加的文件大得多。

这是一个最近的示例:两张图像,一张在13MB,一张在3.6MB,总共应该大约为17MB。一共有四行文字。然后,雷鸟问我是否真的要发送总大小为22MB的电子邮件。

差异来自何处?5MB的文本听起来有点多。


2
请注意,这通常会影响最大尺寸等内容。如果我没记错的话,Google邮件通常最多允许25MB的电子邮件,但是25MB是编码计算出来的,因此您无法通过电子邮件发送25MB的图像,因为在编码时它实际上会太大。
巴库里

4
@Bakuriu的注释也适用于Outlook + Exchange服务器。我建议潜在的问题实际上是,为什么邮件客户端(通常-Tbird看起来比Outlook还要好)在报告以base64编码的大小时才只报告本地文件大小?
克里斯·H

@MarcksThomas我不想反对拥有一个全包(包括易于搜索的)知识源的吸引力,而不是仅仅拥有所有易于搜索的知识的吸引力。但是有必要吗?我不这么认为。-我认为该问题根本没有用,我只是认为它不能满足基本要求,以使该站点免于不必要的问题,并且使找到真正重要的内容变得更加困难,这不是在其他地方回答。那就是我们应该做的!-arc_lupus,通常我只在这个站点上潜伏,我的否决票还没有投票。但事实如此。
亚历山大·科苏贝克

Answers:


214

您的数据为17 MiB。MiB中有1024 KiB。KiB中有1024B。一个字节中有8位。因此,这是142,606,336位。

Base 64编码将每六个位编码为一个单独的字节。因此,我们需要约23767722字节。两次除以1024得到22.67 MiB。这就是22 MiB的来源。

电子邮件是一项相当古老的技术,没有采用8位纯净管道。


79
为了稍微解码最后一行:base-64是一种使用有限的“保证安全字符”集将附件编码为文本的方式,这种中间字符不会被某些中间设备(例如,az,AZ,0-9)弄乱
Yorik '16

64
而且,一旦您了解了David出色答案的数学原理,您就可以将附件的大小乘以4/3来获得将要发送的邮件大小(加上实际文本)。
肯特

12
即使电子邮件知道它具有完整的8位管道,也必须进行编码,因为它基本上是文本流-有些字符具有控制功能,因此一定不能出现在数据中。话虽这么说,有更好的编码技术,但尚未被采用。
罗伦·佩希特尔

3
@LorenPechtel,您可以很高兴在MIME消息中包含一个应用程序/八位字节流部分。您所要做的就是选择数据中不存在的边界。
OrangeDog

8
base64 实际执行的操作是每3个原始字节使用4个字节。虽然这听起来很相似,但是很重要,因为该长度始终是4的倍数,并且还因为没有理由使用位级别。
njzk2

50

为什么电子邮件更大?

因为数据被编码,base64其中将最多三个字节的组编码为四个可打印ASCII字符的组。通常,将这些可打印字符组分成几行。

结果是,编码数据的大小刚好是原始数据大小的1/5倍。

为什么使用base64?

电子邮件源远流长,最初设计为携带文本。只有代表ASCII可打印字符的字节值才能可靠地通过地球上各种各样的电子邮件系统。

因此,MIME分为两种用于将其他数据编码为ASCII文本的方案-“ quoted-printable”主要用于带有一些其他位的ASCII文本,而“ BASE64”则用于任意二进制数据。

SMTP协议已扩展,可以尝试消除这些限制。首先,1994年的8BITMIME允许更高的八位位组值,但不幸的是,它没有消除与行长和行尾相关的限制,因此不适用于任意二进制数据。然后是1995年的BINARYMIME,它允许传输包含任意二进制数据的消息。

但是,这些标准尚未得到广泛采用。一个问题是,如果邮件链中的一跳支持但下一跳不支持怎么办?然后,邮件服务器无法按原样发送邮件,它必须要么将其拒绝为无法送达并退回(用户不太可能接受),要么将其转换(这需要邮件服务器中的大量额外代码) 。关于不对多部分类型使用内容传输编码的MIME规则使转换特别痛苦。


1
我不知道为什么yEnc在Usenet中在取代UUE方面非常成功。可能是因为二进制新闻组比偶尔的二进制电子邮件给ISP带来了更大的压力?
igorsk

2
@igorsk:加上Usenet / NN并被认为是有损的,您可以在其中发布文章,并且并非所有服务器上的所有订阅者都一定会收到该文章。关于(在很大程度上仍保留)关于引用前一篇文章的后续“足够”的习俗,而没有得到前一篇文章的人可以理解您的后续。相比之下,大多数(非垃圾邮件发送者)电子邮件发件人期望“系统”将其消息发送给指定的收件人,尽管有时是数小时或数天之后;今天人们抱怨甚至短暂的延迟。
dave_thompson_085 '16
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.