URL エンコード

URL は部分でできていて、それらを区切る文字——`/`、`?`、`&`、`=`、`#`——は、その役割を果たしているときは構造であり、そうでないときはデータです。アドレス全体のエンコードはそれらに触れてはならず、触れればアドレスでなくなります。単独の値のエンコードはそれらを逃がさなければならず、さもなければ値がそこで終わって別の何かが始まります。

これは `encodeURI` と `encodeURIComponent` の違いそのもので、ウェブに存在する壊れたリダイレクトパラメーターの大半がここから出ています。`?next=https://example.com/a?b=c` の 2 つめの疑問符がエスケープされておらず、その後ろがすべて外側の URL のものになる。リンクは、遷移先にクエリ文字列のないテスト環境では動き、ある本番では壊れます。

パーセント列は `%` に 16 進 2 桁が続いたもので、1 バイトを指します。ASCII の外の文字は複数必要です。「あ」は `%E3%81%82` の 3 列で、漢字も 3 列、絵文字は 4 列です。

古い `escape()` 関数はこれをまったく別に扱い、U+00FF を超える文字に `%u3042` という独自の形を出します。標準ではなく、これを受け取ったサーバーはパーセントデコードでは戻せません。その出力はいまも古いコードと一部の古い連携に残っています。ここでは最初から最後まで UTF-8 です。

`encodeURIComponent` は感嘆符、アポストロフィー、2 種類の丸かっこ、アスタリスクをエスケープしません。RFC 3986 はそれらを予約文字として挙げているので、厳密に準拠するエンコーダーはエスケープします。両者は、普通の文章に絶えず現れる 5 つの文字で食い違います。

気づくのは署名が絡んだときだけです。OAuth 1.0 と AWS Signature Version 4 はエンコード後の文字列に対してハッシュを計算するので、エスケープされていないアポストロフィーが 1 つあるだけでハッシュが変わり、リクエストが拒否されます。しかも資格情報に関するエラーとして返るので、まったく見当違いの場所を探すことになります。ここの厳密モードは 5 つとも逃がします。

両方が現れ、しかも同じ規則ではありません。`%20` はパーセントエンコードで、URL のどの部分でも正しい形です。プラス記号は `application/x-www-form-urlencoded`——HTML のフォームが送信する形式——から来ていて、そこでは空白が `+` と書かれます。現在の仕様より古い慣習が、フォームが生き残っているために生き残っています。

パスの中の `+` は本物のプラスです。クエリ文字列の中では、フォームの符号化がそう定めているため、ほとんどのサーバーが空白として読みます。つまりクエリの値の中の本物のプラスは `%2B` と書かなければ消えます。このエンコーダーは `%20` を出します。どちらの場所でも曖昧になりません。

すでにエンコードされた文字列をエンコードすると `%` 自体が逃がされ、`%20` は `%2520` になります。関係するどの部品にとってもこれは誤りではありません。文字列「%20」の完全に妥当なエンコードです。だから二重エンコードは、利用者が見出しに `こんにちは%20世界` を見る地点まで生き延びます。

手がかりは、`%` があるべき場所の `%25` です。見つけたら、鎖のどこかがエンコード済みの値をもう一度エンコードしています。たいていはフレームワークが自動でやり、テンプレートがもう一度やっています。直し方は片方を取り除くことで、末端で 2 回デコードすることではありません。

英数字と `-`、`_`、`.`、`~` の 4 文字は RFC 3986 で「unreserved」と呼ばれ、決してエスケープすべきではありません。ピリオドの代わりに `%2E` を出すエンコーダーは厳密なのではなく、間違っています。一部のシステムはそれを元に戻して正規化し、別のシステムはしないので、同じであるべき 2 つの URL が同じでなくなります。

実務上は、テキストがほとんど英数字なのにパーセント列だらけになっている文字列は、過剰にエンコードする道具から来ていることが多いです。誰かがそれに対して署名やキャッシュキーを計算するまでは無害で、そこから先は 2 つのシステムが噛み合わない理由になります。

`#` より後ろのものはすべてブラウザーに留まります。どのリクエストにも現れず、どのサーバーにも届かず、どのアクセスログにも載りません。プライバシー機能ではなく HTTP の性質で、両方向に切れます。

便利なのは、そこに置いた値がサーバーへ届かないからです。歴史的に OAuth のトークンがそこを旅した理由でもあります。厄介なのは、それでもブラウザーの履歴に残り、一部のスクリプトのリファラー連鎖に残り、共有されたリンクに残るからです。「サーバーへ届かない」は「非公開である」ではありません。

日本語のドメイン名はエスケープされません。Punycode に変換されます。`日本.example` は `xn--wgv71a.example` になります。これが DNS に実在する形です。名前解決の仕組みは ASCII しか知りません。

ホストを値のように扱うエンコーダーは、どの DNS も解決できないアドレスを作ります。だからここのアドレス全体モードはホストに触れません。そして日本語ドメインを含む URL を組み立てているなら、ホストの変換はこの操作の一部ではなく、別の手順です。

エンコードされたものはたいてい URL に入り、URL はサーバーのログ、ブラウザーの履歴、次のクリックのリファラーヘッダーに残ります。値にメールアドレスや識別子や個人的な検索語が入っていれば、使われた瞬間にすでに複数の場所にあります。

このページが解決するのは、エンコードがあなたの端末で行われ、その値が当方へ提供されないという部分です。解決できないのはもう一方で、それはここで言うに値します。個人データが意図せず記録される最も多い場所は、URL のパラメーターです。