AFN post的數據編碼格式問題

想到寫任何關於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的話就不須要本身編碼,他內部已經幫你處理好了!

 

 

但願你們不要碰見這種問題!

轉載請註明出處，謝謝！