今天在跟服務(wù)器的同學(xué)聯(lián)調(diào)接口時(shí)，發(fā)現(xiàn)了個(gè)極其坑爹的BUG，傳遞給服務(wù)器的參數(shù)中如果有空格，就會(huì)報(bào)錯(cuò)，如果沒(méi)有空格就一切正常。
檢查了N久才最終發(fā)現(xiàn)是URLEncode的問(wèn)題：
iOS轉(zhuǎn)義完成后，參數(shù)中的空格被轉(zhuǎn)義成了“%20”，而服務(wù)端轉(zhuǎn)義完成后，參數(shù)中的空格被轉(zhuǎn)義成了“+”；

在Stack Overflow上找到了詳細(xì)點(diǎn)的解釋：URL encoding the space character: + or %20?
簡(jiǎn)單來(lái)說(shuō)就是：%20是比較老一點(diǎn)的寫法，現(xiàn)在的做法是：url中的“？”前的空格要轉(zhuǎn)義成“%20”，“？”之后的空格要轉(zhuǎn)義成“+”！
而java的系統(tǒng)自帶方法也是這么做的；但iOS系統(tǒng)自帶的[str stringByAddingPercentEncodingWithAllowedCharacters:[NSCharacterSet URLQueryAllowedCharacterSet]];方法還是將空格轉(zhuǎn)義成了“%20”.
本來(lái)服務(wù)端是兼容“%20”這種轉(zhuǎn)義方式的，
但這邊為了安全自己做了轉(zhuǎn)義，所以才會(huì)踩到這個(gè)坑；
記錄一下，希望可以幫到有緣人~