RFC-0004：字节单位

MB."/>
RFC-0004：字节单位
状态已接受
区域
  • 治理
说明

在 Fuchsia 中，使用特定的符号来表示字节的倍数。这样可以消除猜测 MB 值的需要，从而提高清晰度。
Gerrit 更改
作者
审核人
提交日期（年-月-日）2020-06-09
审核日期（年-月-日）2020-07-31

修改此 RFC

修改 RFC 元数据

摘要

在 Fuchsia 中，使用特定的符号来表示字节的倍数。这样一来，用户无需猜测“MB”的值，从而提高了清晰度。

IEC 表示法将用于字节的倍数（例如 RAM、磁盘、文件大小）。

  • 在表示字节组时，所有 Fuchsia 开发者文档和工具都会以 1024 为单位（即 2 的幂）显示字节的倍数。
  • 标签“kibibyte”“mebibyte”“gibibyte”分别用于 1024、1024^2 和 1024^3。
  • 以缩写形式描述字节时，请始终使用“i”表示法：KiB、MiB、GiB 等。第一个字母和最后一个字母应采用大写形式，中间的“i”始终采用小写形式。
  • 在面向开发者的材料中，请勿使用 KB、MB、GB 等缩写形式（无论大小写）。也不得使用千字节、兆字节、千兆字节。

这些准则适用于面向开发者的材料。本 RFC 不尝试提供面向用户（营销/销售）的符号指南。

设计初衷

有些人会以 2 的幂来衡量字节。因此，虽然 1 公里等于 1000 米，但这些人会将 1 千字节读作 1024 字节。Henkemans 另请参阅 Google 搜索

在 SI 单位中，千、兆、亿等值是 10 的幂。

千字节的两种可能定义会让开发者感到困惑，例如：

  • 以二进制幂表示，65536 字节写为 64 KB
  • 以十的幂为单位，65536 字节写为 65 KB（有剩余）

由于 KiB 始终是 2 的幂 (1024)，因此可以将相同的值明确地写为 64 KiB。

这种差异可能会导致准确性出现明显偏差。随着值增大，误差会增加。

另请参阅： 维基百科

设计

所有 Fuchsia 开发者文档和工具都会以 1024 为单位（即 2 的幂）显示字节的倍数。

例如，大小为 65536 的缓冲区正好为 64 KiB。

实现

发现 bug 后，我们会立即进行报告。这些 bug 应被列为优先级较高的 bug，并在下一个版本发布之前解决。

我们希望这些更改不会给您带来太多负担，只要及时处理即可。但全面审核我们的所有文档和工具可能很繁琐。

本文档将作为确定要使用哪些单位的依据。提示：在提交的 bug 中添加指向此 RFC 的链接，以提供背景信息。

性能

这项更改可能会改变其他软件的实际性能。例如，如果现有测试测量的吞吐量为 bytes / 1000 / time，然后更改为 bytes / 1024 / time，吞吐量可能会看起来有所降低，即使实际性能完全相同（即 bytes 和 time 保持不变）也是如此。

安全注意事项

如果某个 API 或配置接受的大小输入在内部乘以 1000，那么如果将其更改为 1024，可能会出现问题。（截至本文撰写之时，尚未发现这种情况）。

隐私注意事项

预计不会出现隐私问题。

测试

由于提出的解决方案是随着问题的发现而不断更新的 bug 和 CL 列表，因此测试将由各个 CL 的可测试性要求处理。

文档

清晰的沟通是此提案的核心。一旦发现不合规问题，文档将会更新以符合此 RFC。

指南

这些准则适用于面向开发者的材料。本 RFC 不尝试提供面向用户（营销/销售）的符号指南。

以缩写形式描述字节时，请始终使用“i”表示法：KiB、MiB、GiB 等。第一个字母和最后一个字母应采用大写形式，中间的“i”始终采用小写形式。

在描述字节时，请使用 IEC 中所述的 kibibyte、mebibyte、gibibyte 等单位，而不是使用缩写形式。不缩写的值的大小写遵循美国英语或编码样式指南（具体取决于上下文）。

在面向开发者的材料中，请勿使用 KB、MB、GB 等缩写形式（无论大小写）。也不得使用千字节、兆字节、千兆字节。

缺点、替代方案和未知情况

实施此方案的费用是多少？

  • 通过声明设计选项并允许随时间推移进行更改，预计成本会很低（即与审核流程和常规 bug 处理相融合）。

还有哪些策略可以解决同一问题？

  • 某些操作系统使用 1000 或 1024 的倍数，具体取决于操作系统的版本。差异可能是因为合作伙伴协议而产生的，并且似乎可以采用任一方式（使用 2 的幂或 10 的幂）。这在面向消费者的级别会发生，但在开发者级别不应发生。由于本 RFC 涉及面向开发者的文档、工具、API 等，因此不会采用此替代方案。

  • 某些工具提供以不同倍数显示值的选项。我们认为，这会不必要地使这些工具变得复杂。

  • 继续使用二进制幂来表示字节（不带“i”中缀）。这不合理，因为我们无法移除对字节使用十进制幂的用法。也就是说，一些读者仍然不清楚 1 KB 中有多少字节。

在先技术和参考文档

有大量的现有技术和参考文献可供使用。本文中列举了一些示例，但感兴趣的读者可以轻松在 Google 上搜索更多历史信息（包括哪些公司做出了哪些选择以及做出这些选择的时间）。这可能是一个有趣的琐事，但不太可能与 Fuchsia 的此提案相关。

其他参考文档：

Ubuntu。

标准

有多个标准可供选择，而本 RFC 从众多标准中选择了一个标准。

示例

  • IEC 引入了 KiB、MiB、GiB...
  • JEDEC 明确将字节单位定义为以 2 为底数
  • 显然，有些制造商甚至使用了混合表示法，例如将兆字节表示为 1024 * 1000。
  • 有些操作系统使用 1000 的倍数，有些则使用 1024
  • 有些使用不同的标准，具体取决于主题是 RAM 还是磁盘存储

该提案建议在面向开发者的所有文档、工具、API 等中使用 IEC 准则（其中以 1024 的倍数来统计字节），而不是尝试引入其他标准或规则。