Tag Archives: 微信开发

微信开发

微信用户信息接口的小坑

2016 年 09 月 14 日 – 上午 6:43

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

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

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

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

Tags | Permalink | Comment (0)
Hello World 微信开发

玩转微信公号开发（九）——获取用户信息

2014 年 04 月 12 日 – 上午 8:31

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

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.jiangkl.com/2014/04/weixin_user_info

Tags , | Permalink | Comment (0)
Hello World

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

2014 年 03 月 22 日 – 上午 4:03

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

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

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

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

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

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

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

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

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

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

 

————

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

 

Tags , | Permalink | Comment (0)