将数据附加到电子邮件中时,我注意到Thunderbird计算出的电子邮件总大小比我附加的文件大得多。
这是一个最近的示例:两张图像,一张在13MB,一张在3.6MB,总共应该大约为17MB。一共有四行文字。然后,雷鸟问我是否真的要发送总大小为22MB的电子邮件。
差异来自何处?5MB的文本听起来有点多。
将数据附加到电子邮件中时,我注意到Thunderbird计算出的电子邮件总大小比我附加的文件大得多。
这是一个最近的示例:两张图像,一张在13MB,一张在3.6MB,总共应该大约为17MB。一共有四行文字。然后,雷鸟问我是否真的要发送总大小为22MB的电子邮件。
差异来自何处?5MB的文本听起来有点多。
Answers:
您的数据为17 MiB。MiB中有1024 KiB。KiB中有1024B。一个字节中有8位。因此,这是142,606,336位。
Base 64编码将每六个位编码为一个单独的字节。因此,我们需要约23767722字节。两次除以1024得到22.67 MiB。这就是22 MiB的来源。
电子邮件是一项相当古老的技术,没有采用8位纯净管道。
因为数据被编码,base64
其中将最多三个字节的组编码为四个可打印ASCII字符的组。通常,将这些可打印字符组分成几行。
结果是,编码数据的大小刚好是原始数据大小的1/5倍。
电子邮件源远流长,最初设计为携带文本。只有代表ASCII可打印字符的字节值才能可靠地通过地球上各种各样的电子邮件系统。
因此,MIME分为两种用于将其他数据编码为ASCII文本的方案-“ quoted-printable”主要用于带有一些其他位的ASCII文本,而“ BASE64”则用于任意二进制数据。
SMTP协议已扩展,可以尝试消除这些限制。首先,1994年的8BITMIME允许更高的八位位组值,但不幸的是,它没有消除与行长和行尾相关的限制,因此不适用于任意二进制数据。然后是1995年的BINARYMIME,它允许传输包含任意二进制数据的消息。
但是,这些标准尚未得到广泛采用。一个问题是,如果邮件链中的一跳支持但下一跳不支持怎么办?然后,邮件服务器无法按原样发送邮件,它必须要么将其拒绝为无法送达并退回(用户不太可能接受),要么将其转换(这需要邮件服务器中的大量额外代码) 。关于不对多部分类型使用内容传输编码的MIME规则使转换特别痛苦。