kB を MiB に変換

1 キロバイトは、標準化団体が定義すれば 1,000 バイトで、OS が定義すれば 1,024 バイトです。このページは 1,000 で計算します。1,024 のほうはキビバイトという名前を持っています。

1 メビバイトは 1,024 キビバイト、つまり 1,048,576 バイトです。Linux のツールとメモリーの数値は、表示が「MB」であってもほぼ常にこちらを指しています。

倍率は 0.000954 で、これをそのまま持ち歩く人はまずいません。0.00095 に丸めると 0.39 % ずれます。小さい数では見えもしませんが、1,000 kB あたりで、ずれは丸ごと 1 単位になります。

丸める前に知っておく価値があるのは、ずれの大きさそのものではなく、それを無視できなくなる地点のほうです。それより下なら短い倍率が賢明で、それより上なら上の入力欄を使ってください。あちらは書き出す前に丸めません。

MiB 1 つはひとつ下の単位の 1,024 倍で、MB 1 つは 1,000 倍です。このページでは 1048.576 kB と 1000 kB の差——4.9 %——になり、段を上がるごとにこの隔たりは開いていきます。写真 1 枚では丸め誤差でしかないものが、ハードディスクでは目に見える割合になるのはそのためです。

「容量が消えた」という話の中身は、これだけです。MB で売られたディスクには、書いてあるとおりのバイト数が入っています。それを 1,000 ではなく 1,024 で割り、名前は MB のまま表示しているのが Windows です。macOS は 10.6 以降ディスクの容量を十進の単位で数えているので、同じディスクが 2 台のパソコンで違う大きさに見えることがあります。減ったものはなく、丸めているのでもありません。同じバイト数に、名前が 2 つあるだけです。

フロントエンドのプロジェクトは 2 つの慣習を同時に抱えていて、それがはっきり示されることはめったにありません。ネットワークパネルは転送サイズを 1,000 バイト単位のキロバイトで報告し、パフォーマンスの指針も同じ書き方で、CDN の請求も帯域が昔から売られてきた方法にならって 10 進法のギガバイトを数えます。一方で、その裏にあるビルドツールやプロキシキャッシュ、ブラウザーのストレージ上限はどれも 1,024 のべき乗で数えています。

両者の間の換算は、接頭辞の段を 1 つ移動するのと、10 進法から 2 進法へ乗り換えるのを同時に行うため、1,000 ではなく 1,048.576 で割ることになります。3,000 kB のバンドルでは 3.00 と 2.86 の違いになり、正しいのは小さいほうです。2 進法の上限を 10 進法の簡便法で確認すると、実際より常に多くの余裕があるように見えてしまい、これは確認としては望ましくない方向のずれです。

覚えておく価値がある数字は、500 kB が 0.4768 MiB、1,000 kB が 0.9537、2,000 kB が 1.9073、5,000 kB が 4.7684 になるというものです。ネットワークパネルが 2,090 kB と合計したページは、2 MiB の予算を超えていません。2 MiB は 2,097.152 kB だからです。ただしその差はわずか 7 キロバイトしかなく、10 進法の 2 MB という基準で読んでいたら、実際にはまだ余裕があるうちから予算超過だと判定していたことになります。

2 進法で示された上限を 10 進法で読んだ場合は逆方向のずれが起きます。50 MiB のキャッシュには 50,000 ではなく 52,428.8 kB のアセットが収まり、丸い数字を基準にした容量計画では、キャッシュの 2.5 メガバイト近くを使い残したままにしてしまいます。どちらの誤りも大きくはありませんが、どちらも系統的で、同じ計算を繰り返すたびに同じ方向に積み重なります。

この 4.9 パーセントの議論をする前に、どちらのサイズを測っているかを決めておく価値があります。テキストのバンドルは非圧縮時のおよそ 3 分の 1 かそれ以下に圧縮できるのがふつうなので、同じファイルでも、ビルドが出した数字なのか、ネットワークを通過した数字なのかによって、正直に 900 kB とも 260 kB とも言えてしまいます。これは 5 パーセントの単位の問題より前に効いてくる、3 倍規模の差です。

そのため予算には、単位だけでなく状態も明記すべきです。転送後か、圧縮後か、ディスク上の生のサイズか。ビルドツールはたいてい非圧縮のアセットサイズを報告します。それが手元にある情報だからです。ブラウザーのパネルは転送されたバイト数を報告します。それが観測できたものだからです。どちらの状態を管理する上限なのか明記していない上限は、そのツールがたまたま持っていたほうの数字に対して適用されてしまい、両者は比較できるものではありません。

多くのバンドラーはアセットサイズの上限を素のバイト数で受け付けられ、この形にすれば接頭辞について合意する必要がなくなります。250,000 バイトという上限には曖昧さがなく、grep で正確に見つかり、同じツールが報告するバイト数と直接比較できます。250 kB と書かれた上限は同じ意図に注釈が付いているだけで、その注釈こそが設定を別のプロジェクトへコピーしたときに失われる部分です。

ツールがどうしても接頭辞を求める場合は、2 進法の接頭辞を選び、それを明示してください。プロキシ設定の 50m というキャッシュ上限は、読み手がどう思っていても 52,428,800 バイトであり、その横に MiB とコメントを添えるだけで済みます。代わりに何もしなければ、誰もが 5,000 万バイトだと信じている上限が、実際にはおよそ 250 万バイト多いままになります。

パフォーマンス予算は、小さく着実な肥大化を見つけるために存在します。この単位のずれが吸収してしまう量は、その検知したい肥大化とほぼ同じ規模であることが多いです。1 リリースあたり 4 パーセントの肥大化は、まさに予算が旗を立てるべき種類の変化であり、それがちょうど 10 進法と 2 進法の食い違いが誰にも気づかれずに吸収してしまう量でもあります。この単位のずれ 1 回分だけで、実際の肥大化の 4 分の 1 相当を隠してしまうことになります。

対策は、報告される数字としきい値を同じ出所から来るようにすることです。ビルドツールがバイトで測るならバイトで予算を設定し、モニタリングが転送後のキロバイトを測るなら転送後のキロバイトで予算を設定してください。報告としきい値の間にある変換のたびに、系統的なずれが住み着いて動かなくなる余地が生まれます。

キャッシュやデータベース、永続化された状態といったクライアント側のストレージは、ブラウザーが空きディスクから計算した上限と比較され、そこで報告されるバイト数は接頭辞なしの正確な値です。ストレージの見積もりに問い合わせると、使用量と上限がバイトで返ってきます。比較にはこの形を使い、表示用にメビバイトへ変換するのは後の見た目の話として扱ってください。

生のバイト数を保持しておく理由は、上限が変動するからです。空きディスクの状況やオリジンのストレージクラス、ブラウザーの方針に左右されるため、先週は 500 MiB だった値が今週は違うかもしれません。バイト数を保存してそのつど再確認するコードはこうした変化に正しく対応しますが、換算済みの数字を使いやすい単位でハードコードしたコードはそうなりません。