区别是什么？ 5MB的文本听起来有点多。
#1 楼
您的数据为17 MiB。 MiB中有1024 KiB。 KiB中有1024B。一个字节中有8位。因此，这是142606336位。Base 64编码将每六个位编码为一个单独的字节。因此，我们需要约23767722字节。两次除以1024得到22.67 MiB。因此，这就是22 MiB的来源。
电子邮件是一项非常古老的技术，并且不假定使用8位纯管道。
评论
稍微解码最后一行：base-64是一种使用有限的“保证安全字符”集将附件编码为文本的方式，这种中间字符不会被某些中间设备（例如a-z，A-Z，0-9）弄乱
–约里克
16-10-26在21:53
而且，一旦您了解了David的出色答案中的数学原理，您就可以将附件的大小乘以4/3来获得将要发送的邮件大小（加上实际文本）。
–肯特
16-10-26在23:13
即使电子邮件知道它具有完整的8位管道，也必须进行编码，因为它基本上是文本流-有些字符具有控制功能，因此在数据中不得出现。话虽这么说，有更好的编码技术，但尚未被采用。
–Loren Pechtel
16-10-27在4:24
@LorenPechtel，您可以在MIME消息中愉快地包含应用程序/八位字节流。您所要做的就是选择数据中不存在的边界。
–橙色狗
16-10-27在8:51
base64实际执行的操作是每3个原始字节使用4个字节。虽然这听起来很相似，但是很重要，因为该长度始终是4的倍数，并且还因为没有理由使用位级别。
– njzk2
16-10-27在15:44
#2 楼
为什么电子邮件会更大？因为数据是用
base64编码的，它将最多三个字节的组编码为四个可打印ASCII字符的组。通常，将这些可打印字符组分成几行。结果是，编码数据仅是原始数据大小的1倍多。使用base64吗？
电子邮件具有悠久的历史，最初设计为携带文本。只有代表ASCII可打印字符的字节值才能可靠地通过地球上各种电子邮件系统。 ASCII文本和其他一些位，“ BASE64”表示任意二进制数据。
SMTP协议已有扩展，可以尝试消除这些限制。首先，1994年的8BITMIME允许更高的八位位组值，但不幸的是，它没有消除与行长和行尾相关的限制，因此不适用于任意二进制数据。然后是1995年的BINARYMIME，它允许传输包含任意二进制数据的消息。
但是，这些标准尚未得到广泛采用。一个问题是，如果邮件链中的一跳支持但下一跳不支持怎么办？然后，邮件服务器无法按原样发送邮件，它必须拒绝无法交付的邮件并退回邮件（用户不太可能接受），或者将其转换（这需要邮件服务器中的大量额外代码） 。关于不对多部分类型使用内容传输编码的MIME规则使转换特别痛苦。
评论
我不知道为什么yEnc在Usenet中在取代UUE方面非常成功。可能是因为二进制新闻组对ISP的压力要比偶尔的二进制电子邮件高得多？
–igorsk
16-10-30在19:09
@igorsk：加上Usenet / NN并被认为是有损的，您可以在其中发布文章，并且并非所有服务器上的所有订阅者都一定会收到该文章。关于（在很大程度上）仍然存在关于引用后续文章“足够多”的习惯，即没有得到先前文章的人可以理解您的后续行动。相比之下，大多数（非垃圾邮件发件人）电子邮件发件人期望“系统”将他们的消息发送给指定的收件人，尽管有时是数小时或数天之后。今天人们抱怨甚至短暂的延迟。
–dave_thompson_085
16-10-31在22:35
评论
请注意，这通常会影响最大尺寸等内容。如果我没记错的话，Google邮件通常最多允许25MB的电子邮件，但是25MB是在编码后计算出来的，因此您无法通过电子邮件发送25MB的图像，因为编码时实际上会太大。@Bakuriu的注释也适用于Outlook + Exchange服务器。我建议潜在的问题实际上是，为什么邮件客户端（通常-Tbird看起来比Outlook还要好）在报告以base64编码的大小时只报告本地文件大小？
@MarcksThomas我不想反对拥有一个全包（包括易于搜索的）知识源的吸引力，而不是仅仅拥有所有易于搜索的知识的吸引力。但是有必要吗？我不这么认为。 -我认为该问题根本没有用，我只是认为它不能满足基本要求，从而使该站点免于不必要的问题，并且使找到真正重要的内容变得更加困难，在其他地方回答。那就是我们应该做的！ -arc_lupus，因为我通常只在这个站点上潜伏，通常，我的否决票还没有投票。但是，它原样。
相关于：superuser.com/questions/568506/…