ToolPal
コンピュータ画面に表示されたプログラミングコード

Base64エンコーディング完全ガイド — 概念と実践

📷 Luis Gomes / Pexels

Base64エンコーディング完全ガイド — 概念と実践

Base64エンコーディングとは何か、どのように機能するか、いつ使うべきかを解説。実践的なサンプルと無料のオンラインエンコーダー/デコーダーツール付き。

D著者: Daniel Park2026年3月14日2分で読了

Base64エンコーディングとは?

Base64はバイナリデータをASCII文字列として表現するバイナリ・テキスト変換エンコーディング方式です。バイナリデータを64種類の印刷可能な文字 — A〜Z、a〜z、0〜9、+/ — に変換し、テキストベースのプロトコルで安全に送信できるようにします。

「Base64」という名前は、ちょうど64種類の異なるASCII文字が使用されることに由来しています。これは意図的な設計です。64は2の累乗(2^6)であり、バイナリとBase64の間の変換を簡単かつ効率的にします。

Webの開発を少しでも行ったことがある方なら、気づかないうちにBase64に遭遇したことがあるはずです。1つか2つの=記号で終わる一見ランダムな長い文字列——それがBase64である可能性が高いです。

なぜBase64を使うのか?

Base64が解決する根本的な問題はシンプルです。多くのシステムやプロトコルはテキストのみを扱うように設計されており、生のバイナリデータを確実に通過させることができません。ASCII文字しか扱えないメールプロトコルを通じてJPEG画像を送ると、テキストプロトコルでは特定のバイト値が特別な意味を持つため、データが壊れてしまいます。

Base64はすべてのデータを安全で印刷可能なASCII文字に変換することでこの問題を解決します。

  • メールの添付ファイル: MIMEはバイナリファイルをメールメッセージ内でエンコードするためにBase64を使用
  • データURI: 別のHTTPリクエストなしにHTMLやCSSに直接画像を埋め込む
  • API認証: HTTP Basic AuthはクレデンシャルをBase64でエンコード
  • JWTトークン: JSON Web TokensはヘッダーとペイロードにBase64URLエンコーディングを使用
  • 設定ファイル: バイナリデータ(証明書、キー)をYAMLやJSONのテキストファイルに安全に保存
  • データベースストレージ: 小さなバイナリ値をテキストベースのカラムに保存
  • URLパラメータ: URLクエリ文字列を通じてバイナリデータを安全に渡す

Base64の仕組み

エンコーディングプロセスを段階的に分解すると理解しやすくなります:

  1. バイナリデータを用意する(例:テキストをASCIIバイトに変換)
  2. 通常の8ビットバイトではなく6ビットグループに分割する
  3. 各6ビットグループを64文字のいずれかにマップする
  4. データが3バイトグループで均等に割り切れない場合は埋め込み文字(=)を追加する

Base64アルファベット

標準のBase64アルファベットは以下で構成されます:

  • A-Z(インデックス0〜25)
  • a-z(インデックス26〜51)
  • 0-9(インデックス52〜61)
  • +(インデックス62)
  • /(インデックス63)
  • =(パディング用)

ステップバイステップの例

テキストHiを手動でエンコードしてみましょう:

ステップ1: ASCIIバイトに変換 H = 72、i = 105

ステップ2: バイナリに変換 72 = 01001000105 = 01101001

ステップ3: すべてのビットを結合 01001000 01101001

ステップ4: 6ビットチャンクに再グループ化 010010 000110 1001xx

16ビットしかないので、最後のグループはゼロでパディング:010010 000110 100100

ステップ5: 各6ビット値をBase64アルファベットにマップ

  • 010010 = 18 = S
  • 000110 = 6 = G
  • 100100 = 36 = k

ステップ6: パディングを追加 元の入力は2バイト(3の倍数でない)なので、=パディング文字が1つ追加されます。

結果:SGk=

パディングの理解

パディングはBase64の中でも分かりにくい部分の一つです。ルールは以下の通りです:

  • 入力長が3で割り切れる場合:パディングなし
  • 1バイト余る場合:==を追加
  • 2バイト余る場合:=を追加

例:

  • A(1バイト)→ QQ==
  • AB(2バイト)→ QUI=
  • ABC(3バイト)→ QUJD(パディングなし)

