Quick Cocos2dx Http通讯 JSON
参考:
![](//images0.cnblogs.com/blog2015/397822/201503/031011159411827.png)
![](//images0.cnblogs.com/blog2015/397822/201503/031012156291825.png)
1 http://stackoverflow.com/questions/5975952/how-to-extract-http-message-body-in-basehttprequesthandler-do-post
目的:
1 取得POST消息的消息体
2 使用JSON格式化
3 使用AES对信息加密(可选)
昨天的代码还没有解析到客户端传过来的数据,今天有时间搜索了一下,当前解析以POST方法传过来的数据的方法如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031007485829808.png)
目前已经可以读到客户端传过来的内容,如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031008453326538.png)
只是为毛后面多了个"&"符号呢,不解。
查看了一下CCHTTPReqest.cpp的源码,如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031009070512537.png)
似乎是每个参数后面必加的,
由于it是一个迭代器来的,理论上可以考虑使用it.->hasNext()判断在加"&"符号,具体我就不操作了。
处理起来比较麻烦,于是用了个简单点的处理方法,在服务端处理的时候,直接判断最后一个字符是否是"&",是的话就删掉,如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031009211298868.png)
测试了一下,结果是自己预期的。
嗯,仔细看了一下CCHTTPReqest.cpp的源码,发现了一个CCHTTPRequest::setPOSTData(const char *data)的接口,不用传名值对进去,测试可用。
下面测试用JSON来处理通讯对象吧。
前端的通讯代码修改如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031010416766994.png)
服务端读取代码如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031011159411827.png)
然后我们在测试的地方这样写:
![](http://images0.cnblogs.com/blog2015/397822/201503/031011358019425.png)
然后刷新客户端,服务端收到讯息如图:
![](http://images0.cnblogs.com/blog2015/397822/201503/031012156291825.png)
客户端打印日志如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031012397071435.png)
一切都按照设计好的走,呵呵。
好的,下面我们进行加密操作。
在客户端代码中敲一下crypto,然后会看到可供选择的加密方式有很多种,包括:AES256,MD5,XXTEA等等,如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031012591137807.png)
一直没用过AES加密,何不试试呢。
服务端也需要安装对应的AES加密包,此处下载python的第三方加密包,
然后解压缩到根目录下运行 python setup.py install口令之后,Eclipse会自动集成到里头去的。
我们可以在Eclipse里面直接连接到代码里面去,可以看到这个AES支持3种类型的AES密钥,如果要使用AES256的话,那么密钥的长度应该是32.
我们就用32个"#"作为我们的密钥吧。
客户端代码:
![](http://images0.cnblogs.com/blog2015/397822/201503/031013536297951.png)
服务端代码:
![](http://images0.cnblogs.com/blog2015/397822/201503/031014078169484.png)
然后重启服务器,刷新客户端,赫然发现:
![](http://images0.cnblogs.com/blog2015/397822/201503/031014251292529.png)
本平台不支持此功能,我擦。
那么换成XXTEA吧,
![](http://images0.cnblogs.com/blog2015/397822/201503/031016451297424.png)
客户端,正常:
![](http://images0.cnblogs.com/blog2015/397822/201503/031016546763775.png)
服务端也要装第三方的库,地址:
https://pypi.python.org/pypi/xxtea
安装同上。
服务端代码如下:
![](http://images0.cnblogs.com/blog2015/397822/201503/031017058632824.png)
运行下看看结果:
![](http://images0.cnblogs.com/blog2015/397822/201503/031017214415898.png)
报错了,需要一个16字节的key,好吧,变成16个"#"好么?
前后端都改掉了。
重启服务端,刷新客户端,结果看看如何:
![](http://images0.cnblogs.com/blog2015/397822/201503/031017597859082.png)
好吧,解析正常了。
但是后面的乱码是闹那样啊?!!
在客户端和服务端都打上了长度的输出,结果都是32。
难道是编码问题?
将前后端的编码格式统一为UTF-8,还是没用。
于是在前后端打日志查看数据加密前与加密后的长度。
发现,前端加密前25,加密后32。
服务端解密钱32,解密后32。
这个解密后的数据拿去给JSON解析的话,肯定是会报错的。
![](http://images0.cnblogs.com/blog2015/397822/201503/031018444884594.png)
问题就出现在这个解密后多出来的25-32的字符串了。
通过阅读加密源代码:
![](http://images0.cnblogs.com/blog2015/397822/201503/031019044572692.png)
发现利用xxtea加密和解密字符串都会将字符串变成4的倍数的长度,不足的地方会通过"\0"补位,于是在服务端添加代码确认,确认第25个字符确实是"\0"。
在服务端的假设一下代码:
![](http://images0.cnblogs.com/blog2015/397822/201503/031019217857964.png)
但是可以看到,长度变为29了。
打印一下"\0"的index,还是25,累啊!也就是说25-29还是"\0"。
于是加了一个循环出处理这个字符串:
![](http://images0.cnblogs.com/blog2015/397822/201503/031020196602250.png)
结果呢:
![](http://images0.cnblogs.com/blog2015/397822/201503/031020307381801.png)
呵呵,死循环了。
吗蛋。
字符串是以"\0"结束的,不是吗?
心好累,搜索了一下,看到了这个帖子,感觉要放弃加密了:
额。继续!
心塞,打印了一下多出来的字符串的每一个单位,发现一个乱码不是"\0":
![](http://images0.cnblogs.com/blog2015/397822/201503/031021023018890.png)
额。
搞了好久,还是不止是咋回事,这个乱码的ASCII码打印出来都是乱码。
含泪注释掉前后端的加密,然后运行,OK。
我可以回家了么。!!-_-
服务器源码:https://github.com/AdoBeatTheWorld/waytomobile/tree/master/projects/ServerTest
客户端源码:https://github.com/AdoBeatTheWorld/waytomobile/tree/master/projects/game003