MB を B に変換

1 メガバイトは 100 万バイトです。記憶装置のメーカーは昔から十進で数えてきました。だからその数字は、コンピューターが表示する数より大きく見えます。

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

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

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

サイズを受け付ける設定形式のほとんどは整数のバイト数を求めます。理由は、この領域の他のあらゆる単位があいまいだからです。バイトはどの体系でもどの慣習でも同じ量ですが、メガバイトは標準化団体やネットワーク技術者にとって 1,000,000 でも、多くのソフトウェアにとって 1,048,576 でもあります。バイトで定義されたフィールドは誤読されようがなく、まさにそれゆえバイトで定義されています。

10 進法のメガバイトからの変換は 100 万を掛けるだけです。1 MB は 1000000、10 MB は 10000000、50 MB は 50000000、512 MB は 512000000。これらはすべてこのページが使う体系ではきりの良い数字ですが、2 進法の単位では半端です。ファイルの中に 52428800 という数字を見つけたとき、それが何を意味していたかを見破る最初の手がかりでもあります。

10000000 を受け付ける同じフィールドが、しばしば 10M も受け付けますが、この接尾辞は桁の省略形ではありません。nginx は k を 1,024、m を 1,048,576 として読むので、client_max_body_size 10m は 10,485,760 バイトです。PHP も upload_max_filesize や post_max_size、memory_limit で同じように K、M、G を 1,024 のべき乗として扱います。GNU ツール群はこの区別を明示していて、M は 1,048,576、MB は 1,000,000 を意味し、別々の接尾辞です。

この差はメガバイトの規模で 4.9 パーセントあり、レビューをすり抜けるほど小さく、境界では重要になるほど大きい値です。ファイルの中でも見分けが付きません。10M と 10000000 は同じ意図に見えて 485,760 バイトの差があります。設定が両方の形式を受け付けるなら、ファイル全体で一つの慣習を選び、先頭にそう書いておいてください。次にこの数字を編集する人が同じ問いをもう一度解かずに済みます。

書くべき値は、チームが見るダッシュボードやログ、エラーメッセージでそのサイズを表示するツールにとって正しく見える数字です。もしダッシュボードがメビバイトでサイズを表示するなら、10485760 はきれいな 10 MiB として表示され、10000000 は 9.54 という、誰かが間違えたように見える数字として表示されます。周囲の文書や顧客向けの上限、マーケティングページがすべて 10 MB と言っているなら、10 進法の数字がそれらを一致させ続けます。

うまくいかないのは、各所で独立に選んでしまうことです。プロキシが 10485760 に、アプリケーションが 10000000 に設定されたスタックには 485,760 バイトの隙間があり、そこではリクエストが最初の検査を通過して二番目で失敗し、返ってくるのは境界でのはっきりした拒否ではなくアプリケーション側のエラーになります。どちらの数字を選ぶかより、経路全体での一貫性のほうが重要です。

ファイルのアップロードは通常、少なくとも三つの設定された天井を越えます。リバースプロキシやロードバランサーの本体サイズ上限、ランタイムやアプリケーションサーバーの上限、そしてアプリケーション内のフレームワークやストレージ側の上限です。それぞれ別々に、しばしば異なる時期に異なる人によって設定され、いちばん小さいものが実際の挙動を決めます。誰もが知っている値だけを引き上げて残り二つを放置することが、上限の変更が何の効果もないように見えるいちばんよくある理由です。

どこで発動するかは結果だけでなく体験も変えます。エッジでの拒否は、本体のアップロードが終わる前に、速くきれいに届きます。アプリケーション層での拒否はファイル全体の転送が終わったあとに届き、遅い回線では失敗を待つのに何分もかかります。エッジの上限をアプリケーションの上限よりわずかに高く設定しておけば、ユーザーが見るのは役に立つほうのエラーになります。

上限はリクエスト本体に適用され、リクエスト本体はファイルより大きくなります。マルチパートのフォームデータは各パートを境界行とヘッダーで包み、これはフィールドあたり数百バイトの固定コストで、大きなファイルでは無視できます。Base64 は無視できません。3 バイトごとに 4 文字の印字可能文字に変えるので、JSON の中に運ばれるファイルはおよそ 33 パーセント膨張し、10 MB のファイルはおよそ 13.4 MB の本体として届きます。

ですから 10 MB のファイルを受け付けるつもりの上限は、ファイルサイズではなくエンコード後のサイズから設定すべきです。マルチパートなら数百キロバイトの余裕で十分です。JSON 内の Base64 なら 4/3 を掛けて余裕を足してください。14000000 の上限なら 10 MB のファイルを余裕をもって受け付けますが、10000000 では 7.5 MB を超えるものをすべて拒否し、「上限がおかしい」というバグ報告を生みます。

設定ファイルの中の裸の 52428800 という数字は誰にも検証されず、間違った値でも一見正しい値と見分けが付きません。式を許す形式なら 50 1024 1024 と書いて、読む人にその由来を見せてください。リテラルしか許されないなら、その行の上にコメントとして計算過程を書いてください。意図したサイズ、それがどの体系か、その値が一致すべきツールです。

その数字がどこから来たかを記録しておく価値もあります。顧客との契約が 50 MB と定めているから存在する上限と、メモリープロファイルがそう言ったから存在する上限は別のもので、変更される理由も違います。由来の書かれていない設定値は、不用意に引き上げられるか、いつまでも守られ続けるかのどちらかになりがちで、コメントの一文がその両方を防ぎます。

サイズを理由にリクエストが拒否されたとき、多くのシステムは設定された上限を、多くは受信したサイズもバイトで報告します。この二つの数字は最速の診断手段です。報告された上限はスタックの中のどれか一つの値と正確に一致するので、どの層が拒否したかが分かり、接尾辞が期待どおりに解釈されたかどうかも確認できます。

ファイルが 10000000 と言っているのに上限が 10485760 と報告されれば、接尾辞が 2 進法で読まれたということです。設定した覚えのない層から上限が報告されれば、天井は思っていた場所にありません。どちらもエラーログの 1 行で見つけられ、少しずつ大きいファイルをアップロードして何かが壊れるまで試すよりずっと簡単です。