想到寫任何關於AFN的東西其實我是拒絕的,因為自己這也是第一次用,畢竟AFN現在是最為流行的網絡框架了,害怕自己理解的有誤,所以不敢造次!
先在這里大致講解一下過程吧,后期發現了再更正(主要是想讓看官避免遇到同類的問題),可能原理說得並不正確,所以希望大家直接看解決辦法
在這次使用的過程中,就遇到了編碼格式問題,后來經過抓包(自己客戶端還沒用過charles,說起來也是慚愧,這篇博客后就要滾去學習一下了),發現是自己客戶端的編碼格式的問題
具體什么問題,我下面說:
key point:
大家都知道AFN默認post接受的參數是id類型的,而且他內部已經實現了參數的編碼，僅僅是對參數，如果將url整體傳入的話需要自己編碼
如果你穿的是nsmutabledictionary的話就不需要自己編碼,他內部已經幫你處理好了!
問題其實就是出在這里
后台(接口文檔)要求我們傳的格式是類似於:
tartdate=2015-01-01&enddate=2015-11-01&crdNo=6210888100208023&identityNo=510703198901062430&pageNum=1&trcode=20003&channelflag=1
這種格式的post參數(真是*了dog了),而且加密方式是也很奇葩,而且而且他返回回來的是json,發過去的不是,也是奇葩!這里就不說了
- 一.沒辦法,我就只能把以前的nsdictionary改成nsstring
見下圖(我簡單的封裝的AFN):
后來那邊服務器打開過后,我們進行對接,發現總是返回我們數據簽名不合法!
但是我和安卓組檢查了加密方式和最終的加密結果進行一一比對也還是沒有發現問題,於是大boss(不是搞iOS的)就說他看一看,最后他也說沒發現加密有什么問題(安卓組已經通了),
- 二.於是懷疑是不是post的編碼格式有問題,原先我發送請求的代碼如下:
- 三.后來嘗試更改為:
也還是報錯,於是網上爬文,也嘗試了設置其他的一些請求頭,還是沒有效果
於是大boss說只有抓包才能看出問題!抓包就抓包吧,但是抓出來的結果和安卓組的一樣!
咦!不對,post出去的數據不對啊(抱歉,當時沒有截圖),你傳出去的編碼格式不對啊,
本來應該類似於:
tartdate=2015-01-01&enddate=2015-11-01&crdNo=6210888100208023&identityNo=510703198901062430&pageNum=1&trcode=20003&channelflag=1
&sigh=********** 這種格式的
但是實際上是(網上隨便測試的):
https://www.google.co.jp/?gfe_rd=cr&ei=ey9lVsLPJcfD8Aev6a74Bw&gws_rd=ssl#q=%E4%BD%A0%E5%A5%BD++%E4%B8%AD%E5%9B%BD
四.就是說傳出去的時候AFN自動把&給我們進行url編碼了,但是實際上我們是不需要他給我們進行編碼的
所以又爬文,又是試方法,發現還是沒用!於是大boss就說他也不知道為什么了,按常理這么成熟的框架應該會有這方面的解決方案的啊,他就叫我再看看,如果還是不行,就叫我換ASI
OMG,老大,這不是開玩笑的吧,換框架你知道有多痛苦?而且基本上我這個都寫好了,現在叫我改,豈不是要我命? 而且你還說第二天要發布測試版(發布個*啊)!
我實在是不想改框架,於是就拿安卓代碼來看,最后發現他們竟然是用的map(就是oc的字典),不是說好的不是字典,是字符串嗎? 你們原來不是拼接的post參數嘛?
什么時候改的,為什么不告訴我你們換了,你們還就在我的座位旁邊啊啊啊啊啊啊…
好吧,崩潰心情可想而知
五.於是我就做了最后的嘗試,把接受參數換成NSDictionary
六.傳過去的格式:
然后就TM成功了!
我想說明的其實就是上面那句話:
AFN內部已經實現了參數的編碼，僅僅是對參數，如果將url整體傳入的話需要自己編碼
如果你傳的是NSMutableDictionary的話就不需要自己編碼,他內部已經幫你處理好了!
希望大家不要遇見這種問題!
轉載請注明出處，謝謝！