エンコーディングツール
データをエンコード・デコードするためのツール — Base64、URLエンコード、そして2進数や16進数などの進数変換。すべて完全にブラウザ内で動作します。
よく使う変換
クリックするだけで、その作業用に設定済みのツールが開きます。
オンラインエンコーディングツール - ブラウザで Base64 と URL エンコード
エンコードは暗号化ではありません。何も隠さないし、何も守りません。その役目は、何かを壊してしまうデータ - テキストしか運べない経路、& を区切り文字として扱う URL、Unicode より古いメールヘッダー - を、旅路を生き延びられる文字に作り替えることです。このカテゴリのツールは、それを両方向に、完全にあなたのブラウザの中で行います。
この区別ははっきり言っておく価値があります。この分野で群を抜いて多い誤解だからです。Base64 は誰でも、鍵なしで、即座に元へ戻せます。Base64 で保存されたパスワードは、一手間増えた平文のパスワードにすぎません。秘密が必要なら、必要なのは暗号であってエンコードではありません。
このカテゴリにあるもの
| ツール | できること | 使う場面 |
|---|---|---|
| Base64エンコーダー | テキストとファイルを Base64 に、また元に戻す。URL セーフ版にも対応 | CSS に画像を埋め込む、API キーを読む、テキストしか通らない欄にバイナリを通す |
| URLエンコーダー | URL とクエリ文字列の値をエンコード・デコードする | 最初の空白、アンパサンド、非ラテン文字でリンクが壊れる |
| 進数変換ツール | 2進数・8進数・10進数・16進数、36までの任意の基数の間で変換し、テキストをバイト列に、またその逆にも変換する | 16進ダンプの値、ビットマスク、パーミッションを数値として読む必要がある |
| HTMLエンティティ変換ツール | 名前付きまたは数値のエンティティで HTML 用にテキストをエスケープし、どのエンティティもテキストに戻す | コード例、ユーザーのコメント、エクスポートで、< や & の代わりに < や & が表示される |
Base64 が実際にしていること
Base64 は 3 バイト（24 ビット）ずつ取り、64 文字のアルファベット - A-Z、a-z、0-9、それに + と / - から選んだ 4 文字に書き換えます。64 は 2 の 6 乗なので、出力 1 文字がちょうど 6 ビットを担います。入力が 3 で割り切れないときは = で埋め、長さが常に 4 の倍数になるようにします。
その帰結は意見ではなく算数です。Base64 の出力は入力より約 33% 大きくなります。300 KB の画像をスタイルシートに埋め込むためにエンコードすると、およそ 400 KB のテキストになります。これは実コストであり、小さなアイコンなら埋め込む価値があり、写真ではめったに割に合わない理由でもあります。
+ と / は URL の中では厄介です。そこではすでに意味を持つ文字だからです。URL セーフな Base64 はこれらを - と _ に置き換え、たいていパディングも落とします。JSON Web Token が使っているのはこちらで、両者を取り違えることが、あるツールではトークンのデコードに失敗し別のツールでは成功する理由です。
パーセントエンコーディングが実際にしていること
URL には文法があります。? がクエリ文字列を開き、& がパラメータを区切り、= が名前と値を結び、# がフラグメントを開き、空白はそもそも許されません。値にこれらの文字が含まれるならエスケープしなければ、URL は意図とは別の意味になります。パーセントエンコーディングは、その文字を % とバイト値の 16 進表記に置き換えます。空白は %20、& は %26、/ は %2F。
非 ASCII のテキストは UTF-8 バイト列としてエンコードされ、1 バイトにつき %XX が一つ付きます。ペルシア語や日本語の 1 文字は、たいてい三つのエスケープになります。非ラテン文字の検索語を含む URL が、語そのものよりずっと長く見えるのはこのためです。
落とし穴は、URL のどの部分をエンコードしているのかを把握することです。URL 全体をエンコードすると :// や / までエスケープされ、URL は壊れます。ほぼ常に、エンコードしたいのは一つのパラメータ値で、その周りに URL を組み立てるべきです。URLエンコーダーは両方できますが、選ぶのはあなたです。
進数：ほかのすべての下にあるエンコード
Base64 もパーセントエンコーディングもバイトを扱い、そのバイトはたいてい16進数か2進数で書かれます。進数変換ツールは、任意の基数で書かれた値を読み取って、ほかの基数での表記を一度に表示します。64ビットの上限はなく、「テキスト」タブでは文字列の裏にある UTF-8 のバイト列も確認できます。é がなぜ2バイトになるのか、なぜ %C3%A9 がそのパーセントエンコード形なのか、なぜ 0xFF が255なのかを確かめるには、これがいちばんの近道です。
これらのエンコードに出会う場所
- データ URI -
data:image/png;base64,...は画像を HTML や CSS に直接埋め込み、リクエストを一つ節約します。 - HTTP Basic 認証 - ヘッダーは文字どおり
Basicに続けてユーザー:パスワードの Base64。見た人は誰でも元に戻せるので、TLS の内側にしか居場所がありません。 - JSON Web Token - ドットで繋がれた三つの URL セーフ Base64 セグメント。ペイロードは鍵なしで読めます。
- メールの添付 - MIME は 1990 年代初頭からバイナリを Base64 で運んでおり、今も運んでいます。
- クエリ文字列 - 空白や記号を含む検索語、リダイレクト先、フィルタ値のすべて。
- 設定ファイルとシークレット - Kubernetes のシークレット、サービスアカウントキー、証明書は日常的に Base64 で保存されます。
よくある失敗とその原因
- 二重エンコード。 自分のコードとフレームワークが二度エンコードし、
%20が%2520になる。URL に%25が見えたら、すでにエスケープだったパーセント記号を何かがエンコードしています。 - Base64 アルファベットの取り違え。 デコードできない JWT は、たいてい URL セーフ Base64 を標準デコーダに渡している（またはその逆）。
- パディングの欠落。 末尾の
=を落とす実装があります。厳格なデコーダは拒否し、寛容なものは補います。 - URL 全体をエンコードした。 スキームとパスまでエスケープされ、リンクが解決しなくなります。
- 安全だと思い込む。 クッキー、ヘッダー、設定ファイルの中の Base64 は、そのファイルを読める人には読めます。
- クエリ文字列のプラス記号。 フォームエンコードされたデータでは
+は空白、パスでは文字どおりのプラス。同じ文字に二つの意味。
ローカルで動くことが重要な理由
人がエンコード・デコードしたい文字列は、不釣り合いなほど機微なものです。認可ヘッダー、セッショントークン、サービスアカウントキー、署名付き URL。そうしたものをサーバー側で処理するサイトに貼り付けるのは、生きた資格情報を第三者に手渡すことです。ここの二つのツールはブラウザで動きます。入力がタブから出ることはなく、ネットワークパネルで確かめられます。
関連カテゴリ
- テキストツール - エンコードされたペイロードの中にしばしば潜む JSON を整形・検証する。
- 開発者ツール - パーツを手で Base64 するのではなくJWT をきちんとデコードする、あるいは可逆な形ではなく指紋が欲しいときに値をハッシュ化する。
- ジェネレーター - 後でエンコードされることになる識別子やシークレットを作り出す。