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的话就不须要本身编码,他内部已经帮你处理好了!

 

 

但愿你们不要碰见这种问题!

转载请注明出处，谢谢！