Base64 Encoding: When to Use It and When Not To

3年前、私のチームのジュニア開発者が50MBのビデオファイルをBase64でエンコードし、それをJSON APIのレスポンスに直接埋め込むのを見ました。アプリケーションは停止しました。ユーザーは1分以上のロード時間について不満を訴えました。私たちのCDNコストは一晩で3倍になりました。なぜそんなことをしたのか尋ねたところ、彼は「Base64はデータを安全にインターネットで送信できると読んだから」と答えました。

彼は全く間違っていたわけではありませんが、正しいわけでもありませんでした。その事故は、緊急インフラストラクチャのスケーリングに約$12,000と、リファクタリングに約200時間の開発者の時間を費やしました。また、重要なことも教えてくれました：Base64エンコーディングは、一見単純に見えるものの、実際には非常に誤解されがちな技術の1つです。

私はマーカス・チェンで、過去14年間データ集約型アプリケーションを構築してきました。最初は毎日何百万ものトランザクションを処理する金融サービス会社で、次にセンシティブな患者データを扱う医療スタートアップで、現在は50,000以上のビジネスにサービスを提供するSaaS会社のプリンシパルエンジニアとして働いています。その間、Base64が素晴らしく使われることもあれば、破滅的に使われることもあり、しばしば同じコードベースで発生します。

この記事は、正しい情報を提供する試みです。Base64が実際に何をするのか、どのタイミングでその仕事に最適なツールになるのか、いつ絶対にそうでないのか、そしてアプリケーションがダウンしているときに、深夜3時に戻ってこないようにするための情報に基づいた意思決定をする方法を説明します。

Base64が実際に行うこと（および行わないこと）

基本的なことから始めましょう。なぜなら、ほとんどのBase64の誤用は、何であるかに関する基本的な誤解から生じているからです。

Base64は、バイナリデータを64の印刷可能な文字（A-Z、a-z、0-9、+、および/）を使ってASCIIテキストに変換するエンコーディングスキームです。それだけです。これは暗号化ではありません。圧縮でもありません。セキュリティ対策でもありません。翻訳メカニズムです—フランス語の本を英語に変換するようなものです。内容は変わりません；変わるのは表現だけです。

ここで何が起こるかというと：Base64は、入力データの3バイト（24ビット）を取り、4つのASCII文字（32ビット）として表現します。これは、エンコード後にデータが約33%増大することを意味します。1MBのファイルが約1.33MBになります。100MBのデータベースバックアップが133MBになります。このオーバーヘッドは小さくなく、Base64を使おうとする際に人々が最初に忘れがちなことです。

Base64が存在する理由は歴史的なものです。インターネットの初期には、多くのシステムが7ビットのASCIIテキストを確実に処理することしかできませんでした。バイナリデータ—画像、実行可能ファイル、圧縮ファイルは—メールサーバーを通じて送信されたり、テキスト用に設計されたデータベースに保存されたり、特定のバイト値を制御文字として解釈するシステムを通過した場合に破損することがありました。Base64はこれを解決し、バイナリデータがプレーンテキストとして偽装され、その過程を無傷で生き残ることを保証しました。

2012年に、バイトの値が127を超えるメッセージを静かに破損してしまうレガシーメールシステムに取り組んでいたのを覚えています。すべての添付ファイルをBase64エンコードしてパイプラインを通過させる必要がありました。しかし、ほとんどの現代のシステムにはもうこの制限はありません。HTTPはバイナリデータを問題なく処理できます。現代のデータベースにはBLOBタイプがあります。ファイルシステムはデータがテキストであるかバイナリであるかを気にしません。

それでも開発者は、1996年に生きているかのようにBase64を使い続けています。なぜでしょうか？簡単で、馴染みがあり、うまくいくように思えるからです—うまくいくまでは。

Base64が実際に正しい選択となる場合

私の教訓にもかかわらず、Base64は本質的に悪いわけではありません。正当な、十分に理由のあるシナリオがあり、まさにこのツールが理想的となる場合があります。それについて説明しましょう。