実践的なユースケース

HTMLへの画像の埋め込み(データURI)

Base64の最も実用的な使用法の一つは、小さな画像をHTMLやCSSに直接インライン化することで、追加のHTTPリクエストを不要にします。これは小さなアイコンや装飾要素に役立ちます。

<img src="data:image/png;base64,iVBORw0KGgo..." />
.icon {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxu...");
}

使用タイミング: 2〜3KB未満の画像(小さなアイコンや1×1トラッキングピクセル)では、ネットワークのラウンドトリップを節約することで実際にパフォーマンスが向上します。それより大きなものは、33%のサイズ増加とブラウザキャッシュの喪失により、パフォーマンスが悪化します。

HTTP Basic認証

サーバーがBasic Authを必要とする場合、クライアントはユーザー名とパスワードをコロンで連結し、結果をBase64でエンコードします:

username:password → dXNlcm5hbWU6cGFzc3dvcmQ=

リクエストヘッダーは次のようになります:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

これはエンコーディングであり、暗号化ではありません。このヘッダーを傍受した人は誰でも即座にクレデンシャルをデコードできます。だからこそ、Basic AuthはHTTPS経由でのみ使用する必要があります。

JSONへのバイナリデータの保存

JSONはバイナリデータをネイティブでサポートしていません。JSONドキュメント内にファイル、画像、またはバイナリペイロードを含める必要がある場合、Base64が標準的なアプローチです:

{
  "file": "SGVsbG8gV29ybGQ=",
  "filename": "hello.txt",
  "mimetype": "text/plain"
}

このパターンは、マルチパートフォームデータではなくJSONリクエストボディとしてファイルアップロードを受け付けるREST APIでよく使われます。

JWTトークン

JSON Web TokensはBase64URLと呼ばれる変種を使用します。+-に、/_に置き換え、パディングを省略します。JWTはドットで区切られた3つのBase64URLエンコードされた部分で構成されます:

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiam9obiJ9.abc123signature

最初の部分をデコードするとヘッダー{"alg":"HS256"}が得られます。2番目の部分からはペイロード{"user":"john"}が得られます。

メールの添付ファイル

添付ファイル付きメールを送信すると、バイナリファイルはBase64でエンコードされ、MIMEメッセージボディに含まれます。メールクライアントはこれを自動的に処理しますが、内部的には添付データはMIME仕様に従って76文字の行に分割されたBase64テキストとして表示されます。

Base64 vs Base64URL

実際には2つの一般的なBase64のバリアントがあり、混同するとバグの原因になります:

