URLエンコード・デコード
テキストのURLエンコード・デコードをリアルタイムで変換。クエリパラメータの確認・日本語URLの処理に。
他のオンラインツール
📖 つまずきやすいポイント
テキストの URL エンコードとデコードをリアルタイムに行います。encodeURIComponent に準拠し、処理はブラウザ内で完結します。「URL エンコード」と呼ばれる処理は 1 種類ではありません — URL のどこに置く値なのかによって、エスケープすべき文字が違います。パスの一部と、クエリの値と、フォームの送信内容では規則が異なり、この取り違えが不具合のほとんどを生みます。
| ケース | 何が起きるか | どうする |
|---|---|---|
| encodeURI と encodeURIComponent を取り違える | encodeURI は「URL 全体をエンコードする」ための関数なので、URL の区切りとして意味を持つ /・?・&・=・#・: をそのまま残します。したがってクエリの「値」として URL を渡すときにこれを使うと、値の中の & や = が区切りとして解釈され、パラメータが割れます — ?redirect=https://a.com/?x=1&y=2 なら、受け取る側は redirect・y という 2 つのパラメータとして読みます。症状は「値の途中で切れる」なので、短い値でテストしていると気付けません。 |
URL の「部品」には常に encodeURIComponent を使ってください — クエリの値、パスの 1 セグメント、フラグメントの中身は、すべて部品です。encodeURI を使ってよいのは、すでに組み立て終わった URL 全体を一度だけ通すときだけで、実務ではほとんど出番がありません。より確実なのは、自分で文字列を連結せずに URLSearchParams や new URL() を使うことです — const u = new URL(base); u.searchParams.set("redirect", target); と書けば、エスケープの判断そのものが不要になります。「URL を文字列連結で組み立てている箇所」は、それ自体がバグの候補だと考えてください。 |
| プラス記号が空白に化ける | 空白の表し方が 2 通りあります。URI のパーセントエンコーディングでは %20 ですが、HTML フォームの application/x-www-form-urlencoded では + です。encodeURIComponent は前者に従うので空白を %20 にしますが、受け取る側が form 形式として解釈すると、値に含まれていた本物の + が空白に変換されます。実害が大きいのはメールアドレスのエイリアスで、user+tag@example.com をクエリで渡すと user tag@example.com になって届かなくなります。Base64 の標準アルファベットにも + が含まれるので、トークンを URL に載せると同じ問題が起きます。 |
クエリ文字列を組み立てるなら URLSearchParams を使ってください — 値の中の + を正しく %2B にエスケープし、空白は + として書き出しますので、受け取る側が form 形式として解釈しても一貫します。手で組み立てる場合は、値に + が含まれうるなら明示的に %2B に置き換えてください。Base64 を URL に載せるなら、最初から URL-safe 形式 (- と _) を使ってください — 標準アルファベットを URL エンコードするより確実です。この問題は「たまたま値に + が入っていたときだけ壊れる」ので、テストデータに必ず + を含む値を入れてください。 |
| 二重エンコードで %25 が並ぶ | すでにエンコードされた文字列をもう一度エンコードすると、% 自身が %25 になります — %20 は %2520 に、日本語なら %E3%81%82 が %25E3%2581%2582 になります。デコードを 1 回しかしない側では、この余分な層がそのまま残って画面に %20 という文字列が表示されます。原因は「どの層でエンコードするか」が決まっていないことで、フレームワークが自動でエンコードしているのに、アプリケーション側でも手動でエンコードしている、という組み合わせが典型です。片方を消せば直りますが、どちらを消すべきかはコードを追わないと分かりません。 |
エンコードする場所を 1 箇所に決めて、ドキュメントに書いてください — 「この関数はエンコード済みの値を受け取る」「この層でのみエンコードする」と明記すれば、二重エンコードは構造的に起きなくなります。そしてデコードは必ず 1 回だけにしてください — 「まだ % が残っているからもう一度デコードする」というループは深刻な脆弱性になります。攻撃者が %252e%252e%252f を送り、1 回目のデコードで %2e%2e%2f、2 回目で ../ になると、パストラバーサルの検査を通り抜けます — 検査は 1 回目のデコード結果に対して行われるためです。「念のためもう一度デコードする」という発想自体を避けてください。 |
ドメイン名は URL エンコードではなく Punycode です。日本語ドメインの 例え.テスト は %E4%BE%8B... ではなく xn--r8jz45g.xn--zckzah という形式に変換されて DNS に送られます — ブラウザはアドレスバーに日本語で表示しますが、それは表示上の親切であって、実際に問い合わせているのは xn-- の文字列です。なお、見た目のよく似た別の文字を使ったフィッシング (ホモグラフ攻撃) があるため、ブラウザは条件によって Punycode をそのまま表示します — 「知っているはずのドメインが xn-- で表示されたら疑う」というのは有効な習慣です。もう 1 点、URL のフラグメント (# 以降) はサーバーに送信されません — アクセスログにもリファラにも残らないので、クエリよりは安全です。ただしブラウザの履歴には残るので、機密を URL に入れないという原則は変わりません。
📖 使い方
-
1
エンコードしたいテキストを入力上側の入力欄に日本語・空白・記号などを含むテキストを貼り付けます。encodeURIComponent に従い % + 16 進数の形式でリアルタイムに変換されます。
-
2
デコードしたいエンコード済み文字列を入力下側の入力欄に %E3%81%93%E3%82%93... などの URL エンコード済み文字列を貼り付けます。デコードしてオリジナルのテキストがリアルタイムで表示されます。
-
3
結果をコピーして利用各欄右上の「コピー」ボタンで結果をクリップボードにコピーできます。クエリパラメータ・フォームデータ・API リクエストなど幅広い場面で活用できます。
❓ よくある質問
encodeURIComponent と encodeURI の違いは何ですか?
日本語の URL はどうなりますか?
+記号はスペースを表しますか?
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。