編碼空格字符的URL：+或％20？

URL中的空格什麼時候編碼爲+ ，什麼時候編碼爲%20 ？

---

#1樓

來自維基百科 （重點和連接添加）：

當提交已輸入HTML表單的數據時，表單字段名稱和值將被編碼並使用方法GET或POST在HTTP請求消息中發送到服務器，或者歷史上經過電子郵件發送到服務器。 默認使用的編碼基於通常URI百分比編碼規則的早期版本，具備許多修改，例如換行標準化和用「+」而不是「％20」替換空格。 以這種方式編碼的MIME類型是application / x-www-form-urlencoded，而且它當前在HTML和XForms規範中定義（仍然以很是過期的方式）。

所以， 真正的百分比編碼使用%20而URL中的表單數據是使用+的修改形式。 因此你最有可能只在查詢字符串中的URL中看到+ ? 。

---

#2樓

我會推薦%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+'

---

#3樓

這種混淆是由於到目前爲止，URL仍然「被打破」。

以「 http://www.google.com 」爲例。 這是一個URL。 URL是統一資源定位器，其實是指向網頁的指針（在大多數狀況下）。 自1994年的第一個規範以來，URL實際上具備很是明確的結構。

咱們能夠提取有關「 http://www.google.com 」網址的詳細信息：

+---------------+-------------------+
|      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以前? 和+以後。

資源

---

#4樓

空格只能在URL的「application / x-www-form-urlencoded」內容類型鍵值對查詢部分中編碼爲「+」。 在我看來，這是一個五月，而不是必須。 在其他的URL中，它編碼爲％20。

在我看來，老是將空格編碼爲％20，而不是「+」，即便在URL的查詢部分也是如此，由於它是HTML規範（RFC-1866），它指定空格字符應編碼爲「 +「in」application / x-www-form-urlencoded「內容類型鍵值對（見第8.2.1。分段1）

這種編碼表單數據的方式也在後面的HTML規範中給出。 例如，在HTML 4.01規範中查找有關application / x-www-form-urlencoded的相關段落，依此類推。

如下是URL中的示例字符串，其中HTML規範容許將空格編碼爲「 http://example.com/over/there?name=foo+bar 」。 所以， 只有在「？」以後，才能用加號代替空格 。 在其餘狀況下，空格應編碼爲％20。 但因爲很難正確地肯定上下文，所以最好不要將空格編碼爲「+」。

我建議對全部字符進行百分比編碼，但RFC-3986，p.2.3中定義的「無保留」除外

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

實現取決於您選擇的編程語言。

若是您的URL包含國家字符，請先將它們編碼爲UTF-8，而後對結果進行百分比編碼。