Base64とは、どんなときに使うか
Base64は、任意のバイト列を英大文字26、英小文字26、数字10、+、/の64種類の文字(と、末尾を揃える=)だけで表す方式です。 メール本文、JSONのフィールド、HTTPヘッダー、HTMLのdata: URI、設定ファイルなど、テキストしか安全に通せない経路に、画像や日本語のようにバイト値が自由なデータを載せるときに使います。 HTTP Basic認証のヘッダー(Authorization: Basic ...)やJWTの各区間もこの方式(JWTはURLセーフ形式)で書かれています。 このページは入力文字列をUTF-8のバイト列に変換してからBase64にし、逆方向ではBase64をバイト列に戻してUTF-8のテキストとして読みます。
仕組み:3バイトを4文字に
3バイトは24ビットです。これを6ビットずつ4つに分けると、各塊は0〜63の値になり、64文字の表(A-Zが0〜25、a-zが26〜51、0-9が52〜61、+が62、/が63)で文字に置き換えたものが結果です。 たとえばManはバイト列77・97・110で、2進数でつなぐと010011 010110 000101 101110となり、19・22・5・46番の文字、つまりTWFuになります。 入力が3の倍数でないときは、余り1バイトを文字2つ+==、余り2バイトを文字3つ+=で補い、常に4文字単位で終わるようにします。 そのため結果の長さは常に 4 × ⌈バイト数 ÷ 3⌉ で、元データより約33%大きくなります。
テストベクタ(ビルド時に計算)
下の表はページ生成時にUTF-8バイトを実際にエンコードして埋めた値です。ツールの結果や自作コードと照らし合わせて、実装が正しいか確認できます。
| 入力 | 文字数 | UTF-8バイト数 | Base64 |
|---|---|---|---|
| (空文字列) | 0 | 0 | (空) |
| a | 1 | 1 | YQ== |
| ab | 2 | 2 | YWI= |
| abc | 3 | 3 | YWJj |
| Hello, World! | 13 | 13 | SGVsbG8sIFdvcmxkIQ== |
| {"id":1} | 8 | 8 | eyJpZCI6MX0= |
| こんにちは | 5 | 15 | 44GT44KT44Gr44Gh44Gv |
| 😀 | 1 | 4 | 8J+YgA== |
| user:pass | 9 | 9 | dXNlcjpwYXNz |
英数字は1文字1バイト、ひらがなや漢字は1文字3バイト(「こんにちは」の5文字は15バイトで20文字のBase64)、絵文字は4バイトです。同じ文字数でも日本語のほうがBase64は長くなります。空の入力は空の結果になりますが、エラーではありません。
長さによるサイズの変化
| 元のバイト数 | Base64の文字数 | パディング(=)の数 | 元との比 |
|---|---|---|---|
| 1 | 4 | 2 | 400.0% |
| 2 | 4 | 1 | 200.0% |
| 3 | 4 | 0 | 133.3% |
| 10 | 16 | 2 | 160.0% |
| 100 | 136 | 2 | 136.0% |
| 1,000 | 1,336 | 2 | 133.6% |
| 1,048,576 | 1,398,104 | 2 | 133.3% |
1MiB(1,048,576バイト)のファイルは約1.33MiBのテキストになります。画像をHTMLやCSSに直接埋め込むとリクエストは1回減りますが、ファイルが大きくなりキャッシュも効かなくなるため、小さなアイコン程度にとどめるのが無難です。
URLセーフ形式が必要なとき
標準のBase64にある+と/は、URLの中で空白やパス区切りと解釈されることがあります。そこでURL・ファイル名・JWTでは、+の代わりに-、/の代わりに_を使い、末尾の=を省略する形式(RFC 4648のbase64url)を使います。 たとえばsubject?>>は標準形式でc3ViamVjdD8+Pg==、URLセーフ形式でc3ViamVjdD8-Pgになります。チェックを入れてエンコードするとこの形式になり、デコード時はチェックの有無にかかわらずどちらの形式も受け付けます。
試してみる:3つの例
例1 日本語の往復。 入力欄にこんにちはを入れてエンコードすると44GT44KT44Gr44Gh44Gv(20文字、パディングなし)になります。15バイトは3の倍数なので=が付きません。この値を入力欄に入れてデコードすれば元に戻ります。
例2 Basic認証ヘッダーの確認。 user:passをエンコードするとdXNlcjpwYXNzです。ヘッダーにBasic dXNlcjpwYXNzとあれば、誰でもこのツールでIDとパスワードを読み取れます。HTTPS以外で使ってはいけない理由です。
例3 乱れた入力のデコード。 改行や空白が混ざっている、-や_で書かれている、末尾のパディングが欠けている場合でも、整えてから読み取ります。メールのように76文字ごとに改行されたBase64もそのまま貼り付けられます。
注意点と限界
日本語・絵文字。 文字列を先にUTF-8のバイト列にしてからエンコードします。他のツールや言語で同じ日本語が違う結果になる場合は、Shift_JISやEUC-JP、UTF-16など別の文字コードでバイト列を作っている可能性が高いです。このツールのデコードはUTF-8としての解釈のみで、別の文字コードのバイトが含まれると「UTF-8のテキストではない」と表示されます。
バイナリデータ。 画像、PDF、暗号化されたバイト列をデコードしても文字として読めないため、エラーになります。このツールはテキスト専用で、ファイル変換用ではありません。
不正な入力。 Base64で使えない文字が混ざっている場合や、パディングを除いた文字数を4で割った余りが1の場合(1文字ではバイトを作れない)は、デコードできないと表示します。
大きな入力。 数百KB程度のテキストなら通常は一瞬で処理されますが、非常に大きいとタブが一時的に止まることがあります。変換は分割して行うので、引数の長さ制限によるエラーは起きません。
セキュリティとプライバシー
変換スクリプトは入力欄の値を読み取ってブラウザ内で変換するだけで、入力を送信する通信は行わず、保存もしません。ただし広告スクリプトなどサイトの他の部品は別に動くため、本番のパスワードやAPIキーのような機密値は、できればローカル環境で扱うことをおすすめします。 何より、Base64は暗号化ではありません。鍵がなくても誰でも元に戻せるので、「Base64にしたから安全」と考えるのは危険です。秘密を守りたいなら暗号化、元に戻せない指紋が必要ならハッシュを使ってください。
結果の使い道
認証ヘッダーの確認、JWTの各区間の中身の確認(1区間をURLセーフ形式でデコードするとJSONが見えます)、設定ファイル内のエンコード値の点検、テストデータの作成などに使えます。 デコード結果がJSONなら、JSON整形ツールでインデントを整えると読みやすくなります。
よくある質問
Base64は暗号化ですか?
いいえ。Base64は鍵なしで誰でも元に戻せる「エンコード」です。パスワードや機密情報の保護には使えません。
日本語が文字化けします。
このツールはUTF-8を基準にしているため、日本語は正しく変換されます。他で作ったBase64をデコードして文字化けする場合は、元がShift_JISなど別の文字コードだったか、テキストではないバイナリの可能性が高いです。
末尾の=は何のためにあり、外してもよいですか?
入力が3バイトの倍数でないときに4文字単位に揃えるパディングです。URLセーフ形式では省略されることが多く、このデコーダーはパディングがなくても長さから補えます。ただし、厳密なライブラリにはパディングなしを受け付けないものもあります。
+や/を含む値がURLで壊れます。
クエリ文字列の+は空白、/はパス区切りと読まれることがあります。URLセーフ形式でエンコードするか、URLエンコーダーでパーセントエンコードしてください。
ハッシュとの違いは?
Base64は元に戻せて、長さは入力に比例します。ハッシュは元に戻せない固定長の指紋です。ハッシュが必要なときはハッシュ生成ツールを使ってください。
関連ツール
- URLエンコーダー/デコーダー: パーセントエンコードの変換
- ハッシュ生成ツール: 元に戻せない指紋の作成
- JSON整形ツール: デコードしたJSONを読みやすく
- パスワード生成ツール: 強力なランダムパスワードの作成