特殊文字のURLエンコーディング: 開発者向けリファレンス

URLにおける特殊文字

URLはRFC 3986で定義された厳密な構文を持っています。多くの文字は特別な意味を持っていたり、URLの特定の部分では使用が許可されていなかったりします。これらの文字を正しくエンコードする方法を理解することは、信頼性の高いWebアプリケーションやAPIを構築するうえで欠かせません。

スペース文字

スペース文字は最も頻繁にエンコードされる文字です。ただし、文脈に応じて2通りのエンコード方法があります。

• %20 - RFC 3986のパーセントエンコーディング。URLパスをはじめ、ほとんどの文脈で使われます
• + - application/x-www-form-urlencoded形式（HTMLフォームの送信）で使われます

プログラムでURLを組み立てる場合は、一貫性のために%20を使うのがおすすめです。フォームデータを構築する場合は、+表記が標準となります。

予約文字の詳細

アンパサンド (&)

アンパサンドはクエリパラメータを区切ります。パラメータの値の中にアンパサンドが含まれる場合は、区切り文字として解釈されないように%26としてエンコードする必要があります。HTMLの文脈では、さらに&としてエンティティエンコードする必要もあります。

疑問符 (?)

疑問符はパスとクエリ文字列を区切ります。パラメータの値の中に疑問符が含まれる場合は、%3Fとしてエンコードする必要があります。なお、encodeURI()は疑問符をエンコードしませんが、encodeURIComponent()はエンコードする点に注意してください。

ハッシュ (#)

ハッシュ記号はフラグメント識別子の始まりを表します。URL内では、クエリパラメータの値に含まれる#はすべて%23としてエンコードしなければなりません。そうしないと、ブラウザはその後ろにあるすべてをフラグメント識別子として解釈し、サーバーに送信しなくなります。

スラッシュ (/)

スラッシュはパスのセグメントを区切ります。パスセグメントの値の中にスラッシュが含まれる場合（スラッシュを含むファイル名など）は、%2Fとしてエンコードする必要があります。なお、一部のサーバーは%2Fをデコードしたうえで、依然としてパスの区切り文字として扱うことがある点に注意してください。

Unicode文字

非ASCII文字は、まずUTF-8のバイト列に変換し、その各バイトをパーセントエンコードすることでエンコードします。以下にいくつかの例を示します。

• アキュートアクセント付きのラテン文字e (e) → UTF-8: 0xC3 0xA9 → %C3%A9
• 漢字（中） → UTF-8: 0xE4 0xB8 0xAD → %E4%B8%AD
• 絵文字（地球） → UTF-8: 0xF0 0x9F 0x8C 0x8D → %F0%9F%8C%8D

URLの各構成要素におけるエンコーディング

構成要素	エンコードが必要な文字	例
パスセグメント	スペース、?、#、非ASCII	/path/my%20file
クエリのキー	=、&、#、+、スペース	my%20key=value
クエリの値	&、#、+、スペース、=	key=hello%20world
フラグメント	スペースと非ASCII	#section%20one

よくある落とし穴

• クエリの値で#をエンコードし忘れる（URLの残りの部分が黙って切り捨てられる）
• すでにエンコード済みの文字列を二重にエンコードしてしまう（%20ではなく%2520になってしまう）
• パラメータの値にencodeURIComponent()ではなくencodeURI()を使ってしまう
• クエリの値で+をエンコードしない（スペースとしてデコードされてしまう）
• すべてのサーバーがパス内の%2Fを同じように扱うと思い込む