Base64 デコーダー

Base64 とは？#

Base64 は、バイナリデータを 64 種類の ASCII 文字（A–Z、a–z、0–9、それに + と /）だけのプレーンテキストとして表す方法です。画像や鍵、メール添付ファイルといったバイナリを、テキスト用に作られたシステムでも安全に送れるようにします。これは暗号化ではなくエンコードです。

Base64 は 64 文字の固定されたアルファベットを使います。0 から 63 までの各値がそのうちのちょうど 1 文字に対応し、これによって任意の 3 バイトのバイナリが 4 つの読める文字になります：

おそらくすでに目にしたことがあるはずです。Base64 は、バイナリをテキストの中に載せて運ぶ必要がある場所のいたるところで登場します：

• 小さな画像やアイコンを HTML や CSS に直接埋め込む
• JSON API のレスポンスにバイナリの塊を含めて返す
• メール添付ファイルのエンコード（MIME）
• 鍵や証明書を PEM ファイルに保存する

その data URI のテクニックはこのようになります。長い文字列が画像そのものです：

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

なぜ Base64 が存在するのか？#

初期のネットワークプロトコルは、生のバイトではなくテキストを前提に作られていました。ASCII は 7 ビットで 128 文字を扱い、英語には十分でしたが、バイナリには不向きでした。一部のシステムは制御文字を壊したり、改行コードを書き換えたり（LF を CR + LF に）して、転送中に画像や音声を静かに破損させていました。

Base64 は、どのシステムでも共通して扱える文字だけを出力することで、こうした問題をすべて回避します。Base16 や Base32 も小さなアルファベットで同じ役割を果たしますが、Base64 は安全性を保ちながら 1 文字あたりより多くのデータを詰め込めます。だからこそ広く使われるようになりました。

Base64 エンコードの仕組み#

仕組み全体は、1 つの考え方の繰り返しです。3 バイト（24 ビット）を取り、それを 6 ビットずつ 4 つのグループに切り直し、各グループをアルファベットで引く、というものです。「Logto」という単語を手作業でエンコードしてみましょう。

1. 各文字を、その ASCII コードを使って 8 ビットの 2 進数で書く。
2. 3 バイトずつまとめる。これで 24 ビット。
3. 同じ 24 ビットを、6 ビットずつ 4 つのグループに切り直す。
4. 各 6 ビットのグループを 0〜63 の数として読む。
5. その数をアルファベットで引いて 1 文字を得る。
6. 最後のバイトのまとまりが 3 に満たない場合は、余ったビットを 0 で埋め、「=」を追加して、どのブロックも 4 文字に保つ。

ステップ 1. 各文字を 8 ビットの 2 進数にする：

ステップ 2. 最初の 3 バイト「Log」を取り、その同じ 24 ビットを 6 ビットずつ 4 つのグループに切り直す：

ステップ 3. 各 6 ビットのグループを数として読み、その数をアルファベットで引く：

「Logto」は 5 バイトで、3 の倍数ではありません。最後の 2 バイト「to」は 6 + 6 + 4 に分かれます。最後の 4 ビットを 0 で埋めて 6 ビットのグループにし、「=」を 1 つ追加して 4 文字のブロックを完成させます：

ブロックをつなげると：

"Logto"  →  TG9ndG8=

どの言語にも標準で組み込まれています。Node.js では：

const text = 'Logto';
const base64 = Buffer.from(text).toString('base64');
console.log(base64); // TG9ndG8=

この手順から、覚えておく価値のある 3 つのルールが導けます：

• 3 入って 4 出る: 出力の長さは、入力を 4 文字の倍数に切り上げた値になります。そのため、エンコード後のデータは常に約 33% 大きくなります。
• 「=」はパディングを表す: 入力が 3 バイトの倍数でないときにだけ現れます。
• パディングは余りを示す: 「=」なしなら 3 バイトの倍数、「=」1 つなら余り 2 バイト、「=」2 つなら余り 1 バイトです。

Base64 はいつ使うべきか？#

バイナリをテキストしか通せない経路に通す必要があるときに Base64 を使います：

• アセットの埋め込み: 小さな画像やフォントを HTML/CSS に埋め込み、リクエストを 1 つ節約する。
• テキスト専用の転送: バイナリを JSON、XML、URL のクエリパラメータの中に入れる。
• 使える文字が限られる場面: 制御バイトでつまずくシステムを通してデータを送る。

見返りに得られるもの：

• どこでも動く: ASCII を扱えるシステムなら、文字セットの調整なしで読めます。
• 何も壊れない: 生のバイトなら壊れてしまう経路でも、出力はそのまま生き残ります。

URL セーフな Base64（Base64URL）#

標準の Base64 は、URL・クエリ文字列・ファイル名の仕組みと衝突する 3 つの文字、つまり +、/、そして = によるパディングに依存しています。通常の Base64 文字列をそのままリンクに入れると、気づきにくい形で壊れることがあります：

• + が空白に変わる。クエリ文字列では、多くのサーバーが + を空白として解釈します。そのため ?data=ab+cd は静かに "ab cd" として届き、バイトが壊れます。
• / はパスの区切り文字。値の中の / は新しいパスの一部と解釈されることがあり、ほとんどのファイルシステムはファイル名にそのまま使うことを拒否します。
• = も予約されている。クエリ文字列ではキーと値を区切る文字なので、末尾の = パディングは削られたり誤って読まれたりします。

パーセントエンコードする方法もあります（+ は %2B、/ は %2F、= は %3D）が、文字列が長くなり、誤って二重にエンコードしてしまいやすいです。

Base64URL（RFC 4648 §5）は、これを根本から解決します。+ を - に、/ を _ に置き換え、= のパディングを取り除くのです。その結果、URL・クエリパラメータ・ファイル名にそのまま、何もエスケープせずに入れられます。URL やファイル名、多くの Web API で使われています。

const base64 = 'TG9ndG8=';
const urlSafe = base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '');
console.log(urlSafe); // TG9ndG8

制限事項（そして 1 つの大きな誤解）#

Base64 は表現方法であって、ただ得をする魔法ではありません。3 つのことを覚えておきましょう：

• 約 33% 大きくなる: 3 バイトが 4 文字になるため、エンコード後のデータはおよそ 3 分の 1 ふくらみます。
• CPU を消費する: 大量に処理する場合や大きなペイロードでは、エンコードとデコードのコストは無視できません。
• 人には読めない: 不透明な文字列は、ログやデバッグを難しくします。

よくある質問#