130

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

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

当社は前者に傾いていますが、 (and )で Java メソッドURLEncoder.encode(String, String)を使用すると、後者が返されます。"xbox 360""UTF-8"

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

4

6 に答える 6

119

フォーム データ (GET または POST 用) は通常、次のようにエンコードされます。これは、スペースをapplication/x-www-form-urlencoded指定します。+

URL はRFC 1738としてエンコードされ、 %20.

?理論的には、 %20 の前と + の後にある必要があると思います:

example.com/foo%20bar?foo+bar
于 2009-07-31T08:08:58.187 に答える
53

W3Cによると(これらは公式のソースです)、クエリ文字列 (およびクエリ文字列のみ) 内の空白文字は、" %20" または " "としてエンコードされる可能性があります+。「推奨事項」の下の「クエリ文字列」セクションから：

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

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

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

   query         = *uric

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

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

あなたの質問の3番目の部分については、出力を修正する1つの方法（少し醜いですが）は、戻り値URLEncoder.encode()を呼び出すことです。 replaceAll("\\+","%20")

于 2009-07-31T08:09:42.663 に答える
25

この混乱は、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:bobby@www.lunatech.com: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前後に?持っ+ているべきです

ソース

于 2015-11-26T12:54:24.410 に答える
8

文字 A を %41 としてエンコードした場合と同じように、問題にはなりません。

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

于 2009-07-31T08:07:47.813 に答える
5

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

于 2009-07-31T08:10:39.620 に答える