要点：URL エンコード（パーセントエンコード）は、URL でそのまま使えない文字を %XX 列に置き換え、空白・アクセント・記号があってもリンクを保ちます。空白は %20、アンパサンドは %26 になります。肝心なのは、URL 全体をエンコードするのか、単一のクエリ値だけをエンコードするのかを見分けること——そして encodeURIComponent と encodeURI は交換可能ではない、という点です。
URL が安全に含められる文字は限られています。それ以外——空白、アクセント文字、そして ?・&・#・= のような予約記号——はパーセントエンコードが必要で、さもないとリンクが壊れるか、意図しない場所を指します。
パーセントエンコードが実際にすること
URL でそのまま使えない文字はそれぞれ、パーセント記号にその 16 進バイト値を続けた形に置き換えられます。空白は %20、アンパサンドは %26、疑問符は %3F。デコードはこれを逆にし、有効な %XX をすべて元の文字へ戻します。
空白は %20 か + か
どちらも「空白」を意味し得ますが、同じ場所ではありません。%20 は URL のパスとクエリ全体で使うパーセントエンコードの空白です。プラス記号 + は application/x-www-form-urlencoded の文脈（フォーム送信とクエリ文字列）でのみ空白を意味し、それ以外では文字どおりに扱われます。迷ったら %20 がより安全で普遍的です。
encodeURIComponent と encodeURI
これがつまずきやすい区別です。URL に差し込む単一の値には encodeURIComponent を使います——たとえば ?q=hello%20world の検索語です。& や = のような予約文字をエンコードし、URL の構造と誤認されないようにします。encodeURI は完全な URL にのみ使い、そこでは予約文字が構造上の意味を保つ必要があります。URL 全体を encodeURIComponent でエンコードすると自身の :// や ? を壊し、単一パラメータを encodeURI でエンコードするとURL でそのまま使えない文字がエスケープされずに残ります。
いつエンコードするか
- ユーザー入力からクエリ文字列を組み立てるとき（検索語、フィルタ、名前）。
- あるリンクを別のリンクの
?redirect=や?url=パラメータとして入れるとき。 - 空白やアクセントを含むファイル名やパスを扱うとき。
- ローカルでは動くのに共有すると壊れるリンクをデバッグするとき。
URL エンコードは Base64 ではない
両者は別の問題を解きます。パーセントエンコードはURL でそのまま使えない文字を URL 内で使える形にし、Base64 はバイナリデータを簡潔な ASCII 文字列へ再符号化します。その出力もリンクに入れるなら URL エンコードが必要です。取り違えると、エンコード済みに見えて動かないリンクになります。
実用的なワークフロー
生の値を URL エンコーダー / デコーダー に貼り付けて、パラメータをエンコードするか、疑わしい %XX 文字列をデコードします——有効な列はデコードし、無効な列は黙って壊さず警告します。同じ内容が Base64 も通るなら、Base64 エンコーダー / デコーダー で確認し、二つの手順を正しい順序で適用しましょう。
避けたいよくある間違い
- URL 全体を
encodeURIComponentでエンコードし、構造を壊す。 +が URL のどこでも空白を意味すると思い込む。- 二重エンコード——すでにエンコード済みの文字列を再度エンコーダーに通す。
- パーセントエンコードを Base64 と混同する。
全体ではなく各部分をエンコードすれば、空白・アクセント・入れ子の URL を含むリンクも無事に届きます。