web-dev-qa-db-ja.com

URLで、スペースは％20または+を使用してエンコードする必要がありますか？

URLで、%20または+を使用してスペースをエンコードする必要がありますか？たとえば、次の例では、どれが正しいですか？

www.mydomain.com?type=xbox%20360
www.mydomain.com?type=xbox+360

当社は前者に傾いていますが、Javaメソッドを使用します URLEncoder.encode(String, String) with "xbox 360"（および"UTF-8"） 後者を返します =。

それで、違いは何ですか？

urlurlencodeurl-encoding
107
MegaByter

フォームデータ（GETまたはPOST用）は通常application/x-www-form-urlencodedとしてエンコードされます：これはスペースの+を指定します。

URLは%20を指定する RFC 1738 としてエンコードされます。

理論的には、?の前に％20が、+の後に+が必要です。

example.com/foo%20bar?foo+bar
96
Greg

W3C （およびこれらの公式ソース）によると、クエリ文字列（およびクエリ文字列のみ）のスペース文字は、「%20」としてエンコードされます。または「+」。 「推奨事項」の下の「クエリ文字列」セクションから：

クエリ文字列内で、プラス記号はスペースの省略表記として予約されています。したがって、実際のプラス記号をエンコードする必要があります。このメソッドは、スペースを許可しないシステムでクエリURIを渡しやすくするために使用されました。

一般的なURIの公式仕様である RFC2396 のセクション3.4によると、「クエリ」コンポーネントはURLに依存しています。

3.4。クエリコンポーネントクエリコンポーネントは、リソースによって解釈される情報の文字列です。

   query         = *uric

クエリコンポーネント内では、文字「;」、「/」、「？」、「：」、「@」、「＆」、「=」、「+」、「、」、および「$」が予約されています。

したがって、「+」文字としてエンコードされたクエリ文字列にスペースがあるURLを受け入れない場合、他のソフトウェアのバグになります。

質問の3番目の部分については、URLEncoder.encode()からの出力を修正する1つの方法（わずかにいですが）は、戻り値で callreplaceAll("\\+","%20")にすることです。

47
Adam Batkin

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

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

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

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

「 https：// bob：[email protected]：8080/file; p = 1？q = 2＃third 」のようなより複雑なURLを見ると、次の情報：

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

予約文字は各部分で異なります

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

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

つまり、「blue + light blue」文字列は、パス部分とクエリ部分で異なる方法でエンコードする必要があります。「 http://example.com/blue+light%20blue?blue%2Blight+blue 「。そこから、完全に構築されたURLのエンコードは、URL構造を構文的に認識しないと不可能であると推測できます。

要するにこれは

%20および?の前に+が必要です

ソース

14
Matas Vaitkevicius

文字Aを％41としてエンコードした場合を除いて、それは問題ではありません。

ただし、1つのフォームを認識しないシステムを扱っている場合は、「仕様」が何を言っているかに関係なく、期待どおりのものを与える必要があるように思えます。

6
Gary McGill

どちらでも使用できます。つまり、ほとんどの人は「+」を選択すると、人間が読みやすくなります。

5
Fenton