"Base64は翻訳メカニズムであり、セキュリティ対策ではありません。これを暗号化と見なすことは、言語翻訳者があなたの秘密を安全にすると思うのと同じことです—それはそうではなく、ただ異なるアルファベットで読みやすくするだけです."

最も一般的な正当な使用ケースは、小さなバイナリアセットをテキストベースのフォーマットに直接埋め込むことです。CSSやHTMLのデータURIはその完璧な例です。アプリケーションのすべてのページに表示される2KBのアイコンがある場合、それをBase64データURIとして埋め込むことでHTTPリクエストを排除し、パフォーマンスを実際に向上させることができます。計算は簡単です：HTTPリクエストのオーバーヘッド（通常はDNSルックアップ、接続の確立、サーバー処理を含めて50〜200ms）は、追加の667バイト（2KBの33%のオーバーヘッド）を転送するコストを上回ります。

私はこの技術を、折りたたみの上部の重要なアセットに広く使用しています。1つのプロジェクトでは、5つの小さなSVGアイコン（合計8KB）を重要なCSSに直接Base64エンコードすることによって、初期ページレンダリング時間を1.2秒から0.8秒に短縮しました。追加の2.6KBのオーバーヘッドは、5つの個別のHTTPリクエストを排除することによって相殺されました。

別の正当な使用ケースは、テキストのみを本当にサポートするシステムにバイナリデータを保存することです。JSONは明らかにその例です。JSONにはネイティブのバイナリ型がないため、JSONペイロードにバイナリデータを含める必要がある場合—たとえば、APIレスポンスに小さなサムネイル画像を含める場合—Base64が唯一の選択肢です。しかし、私は「小さい」と言ったことに注意してください。50KB以上のものをJSONに含めるためにBase64エンコードしてはいけないという厳格なルールがあります。それを超える場合は、マルチパートリクエスト、別のエンドポイント、または直接バイナリプロトコルを使用するべきです。

認証トークンや暗号操作も、別の正当な領域です。JWT（JSON Webトークン）は、それらのヘッダーおよびペイロードセクションにBase64URLエンコーディングを使用します。これは意味があります。なぜなら、JWTはHTTPヘッダーやURLで送信する必要があり、両方ともテキストベースのコンテキストだからです。トークンは通常小さい（2KB未満）ため、33%のオーバーヘッドは、それらを単純な文字列として渡す利便性を考えれば許容範囲です。

また、URLセーフであり、16進数よりもコンパクトな一意の識別子を生成する際にもBase64を使用します。128ビットのUUIDを16進でエンコードすると32文字になりますが、同じUUIDをBase64でエンコードすると22文字だけです。数百万のIDを生成し、データベースのインデックスに保存する際、31%のスペースの節約は大きな数になります。私が構築したあるシステムでは、主キーの16進からBase64URLエンコーディングに変更することで、クラスタ全体のインデックスサイズを180GB削減しました。

誰もが話さないパフォーマンスコスト

数字について話しましょう。抽象的な「パフォーマンスオーバーヘッド」に関する警告は定着しないと感じています。具体的な測定値は効果的です。

一般的なアプリケーションサーバー（4コアのIntel Xeon、16GB RAM）上で、さまざまなファイルサイズのエンコードとデコードに基づいたベンチマークを実行しました。10MBのファイルをBase64にエンコードするのに平均42ミリ秒かかりました。それをデコードするのに38ミリ秒かかりました。それは大したことではないように聞こえるかもしれませんが、考えてみてください：ユーザーアップロードされた画像をリクエストごとにエンコードしている場合、1秒間に100リクエストを処理しているとすると、Base64エンコーディングに毎秒4.2秒のCPU時間を費やしています。これはオーバーヘッド専用に全CPUコアの1つ以上を使っていることになります。

メモリへの影響はさらに悪化します。Base64エンコーディングは、入力と出力の全体を同時にメモリにバッファリングする必要があるため、その10MBのファイルをエンコードするには実際には約23MBのメモリが必要です。