URL エンコーディング解説

検索語が入った URL をコピーすると、空白やアクセント付き文字があるべき場所に %20 や %C3%A9 のようなものが見えることがよくあります。それが URL エンコーディングの働きです。このガイドはそれが何をするか、なぜ必要か、どの文字がエスケープされるかを説明します。

URL エンコーディングとは

URL エンコーディング — パーセントエンコーディング（percent-encoding） とも呼ばれます — は、そのままでは安全でない、あるいは曖昧になる文字を URL の中で表現する方法です。そうした文字はそれぞれ % に 16 進数のバイト値を続けたものに置き換えられます。空白は %20 に、アンパサンドは %26 になります。

なぜ必要なのか

URL は限られた文字集合しか含められず、その一部には特別な役割があります: ? はクエリ文字列を始め、& はパラメータを区切り、/ はパスセグメントを区切り、# はフラグメントを示します。URL に入れようとする値がこれらのどれかを含むなら、構造ではなくデータとして扱われるようにエンコードしなければなりません。

Search term:  cats & dogs
In a URL:     ?q=cats%20%26%20dogs

エンコードしないと、生の & が新しいパラメータの始まりと読まれ、検索が壊れてしまいます。

予約文字 vs. 非予約文字

• 非予約（Unreserved） 文字 — 英字、数字、そして - _ . ~ — は常に安全で、決してエンコードが必要ありません。
• 予約（Reserved） 文字 — ? & / # : @ = のようなもの — は特別な意味を持ち、文字どおりのデータとして使うときはエンコードしなければなりません。
• それ以外のすべて — 空白、アクセント付き文字、絵文字、そしてほとんどの記号 — はその UTF-8 バイトに基づいてエンコードされ、だから 1 文字が複数の %xx ペアになり得ます。

よくある混同: プラス記号

フォーム送信のクエリ文字列では、空白が %20 ではなく + としてエンコードされることがあります。文脈によってはどちらも「空白」を意味しうるため人々を戸惑わせます — 迷ったら %20 が常に安全です。

URL エンコーディング vs. Base64

この二つは別々の問題を解きます。URL エンコーディングはテキストを URL の中 に置くのに安全にします。Base64 は バイナリ データをテキストベースのチャネルで運ぶのに安全にします。両者は時に組み合わされますが（Base64URL）、交換可能ではありません。

値をエンコードまたはデコードするには URL エンコーダー を使い、クエリ文字列のすべてのパラメータを分解するには クエリ文字列パーサー がそれらを読みやすいリストに分けてくれます。