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