imap_fetchheader 字节与实际文件大小答案

【问题标题】：imap_fetchheader bytes vs actual file sizeimap_fetchheader 字节与实际文件大小
【发布时间】：2014-04-03 15:32:13
【问题描述】：

我正在使用 imap_fetcheader 来获取邮件的附件，只是内容。这是代码-

if (isset($content->ifdparameters) && $content->ifdparameters == 1 && isset($content->dparameters) && is_array($content->dparameters)) {
            foreach ($content->dparameters as $object) {
                if (isset($object->attribute) && preg_match('~filename~i', $object->attribute)) {                    
                    $attachment = new EmailAttachment();

                    $attachment->attachment_name = $object->value;                                                              
                    $attachment->attachment_size = $this->format_bytes($content->bytes);
                    $attachment->attachment_part_id = empty($actualpart) ? 1 : $actualpart;
                    $attachment->attachment_encoding = $content->encoding;
                    $results[] = $attachment;
                }
            }
        }

format_bytes 函数在这里 -

private function format_bytes($bytes, $precision = 2) {
    $units = array('B', 'KB', 'MB', 'GB', 'TB');

    $bytes = max($bytes, 0);
    $pow = floor(($bytes ? log($bytes) : 0) / log(1024));
    $pow = min($pow, count($units) - 1);

    $bytes /= pow(1024, $pow);

    return round($bytes, $precision) . ' ' . $units[$pow];
}

当用户点击附件时，我从邮件服务器抓取附件内容并将内容回显。

问题是——

$content->bytes 属性报告的字节与下载到客户端计算机的字节大不相同...

这是一个已知问题吗？

邮件服务器是托管在 CentOS 操作系统上的 POSTFIX。

【问题讨论】：

标签： php email filesystems imap

【解决方案1】：

它通常大 33% 左右，因为这是增加了多少额外的批量 base64 编码。

但并不总是 33%：还有其他编码，base64 只是附件中最常见的一种。

【讨论】：

因此，当我在不实际下载附件的情况下向用户显示大小时，是否可以将其缩小 33% 并将其显示给用户，或者这样的假设是否太糟糕了？
大部分时间是合理的，但这个大小实际上反映了数据使用情况。在某些情况下，它可能被引用可打印编码，或者可能根本不编码（纯 ascii.txt 文档）。您需要在调整之前找出编码。如果是 base64，这是一个合理的假设。
另外，这是 PHP 数学；) 您需要将其减少 25%，而不是 33%。将 33% 加到 3，你就有 4 个。现在减少 25%，你又得到 3 个。