【问题标题】:content-length conversion内容长度转换
【发布时间】:2012-11-03 23:44:37
【问题描述】:

我正在使用一个脚本检查文件大小,该脚本报告的 BYTES 内容长度与我在 Mac 上看到的完全匹配,但是如果我将字节转换为 KB:

function formatBytes($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 /= (1 << (10 * $pow)); 

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

...以 KB 为单位的大小总是与我在 Mac 上看到的不同。

例如:

Windows 8 TV Ad Tune.m4r

  • 字节(Mac):4,27,840 字节
  • KB(Mac):428KB

  • 字节(脚本):427840

  • KB(脚本):417.81 KB

我想知道是脚本还是其他原因导致了这种差异?

谢谢!

【问题讨论】:

    标签: php macos file curl size


    【解决方案1】:

    看起来 Mac 正在使用 1000 约定,即 1kB 是 1000 字节。您的转换使用 1kB = 1024 字节。两者在技术上都是正确的,但是大多数程序员会使用 1kB = 1024。Mac 使用 1kB = 1000,Windows 使用 1kB = 1024。

    硬盘制造商将使用 1000 约定,以便他们在做广告时可以使用更大的数字,这就是为什么我在我的机器上安装的 1 TB 硬盘在 Windows 中被列为只有 931 GB。

    在检查代码中的文件大小时,我的建议是始终使用字节,因为这样可以避免这种差异并且更便于移植。

    【讨论】:

    • 我还要考虑到文件中包含的数据字节数与给定系统占用的磁盘空间之间存在差异(这取决于文件系统类型 - FAT32、NTFS、HFS+、ext3 等 - 和配置)。
    【解决方案2】:

    也许您正在比较磁盘大小(在 Mac 上)和您的脚本大小转换。磁盘大小取决于您的硬盘分区块大小。

    如果实际大小是 417.81 KB,而您的块大小是 200 KB(这不是一个真实示例),那么您的磁盘大小将是 600 KB。

    磁盘大小不是你文件的实际大小,而是你的文件在磁盘上占用的大小。

    希望这会有所帮助。

    【讨论】:

    • 不同的文件系统(以及块大小的格式化选项,即使在相同大小的文件系统上)也会导致相同的文件在不同的系统上占用不同的空间。
    【解决方案3】:

    似乎差异是由转换引起的。你做 1 KB = 1024 B,而 Mac 似乎做 1KB = 1000 B。

    【讨论】:

      猜你喜欢
      • 2013-05-28
      • 2016-01-05
      • 1970-01-01
      • 1970-01-01
      • 2012-05-01
      • 2016-04-23
      • 2010-10-17
      • 2014-04-20
      • 2011-07-30
      相关资源
      最近更新 更多