所以，這里的答案都有點不完整。使用‘%20’對URL中的空格進行編碼是在RFC 3986，它定義了如何構建URI。本規范中沒有提到使用“+”對空間進行編碼-如果僅按此規范進行編碼，則必須將空間編碼為‘%20’。

對編碼空間使用“+”的提及來自HTML規范的各種形式-特別是在描述內容類型‘application/x-www-form-urlencode’的一節中。這用于發布表單數據。

現在，HTML2.0規范(RFC 1866)第8.2.2節明確指出，GET請求的URL字符串的查詢部分應該編碼為‘application/x-www-form-urlencode’。理論上，這表明在查詢字符串中的URL中使用‘+’是合法的(在‘？’之后)。

但是.。真的嗎？記住，HTML本身就是一個內容規范，帶有查詢字符串的URL可以與HTML以外的內容一起使用。此外，盡管HTML規范的后期版本繼續在‘application/x-www-form-urlencode’內容中將‘+’定義為合法，但它們完全忽略了GET請求查詢字符串定義為該類型的部分。事實上，在HTML2.0規范之后，沒有提到查詢字符串編碼。

這就給我們留下了一個問題-它有效嗎？當然，在查詢字符串中支持“+”的遺留代碼很多，生成它的代碼也很多。所以，如果你使用“+”，幾率是很好的。(事實上，我最近對此做了所有的研究，因為我發現了一個主要的站點，它沒有接受GET查詢中的‘%20’作為一個空間。他們實際上沒能解碼任何百分比編碼的字符。因此，您使用的服務也可能是相關的。)

但是，從規范的純讀來看，如果沒有HTML 2.0規范中的語言轉到以后的版本，URL就完全由RFC 3986覆蓋，這意味著空間應該轉換為‘%20’。當然，如果您請求的不是HTML文檔，就應該是這種情況。