RFC-0004：字节单位

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

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

修改此 RFC

修改 RFC 元数据

总结

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

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

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

这些指南适用于面向开发者的资料。此 RFC 不会尝试为面向用户（营销/销售）的表示法提供准则。

设计初衷

有些人以 2 的次方来衡量字节数。因此，当一公里为 1000 米时，这些人将 1 千字节读为 1024 字节。Henkemans 另请参阅，Google 搜索

在 SI 单位中，千、兆、吉等的值为 10 的幂。

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

  • 65536 字节的 2 次方，写入为 64 KB
  • 10 次方，65536 字节写入为 65 KB（有一些剩余部分）

相同的值可以明确写为 64 KiB，因为 KiB 始终为 2 (1024) 的幂。

这种差异可能会导致准确性出现显著偏移。错误值越大，错误就越大。

另请参阅：维基百科

设计

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

例如，65536 的大小确切为 64 KiB。

实现

如已发现错误，我们会提交。这些 bug 的优先级应相对较高，并且会在下一个版本发布之前得到解决。

正常情况下，这些更改看起来不会像以前一样快速处理，所以不会造成负担。然而，对所有文档和工具进行全面审核可能非常繁琐。

本文档将决定应使用哪些单元。提示：请在提交的 bug 中添加指向此 RFC 的链接，以提供背景信息。

性能

这一变化可能会改变其他软件的感知性能。例如，如果现有测试将吞吐量测量为 bytes / 1000 / time 并更改为 bytes / 1024 / time，那么即使实际性能相同（即当 bytes 和 time 保持不变时），吞吐量似乎也会降低。

安全注意事项

如果 API 或配置接受的大小输入值在内部乘以 1000，如果该输入值更改为 1024，可能会出现问题。（在撰写本文时，还不知道会发生这种情况。）

隐私注意事项

未预见到任何隐私问题。

测试

由于建议的解决方案是在发现问题时不断发布的 bug 和 CL 列表，因此测试将根据各个 CL 的可测试性要求进行处理。

文档

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

指南

这些指南适用于面向开发者的资料。此 RFC 不会尝试为面向用户（营销/销售）的表示法提供准则。

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

如果描述字节时不采用缩写形式，请使用 kiB、MiB、GiB 等，如 IEC 所述。不缩写值的大小写形式遵循美式英语或编码样式指南，具体取决于上下文。

系统不会在面向开发者的材料中使用缩写 KB、MB、GB（无论字母大小写如何）。也不会使用千字节、兆字节和千兆字节。

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

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

  • 通过声明设计选择并允许随时间进行更改，预计开销将会降低（即纳入审核流程和正常的 bug 处理）。

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

  • 一些操作系统使用 1000 或 1024 的倍数，具体取决于操作系统版本。 这种差异可能是由合作伙伴协议造成的，并且看上去是方向性的（使用 2 的幂或 10 的幂）。此操作是在面向消费者的级别发生的，在开发者级别是不需要的。由于此 RFC 涉及面向开发者的文档、工具、API 等，因此不使用此替代方案。

  • 某些工具支持以不同倍数显示值。我们认为，这会使这些工具变得不必要的复杂化。

  • 继续使用 2 的幂表示字节（不加“i”后缀）。这不合理，因为我们无法取消对字节的 10 次幂的使用。也就是说，有些读者仍然不清楚 KB 中有多少字节。

早期技术和参考资料

有很多先有技术和参考资料。此处提供了一些示例，感兴趣的读者可以轻松通过 Google 查询更多历史记录（包括哪些公司做出了哪些选择以及何时做出）。这可能是一个有趣的知识问答，但不太可能与 Fuchsia 的这一方案有关。

其他参考：

Ubuntu。

标准

有多种标准可供选择，并且此 RFC 会从现有标准中选择一个标准。

示例

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

此方案建议采用 IEC 准则，而不是尝试引入其他标准或一组规则，在面向开发者的所有文档、工具、API 等中，字节数均以 1024 的倍数计算。