スペース文字をエンコードするURL：+または％20？

URLのスペースはいつにエンコードされ+、いつエンコードされ%20ますか？

ウィキペディアから（強調とリンクを追加）：

HTMLフォームに入力されたデータが送信されると、フォームのフィールド名と値がエンコードされ、GETまたはPOSTメソッドを使用してHTTPリクエストメッセージでサーバーに送信されます。デフォルトで使用されるエンコーディングは、改行の正規化やスペースの "％20"ではなく "+"への置換など、多くの変更を加えた一般的なURIパーセントエンコーディングルールの非常に初期のバージョンに基づいています。この方法でエンコードされたMIMEタイプのデータはapplication / x-www-form-urlencodedであり、現在HTMLおよびXForms仕様で（まだ非常に古い方法で）定義されています。

したがって、URLのフォームデータがを使用する変更された形式であるときに、実際のパーセントエンコーディングが使用%20します+。その+ため、クエリ文字列内のURLでのみ表示されます?。

この混乱は、URLが今でも「壊れている」ためです。

たとえば「http://www.google.com」を例にとります。これはURLです。URLはUniform Resource Locatorであり、実際にはWebページへのポインタです（ほとんどの場合）。実際、URLは1994年の最初の仕様以来、非常に明確に定義された構造を持っています。

「http://www.google.com」のURL に関する詳細情報を抽出できます。

+---------------+-------------------+
|      Part     |      Data         |
+---------------+-------------------+
|  Scheme       | http              |
|  Host         | www.google.com    |
+---------------+-------------------+

次のようなより複雑なURLを見ると、

" https：// bob：bobby@www.lunatech.com：8080 / file; p = 1？q = 2＃third "

次の情報を抽出できます。

+-------------------+---------------------+
|        Part       |       Data          |
+-------------------+---------------------+
|  Scheme           | https               |
|  User             | bob                 |
|  Password         | bobby               |
|  Host             | www.lunatech.com    |
|  Port             | 8080                |
|  Path             | /file;p=1           |
|  Path parameter   | p=1                 |
|  Query            | q=2                 |
|  Fragment         | third               |
+-------------------+---------------------+

https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third
\___/   \_/ \___/ \______________/ \__/\_______/ \_/ \___/
  |      |    |          |          |      | \_/  |    |
Scheme User Password    Host       Port  Path |   | Fragment
        \_____________________________/       | Query
                       |               Path parameter
                   Authority

予約文字はパーツごとに異なります。

HTTP URLの場合、パスフラグメントパーツのスペースは「％20」にエンコードする必要があります（絶対に「+」ではない）。一方、パスフラグメントパーツの「+」文字はエンコードしないでおくことができます。

クエリ部分では、スペースは「+」（後方互換性のために：URI標準で検索しないでください）または「％20」のいずれかにエンコードできますが、「+」文字（このあいまいさの結果として） ） "％2B"にエスケープする必要があります。

つまり、「青+水色」の文字列は、パス部分とクエリ部分で別々にエンコードする必要があります。

「http://example.com/blue+light%20blue?blue%2Blight+blue」。

そこから、完全に構築されたURLをエンコードすることは、URL構造の構文上の認識がなければ不可能であると推測できます。

これは要約すると：

あなたは%20前後に持っている必要が?あり+ます。

ソース

お勧めし%20ます。

それらをハードコーディングしていますか？

ただし、これは言語間であまり一貫していません。誤解しない限り、PHP urlencode()ではスペースをとして扱い+、Python ではスペースをとしてurlencode()扱います%20。

編集：

誤解しているようです。Python urlencode()（少なくとも2.7.2では）のquote_plus()代わりにquote()を使用し、スペースを "+"としてエンコードします。W3Cの推奨事項は、http：//www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1のように "+"でもあるようです。

そして実際には、スペースのエンコードに何を使用するかについて、Python独自の課題追跡システムに関するこの興味深い議論をフォローできます：http : //bugs.python.org/issue13866。

編集＃2：

""をエンコードする最も一般的な方法は "+"であると理解していますが、ただのメモです。

import urllib
print(urllib.urlencode({' ' : '+ '})

>>> '+=%2B+'

スペースは、「application / x-www-form-urlencoded」コンテンツタイプのキーと値のペアのクエリ部分でのみ「+」にエンコードできます。私の意見では、これはMAYであり、MUSTではありません。残りのURLでは、％20としてエンコードされます。

私の意見では、URLのクエリ部分であっても、常に「+」ではなく％20としてスペースをエンコードする方が良いです。これは、スペース文字を「」としてエンコードするように指定したのがHTML仕様（RFC-1866）だからです「」/「application / x-www-form-urlencoded」コンテンツタイプのKey-Valueペア（8.2.1項、サブパラグラフ1を参照）

このフォームデータのエンコード方法は、後のHTML仕様でも規定されています。たとえば、HTML 4.01仕様などでapplication / x-www-form-urlencodedに関する関連する段落を探します。

HTML仕様でスペースをプラスとしてエンコードできるURLのサンプル文字列は次のとおりです： " http://example.com/over/there?name=foo+bar "。したがって、「？」の後のみ、スペースをプラス記号に置き換えることができます。その他の場合、スペースは％20にエンコードする必要があります。ただし、コンテキストを正しく判断するのは難しいため、スペースを「+」としてエンコードしないことがベストプラクティスです。

RFC-3986、p.2.3で定義されている「予約されていない」以外のすべての文字をパーセントエンコードすることをお勧めします。

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

実装は、選択したプログラミング言語によって異なります。

URLに国別文字が含まれている場合は、まずそれらをUTF-8にエンコードしてから、結果をパーセントエンコードします。