URLエンコード・デコード

「URLエンコード」という名前の下には、3つの異なるエンコードがあります。間違ったものを選ぶと、決してエラーを投げないバグが生まれます。

パーセントエンコードとフォームエンコードは別物

RFC 3986のパーセントエンコードでは、スペースは%20と書きます。application/x-www-form-urlencoded形式（クエリ文字列とフォームのPOSTボディが実際に使う形式）では、スペースは+と書かれます。つまり、リテラルのプラスは%2Bと書く必要があります。フォームボディをdecodeURIComponentでデコードすると、+はそのまま残ります。その結果、検索語「a + b」は、ユーザーがプラスを入力したときには「a + b」として届き、スペースを入力したときには「a+b」として届きます。どちらか一方は間違いなのに、どちらもエラーを出しません。

encodeURIComponentはRFCが予約する5文字をそのままにする

!、'、(、)、*の5文字はRFC 3986が予約しており、encodeURIComponentはこれらをそのままにします。たいていは無害です。しかし、エンコード結果を入力に署名を計算する場面では無害ではありません。だからこそ、AWS SigV4とOAuth 1.0aのライブラリはどれも独自のエンコーダを同梱しています。strictオプションはこれらもエンコードします。

URLの各構成要素にはそれぞれ固有のルールがある

パスには/を含められます。一方、クエリの値にエンコードしていない&を含めると、そこで2つのパラメータに分断されます。これがコンポーネントモードとURL全体モードの違いです。前者はunreserved以外のすべてをエンコードし、後者はURLの構造を形作る文字を保護します。URL全体をencodeURIComponentでエンコードすると、もはやURLではない文字列ができます。

二重エンコードと、その見分け方

%2520は、エンコーダを2回通ったスペースです。%20の%が、今度は%25としてエンコードされたものです。ログを流し読みする人には「%20」と見え、デコードした値にはリテラルの%20が生じます。このツールは、入力が何回のデコードに耐えるかを数えるので、紛れ込んだ余分な層は、不可思議な挙動ではなく目に見えるものになります。

URLの分解にはプラットフォームのパーサを使う

構成要素の分解には、正規表現ではなくブラウザ自身のURL実装を使っています。URLのパースにはuserinfo、IPv6リテラル、デフォルトポート、パーセントエンコードされたホストといったエッジケースが山ほどあり、プラットフォームに既にあるWHATWGアルゴリズムの方が、どんなパターンよりも短く、より正確だからです。重複するクエリキーは順序を保ったまま残します。多くのAPIがこれに意味を与えているからです。