プロパティ標準Base64Base64URL
文字62〜63+/-_
パディング必須(=通常省略
使用場面MIME、一般エンコーディングURL、JWT、ファイル名

Base64URLが存在するのは、+/=がURLで特別な意味を持つためです。標準のBase64エンコードされた文字列をクエリパラメータに入れると、+はスペースとして解釈され、/はURLパスを壊し、=はキー値構文と競合します。

Base64 vs 暗号化

重要: Base64は暗号化ではありません。これはエンコーディング方式であり、誰でもデコードできます。機密データを保護するためにBase64単体を使用しないでください。

このミスは頻繁に起こります。開発者がAPIキーやパスワードをBase64でエンコードして隠れていると思い込む。しかし実際には隠れていません。ブラウザの開発者ツールを開き、atob()に文字列を貼り付ければ、元の値が即座に表示されます。

データを保護する必要がある場合は、適切な暗号化(AES、RSA)またはハッシュ化(SHA-256、bcrypt)を使用してください。Base64はトランスポートの互換性のためのものであり、セキュリティのためではありません。

よくある間違いと落とし穴

1. 33%のサイズ増加を見落とす

入力の3バイトごとに出力は4バイトになります。1MBの画像をBase64としてHTMLにインライン化すると、約1.33MBのデータを送信することになり、ブラウザはその画像をページとは別にキャッシュできません。大きなファイルではこのオーバーヘッドが積み重なります。

2. MIMEの行の長さ

MIME標準では、Base64エンコードされたデータを76文字の行に分割する必要があります。メールやMIMEメッセージを手動で作成して改行をスキップすると、一部のメールサーバーがメッセージを拒否または破損させる可能性があります。

3. Base64とBase64URLの混同

標準のBase64デコーダーでJWTトークンをデコードすると、文字セットが異なるため、失敗したり間違った結果を生成したりすることがあります。常にどのバリアントを使用しているか確認してください。

4. ダブルエンコーディング

意外と多いバグ:既にエンコードされたデータを再度エンコードしてしまう。文字列をBase64エンコードして、誤って2回目のエンコードを行うと、結果は有効なBase64ですが、1回デコードすると元のデータではなく最初のエンコードされた文字列が得られます。デコードされた出力がBase64のように見える場合は、どこかでダブルエンコードが発生しています。

5. 文字エンコーディングの混乱

Base64は文字ではなく生のバイトをエンコードします。アクセント付き文字を含む文字列はUTF-8とISO-8859-1で異なる場合があります。テキストをBase64エンコードする前に、常に文字エンコーディングを明確にしてください。

各言語でのBase64の使い方

JavaScript(ブラウザ)

// エンコード
const encoded = btoa("Hello World");  // "SGVsbG8gV29ybGQ="

// デコード
const decoded = atob("SGVsbG8gV29ybGQ=");  // "Hello World"

注意:btoaatobはASCII文字列でのみ動作します。Unicodeテキストの場合は先にUTF-8としてエンコードします:

// Unicodeテキストのエンコード
const encoded = btoa(unescape(encodeURIComponent("こんにちは")));

// デコード
const decoded = decodeURIComponent(escape(atob(encoded)));

Python

import base64

# エンコード
encoded = base64.b64encode(b"Hello World").decode()  # "SGVsbG8gV29ybGQ="

# デコード
decoded = base64.b64decode("SGVsbG8gV29ybGQ=").decode()  # "Hello World"

# Base64URLバリアント
url_encoded = base64.urlsafe_b64encode(b"Hello World").decode()

コマンドライン

# エンコード
echo -n "Hello World" | base64
# SGVsbG8gV29ybGQ=

# デコード
echo "SGVsbG8gV29ybGQ=" | base64 --decode
# Hello World

echo-nフラグは重要です。これがないと改行文字もエンコードされ、異なる結果になります。

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

Base64のエンコードとデコードは高速な操作ですが、パフォーマンスが重要な場面ではサイズが問題になります:

  • 大きなファイルの転送: 33%のオーバーヘッドが積み重なります。10MBのファイルはエンコード後約13.3MBになります。頻繁にファイルを転送する場合は、バイナリプロトコルやマルチパートアップロードを使用してください。
  • インラインCSSイメージ: スタイルシートに埋め込まれたBase64エンコードされた画像は、ページを読み込むたびに再ダウンロードされます。2KB未満のアイコンなら問題ありませんが、それより大きいものはブラウザがキャッシュできるように別ファイルにすべきです。
  • データベースストレージ: テキストカラムにBase64を保存することはできますが、バイナリ/blobカラムに生のバイトを保存するより33%多くのスペースを使用します。大規模では、そのストレージコストは無視できません。

Base64を使うべきでない場合

  • 機密データの暗号化 — セキュリティは全く提供されません
  • データURIとしての大きなファイル — サイズのオーバーヘッドとキャッシュの欠如がパフォーマンスを損ないます
  • バイナリ転送が利用可能な場合 — プロトコルがバイナリデータをネイティブでサポートしている場合(HTTPマルチパート、gRPC、バイナリモードのWebSocket)、Base64のオーバーヘッドを追加する理由はありません
  • データベースへの大きなファイルの保存 — 代わりにblobまたはバイナリカラムを使用してください

今すぐ試す

無料のBase64エンコーダー/デコーダーを使って、Base64文字列を即座にエンコードまたはデコードしてください。すべての処理はブラウザ内で行われ、データがデバイスの外に出ることはありません。

よくある質問

D

著者について

Daniel Park

Senior frontend engineer based in Seoul. Seven years of experience building web applications at Korean SaaS companies, with a focus on developer tooling, web performance, and privacy-first architecture. Open-source contributor to the JavaScript ecosystem and founder of ToolPal.

詳細はこちら

この記事を共有

XLinkedIn

関連記事