Base64にエンコード
テキストでも画像でも、どんなファイルでも、正しくBase64に変換します。よくある1行の実装では扱えないアクセント付き文字や絵文字も、そのまま保たれます。データは保存されません。
- 保存しません
- 順番待ちなし
- 登録不要・透かしなし
テキストはUTF-8でエンコードされるため、アクセント記号や絵文字もそのまま保たれます。
ここにBase64が表示されます。
使い方
テキストを貼り付けるかファイルをドロップ
テキストはUTF-8としてエンコードされます。ファイルは1バイトずつそのままエンコードされ、保存されることはありません。
種類を選ぶ
標準のBase64、トークンやクエリ文字列向けのURLセーフなBase64URL、またはCSSや<img>タグにそのまま貼り付けられる完全なData URI。
コピー
結果をコピーするか、大きい場合はテキストファイルとしてダウンロードします。
ちょうど3分の1大きくなる理由
Base64は3バイトずつ取り出し、それを4文字で表します。1文字が24ビットのうち6ビットずつを受け持ちます。4÷3、これがよく知られた33%の出どころです。非効率なのではなく算数の結果で、印字可能な文字の範囲にとどまる限り、これより効率のよいエンコーダーはありません。データが3バイト単位で割り切れないときは、最後のグループにパディングを加えて1つか2つの = で示します。Base64の文字列の長さが必ず4の倍数になるのはそのためです。
文字セットは2種類あり、間違ったほうを選ぶことが、ここに寄せられる問題で最も多いものです。標準の文字セットは最後が + と / で、どちらもURLでは意味を持ちます。プラスはクエリ文字列の中でスペースになり、スラッシュはパスの区切りに見えます。URLセーフ版はその代わりに - と _ を使い、JSON Web Token、ファイル名、アドレスに含まれるものすべてで使われています。それ以外はまったく同じで、片方でエンコードした値をもう片方としてデコードすると、データ破損のように見える形で失敗します。
もう1つ、用途によって変わる細部が折り返しです。メールの添付ファイルは1行76文字、PEM形式の証明書や鍵は64文字を想定し、Data URIやJSONのフィールドは改行なしを想定しています。今は折り返さないほうが一般的なので、ここではデフォルトでオフにしています。送り先がメールヘッダーや -----BEGIN----- ブロックの場合はオンにしてください。そうした場所では、巨大な1行は受け付けられません。
Base64は暗号化ではなく、何の保護にもなりません。 文字セットを変えているだけで、誰でもすぐに元に戻せますし、セキュリティスキャナーは自動的に戻します。目的は、テキストしか受け付けない経路でバイナリデータを運ぶことです。メール本文、JSONのフィールド、XML文書、スタイルシート内のData URIなどです。設定ファイルのパスワードを隠すためにBase64を使っても、見ようとする人からは何も隠せません。
ほかの目的には
コマンドラインなら、Linuxでは base64 -w 0 file.bin で折り返さずにエンコードでき、macOSではただの base64 が同じ動作をします。openssl base64 -A はどの環境でも同じように動きます。URLセーフの文字セットなら、置換の手間なく正しく処理できるのは basenc --base64url です。
大きなファイルには、ここでの方法はどれも向いていません。ファイル全体をメモリに保持し、ほかの処理より先にエンコードで3分の1膨らませるからです。コマンドラインツールは代わりにストリーム処理を行い、コードならどの言語にも逐次処理のエンコーダーがあります。そもそもBase64が必要かどうかも考える価値があります。バイナリを multipart/form-data や生のボディとして送れば、メモリの問題も33%の増加も避けられます。
よくある質問
テキストやファイルはどこかに保存されますか？
いいえ。何も保存されず、ログも残らず、サーバーが目にすることもありません。ネットワークを切断しても動作し続けます。この種のツールでは、これはおまけではありません。オンラインのエンコーダーやデコーダーに貼り付けられるものは、日常的に現役の情報です。セッショントークン、APIキー、Authorizationヘッダー、顧客データ。それをどこかへ送信するページに貼り付けることは、サイトが削除についてどう約束していようと、情報の開示です。
なぜアクセント付き文字や絵文字も正しく扱えるのですか？
テキストをエンコードする前にUTF-8のバイト列に変換しているからです。これが正しい順序で、手軽な実装の多くはこれを省いています。ブラウザ標準の `btoa` はそもそもテキストを受け付けません。1文字を1バイトとして扱うため、`btoa("café")` は単にエラーになります。広く使われている回避策の `btoa(unescape(encodeURIComponent(s)))` はたまたま動いているだけで、絵文字など基本範囲外の文字では破綻します。このページはUTF-8を正しく1回だけエンコードするので、日本語も🎉もそのまま通り、デコードすると元どおりに戻ります。
Base64URLとは何で、いつ必要ですか？
2つの文字を入れ替えたBase64です。+が-に、/が_になり、末尾の=のパディングは省かれます。+、/、=はどれもURLの中で意味を持つため、通常のBase64はクエリ文字列やパスで運ばれると崩れてしまいます。そのために存在する形式です。JWT、OAuthトークン、URLに含まれるものはすべてBase64URLを使います。結果をリンクに入れるなら、こちらを選んでください。
Base64で暗号化や保護はできますか？
できません。ここははっきり言っておく価値があります。Base64はエンコード方式であって暗号化ではなく、鍵も秘密もありません。文字列を見た人は誰でも、このサイトを含め、1ステップでデコードできます。Base64の目的は、メールの添付ファイルやData URIのように、テキストしか受け付けない経路でバイナリデータを安全に運ぶことです。秘密にすべきものには暗号化が必要で、Base64では一切保護されません。
なぜBase64は元のファイルより大きいのですか？
必ず約33%大きくなります。Base64は3バイトごとを4文字のテキストで表すため、仕組み上サイズが3分の1増え、さらにわずかなパディングが加わります。バイナリをテキストにする代償であり、大きな画像をData URIとしてCSSに埋め込むのがたいてい割に合わない理由でもあります。
画像をData URIとしてエンコードできますか？
できます。画像をドロップして「Data URI」を選んでください。正しいメディアタイプが入った完全な `data:image/png;base64,…` 文字列が得られ、スタイルシート、<img>タグ、メールテンプレートにそのまま貼り付けられます。
サイズの上限はありますか？
固定のサイズ上限ではなく、使用可能なメモリ次第で、余裕は十分にあります。何MBもあるファイルでも問題なくエンコードできます。大きなファイルを扱うために、あえて分割しながらエンコードしています。素直に実装すると約125 KBで「Maximum call stack size exceeded」となってクラッシュします。非常に多くのオンラインエンコーダーにあるバグです。
ご注意： Base64にするとデータは約33%大きくなります。これは形式の性質で、不具合ではありません。ファイルは丸ごとメモリに読み込むため、非常に大きなファイルでは、処理が終わる前にスマートフォンのタブのメモリが足りなくなることがあります。折り返しはデフォルトでオフです。メールやPEM形式ではオンにする必要があります。
このツールをあなたのサイトに設置
ブログ、授業のページ、ヘルプ記事などに無料で設置できます。コードを1つ貼り付けるだけで、訪問者がそのページ上でツールを使えるようになります。