Base64：スペース使用量の増加として考えられる最悪のものは何ですか？

サーバーがbase64文字列を受け取り、変換前にその長さを確認したい場合は、最終的なバイト配列を常に16KBにすることを許可したいとします。Base64文字列に変換すると、16KBのバイト配列はどのくらいの大きさになる可能性がありますか（1文字あたり1バイトを想定）。

Base64は、3バイトの各セットを4バイトにエンコードします。さらに、出力は常に4の倍数になるように埋め込まれます。

これは、サイズnの文字列のbase-64表現のサイズが次のとおりであることを意味します。

ceil(n / 3) * 4

したがって、16kB配列の場合、base-64表現はceil（16 * 1024/3）* 4 = 21848バイト長〜= 21.8kBになります。

粗い近似は、データのサイズが元の4/3に増加していることであろう。

ウィキペディアから

入力がnバイトの場合、出力は（n + 2-（（n + 2）％3））/ 3 * 4バイトの長さになるため、入力バイトあたりの出力バイト数は4/3に収束することに注意してください。大きなnの場合は1.33333。

つまり、16kb * 4/3は、正確には21.3キロバイト（21848バイト）を少し上回ります。

お役に立てれば

16kbは131,072ビットです。Base64は24ビットバッファを4つの6ビット文字にパックするため、5,462 * 4 = 21,848バイトになります。

質問は考えられる最悪の増加に関するものだったので、通常、80文字ごとに改行があることを付け加えておきます。これは、Windowsでテキストファイルにbase64エンコードデータを保存する場合、Linuxでは各行に1バイトが追加され、2バイトが追加されることを意味します。

実際のエンコーディングからの増加については、上記で説明しています。

これは私自身の将来のリファレンスです。質問は最悪の場合なので、改行を考慮する必要があります。RFC 1421は最大行長を64文字と定義していますが、RFC 2045（MIME）は、1行に最大で76文字あると述べています。

後者は、C＃ライブラリが実装したものです。したがって、改行が2文字（\ r \ n）のWindows環境では、次のようになります。Length = Floor(Ceiling(N/3) * 4 * 78 / 76)

注：フローリングは、C＃を使用したテスト中に、最後の行がちょうど76文字で終了した場合、改行が行われないためです。

次のコードを実行して証明できます。

byte[] bytes = new byte[16 * 1024];
Console.WriteLine(Convert.ToBase64String(bytes, Base64FormattingOptions.InsertLineBreaks).Length);

76文字の行でbase64にエンコードされた16 kBytesの答え：22422文字

Linuxではそうなると思いますLength = Floor(Ceiling(N/3) * 4 * 77 / 76)が、.NETコアでのテストはまだできていません。