パーセントエンコード

デコード後テキスト

URLデコーダーとは？

左側のパネルにパーセントエンコードされた文字列を貼り付けると、右側に元の文字列が表示されます。内部ではdecodeURIComponentを実行し、入力中の%XXシーケンスを順番に処理して、それらの16進ペアをUTF-8バイトとして扱い、元の文字を復元します。%20はスペースに、%26は&に、%E2%9C%85はチェックマークになります。逆方向の処理はURLエンコーダーにあります。

デコードがなぜ難しいのか？それは、世の中にあるすべての%が有効なパーセントエンコードシーケンスの一部とは限らないからです。16進数以外の文字が続く単独の%（%G1、文字列末尾の%）は不正な形式で、デコーダーはURIError: URI malformedをスローします。このページはそれをキャッチして、スタックトレースの代わりに親しみやすい「無効なエンコード」メッセージを表示するので、壊れた貼り付けでもページは壊れません。何を有効とするかの正確なルールはRFC 3986 §2.1とWHATWG URL標準に定められています。

二重エンコードに注意してください。文字列をデコードして出力にまだ%文字が含まれている場合（例: Ava ChenではなくAva%2520Chenが返ってきた）、その値はチェーンのどこかで二度エンコードされています — 通常はプロキシまたは既にエンコード済みの値を自動エンコードしてしまったフレームワークが原因です。もう一度デコードすれば残りの道のりを進めます。Wikipediaの二重エンコードに関する解説には、これがどのように起きるかの良い説明があります。すべてはあなたのブラウザで動きます。アップロードもサーバーもログもありません。

URLデコーダーの使い方

3ステップ。入力中にページが更新されます — 変換ボタンはありません。

エンコード文字列を貼り付けるかサンプルをクリック

パーセントエンコードされた文字列を左側パネルにドロップ。サンプルをクリックすると現実的な例を読み込みます。入力例:

Ava%20Chen%20%26%20friends%3F%20customer%40shop.com%20%20100%25%20off!

不正な入力（単独の<code>%</code>、<code>%G1</code>のような無効な16進ペア）は出力パネルに「無効なエンコード」メッセージとして表示されます — 正確な失敗ルールは<a href="https://tc39.es/ecma262/#sec-decodeuricomponent-encodeduricomponent" target="_blank" rel="noopener">decodeURIComponentのECMAScript仕様</a>を参照してください。

デコード結果を読む

右側パネルにデコード後のテキストが表示されます。%20はスペース、%26は&、%3Fは?、%40は@、%25は%になります。入力中に更新されます。

コピーまたはダウンロード

コピーをクリックしてデコード後のテキストをクリップボードへ、またはダウンロードで.txtファイルとして保存します。入力パネルのクリアでやり直せます。逆方向に行くなら、URLエンコーダーへ。

実際にこれを使う場面

クエリパラメータの実際の中身を読む

?customer=Ava%20Chen&tag%5B0%5D=redのようなURLは、パーセントコードが残っていると目視しづらいです。ここに値を1つ貼り付けるとAva Chenやtag[0]が返ってきて、パラメータが期待通りかどうかが一目でわかります。URL全体を分解するなら、URLパーサーがクエリパラメータを自動処理します。

二重エンコードされた値のデバッグ

Ava%2520Chenを貼り付けて1回デコードするとAva%20Chenが返ってきます。この余分なレイヤーが決定的な証拠 — どこかでプロキシ、フレームワーク、ライブラリが値を二度エンコードしています。もう一度デコードすれば実際の文字列が得られます。OAuth仕様はよくある原因で、redirect_uriの値が親切にも各レイヤーで再エンコードされてしまうことが多いからです。

ログからWebhookやアナリティクスのURLを調べる

本番環境で何かが失敗したとき、アクセスログのURLは通常完全にエンコードされています — Webhookが実際に送信したJSONではなく%7B%22event%22%3A%22signup%22%7Dです。ここに貼り付けると{"event":"signup"}が返ってきて、これなら読めます。

マジックリンクやパスワードリセットURLのデコード

Marco Riveraのような顧客が「リセットリンクが壊れている」と言ってきたとき、リンクにはトークン、メール、リダイレクト先 — すべてパーセントエンコードされて — が含まれています。怪しいパラメータをデコードすれば、メールアドレスが正しいか、トークンがメールクライアントの加工で生き残ったか、リダイレクトURIが切り詰められたかがわかります。

よくある質問

単独の%や%G1のような不正な入力では何が起きますか？

ネイティブのdecodeURIComponentは、有効な%XX16進ペアではないシーケンスに対してURIError: URI malformedをスローします。このページはそれをキャッチして、クラッシュする代わりに「無効なエンコード: ...」を出力パネルに書き込みます。最も多い原因は、%25であるべきだった単独の%リテラル、または末尾の16進数が欠けたコピペです。

入力が二重エンコードされているかどうかをどう判断しますか？

一度デコードしてみてください。出力にまだ%文字（特に%20、%2F、%3A）が残っていて、本来プレーンテキストのはずなら、二度エンコードされています。最初のデコードの出力をもう一度デコードしてください。3回は珍しいですが起こり得ます — 通常は3つの異なるサービスが同じ値をそれぞれエンコードしたチェーンを意味します。

+記号はスペースにデコードされるべきでは？

decodeURIComponentではされません — +はそのまま残ります。+をスペースとする慣習はapplication/x-www-form-urlencoded（HTMLフォーム送信）のもので、一般的なURLパーセントエンコードのものではありません。フォームボディから来た入力で+がスペースの意味なら、まず.replace(/\+/g, "%20")を実行してからデコードしてください。application/x-www-form-urlencodedのWHATWG仕様がこの2つの流派の状況を説明しています。

Unicodeや絵文字も正しく往復しますか？

はい。パーセントエンコードされたマルチバイトUTF-8シーケンス（例: チェックマークは%E2%9C%85、ロケットは%F0%9F%9A%80）は元の文字に直接デコードされます。失敗するのは、エンコーダーがUTF-8以外の文字セットを使っていた場合だけですが、現代のシステムではそれは行われません。

ここに貼り付けた入力はどこかに送信されますか？

いいえ。デコードはあなたのブラウザ内で完結します。ネットワーク呼び出しもサーバーログもなく、何もマシンから出ません。トークン、メール、署名済みURL — すべて貼り付けても安全です。

どのくらいの大きさの文字列をここでデコードできますか？

入力には256 KBの上限があります。数百KBのパーセントエンコードされたテキストがあるなら、それはツールに貼り付けるよりサーバーサイドでデコードすべきペイロードである可能性が高いです — それほど大きいエンコード済みペイロードは通常、base64やリクエストボディが適切な場面でURLエンコードを誤用しているサインです。

その他のURL・エンコードツール

デコードは1つの操作です。これと自然に組み合わせられるツール: