imap_fetchheader字节与实际文件大小

我使用imap_fetcheader获取邮件的附件，只是内容。下面的代码 -imap_fetchheader字节与实际文件大小

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。

来源

2014-04-03 Abijeet Patro

它往往大约33％，因为这是多少额外的批量base64编码增加。

虽然这并不总是33％：还有其他的编码，base64是附件中最常用的编码。

来源

2014-04-03 16:07:37 arnt

因此，当我没有真正下载附件时向用户展示尺寸时，我可以将其减少33％并将其显示给用户，否则这会太糟糕了吗？ –

大部分时间都合理，但这个大小实际上反映了数据的使用情况。在某些情况下，它可能会被引用 - 可打印编码，或者可能根本没有编码（纯粹的ascii.txt文档）。在调整之前，您需要找出编码。如果它是base64，那是一个合理的假设。 – Max

另外，这是PHP数学;）你需要减少25％，而不是33％。增加33％到3，你有4。现在减少25％，你又有3。 – arnt

imap_fetchheader字节与实际文件大小

回答

相关问题