URLエンコード

正しい答えが3つあり、ボタン1つでは間違う理由

パーセントエンコーディングは、文字を % とそのバイト値の16進数に置き換えます。仕様は文字を3つのグループに分けており、分かりにくさはすべてそこから生じています。非予約文字（英字、数字、ハイフン、ピリオド、アンダースコア、チルダ）はエンコードする必要がありません。予約文字（URLの構造を作るスラッシュ、疑問符、アンパサンド、等号、コロン）は、*データであるときは*エンコードしなければならず、*構造であるときは*エンコードしてはいけません。それ以外はすべて常にエンコードします。

だからこそ、唯一の正解はありません。 URL全体をエンコードするなら、スラッシュや疑問符はそのままにしなければ、アドレスがアドレスでなくなります。クエリパラメーターに入れる値をエンコードするなら、アンパサンドと等号をエスケープしなければ、それを含む値が2つのパラメーターに分かれてしまいます。パスのセグメントをエンコードするなら、スラッシュをエスケープしなければ、スラッシュを含むファイル名が2つのディレクトリになってしまいます。「エンコード」ボタンが1つだけなら、このうち1つを選ぶことになり、残りの3分の2のケースでは間違えます。たいていは気づかれないまま、そして珍しい入力のときにだけ表に出る形で。

最も多くの経緯を背負っている文字がスペースです。URLの中では %20 です。HTMLフォームで送信されると + になります。これは別の古いエンコード方式で、フォームが1994年からそう動いてきたために残っています。どちらもそれぞれの文脈では正しく、もう一方の文脈では正しくありません。クエリ文字列の中のプラス記号が曖昧になるのはそのためで、これはエンコードする側がいくら気を付けても解決できません。

ASCII以外のテキストはまずUTF-8にエンコードしてから1バイトずつエンコードするため、アクセント付きの1文字は2つ、絵文字は4つのパーセントシーケンスになります。典型的なバグが二重エンコードです。すでにエンコード済みのものをエンコードするとすべての % が %25 になり、%20は%2520になって、受け取る側には%記号がそのまま届きます。URLに%25がたくさん含まれていたら、エンコーダーを1回余計に通っています。

ほかの目的には

コードでは、言語に用意された関数を使い、このページで選ぶのと同じくらい意識して選んでください。JavaScriptにはアドレス全体用の encodeURI と値用の encodeURIComponent があります。Pythonの urllib.parse.quote には、デフォルトでスラッシュをそのまま残す safe 引数があります。PHPは rawurlencode と urlencode を区別しており、両者の違いはまさに上で述べたスペースかプラスかの問題です。さらに良いのは、文字列をつなげるのではなくURL型を使ってURLを組み立てることで、そうすればこの問題自体がなくなります。

コマンドラインでは、jq -rR @uri が安全にエンコードでき、リストも扱えます。curl --data-urlencode は、3つのうちどのケースかを考えなくても正しくエンコードしたパラメーターを組み立ててくれます。これが本当に簡単に済む唯一の場面です。