%E4%B8%AD%E6%96%87 のようなパーセントエンコーディングを、ここで元の文字に戻せます。逆方向も可能で、日本語やスペース、記号を URL に安全に入れられる形へエンコードできます。UTF-8 と GBK の 2 つの文字セットに対応し、スペースを表す + も認識します。URL を丸ごと貼り付ければ、クエリパラメータも自動で分解して 1 つずつデコードします。すべてブラウザ内で完結し、データは一切送信されません。%XX が含まれていれば自動でデコードに、含まれていなければエンコードに切り替わります。自分でボタンを押したあとは、自動では切り替えません。% があっても全体が失敗することはありません。その数文字だけをそのまま残し、ほかは通常どおりデコードします。URL の仕様（RFC 3986）で使えるのは英数字とごく一部の記号だけで、漢字や仮名、スペース、引用符は含まれていません。これらをリンクに入れるには、まず何らかの文字セットでバイト列に変換し、各バイトをパーセント記号と 16 進 2 桁で書き表す必要があります。これがパーセントエンコーディング、別名 URL エンコードです。「中」という漢字は UTF-8 では 3 バイトの E4 B8 AD で、書き下すと %E4%B8%AD になります。つまり %E4%B8... の並びは文字化けでも暗号でもなく、同じ文字列の別の書き方にすぎません。 %XX が 3 つひと組で並んでいれば、UTF-8 でエンコードされた漢字や仮名だとほぼ判断できます。
コードを書くときにいちばん間違えやすいところです。encodeURIComponent は : / ? # & = といった構造を表す文字までエンコードします。向いているのは個々のパラメータ値です。一方 encodeURI はそれらを残すので、向いているのはすでに組み立て終えた URL 全体です。取り違えたときの結果は具体的です。URL 全体に使うのが encodeURIComponent、https:// のような部分まで https%3A%2F%2F になってリンクが壊れます。逆に、 encodeURI で、 & を含むパラメータ値（たとえば検索語が「A&B」の場合）をエンコードすると、その & はそのまま残るため、サーバー側は区切り文字と解釈し、1 つのパラメータが 2 つに割れてしまいます。上のエンコード方式は両方用意してあり、既定はパラメータ値のほうです。
URL エンコードは Base64と同じくエンコードであって、暗号化ではありません。規則は完全に公開されていて鍵もなく、文字列さえあれば誰でも一手で元に戻せます——このページがまさにそれをしています。存在意義は、特殊な文字を URL という経路に安全に通すことであり、秘匿性はいっさい提供しません。注文番号や電話番号、内部 ID を URL エンコードしてリンクに入れても、何も保護したことになりません。アドレスバーにもサーバーのログにも Referer ヘッダーにも、平文のまま残ります。本当に不可逆にしたい場合は SHA-256 を、機微なパラメータを送るなら HTTPS 上の POST を使ってください。ちなみに「URL 復号」という言い方はそもそも成り立ちません。正しい言葉はデコードです。
スペースには 2 通りの書き方があります。フォーム送信で使われる application/x-www-form-urlencoded はスペースを + にエンコードしますが、パスや現代的な API では一般に %20 が使われます。厄介なのは、JavaScript の decodeURIComponent が + を解釈せず、プラス記号をそのまま残してしまうことです。そのため、このページには切り替えを用意し、既定ではスペースとして解釈します。逆に、内容にもともとプラス記号が含まれている場合（たとえば 1+1）、エンコードすると %2B になりますが、これで正しい動作です。
文字セットがもう 1 つの落とし穴です。いまはどこも UTF-8 が既定ですが、古いサイトや古いシステムには GBK（中国語圏で使われてきた文字セット）を使うものが少なくありません。「中」は GBK では 2 バイトの %D6%D0 です。GBK でエンコードされた内容を UTF-8 として読めば、出てくるのは「?」や「□」です。このページはデコード側で GBK に切り替えられます。エンコード側は UTF-8 のみです。ブラウザが標準で生成できるのが UTF-8 だけだからです。
言語ごとの関数名の対応。PHP の urlencode はスペースを +、rawurlencode は %20 にエンコードします。対応するデコードは urldecode / rawurldecode です。Java の URLEncoder.encode(s, "UTF-8") はフォーム送信の流儀に従うので、こちらも + です。Python は urllib.parse.quote / unquote を使い、 quote_plus だけが + にします。JavaScript には encodeURIComponent / decodeURIComponent しかなく、常に %20 です。フロントエンドとバックエンドで結果が食い違うときは、たいていこのプラス記号が原因です。
それは URL エンコードされた文字であって、文字化けではありません。URL の仕様で使えるのは英数字とごく一部の記号だけなので、それ以外の文字はまず UTF-8 でバイト列に変換され、各バイトが 1 つの %XX として書かれます。漢字や仮名は通常 %XX 3 つ分になります。全体を上に貼り付けて「デコード」を押せば元に戻ります。逆もまた同じで、アドレスバーに日本語のまま見えているリンクは、ブラウザがエンコード済みの形を読める形で表示しているだけなので、コピーするとたいてい %XX。
まずは GBK に切り替えて、もう一度デコードしてください。ここでは既定で UTF-8 として解釈しますが、古いサイトや古いシステムには GBK を使うものが少なくありません。同じ「中」という漢字が UTF-8 では %E4%B8%AD、GBK では %D6%D0 になるため、文字セットを間違えれば必ず「?」や「□」になります。簡単な見分け方があります。%XX が 3 つひと組なら UTF-8、2 つひと組で先頭バイトが %A1–%FE の範囲に収まっていれば GBK である可能性が高いです。
前者は : / ? # & = までまとめてエンコードするので、用途は個々のパラメータ値です。後者はこれらの構造文字を残すので、用途はURL 全体です。URL を組み立てるときは、ほぼ常に encodeURIComponent で各パラメータ値をエンコードし、 ? と & は自分で連結します。 encodeURI で URL 全体をエンコードするのが向くのは、「リンクはすでに組み立て済みで、中の日本語やスペースだけを正当な形にしたい」という場面だけです。
文脈によります。そしてここが最も間違えやすいところです。フォーム送信（application/x-www-form-urlencoded）はスペースを + にエンコードするので、クエリ文字列の中の + はたいていスペースです。一方、パス部分や現代的な API に出てくる + は普通そのままプラス記号です。JavaScript の decodeURIComponent はこの変換を行いません。このページは既定で + をスペースとして扱うので、内容にもともとプラス記号が含まれる場合（たとえば C++）は、そのチェックを外してからデコードしてください。
文字列に不正なパーセント列があるということです。% のあとに 16 進 2 桁が続いていないか、バイト列が正しい UTF-8 になっていない状態です。コピーの際に文字が欠けた場合や、内容が二重にエンコードされている場合によく起こります（%25E4 のような形で、%25 は % そのものなので、もう一度デコードすれば本来の文字になります）。このページはこれで全体を失敗させることはありません。不正な部分だけをそのまま残し、ほかは通常どおりデコードするので、どこが壊れているかがそのまま見て取れます。
できません。暗号化とは無関係です。規則は公開されていて誰でも一手で元に戻せるので、電話番号も注文番号も、エンコードしたところでアドレスバー・閲覧履歴・サーバーログ・Referer ヘッダーに平文のまま残ります。機微なパラメータを本当に守りたいなら、HTTPS 上の POST で送り、サーバー側で権限を検証し、あるいは不可逆なハッシュ値に置き換えてください。なお「URL 復号」という言い方自体が不正確で、正しくはデコードです。
いいえ。エンコードとデコードにはブラウザ内蔵の encodeURIComponent / TextDecoder を使い、すべてお使いの端末で計算してそのまま表示します。1 バイトもブラウザの外には出ません。ページを読み込んだあとにネットワークを切っても動作します——これがいちばん直接的な確認方法です。トークンや注文番号を含むリンクも安心して貼り付けられます。詳しくはプライバシーポリシー。
あります。JSON 整形は API のレスポンスを読める階層に展開し、Base64 エンコード / デコードはもう 1 つのよく出会うエンコードを扱い、タイムスタンプ変換はログの 10 桁 / 13 桁の数字を人が読める日時に直します。MD5 と SHA-256 は検証用のハッシュを計算します。いずれも同じくローカルで動作し、データは送信しません。