URLエンコード・デコード

URLに使えるASCII文字は限られています。2005年に策定されたURI構文の仕様であるRFC 3986は、それらを2つのグループに分けています。非予約文字（A–Z、a–z、0–9、および記号の - . _ ~ の4つ）は、エンコードする必要がありません。予約文字にはそれぞれ役割があります。一般区切り文字 : / ? # [ ] @ はスキーム、ホスト、パス、クエリ、フラグメントを区切り、サブ区切り文字 ! $ & ' ( ) * + , ; = はその内部の項目を区切ります（クエリ文字列での & と = がその例です）。それ以外の文字や、通常のデータとして使う予約文字は、パーセントエンコードが必要です。

パーセントエンコードは、1バイトを % とそれに続く2桁の16進数で表します。テキストはまずUTF-8に変換されるため、スペースは %20、é（2バイト）は %C3%A9、絵文字は4つの %XX になります。そのため、「café & bar」の検索はリンク内で caf%C3%A9%20%26%20bar となります。& をエンコードしておくことで、サーバーが新しいパラメーターの開始と誤解しません。

クエリの値、パスの一部分、パラメーターとして渡すリダイレクトURLのように、1つの部分だけを扱うなら encodeURIComponent が適切です。非予約文字と、JavaScriptが歴史的な理由でそのまま残す ! ' ( ) * 以外はすべてエスケープされます。encodeURI（URL全体） は、入力がすでに完全なアドレスであると想定して予約文字をそのまま残すため、https://example.com/a b?q=1 ではスペースだけがエンコードされます。パラメーターの値にencodeURIを使うのはよくあるバグです。値に含まれる & や # が残ったままになり、URLが壊れます。

デコードは、どちらの関数の処理も元に戻します。GETで送信されるHTMLフォームは、古い application/x-www-form-urlencoded 形式を使い、スペースを %20 ではなく + で表します。その場合は + をスペースとして扱う にチェックを入れたままにし、電話番号のようにプラス記号そのものが必要な場合はチェックを外してください。% の後ろに2桁の16進数がない場合や、UTF-8として無効なバイトが含まれる場合は、推測せずに分かりやすいメッセージを表示してデコードを失敗とします。テキストにクエリ文字列が含まれていれば、ツールの下の表にデコードされたパラメーターが表示されます。URL内でバイナリデータを扱う場合は、Base64url が一般的な代替手段です。