Base64 エンコード / デコード
Base64 のエンコードとデコード。UTF-8 対応、URL セーフ版あり。
このツールについて
テキストを Base64 に変換し、元に戻します。あらゆる Unicode テキストを正しく扱え、JWT や URL で使われる URL セーフなアルファベット(base64url)にも対応しています。
使い方
- テキストを Base64 に変換するなら「エンコード」、Base64 をテキストに戻すなら「デコード」を選びます。
- 入力を貼り付けます。アクセント記号や絵文字などの Unicode テキストも正しく扱われます。
- トークンや URL 用には、「URL セーフ」をオンにして + と / の代わりに - と _ を使います。
- 結果をコピーするか、「入れ替え」をクリックして逆の操作を行います。
よくある質問
- Base64 は暗号化ですか?
- いいえ。Base64 は誰でもすぐに元に戻せるエンコード方式です。パスワードや秘密情報を隠すために使ってはいけません。
- Base64 と Base64url の違いは何ですか?
- Base64url は + を - に、/ を _ に置き換え、通常は = のパディングを省くため、URL やファイル名に使えます。JWT は Base64url を使っています。
- デコードに失敗するのはなぜですか?
- 入力に Base64 のアルファベット以外の文字が含まれているか、デコード結果が UTF-8 テキストではなく画像や圧縮ファイルのようなバイナリデータになっています。
- エンコードしたテキストが長くなるのはなぜですか?
- Base64 は 3 バイトごとに 4 文字で表すため、出力は入力より約 33% 大きくなります。
- Base64 の末尾の = は何を意味しますか?
- パディングです。Base64 の出力は常に 4 文字の倍数なので、= が 1 つなら最後のグループに 2 バイト、== なら 1 バイトが入っていたことを意味します。パディングはデータを持たないため、base64url では通常省略されます。このツールはデコードする前に、欠けているパディングを補います。
- コマンドラインで Base64 エンコードするには?
- Linux と macOS では、printf hello | base64 を実行すると aGVsbG8= が得られます。単純な echo は改行を追加して aGVsbG8K になってしまうので避けてください。デコードには base64 -d を、古い macOS では base64 -D を使います。PowerShell では、テキストのバイト列を [Convert]::ToBase64String に渡します。
- Base64 の画像や PDF をデコードするには?
- このツールは UTF-8 テキストにデコードするため、PNG や PDF などのバイナリデータはファイルではなくエラーになります。Base64 文字列をファイルに保存し、ターミナルで base64 -d input.txt > image.png を実行してください。data:image/png;base64, のような接頭辞はエンコードされたデータの一部ではないため、先に取り除いてください。
Base64 エンコードとは? その仕組み
Base64 は、バイナリデータを 64 種類の印字可能な ASCII 文字(A–Z、a–z、0–9、+、/)で表現します。標準のアルファベットは RFC 4648 で定義されています。エンコーダーは入力を 3 バイトずつ読み込み、その 24 ビットを 6 ビットずつ 4 つのグループに分け、各グループを 1 文字に対応付けます。こうして「Man」の 3 バイトが「TWFu」になります。入力の長さが 3 の倍数でない場合は、= のパディングで最後のグループを埋めます。
Base64 が存在するのは、多くの通信経路が生のバイトではなくテキスト向けに作られているためです。メールの添付ファイル(MIME)、HTML や CSS の data: URL、HTTP の Basic 認証ヘッダー、PEM 形式の証明書、画像を運ぶ JSON フィールドは、どれも Base64 に頼っています。Base64 は転送用のエンコーディングであり、圧縮でもセキュリティでもありません。デコードは一瞬でキーも不要なので、Base64 エンコードしたものは誰でも読める平文として扱ってください。
Base64 をテキストにデコードする方法と UTF-8 が重要な理由
Base64 をオンラインでデコードするには、「デコード」を選んで文字列を貼り付けます。スペースと改行は先に取り除かれるため、PEM ファイルやメールの折り返された出力もそのままデコードできます。欠けている = のパディングは自動的に補われ、URL セーフな文字 - と _ も受け付けるので、どちらの方式かを知らなくてもかまいません。デコードしたバイト列は UTF-8 テキストとして読み込まれます。
UTF-8 が重要なのは、Base64 が文字ではなくバイトをエンコードするからです。ブラウザー組み込みの btoa() は Latin-1 しか受け付けないため、✓ や絵文字を含むテキストに使うと InvalidCharacterError が発生します。このツールは先にテキストを UTF-8 のバイト列に変換するため、アクセント付き文字や絵文字も正しく往復します。「é」は C3 A9 の 2 バイトになり、「w6k=」とエンコードされます。画像や gzip ファイルのように、デコードしたバイト列が有効な UTF-8 でない場合は、文字化けしたテキストではなくエラーが表示されます。
Base64、16 進数、URL エンコードの違いと使い分け
Base64、16 進数、パーセントエンコーディングは、どれもデータを安全なテキストに変換しますが、向いている用途が異なります。16 進数は 1 バイトに 2 文字を使うため出力のサイズは 2 倍になりますが、読みやすく、ハッシュやチェックサムの標準的な表記です。Base64 は 3 バイトごとに 4 文字を使い、オーバーヘッドは約 33% なので、画像、鍵、JSON 内のファイルの中身など、大きめのバイナリデータに適しています。
URL で使われるパーセントエンコーディングは、いくつかの予約文字を含むテキスト向けで、バイナリデータ向けではありません。Base64 の値を URL、クエリ文字列、ファイル名に入れる必要がある場合は、+ と / をパーセントエンコードするのではなく、base64url のアルファベットを使ってください。ここでエンコードするときに「URL セーフ(base64url)」をオンにすると、+ と / が - と _ に置き換わり、= のパディングが省かれます。これはまさに JWT が使う形式です。パーセントエンコーディングそのものには、URL ツールを使ってください。
うまく動かない、または結果がおかしいですか? このツールの問題を報告