Tag Archives: 微信开发

微信开发

微信用户信息接口的小坑

基于微信的开发,用户信息是基础,甭管是关注后,还是强制授权,都需要调取“sns/userinfo”接口,提取用户消息
很多事情,我们觉得理所当然,比如,sns/userinfo返回的nickname和headimgurl,这俩不都该成对出现吗?要么都有、要么都没有
不过,事与愿违,到库里去看用户消息,还真有不少nickname、headimgurl只有一个,另一个是空的;特别是nickname,很多都是空的

发现问题,就要寻找原因、解决问题,首先看nickname
由于项目里对外部资源调用的日志记录比较齐全,通过openid,很容易就能发现,比如nickname是下面早这类值时:
存到库就是空的。。。字符集的问题
库里varchar用的是utf8,请教运维,可以不可通过修改字符集,来保存这类支付,无果。。。
无奈关键用户表就不要胡乱做测试,解决方案是加了一个字段,专门保存urlencode(nickname),提取用户信息、需要显示昵称的时候,加个简单判断,再把urldecode显示出来

然后是headimgurl为空的情况
这个再查日志就没啥办法了:就是空的
猜测是用户本来就没上传头像,微信客户端里显示的默认头像,但默认头像既然非用户上传,就认为用户无头像,所以userinfo接口就不给喽
没限制的微信号做这类实际测试,还好headimgurl为空只是极少数

——补充。。。上面说的昵称中的表情符太毒了,wordrpess居然也没能兼容,无奈只能用图

Hello World 微信开发

玩转微信公号开发(九)——获取用户信息

这里的“用户信息”,指的是昵称、头像等信息,具体的:

1
2
3
4
5
6
7
8
9
10
11
12
{
    "subscribe": 1, 
    "openid": "o6_bmjrPTlm6_2sgVt7hMZOPfL2M", 
    "nickname": "Band", 
    "sex": 1, 
    "language": "zh_CN", 
    "city": "广州", 
    "province": "广东", 
    "country": "中国", 
    "headimgurl": "http://wx.qlogo.cn/mmopen/g3MonUZtNHkdmzicIlibx6iaFqAc56vxLSUfpb6n5WKSYVY0ChQKkiaJSgQ1dZuTOgvLLrhJbERQQ4eMsv84eavHiaiceqxibJxCfHe/0", 
   "subscribe_time": 1382694957
}

具体的接口是:

https://api.weixin.qq.com/cgi-bin/user/info?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN

这里的ACCESS_TOKEN获取方法可以参考本系列之前的文章

如果用户没关注,subscribe字段为0,没有nickname、headimgurl等字段,只有用户关注你的公众号,才能拿到上面的全部信息

你可以用这个接口取得用户基本信息,也可以那它判断当前用户是否关注你的公众号

早期的时候,微信对用户基本信息控制的比较严格,只有用户授权过才能拿到这些信息,而且,再次拿信息的话,还要重新授权

偶然才看到微信的文档有了升级,用户信息接口换成了这个新的:/user/info,免去了惹人厌的授权过程。这点小小的开放,让很多基于微信的活动方案成为可能【赞一个】

————–
转载请注明出处:http://www.jiangkunlun.com/2014/04/weixin_user_info

Hello World

玩转微信公号开发(八)——消息的排重与回复

随着微信公号系统的逐步完善,原来的许多机制都得到了升级、增强,这可以让我们公众号的表现更稳定,但有时,也会给我们带来一下麻烦,比如下面这段微信文档新增的内容

————————————————
微信服务器在五秒内收不到响应会断掉连接,并且重新发起请求,总共重试三次,如果在调试中,发现用户无法收到响应的消息,可以检查是否消息处理超时。

关于重试的消息排重,有msgid的消息推荐使用msgid排重。事件类型消息推荐使用FromUserName + CreateTime 排重。

假如服务器无法保证在五秒内处理并回复,可以直接回复空串,微信服务器不会对此作任何处理,并且不会发起重试。 这种情况下,可以使用客服消息接口进行异步回复。
————————————————

首先,如果后端没有复杂的逻辑,5秒足够了,但是如果不能保证5秒内回复消息,就只能调客服消息接口了,可惜客服接口属于高级接口,订阅号是没有的(坑爹啊!),并且,即使是订阅号,客服消息的限制也挺多

另外,所谓的“断掉连接,重新发起请求”并不靠谱,我自己扫码或者点按钮后就经常会收到重复消息,也就是说,第一个请求还没结束,的二个请求可能就来了。。。

综合这两点,我们其实可以搭建一种这样的回复方式:

一个消息来了以后,首先根据微信文档里提到的排重方式,比如使用fromusername/msgid/event/count/createtime做md5,作为key,来标示这个消息,在这个请求内,处理相关的业务逻辑,但处理结果不在这个消息内回复,而是放到类似redis的缓存内

再有消息来时,由于同一个消息重复发送,key也是相同的,首先检查redis有没有该消息key的回复内容存在,如果有,直接回复,如果没有,再走上面的逻辑

这样子,不但可以排重,还可以为自己的业务逻辑多争取些处理时间

 

————

转载请注明出处:http://www.jiangkunlun.com/2014/03/重复消息/ ‎