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的话就不需要自己编码,他内部已经帮你处理好了!
希望大家不要遇见这种问题!
转载请注明出处，谢谢！