在網址空間的頁面被編碼爲+和20％沒有得到正確翻譯： 即不同的行爲時，空間在URL
http://www.streetinsider.com/Press發佈/全國的趨勢在普萊諾房屋市場/ 9778767.html反映
或
給出404請注意 「新聞發佈」 編碼爲 「按下％20Releases」。
但是，以下兩個版本在「Press Releases」編碼爲「Press + Releases」的情況下工作正常。
文章解析精用加號或HEX空格％20。 http://www.streetinsider.com/Press+Releases/National%20Trends%20Reflected%20in%20Plano%20Housing%20Market/9778767.html
+和％20都代表空格。那爲什麼是這種行爲。
而且也，在java中我有什麼可以用它來得到正確編碼的URL
兩個+和％20代表空格
只有在查詢字符串。在URL的其他地方，加號是一個加號，而不是空格。在這種情況下，Web服務器爲您提供了兩種不同的網址
和
但兩者相同內容 ü RL是獨特的，它們不是同一個URL的替代表示。
正式+可能只能用於查詢字符串（在?之後）。
這是URLEncoder的是：
"?x=" + URLEncoder.encode("Hello World", "UTF-8");
"?x=" + URLEncoder.encode("ŝi estas ĉarma", "UTF-8");
?x=Hello+World
?x=%C5%9Di+estas+%C4%89arma
的更普遍的類URI，服從於空間的規範進行替換，使用％。
URI uri = new URI("http", "www.streetinsider.com",
"/Press Releases/National Trends Reflected in Plano Housing Market/9778767.html",
"?x=ŝi estas ĉarma");
String u = uri.toString();
http://www.streetinsider.com/Press%20Releases/National%20Trends%20
Reflected%20in%20Plano%20Housing%20Market/9778767.html#?x=ŝi%20estas%20ĉarma
有時遇到URI作爲File和其他的泛化，然後必須小心，不要在文件名中引入％20。
因此，可能在+或甚至%20的streetinsider上有部分重新映射;以達到相同的代碼。
你的陳述
Both + and %20 represent spaces.
是不是在所有情況下完全如此。
空格字符只能在一個上下文中編碼爲「+」：application/x-www-form-urlencoded鍵值對。
RFC-1866（HTML 2.0規範）第8.2.1節。第1項說：「表單字段名稱和值被轉義：空格字符被替換爲'+'，然後保留字符被轉義」）。
以下是RFC-1866允許將空格編碼爲加號的URL中的這種字符串的示例：「http://example.com/over/there?name=foo+bar」。所以，只有在「？」之後，空格可以被加號代替（在其他情況下，空格應該被編碼爲％20）。這種編碼形式數據的方式也在稍後的HTML規範中給出，例如，在HTML 4.01規範中尋找關於application/x-www-form-urlencoded的相關段落，等等。
您所提供的網址不包含鍵/值對的表格數據，它只是一個9778767.html文件的路徑：
http://www.streetinsider.com/Press%20Releases/National+Trends+Reflected+in+Plano+Housing+Market/9778767.html
所以，它是非法在這裏使用的長處。在這種情況下，正確的URL應該如下：
http://www.streetinsider.com/Press%20Releases/National%20Trends%20Reflected%20in%20Plano%20Housing%20Market/9778767.html