Base64 エンコード・デコード

Base64 とは何か、なぜ存在するのか

Base64 は、任意のバイト列を A–Z、a–z、0–9、+、/ の安全な 64 文字だけで表します。入力の 3 バイトごとに出力が 4 文字になり、入力の長さが 3 の倍数でない場合は、末尾に 1 つか 2 つの = が埋められます。

Base64 が存在するのは、多くの通信経路がバイナリデータではなくテキスト向けに作られていたためです。メール（MIME）、JSON、XML、HTML の属性、HTTP ヘッダー、環境変数は、生のバイトでは壊れてしまう場面でも Base64 なら安全に運べます。そのため、メールの添付ファイル、data: URI、Basic 認証のヘッダー、JSON Web Token、ファイルを埋め込む API のデータなどで目にします。

Base64 はエンコードであって暗号化ではありません。誰でもデコードできるので何も隠せません。値を秘密にする必要があるなら暗号化してください。データが変わっていないかを確認したいなら、ハッシュ値計算ツールのチェックサムが適しています。

標準の Base64、Base64URL、改行

デコーダーはこれらすべてを受け付けます。どちらの文字セットでも、パディングや改行・スペースの有無にかかわらず使えます。data:…;base64, で始まる URI 全体をそのまま貼り付けることもできます。

標準（RFC 4648）

+ と / を使い、= でパディングします。MIME、data URI、ほとんどのライブラリ、base64 コマンドが出力する形式です。

URL セーフ、Base64URL

+ を - に、/ を _ に置き換え、パーセントエンコードなしで URL やファイル名に入れられるようにします。JWT はパディングを除いた形で使っており、パディングのオプションがあるのはそのためです。

MIME の改行

メールでは 1 行が 76 文字以下である必要があるため、MIME エンコーダーは 76 文字ごとに改行を入れます。メールのソースや PEM のようなブロックに貼り付けるときはオンにし、JSON、URL、コードではオフのままにしてください。

テキストを先に UTF-8 にする理由

Base64 がエンコードするのは文字ではなくバイトなので、テキストはエンコードの前にバイトに変換する必要があります。ブラウザ組み込みの btoa() は U+00FF までの文字しか受け付けず、それ以外ではエラーになるため、素朴なエンコーダーは「€」「日本」や絵文字で失敗します。このツールは、ほぼすべてのシステムが前提とする UTF-8 でテキストをエンコードするので、é は 2 バイトの C3 A9 になり、どのプラットフォームでも é にデコードされます。

デコードするときは、バイト列が有効な UTF-8 かどうかを確認します。そうでない場合、その Base64 はほぼ確実にテキストではなくバイナリファイルなので、画面いっぱいの文字化けを表示する代わりにそのことを伝え、シグネチャを認識できればファイルの種類も示します。

ファイル：サイズ、シグネチャ、大きな入力

Base64 にするとデータは約 3 分の 1 大きくなります。3 バイトごとに 4 文字になり、改行すればその分も加わります。3 MB の画像はおよそ 4 MB のテキストになります。ファイル表示ではコピーする前に両方のサイズが表示されるので、大きなファイルをスタイルシートや JSON ドキュメントに埋め込む前に確認する価値があります。

Base64 文字列をファイルにデコードする場合はその逆です。ほとんどのファイル形式の先頭バイトは決まったシグネチャで、PNG は 89 50 4E 47、PDF は %PDF、ZIP（つまり DOCX や XLSX も）は PK です。ツールはこれを読み取ってダウンロードに正しい名前を付け、画像をプレビューします。大きなファイルは進捗バー付きで分割してエンコードされるのでページの反応は保たれ、非常に長い結果は一部だけプレビューされますが、コピーとダウンロードでは常に全体が得られます。

画像の場合は、画像 Base64 変換を使えば、そのまま貼り付けられる HTML、CSS、Markdown のスニペットも作れます。