Base64 Encoding: When to Use It and When Not To

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

その瞬間は、私がさまざまなSaaS企業で12年間バックエンドインフラエンジニアとして観察してきたことをクリスタル化しました：Base64エンコーディングは、開発者のツールキットの中で最も有用であり、同時に最も誤用されるツールの1つです。それは人々がハンマーとして使おうとするスイスアーミーナイフのようなものです。

私はサラ・チェンです。データパイプラインを構築・最適化することに10年以上を費やしており、毎月数十億のリクエストを処理しています。私は、Base64が複雑なエンコーディングの問題を解決するために素晴らしく使用されるのを見てきましたし、同時に企業に何万ドルものコストをもたらす壊滅的なパフォーマンス問題を引き起こすのを見てきました。今日は、Base64があなたの最良の友である時と、最悪の敵である時について学んだことを共有したいと思います。

Base64が実際に行うこと (およびしないこと)

基礎から始めましょう。多くの開発者がBase64を使用する際に、実際に何が起こっているのかを深く理解していないことがわかりました。Base64は、64の印刷可能な文字（A-Z、a-z、0-9、+、および/）を使用してバイナリデータをASCIIテキストに変換するエンコーディングスキームです。それが全てです。それは暗号化ではありません。それは圧縮ではありません。表現の変換です。

ほとんどの人が見逃す重要なことは、Base64がデータサイズを約33%増加させるということです。入力の3バイトごとに、出力は4バイト得られます。これはバグではありません—それは8ビットバイトを1キャラクターあたり6ビットの情報だけを使って表現するという数学的現実です（2^6 = 64の可能なキャラクター）。

これを開発者に説明するとき、私はシンプルな例えを使います：家を引っ越すと考えて、標準的な段ボール箱にしかアイテムを運べないとします。あなたのいくつかの持ち物はうまく収まりますが、形が変わったランプなどは大きな箱を必要とし、たくさんのパッディングが必要です。Base64はそのパッディングです。あなたはデータを制約のある輸送フォーマット（ASCIIテキスト）に適合させているため、追加のスペースが必要になります。

エンコーディングプロセスは、3バイト（24ビット）のバイナリデータを取得し、それを4つの6ビットグループに分割します。各グループはBase64アルファベットの64文字の1つにマッピングされます。入力が3で完璧に割り切れない場合、最終グループを完成させるためにパディング文字（=）が追加されます。これが、Base64文字列の最後にイコールサインが1つまたは2つ見られる理由です。

コードベースの監査経験に基づけば、約40%のBase64の使用は、提供しているものについての基本的な誤解から来ているとわかりました。開発者は彼らがセキュリティを手に入れていると思っています（実際にはそうではありません—Base64は簡単に逆転可能です）、または圧縮（その逆が真実です）、あるいは何らかの魔法のデータサニタイズを期待しています。Base64が実際に行うことを理解することは、適切に使用するための第一歩です。

完璧なユースケース：Base64が輝く場所

サイズのオーバーヘッドにもかかわらず、Base64が絶対に正しい選択肢であるシナリオがあります。私は主な利点がコストを上回る5つの主要なユースケースを特定し、これらは生産システムで定期的に出会います。

「Base64は暗号化ではなく、圧縮でもありません—それはデータサイズを33%増加させる表現の変換です。この基本的な真実を理解することが、賢く使用することとパフォーマンスの災害を引き起こすことの違いです。」

テキストベースの形式にバイナリデータを埋め込むこと。これは元々の、そして依然として最も正当なユースケースです。JSON、XML、またはHTMLにバイナリデータ（画像、フォント、証明書）を含める必要があるとき、Base64はしばしば唯一のオプションです。最近、小さな会社のロゴ（10KB未満）をHTMLメールにBase64データURIとして直接埋め込むメールテンプレートシステムに取り組みました。これにより、外部HTTPリクエストが排除され、ユーザーがデフォルトで画像を無効にしていてもロゴが表示されることが保証されました。この33%のサイズ増加は、信頼性の向上に見合うものでした。

テキスト専用プロトコルを介したバイナリデータの送信。いくつかのレガシーシステムやプロトコルは、ASCIIテキストのみをサポートしています。私はかつて、7ビットのASCIIしか受け付けない1990年代のメインフレームシステムとの統合を維持していました。全てのバイナリ添付ファイルを送信前にBase64エンコードする必要がありました。代替手段は本当にありませんでした。このシステムは毎日約50,000のトランザクションを処理し、Base64エンコーディングは合計処理時間に約2秒の追加をしました—メインフレームの他のボトルネックと比べると無視できるものでした。

バイナリサポートのないデータベースにバイナリデータを保存すること。ほとんどの現代のデータベースはバイナリデータをうまく処理しますが、私はBase64エンコードされたテキストを保存する方がBLOBフィールドを扱うよりも簡単なシステムで作業したことがあります。ある特定のケースでは、分散されたSQLite設定で、レプリカ間でBLOB処理が不一致でした。Base64に変換することで同期問題が完全に解消されました。私たちは約200万の小さなバイナリレコード（各500バイト平均）を保存し、33%のオーバーヘッドで追加の330MBのストレージを費やしました—私たちのインフラで月に約$0.50です。

小さな資産のためにデータURIを作成すること。5KB未満の資産の場合、Base64データURIとして埋め込むことでHTTPリクエストを削減し、実際のパフォーマンスを向上させることができます。私は、20の小さなアイコン（各2KB）を持つダッシュボードアプリケーションでテストを行いました。別々のリクエストでそれらを読み込むのには接続オーバーヘッドのために平均340msかかりました。Base64データURIとして読み込むことで、合計読み込み時間は大きなHTMLファイルサイズにもかかわらず180msに減少しました。往復回数の減少が、帯域幅の増加より重要でした。

認証トークンと資格情報のエンコード。多くの認証システムは、HTTPヘッダー（基本認証など）に資格情報をエンコードするためにBase64を使用します。これはセキュリティのためではなく、互換性のためです。HTTPヘッダーはASCIIでなければならず、Base64は特殊文字を含むユーザー名とパスワードがプロトコルを壊さないようにします。私は数十のAPI認証システムを実装してきましたが、資格情報のBase64エンコーディングは標準的なプラクティスであり、実際のセキュリティのためには常にHTTPSと組み合わせるべきです。

パフォーマンスの罠：Base64がアプリケーションを殺すとき

さて、事がうまくいかない箇所について話しましょう。私は不適切なBase64の使用によって引き起こされたパフォーマンス問題を数多くデバッグしましたが、その数を数えたくありません。パターンは常に似ています：開発者は、スケール時の影響を考慮せずに便利さのためにBase64を選択します。