RFC-0004：位元組單位

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

在 Fuchsia 中，特定標記法是用來表示位元組的倍數。如此一來，您就不需要猜出 MB 的值，讓內容更清楚好懂。
變更
  • 397239
作者
審查人員
提交日期 (年/月)2020-06-09
審查日期 (年/月)2020-07-31

編輯此 RFC

編輯 RFC 中繼資料

摘要

在 Fuchsia 中，特定標記法是用來表示位元組的倍數。這無需猜測「MB」的值，可提高明確程度。

IEC 標記法將用於多個位元組 (例如 RAM、磁碟、檔案大小)。

  • 指出位元組群組時，所有 Fuchsia 開發人員說明文件和工具都會以 1024 個單位 (即 2 次方數) 顯示位元組倍數。
  • 標籤 KibB、1024^2 和 1024^3 分別用於 1024、1024^2 和 10B。
  • 以縮寫格式描述位元組時，請一律使用「i」標記法：KB、MiB、GiB 等。第一個和最後一個字母大寫，中間的「i」一律為小寫。
  • 開發人員提供的內容中，不得使用縮寫 KB、MB、GB (不論字母大小寫)。也只會使用 KB、MB 和 KB。

這些規範的適用對象為開發人員提供的內容。此 RFC 不會嘗試提供面向使用者 (行銷/銷售) 標記的準則。

提振精神

有些人會衡量位元組，也就是 2 的次方。因此，儘管 1 公里是 1,000 公尺，這些人看到的是 1024 位元組。Henkemans 另請參閱 Google 搜尋

以「SI 單位」來說，千-、mega-、giga- 等的值為 10 的次方。

KB 的兩種可能定義會對開發人員造成混淆，例如：

  • 雙 65536 位元組會寫成 64 KB
  • 10 次方等於 65536 位元組會寫入為 65 KB (還有一些剩餘)

由於 KiB 一律是二 (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」標記法：KB、MiB、GiB 等。第一個和最後一個字母大寫，中間的「i」一律為小寫。

如在不採用縮寫的情況下說明位元組，請使用 IEC 的說明，使用 kibibyte、Mibibyte、GiB 等。空白值的大寫方式會遵循美國英文或程式設計樣式指南，視情境而定。

開發人員提供的內容中，不得使用縮寫 KB、MB、GB (不論字母大小寫)。也只會使用 KB、MB 和 KB。

缺點、替代方案和未知

實作這項提案需要多少費用？

  • 宣告設計選項並允許隨時間變更之後，成本將會很低，也就是同時融入審查程序和一般錯誤處理作業。

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

  • 視 OS 版本而定，某些 OS 會使用 1000 或 1024 的倍數。這些差異可能因合作夥伴協議的考量而產生，看似任一種方式 (使用 2 的次方或 10 的次方)。這在消費者端層級進行，因此不建議在開發人員層級進行。由於這個 RFC 與開發人員面向的說明文件、工具、API 等有關，因此不使用這個替代選項。

  • 有些工具可讓您選擇以不同倍數顯示值。我們認為這項技術可說是讓這些工具顯得更複雜。

  • 請繼續以二次方做為位元組單位 (沒有固定的「i」)。由於我們無法移除十位元組的力量，因此這並不合理。也就是說，部分讀取器不會知道每個 KB 包含多少位元組。

先前的圖片和參考資料

目前有許多先前的圖片和參考可供使用。此處列舉了一些範例，但有興趣的讀者可以透過 Google 獲得更多歷史記錄 (包括哪些公司做出了選擇，以及何時做出選擇)。這項益智問答或許深具意義，但這對 Fuchsia 而言不太可能是如此。

其他參考資料：

Ubuntu。

標準

目前有許多標準可以選擇，而這份 RFC 會從現有的許多標準中選擇一項標準。

範例

  • IEC 推出 KiB、MiB、GiB...
  • JEDEC 會將位元組單位明確定義為底數 2
  • 有些製造商甚至會使用混合標記，例如 1024 * 1000 的 MB。
  • 某些 OS 使用 1000 的倍數，部分使用 1024 的倍數
  • 有些標準會根據主題是 RAM 還是磁碟儲存空間，而採用不同的標準

比起嘗試導入其他標準或一組規則，本提案並未採用 IEC 準則，在 1024 的倍數中，在所有與開發人員使用的文件、工具、API 等項目中都會計算位元組的倍數。