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 的幂。

千字节的两种可能定义会给开发者带来困惑，例如：

  • 以 2 的幂表示，65536 字节写为 64 KB
  • 以 10 的幂表示，65536 字节写为 65 KB（有剩余）

相同的值可以明确地写为 64 KiB，因为 KiB 始终是 2 的幂（1024）。

这种差异可能会导致准确率出现显著漂移。值越大，误差越大。

另请参阅：维基百科

设计

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

例如，大小为 65536 时，即为 64 KiB。

实现

系统会按发现情况提交 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”始终小写。

在不使用缩写的情况下描述字节时，请使用 kibibyte、mebibyte、gibibyte 等，如 IEC 所述。 未缩写值的首字母大写遵循美国英语或编码样式指南，具体取决于上下文。

面向开发者的资料中不会使用 KB、MB、GB（不区分大小写）等缩写。也不会使用千字节、兆字节、千兆字节。

缺点、替代方案和未知因素

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

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

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

  • 有些操作系统使用 1000 或 1024 的倍数，具体取决于操作系统版本。 这些差异可能是由于合作伙伴协议造成的，并且似乎会以两种方式（使用 2 的幂或 10 的幂）出现。这种情况发生在面向消费者的层面，在开发者层面是不应出现的。由于此 RFC 涉及面向开发者的文档、工具、API 等，因此未使用此替代方案。

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

  • 继续使用 2 的幂作为字节数（不含“i”中缀）。这并不合理，因为我们无法移除字节的 10 的幂的使用。也就是说，一些读者仍不清楚 1 KB 中有多少字节。

在先技术和参考资料

有相当多的在先技术和参考资料可供使用。此处列举了一些示例，但感兴趣的读者可以轻松地在 Google 上搜索更多相关历史信息（包括哪些公司做出了哪些选择以及何时做出的）。这可能是一件有趣的小事，但不太可能对 Fuchsia 的这项提案产生影响。

其他参考资料：

Ubuntu。

标准

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

示例

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

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