URLのスペースは+
いつにエンコードされ、いつエンコードされ%20
ますか?
4 に答える
ウィキペディアから(強調とリンクが追加されました):
HTMLフォームに入力されたデータが送信されると、フォームのフィールド名と値がエンコードされ、メソッドGETまたはPOSTを使用して、または従来は電子メールを介してHTTP要求メッセージでサーバーに送信されます。デフォルトで使用されるエンコーディングは、一般的なURIパーセントエンコーディングルールの非常に初期のバージョンに基づいており、改行の正規化やスペースを「%20」ではなく「+」に置き換えるなどの多くの変更が加えられています。この方法でエンコードされたデータのMIMEタイプはapplication/x-www-form-urlencodedであり、現在HTMLおよびXForms仕様で定義されています(まだ非常に時代遅れの方法です)。
したがって、実際のパーセントエンコーディングは%20
、URLのフォームデータがを使用する変更されたフォームである間に使用します+
。したがって、ほとんどの場合、。+
の後にあるクエリ文字列のURLにのみ表示されます?
。
この混乱は、URLが今日でも「壊れている」ためです。
ブログ投稿から:
たとえば、「http://www.google.com」を考えてみましょう。これはURLです。URLはUniformResourceLocatorであり、実際には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ではスペースをとして扱いますが、Pythonurlencode()
ではスペースをとして扱います。+
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+'
スペースは、URLの「application/x-www-form-urlencoded」コンテンツタイプのキーと値のペアのクエリ部分で「+」にのみエンコードできます。私の意見では、これは必須ではなく、 5月です。残りのURLでは、%20としてエンコードされます。
私の意見では、スペース文字を「+」としてエンコードするように指定したのはHTML仕様(RFC 1866)であるため、URLのクエリ部分でも、常にスペースを「+」ではなく%20としてエンコードすることをお勧めします。 "" application / x-www-form-urlencoded "コンテンツタイプのキーと値のペア(8.2.1項。サブパラグラフ1を参照)
フォームデータをエンコードするこの方法は、後のHTML仕様でも規定されています。たとえば、HTML4.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にエンコードしてから、結果をパーセントエンコードします。