B を kB に変換

1 バイトは 8 ビットですが、いつもそう決まっていたわけではありません。初期の計算機は 6 ビット、7 ビット、9 ビットを使っていました。8 が勝ったのは、そこに 1 文字が収まり、しかもその数がきれいに半分ずつ割れるからです。

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

バイトからキロバイトへ移ると、小数点が左へ 3 桁ずれます。ほかには何も変わりません。覚えておく倍率もなければ、丸め方を決める必要もありません。数字は同じ並びのまま、位置だけが動きます。

1,234 B は 1.234 kB——同じ数字が、ずれただけです。ひと目で検算できる数少ない計算がこれです。結果の数字が始めたときの数字と違っていたら、それを変えたのはこの計算ではありません。

1 メガバイトを下回るうちは、バイト数そのものがまだ読める大きさです。誰も 27,504 バイトを理解できないから KB に変換するのではありません。比較したい相手——アセットの予算、フォームの上限、誰かが「30 KB」と言っていた別のファイル——がすべて KB で語られているから変換するのです。この変換は、その会話が使っている単位への翻訳です。

だからこそ、この規模では小数の精度が安く手に入ります。小数点第 1 位は 100 バイトを、第 2 位は 10 バイトを表すので、27.5 KB も 27.50 KB もどちらも正直な表記であり、後者は水増しではありません。もっと大きな桁では余分な数字は意味を失いますが、この規模では 0.1 KB が実際にファイルから削れる量に相当します。

ここでの KB は 1,000 バイトです。ですから変換は小数点を 3 桁分だけ左へ動かすだけの作業です。これは接頭辞 kilo の SI での意味であり、ドライブメーカーやネットワーク機器、あらゆるブラウザーの計測ツールが使う意味であり、KB・MB・GB がすべて同じ係数で関係し合う唯一の解釈でもあります。

1,024 バイトの単位は KiB と呼ばれ、この段階では両者の差が全体の中でいちばん小さく、2.4 パーセントです。アイコン 1 個なら無視できる差ですが、まとめて考えると 900 KB の予算と 900 KiB の予算では約 22 KB——ほぼ Web フォント 1 本分——の差になります。この差は段が上がるたびに広がり、ギガバイトでは 7.4 パーセントに達しますが、ここではまだ「同じに見える二つの数字」の違いにすぎません。

ファイルシステムは 1 バイトずつ容量を割り当てません。典型的には 4,096 バイトのブロック単位で割り当て、ファイルはそれを満たしていなくても丸ごと 1 ブロックを占有します。300 バイトのファイルは長さとしては 0.3 KB でも、ディスク上では 4 KB を占め、4,100 バイトのファイルは 8 KB を占めます。この無駄になった部分はスラック領域と呼ばれ、小さなアセットのフォルダーでは合計を軽く二倍にすることもあります。

ここは、バイト数と占有容量が単に一つの数字の別表現ではなく、本当に異なる量になる数少ない場所です。どちらを変換すべきかは問いの内容によります。アップロードの上限や転送予算が気にするのは長さで、端末の空き容量が気にするのは割り当てです。ツールも同じ線で分かれます。ファイル一覧は長さを、ディスク使用量ツールはブロックを報告し、この規模ではその二つは一致しません。

フロントエンドの予算がキロバイトで書かれるのは、その単位でこそ数字が比較できるからです。スタイルシート 18 KB、スクリプト 140 KB、フォント 24 KB という並びは誰かが議論できる数字ですが、同じ 3 つを 18,432、143,360、24,576 バイトと表記しても同じ会話は生まれません。この変換は、3 つのビルド成果物を一つの判断材料に変える作業です。

予算に本来入るべき数字は、たいてい圧縮後の値です。テキスト系アセットは gzip や brotli を介して配信され、140 KB のスクリプトがネットワーク上では 45 KB で済むこともあります。ビルドツールが生のバイト数だけを報告していると、実際の 3 分の 1 の見積もりになりかねません。どちらか明示されていない場合は、生のバイト数を 1,000 で割っただけで圧縮は考慮されていないと考えるのが安全です。

普通のネットワークではデータはパケット単位で運ばれ、Ethernet 経路の一般的な最大ペイロードはおよそ 1,500 バイトです。キロバイトで測るものはすでに小さなパケットの山であり、27.5 KB はおよそ 19 個分に相当します。実務上の帰結として、バイトを削ることには階段状の効果があります。1,600 バイトから 1,400 バイトへ削れば 1 パケットと往復が 1 回減りますが、40 KB を 39 KB にしてもユーザーが体感できる差はほとんど生まれません。

これはまた、ブラウザーが報告する転送サイズが、何も圧縮していなくてもファイルサイズよりわずかに大きく出る理由でもあります。各パケットはプロトコルのヘッダーを運び、接続自体もファイルが届く前に独自の準備段階を持ちます。ファイルをキロバイトに変換すれば内容の大きさが分かり、通信のコストはそこに数パーセント上乗せされ、非常に小さなファイルではその上乗せが全体の大半を占めることもあります。

平文の英語なら 1 キロバイトはおよそ 1,000 文字、段落 1 つ半程度です。ASCII では 1 文字 1 バイトで、Latin 文字の範囲であれば UTF-8 でも実質同じです。その範囲を外れると UTF-8 はギリシャ文字やキリル文字に 2 バイト、多くの漢字や日本語・デーヴァナーガリー文字に 3 バイト、絵文字に 4 バイトを使うので、同じ見た目のページでも言語によってサイズが 3 倍近く変わることがあります。

構造化データは、意味の量に対して散文より重くなります。説明的なキー名を持つ JSON レスポンスは、レコードごとにそのキー名を繰り返すことにバイト数の大部分を費やすため、数百行でも簡単に数十キロバイトに達し、圧縮がよく効く理由でもあります。バイナリ形式は逆で、小さな PNG はほとんどが圧縮済みの画素データなので、転送中にさらに縮むことはありません。

1,000 で割って小数点第 1 位に丸めると、公開される数字はたいてい実際より小さく見せるために切り下げられているため、過大よりわずかに過小に出やすくなります。予算や上限に使う数字なら切り上げてください。100 KB を受け付けるフォームに対して 99,987 バイトのファイルでは、あとで何かを追加する余地がまったくなく、実際にチェックが使うのはバイト数そのものだからです。

文章の中で使う数字なら小数点第 1 位で十分で、第 2 位はたいてい偽りの安心感にしかなりません。次のビルドでファイルは変わるからです。例外は上限やキャッシュのしきい値、1 パケットなど、境界線に近い場合で、そこでは正確なバイト数だけが問いに答え、キロバイトの数字はその要約にすぎません。