URL エンコード / デコード
中国語のパラメータを変換 %E4%B8%AD%E6%96%87、文字化けしたリンクを復元できます。
encodeURIComponent はエスケープされます / ? & = などの区切り文字は、単一のパラメータ値に向いています；encodeURI 残す場合はリンク全体向きです。上の「全体」は 1 つ目の方式（最も一般的）を使い、「パラメータ値のみエンコード」は ? と & 1 つずつに分けて処理します。
使う場面
- リンクのクエリ値に日本語や空白、あるいは既に %26 にエンコードされた & が入っているとき。「パラメータ値のみ」なら ? と & の区切りはそのままに、値の中の既存のパーセントエンコードを %2526 のように二重化せず、一度デコードしてから再エンコードします。
- ログやアクセス解析、メールで %E4%B8%AD%E6%96%87 のような文字列を見つけ、人が読める形に戻したいとき。絵文字（4 バイト UTF-8）も正しく復元できます。
使わないほうがよい場面
- application/x-www-form-urlencoded のボディや署名対象の文字列を作るとき。この形式では空白を + にしますが、本ツールは %20 を出力します。厳密な実装では両者は別物なので URLSearchParams を使ってください。
- URL 全体をエンコードしつつ https:// やパスの区切りは残したいとき。それは encodeURI の役割です。本ツールの「全体」モードは encodeURIComponent と同じで、:// も %3A%2F%2F になります。
エンコードとデコードはブラウザ内で完結し、入力は送信されません。制限：ネイティブの encodeURIComponent / decodeURIComponent（UTF-8）を使うため、空白は %20 で + は空白として扱いません。パラメータモードは ? と & だけで分割し、# 以降のフラグメントや ; 区切りは解釈しません。不正な % の並びがあると全体がエラーになります。URL としての妥当性は検証しません。
よくある質問
空白が + ではなく %20 になるのはなぜ？
encodeURIComponent は RFC 3986 に従い、空白を %20 にします。+ にするのは HTML フォームの application/x-www-form-urlencoded の規則です。クエリ文字列では多くのフレームワークがどちらも受け付けますが、厳密な実装は自分の規則しか解釈しません。署名、OAuth、古いゲートウェイは + を文字どおりの加算記号として扱います。+ が必要なときは URLSearchParams で組み立ててください。手作業の置換は、すでに正しい %2B まで壊してしまいます。
「不正なパーセントエスケープ」と出てデコードできません
decodeURIComponent は、単独の %、%ZZ、%E4 のような途中で切れた並びに出会った時点で例外を投げます。原因はたいてい 3 つです。二重エンコード、チャットアプリによる切り詰め、そして本文が本当に 100% のような文字列を含んでいるケース。% の後ろに 16 進 2 桁があるかを確認し、文字としての % は %25 と書きます。本ツールは部分的な復元をせず全体を失敗させるため、ずれたまま「それらしい」結果を返すことはありません。
1 回デコードしても文字化けします。2 回必要ですか？
その場合は二重エンコードされています。リダイレクト用パラメータの中にコールバック URL が入れ子になっているときによく起きます。デコードは 1 回で 1 層だけ剥がします：%25E4%25B8%25AD が %E4%B8%AD に、次に「中」になります。連続して押しても構いませんが、何層剥がしているのかは意識してください。根本的にはエンコードを 1 回に直すべきです。二重エンコードは + や & の意味も予測しにくくし、調査を難しくします。