RFC-0004：位元組單位

MB."/>
RFC-0004：位元組單位
狀態已接受
區域
  • 管理事宜
說明

在 Fuchsia 中，會使用特定符號表示位元組的倍數。這樣一來，您就不必猜測 MB 的值，可提高清楚度。
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2020-06-09
審查日期 (年-月-日)2020-07-31

編輯這項 RFC

編輯 RFC 中繼資料

摘要

在 Fuchsia 中，會使用特定符號表示位元組的倍數。這樣就不必猜測「MB」的值，可提高清楚度。

位元組倍數 (例如 RAM、磁碟、檔案大小) 會使用 IEC 標記法。

  • 表示位元組群組時，所有 Fuchsia 開發人員文件和工具都會以 1024 個單位 (即 2 的次方) 呈現位元組的倍數。
  • KiB、MiB 和 GiB 分別代表 1024、1024^2 和 1024^3。
  • 以縮寫形式描述位元組時，一律使用「i」標記：KiB、MiB、GiB 等。第一個和最後一個字母大寫，中間的「i」一律小寫。
  • 開發人員相關資料不得使用 KB、MB、GB 縮寫 (不論大小寫)。也不會使用 KB、MB、GB。

這些規範適用於開發人員相關教材。本 RFC 並未嘗試提供使用者導向 (行銷/銷售) 標記的指南。

提振精神

有些人會以 2 的次方來計算位元組。因此，雖然 1 公里等於 1000 公尺，但這些人認為 1 KB 等於 1024 個位元組。Henkemans 另請參閱： Google 搜尋

在國際單位制中，千、兆、吉等值都是 10 的次方。

千位元組有兩種可能的定義，可能會造成開發人員混淆，例如：

  • 以 2 的次方表示，65536 個位元組會寫成 64 KB
  • 以 10 的次方表示，65536 個位元組會寫成 65 KB (有剩餘部分)

由於 KiB 一律是 2 的次方 (1024)，因此相同的值可明確寫為 64 KiB。

這項差異可能會導致準確度大幅下降。值越大，誤差就越大。

另請參閱： 維基百科

設計

所有 Fuchsia 開發人員文件和工具都會以 1024 個位元組為單位 (即 2 的次方) 呈現位元組倍數。

例如，65536 的大小正好是 64 KiB。

實作

系統會將錯誤歸類為已發現。這些錯誤的優先順序應相對較高，且必須在下一個版本發布前解決。

預期這些變更不會造成負擔，因為這些變更會快速顯示。但全面檢查所有文件和工具可能很麻煩。

這份文件將做為決定使用哪些單位的依據。提示：在回報錯誤時附上這份 RFC 的連結，方便瞭解相關背景資訊。

效能

這項變更可能會影響其他軟體的效能。舉例來說，如果現有測試測得的總處理量為 bytes / 1000 / time，但變更為 bytes / 1024 / time，總處理量可能會減少，即使實際效能相同 (即 bytes 和 time 維持不變)。

安全性考量

如果 API 或設定接受的大小輸入值會在內部乘以 1000，則變更為 1024 時可能會發生問題。(撰寫本文時，我們尚未發現這類情況)。

隱私權注意事項

預計不會有隱私權問題。

測試

由於建議的解決方案是持續更新的錯誤和 CL 清單，因此測試將由個別 CL 的可測試性需求處理。

說明文件

清楚的溝通是這項提案的核心。如果發現不符規定的問題，我們會更新說明文件，以符合這項 RFC。

規範

這些規範適用於開發人員相關教材。本 RFC 並未嘗試提供使用者導向 (行銷/銷售) 標記的指南。

以縮寫形式描述位元組時，一律使用「i」標記：KiB、MiB、GiB 等。第一個和最後一個字母大寫，中間的「i」一律小寫。

如要說明位元組，請使用 kibibyte、mebibyte、gibibyte 等，如 IEC 所述。視情況而定，未縮寫的值會遵循美國英文或程式碼樣式指南的規定。

開發人員相關資料不得使用 KB、MB、GB 縮寫 (不論大小寫)。也不會使用 KB、MB、GB。

缺點、替代方案和未知事項

實施這項提案的成本為何？

  • 聲明設計選擇並允許隨時間變更，預期成本會很低 (即併入審查程序和正常錯誤處理)。

還有哪些策略可以解決相同問題？

  • 部分作業系統會使用 1000 或 1024 的倍數，視作業系統版本而定。 這些差異可能是因為合作夥伴協議所致，且可能以 2 的次方或 10 的次方表示。這項異動發生在面向消費者的層級，開發人員層級不會受到影響。由於這項 RFC 與開發人員適用的說明文件、工具、API 等有關，因此不會使用這個替代方案。

  • 部分工具可選擇以不同倍數顯示值。我們認為這樣會讓這些工具變得不必要地複雜。

  • 繼續使用 2 的次方表示位元組 (不含「i」中綴)。我們無法移除位元組的十次方冪用法，因此這並不合理。也就是說，部分讀者仍不清楚 1 KB 含有多少位元組。

既有技術和參考資料

目前有相當多的既有技術和參考資料。本文列舉了幾個例子，但有興趣的讀者可以輕鬆在 Google 上搜尋更多歷史記錄 (包括哪些公司做出哪些選擇，以及時間)。這可能是有趣的冷知識，但不太可能與 Fuchsia 的提案有關。

其他參考資料：

Ubuntu。

標準

可供選擇的標準有很多，而本 RFC 從眾多標準中選擇了一種。

範例

  • IEC 推出 KiB、MiB、GiB...
  • JEDEC 嚴格定義位元組單位為以 2 為底數
  • 據說有些製造商甚至會使用混合標記法，例如 1024 * 1000 表示百萬位元組。
  • 部分作業系統使用 1000 的倍數，部分則使用 1024 的倍數
  • 部分標準會因主題是 RAM 或磁碟儲存空間而異

這項提案建議在所有面向開發人員的文件、工具和 API 等項目中，使用 IEC 指南 (以 1024 的倍數計算位元組)，而非嘗試導入其他標準或規則集。