Base64 エンコード・デコード

Base64 とは？#

Base64 は、任意のバイトを 64 種類の印字可能 ASCII 文字（A-Z、a-z、0-9、+、/、詰め用に =）だけで書く方法です。これが存在するのは、計算機世界の大部分がテキスト向けに設計されている——メールの本文、JSON のフィールド、HTTP ヘッダー、data-URI のプレフィックス——ためであり、それらは生バイト、とりわけ最上位ビットが立ったバイトや制御コードが埋め込まれたバイトを扱えません。Base64 は、バイナリの形をしたデータをテキスト専用の経路で生き延びさせる必要があるときに手にする共通言語です。

入力 3 バイト（24 ビット）ごとに 4 つの base64 文字（各 6 ビットを符号化）になります。だから base64 の出力は常に 4 文字の倍数の長さになり、元のバイトより約 33% 大きくなります——この冗長さが印字可能性の代償です。入力長が 3 の倍数でないとき、末尾に 1 つまたは 2 つの = 詰め文字が現れます。

このページは base64 をUTF-8 セーフにエンコード・デコードします。人が絶えず陥る罠: 文字列をそのまま btoa() に渡すと、非 ASCII 文字（é、中文、絵文字）を含んだ moment に InvalidCharacterError を投げます。修正は、テキストをまず UTF-8 バイトにエンコードしてから base64 にすることです——まさにこのツールがしていることなので、café は例外を投げずに正しく往復変換できます。

使い方#

1. ツールバー左上のエンコード / デコード切り替えで方向を選びます。
2. 左側の入力ペインに入力または貼り付けを行います。
   • エンコードモードでは、入力は UTF-8 テキストとして扱われます。
   • デコードモードでは、入力は base64 文字列であるべきです。空白は許容されます。
3. base64url アルファベット（+ と / の代わりに - と _、詰めなし）が必要な場合は**URL セーフ（– と _）**にチェックを入れます。これが JWT や多くの署名付き URL スキームが期待する形式です。
4. 結果は右側の出力ペインにリアルタイムで表示されます。コピーで取り出せます。
5. サンプルでデモのペアを流し込み、クリアで両ペインをリセットします。

主な特徴#

• 両方向で UTF-8 セーフ。 エンコードはまずテキストを TextEncoder に通すため、マルチバイト文字が破裂することはありません。デコードはバイトを TextDecoder に通すため、元のテキストが正確に復元されます。
• 標準と URL セーフの両アルファベット。 1 つのチェックボックスで古典的 base64（+/=）と base64url（-_、詰めなし）を切り替え、デコード時には正しく再詰めします。
• 純粋なクライアントサイド。 変換はブラウザ内だけで走ります——バックエンドもネットワークリクエストもありません。ここに機密トークンを貼り付けても、どこにも送信されません。
• リアルタイムのステータス行。 ペインの下のバーは、黙ってゴミを生成するのではなく、エンコード/デコードのエラー（例えば % 形の、あるいは切り詰められた入力）を報告します。

実例#

エンコード、標準（URL セーフではない）モードで、ASCII テキスト Hello, World! は次のようになります:

SGVsbG8sIFdvcmxkIQ==

末尾の 2 つの = は、13 バイトの入力が 3 の倍数でなかったことを示します——間違いではなく、予期されたことです。

UTF-8 の扱いは、ASCII を離れた瞬間に重要になります。café（é は 2 つの UTF-8 バイト c3 a9）をエンコードすると次になります:

Y2Fmw6k=

コンソールで直接 btoa("café") を呼んでいれば、例外を投げていたでしょう。このツールは最初に UTF-8 バイトにエンコードするため、投げません。

URL セーフモードはアルファベットを書き換え、出力が URL が誤読する文字を決して持たないようにします——+ は - に、/ は _ になり、末尾の = 詰めは削られます（デコード時に自動的に再追加されます）。上の標準出力 SGVsbG8sIFdvcmxkIQ== を取ると——URL セーフモードでは 2 つの詰め = が削られ、SGVsbG8sIFdvcmxkIQ になります。+// → -/_ の置換は、それらの文字が出力に実際に現れたときにだけ影響します。それはハッシュダイジェストやランダムトークンのようなバイナリペイロードで起こりがちです——まさに、さらなるエスケープなしに URL のパスやクエリパラメータに差し込みたくなる種類のデータです。

よくある質問#

デコードしたテキストが文字化けします。どうしましたか？#

ほぼ常に、あなたがデコードした base64 が UTF-8 ではなく他の文字セット（多くは Latin-1 や Windows-1252）でエンコードされたバイト列でした。このツールはバイトを UTF-8 としてデコードするため、Latin-1 でエンコードされた é（0xe9、単独バイト）は有効な UTF-8 ではなく、正しく表示されません。相手側が元のテキストをどうエンコードしたか調べるか、まず UTF-8 として再エンコードしてください。

標準 base64 と base64url のどちらがいいですか？#

標準（+/=）は、URL に入らないもの——メールの添付、data: URI、バイナリを運ぶ JSON フィールド——の既定です。出力が URL のパス、クエリ文字列、JWT セグメントに置かれ、そこで +、/、= が解析を壊したりトランスポートに破壊されたりする場合は、**URL セーフ（– と _）**をオンにします。どちらの形式のデコードも自動的に受け付けます。

エンコード出力が入力より長いのはなぜですか？#

それは仕様であり、バグではありません。Base64 は 8 ビットではなく 1 文字あたり 6 ビットを詰めるため、出力は入力の約 4/3 のサイズ——おおむね 33% のオーバーヘッドになります。非常に小さな入力では、固定構造が支配的になるため、元に対する相対サイズはさらに大きく見えることがあります。

base64 文字列を復号・解読できますか？#

いいえ——base64 は暗号化ではなくエンコードです。設計上完全に可逆で、鍵を持ちません。文字列を持つ誰もがデコードできます。本当に秘匿性が必要なら、まず暗号化し（例えば認証付き暗号スキームで）、その暗号文をトランスポート用に base64 エンコードしてください。