在介面傳參過程中，我們通常會把引數內容進行一次編碼 ，通過URLEncoder.encode()，如下所示：

public static void main(String[] args) {
	String string = "<font color=\\\"#000000\\\"> \\r\\n最低還款金額：                       ￥3,685.17<br>\\r\\n最低還款金額";
	try {
		string = URLEncoder.encode(string, Charset.defaultCharset().displayName
 
());
		//string = string.replaceAll("\\+", "%20");
		System.out.println(string);
		String res = URLDecoder.decode(string,Charset.defaultCharset().displayName());
		System.out.println(res);
	} catch (UnsupportedEncodingException e) {
		e.printStackTrace();
	}	
}

執行結果如下：

%3Cfont+color%3D%5C%22%23000000%5C%22%3E+%5Cr%5Cn%E6%9C%80%E4%BD%8E%E8%BF%98%E6%AC%BE%E9%87%91%E9%A2%9D%EF%BC%9A+++++++++++++++++++++++%EF%BF%A53%2C685.17%3Cbr%3E%5Cr%5Cn%E6%9C%80%E4%BD%8E%E8%BF%98%E6%AC%BE%E9%87%91%E9%A2%9D
<font color=\"#000000\"> \r\n最低還款金額：                       ￥3,685.17<br>\r\n最低還款金額
 

可以很明顯看出來，URLEncoder.encode()方法，預設將需要編碼的內容中的空格轉換為了+。但是預設通過URLDecoder.decode()方法，可以將轉換為+號的內容還原。

• 此編碼與 WWW表單 POST 資料的編碼方式是一樣的，同時與application/x-www-form-urlencoded的媒體型別編碼方式一樣。由於歷史原因，此編碼在將空格編碼為加號（+）方面與RFC1738 編碼不同。
• 另一份規範(RFC 2396，定義URI)裡, URI裡的保留字元都需轉義成%HH格式(Section 3.4 Query Component)，因此空格會被編碼成%20，加號+本身也作為保留字而被編成%2B，對於某些遵循RFC 2396標準的應用來說，它可能不接受查詢字串中出現加號+，認為它是非法字元。所以一個安全的舉措是URL中統一使用%20來編碼空格字元

那麼問題來了，正常情況下空格不應該轉換為+，而是轉換為%20。
一次經歷：服務端按照URLEncoder.encode(str)編碼，安卓客戶端根據Uri.decode(str)解碼，除+之外，所有的字元都解析正確，唯獨這個+沒有解碼為空格，這問題也好解決，安卓客戶端使用URLDecoder.decode(str)就可以了，客戶端程式碼改動，需要上線才能解決問題，最好還是服務端解決空格轉+問題。其實也很簡單。直接將encode之後的結果再做一次統一轉換，將+統一改為%20。這樣，安卓客戶端也不用修改Uri.decode()為URLDecoder.decode()了，而且這類問題就從根本上解決了。

string = URLEncoder.encode(string, Charset.defaultCharset().displayName());
string = string.replaceAll("\\+", "%20");
System.out.println(string);