Base64エンコーダー/デコーダー

Base64はコンピューティングで最も広く使用されているバイナリ-テキストエンコード方式の一つです。任意のバイナリデータを印刷可能なASCII文字の文字列に変換し、テキストのみを扱うシステムを通じて安全に送信できるようにします。数十年前にメール添付ファイルのために考案されたにもかかわらず、Base64は現代のWeb開発、API設計、データ交換において依然として不可欠です。その仕組みと使用すべきタイミングを理解することは、ネットワークプロトコルやデータフォーマットを扱うすべての開発者にとって基礎的なスキルです。

Base64エンコーディングの仕組み

Base64エンコーディングは入力データを3バイト（24ビット）のグループに分割します。各24ビットグループは4つの6ビットセグメントに分割されます。各6ビットセグメントは64個の印刷可能なASCII文字のいずれかにマッピングされます：A-Z（0-25）、a-z（26-51）、0-9（52-61）、+（62）、/（63）。これがRFC 4648で定義された標準Base64アルファベットです。

入力長が3バイトの倍数でない場合、パディングが適用されます。最後の完全なグループの後に1バイトが残る場合、2つのBase64文字が生成され、2つの=パディング文字が続きます。2バイトが残る場合、3つのBase64文字が生成され、1つの=文字が続きます。パディングによりエンコード出力の長さは常に4の倍数になり、デコードが簡素化されます。

結果は元のバイナリデータより約33%大きい文字列です。3つの入力バイトから4つの出力文字が生成され、4:3の比率になります。このサイズオーバーヘッドはBase64の基本的なトレードオフです。データサイズの増加と引き換えに、テキストのみの転送チャネルとの互換性を得られます。

UTF-8とUnicodeサポート

元のBase64仕様は文字ではなくバイトに対して動作します。絵文字、CJK文字、アクセント付き文字などの非ASCII文字を含むテキストをエンコードする場合、テキストはまず文字エンコーディングを使用してバイトに変換する必要があります。UTF-8は現代のWebの標準エンコーディングです。

JavaScriptの組み込みbtoa()関数はLatin-1文字（バイト値0-255）のみを処理します。Unicodeテキストをエンコードするには、まずTextEncoderを使用して文字列をUTF-8バイトに変換し、それらのバイトをbtoa()でエンコードする必要があります。このツールはその変換を自動的に処理するため、マルチバイト文字を含む任意のUnicodeテキストを基盤のバイト表現を気にせずエンコード・デコードできます。

Web開発での一般的な用途

データURIはWebにおけるBase64の最も目に見える用途の一つです。画像をBase64文字列にエンコードしCSSやHTMLに直接埋め込む（例：background-image: url(data:image/png;base64,...)）ことで、ドキュメントサイズの増加と引き換えにHTTPリクエストを削減できます。この手法はHTTPオーバーヘッドがBase64のサイズ増加を超える小さな画像、アイコン、SVGに最も有効です。

HTTP Basic認証はAuthorizationヘッダーでユーザー名とパスワードをBase64文字列としてエンコードします。Base64は暗号化ではないため誰でも文字列をデコードでき、Basic認証はHTTPS接続上でのみ使用すべきであることを理解することが重要です。JSON Web Token（JWT）もヘッダーとペイロードセクションのエンコードにURLセーフなBase64変種を使用しています。

メール添付ファイルはMIME標準を通じてBase64に依存しています。画像、PDF、実行ファイルなどのバイナリファイルはテキストベースのメールフォーマットに埋め込む前にBase64にエンコードされます。受信側のメールクライアントがBase64を元のバイナリデータにデコードします。そのため、メール添付ファイルは元のファイルよりわずかに大きくなることがあります。

Base64のバリエーション

標準Base64アルファベットは62番目と63番目の文字として+と/を使用します。これらの文字はURLで特別な意味を持つ（+はスペース、/はパス区切り文字）ため、URLセーフ変種ではそれぞれ-と_に置き換えます。base64urlと呼ばれるこの変種はRFC 4648セクション5で定義されており、JWT、URLパラメーター、ファイル名セーフなエンコーディングで使用されます。

一部の実装ではパディング文字（=）を省略します。エンコード長から元のデータ長を推測できるためです。これはbase64urlエンコーディングで一般的で、末尾の=文字はURLでパーセントエンコードする必要があるためです。パディングが必要かどうかは使用するプロトコルやライブラリによります。

パフォーマンスの考慮事項

Base64のエンコードとデコードは計算コストの低い操作です。ビットシフトとテーブルルックアップのみで構成されます。主なコストは33%のサイズ増加で、帯域幅、ストレージ、メモリ使用量に影響します。小さなペイロード（数キロバイト未満）の場合、このオーバーヘッドは無視できるレベルです。大きなファイルの場合は顕著になります。

Webアプリケーションでは、大きな画像をBase64データURIとして埋め込むことは逆効果になる場合があります。100KBの画像はBase64で約133KBになり、埋め込まれたドキュメントとは別にキャッシュできません。約2-5KBを超える画像は、適切なHTTPキャッシュヘッダーを持つ別ファイルとして配信する方が効率的です。webpackやViteなどのビルドツールは、小さなアセットをインライン化し大きなものは別途読み込むことでこの判断を自動化できます。

セキュリティ：Base64は暗号化ではない

根強い誤解として、Base64が何らかのセキュリティや難読化を提供するというものがあります。Base64は可逆的なエンコードであり、エンコードされた文字列にアクセスできれば誰でもキーやパスワードなしに即座にデコードできます。パスワード、APIキー、機密データをBase64で保存してもセキュリティ保護にはなりません。

転送中のデータを保護するにはTLS/HTTPS暗号化を使用してください。保存データを保護するにはAES-GCMなどの認証付き暗号化アルゴリズムを使用してください。Base64はデータフォーマットツールであり、セキュリティツールではありません。いかなる形態の機密性にも依存しないでください。