UUENCODE 会使二进制文件变大多少？

Question 1

简短回答：

uuencoded 文件的大小会比原始文件大约大 35%。

长答案：

Uuencode 文件如下所示：

开始 600 文件名
*“F9O；R！B87（*”@``
`
结尾

其中 7 个字节用于begin表示权限，2 个字节用于表示分隔空格。
X 字节为文件名（取决于名称）
然后是实际的编码数据。每 6 位映射到 8 位（结果都是可打印的 ASCII 字符）。这会使大小增加到⁸ / ₆，即原始大小的 1⅓ 倍。
然后，结果被分成 65 个字符的行，因此结果将显示在 80 个字符宽的屏幕上。这样每 65 个字符就会增加一个换行符。因此文件大小_增加^了^1/65
最后 3 个字节end

因此我们得到：13 个字节，加上文件名长度，加上原始文件大小的¹⁶⁸ / _{195 。}

（⁶⁸ / ₁₉₅^是1⅓ 加¹ / ₆₅，或 1 ⁶⁵ / ₁₉₅加³ / ₁₉₅。这非常接近 35％，这就是为什么经验法则是“尺寸增加了三分之一”）。

Answer

简短回答：

uuencoded 文件的大小会比原始文件大约大 35%。

长答案：

Uuencode 文件如下所示：

开始 600 文件名
*“F9O；R！B87（*”@``
`
结尾

其中 7 个字节用于begin表示权限，2 个字节用于表示分隔空格。
X 字节为文件名（取决于名称）
然后是实际的编码数据。每 6 位映射到 8 位（结果都是可打印的 ASCII 字符）。这会使大小增加到⁸ / ₆，即原始大小的 1⅓ 倍。
然后，结果被分成 65 个字符的行，因此结果将显示在 80 个字符宽的屏幕上。这样每 65 个字符就会增加一个换行符。因此文件大小_增加^了^1/65
最后 3 个字节end

因此我们得到：13 个字节，加上文件名长度，加上原始文件大小的¹⁶⁸ / _{195 。}

（⁶⁸ / ₁₉₅^是1⅓ 加¹ / ₆₅，或 1 ⁶⁵ / ₁₉₅加³ / ₁₉₅。这非常接近 35％，这就是为什么经验法则是“尺寸增加了三分之一”）。

Question 2

常见的现代电子邮件客户端都会使用 base64，这会使文件体积增大约 35%，但仅限于电子邮件内部。

如今，通常使用 base64 来代替。原始二进制文件的每个字节包含 8 位。Base64 可以在每个编码字节中存储相当于 6 位原始数据的内容。因此编码大小是原始大小的 8/6：

8 / 6 = 1.33... = 133% = 33% more

然后添加换行符，这又增加了百分之几。

当然，一旦文件被解码并保存到接收者的文件系统，解码后的文件将与原始文件完全相同。

Answer

常见的现代电子邮件客户端都会使用 base64，这会使文件体积增大约 35%，但仅限于电子邮件内部。

如今，通常使用 base64 来代替。原始二进制文件的每个字节包含 8 位。Base64 可以在每个编码字节中存储相当于 6 位原始数据的内容。因此编码大小是原始大小的 8/6：

8 / 6 = 1.33... = 133% = 33% more

然后添加换行符，这又增加了百分之几。

当然，一旦文件被解码并保存到接收者的文件系统，解码后的文件将与原始文件完全相同。

Question 3

虽然实际答案（由@Per Salmi 和@depquid 给出）只比 33% 多一点（3 个字节变成 4 个，加上行尾，再加上一些内务处理）但您不必担心uuencode。

uuencode可以追溯到 UNIX 的古老时代，那时还没有 MIME 邮件程序。在那个年代，要在纯文本环境中（例如 Mail、netnews/usenet）拖拽字节，您必须手动将文件编码为 7 位字符安全。然后，接收者必须手动将文件保存在某个地方，可能要连接并排序多封邮件/帖子，然后运行uudecode（它足够智能，可以忽略 BEGIN/END 块之外的任何内容）并获取二进制文件。但我们不再需要这样做了，至少对于邮件来说不需要。

如果你使用任何现代邮件程序，这种交叉编码已经自动发生。二进制 MIME 元素通常采用 base64 编码（如@depquid 所述）。

因此，您已经进行了 MIME Base64 编码，如果您对带宽分配的影响感到好奇，这会使文件体积增大 33% 以上。执行 uuencode/uudecode 只会给您和接收方增加更多工作量。

Answer