微信公众平台的通讯过程

最新推荐文章于 2022-08-02 12:34:32 发布

三只蚂蚁2008

最新推荐文章于 2022-08-02 12:34:32 发布

阅读量6.3k

点赞数

作为开发者，我们需要面对的主要有两个对象：微信服务器和应用程序（网站）服务器。

当微信用户向你的公众平台发送一条消息，实际上这条消息首先发送到微信服务器，由微信服务器向网站服务器发起另外一个请求，网站服务器返回这个请求的结果，再由微信服务器发送到微信客户端。

整个消息通讯流程如下图：

上述5个步骤中，作为开发者我们主要精力都集中在步骤3上，这个步骤主实际上要有3项任务：

接收来自2的XML信息
服务器内部逻辑执行
组织并返回用于4的XML信息

上述三项任务我会在后面做详细说明，并提供一整套简单、高效的处理方法。

二、XML通讯格式

用户使用微信客户端发送的不同类型的消息，网站服务器会收到不同格式的数据（文字、语音、图片等等），数据格式暂时只有XML一种。

作为学习，我觉得只要熟练掌握最简单的文字类型就可以了，其他的格式都是大同小异。且在后面的说明中你会发现，Senparc.Weixin.MP.dll可以帮助我们完全忽略这些繁琐的格式和定义。

一个简单的文字请求XML（RequestMessage）内容如下：

<xml>
    <ToUserName><![CDATA[gh_a96a4a619366]]></ToUserName>
    <FromUserName><![CDATA[olPjZjsXuQPJoV0HlruZkNzKc91E]]></FromUserName>
    <CreateTime>1357986928</CreateTime>
    <MsgType><![CDATA[text]]></MsgType>
    <Content><![CDATA[TNT2]]></Content>
    <MsgId>5832509444155992350</MsgId>
</xml>

　　对应节点的官方说明如下：

参数	描述
ToUserName	开发者微信号
FromUserName	发送方帐号（一个OpenID）
CreateTime	消息创建时间（整型）
MsgType	text
Content	文本消息内容
MsgId	消息id，64位整型

一个简单的文字返回XML（ResponseMessage）内容如下：

<xml>
   <ToUserName><![CDATA[olPjZjsXuQPJoV0HlruZkNzKc91E]]></ToUserName>
   <FromUserName><![CDATA[gh_a96a4a619366]]></FromUserName>
   <CreateTime>12345678</CreateTime>
   <MsgType><![CDATA[text]]></MsgType>
   <Content><![CDATA[content]]></Content>
   <FuncFlag>0</FuncFlag>
</xml>

　　对应节点的官方说明如下：

参数	描述
ToUserName	接收方帐号（收到的OpenID）
FromUserName	开发者微信号
CreateTime	消息创建时间
MsgType	text
Content	回复的消息内容,长度不超过2048字节
FuncFlag	位0x0001被标志时，星标刚收到的消息。

三、一些需要注意和容易被忽视的问题：

每条XML信息都有大小限制，如文本信息，建议Content内容不要超过600字。
上图中，步骤2开始之后，微信服务器有一个等待时间：5秒，如果在这个时间内没有进行到步骤4，那么这个请求将会被关闭（包括数据传输的时间）。也就是说如果超过时间，即使网站服务器返回了数据，客户端也无法收到回复。
在文本消息中，是允许添加<a>标签来放置连接的，但是有许多朋友测试之后发现iOS没问题，Android上链接无法点击，其实原因是（至少目前为止）：Android的微信客户端对<a>标签格式的判定比较严格，请严格按照这个格式书写：<a href="http://xxxx">内容</a>，href后不要使用单引号，也不要添加其他属性。
上面XML节点中的FromUserName即微信用户的OpenId，对于同一个公众账号，这个OpenId的前6位是一致的，并且在整个公众平台的记录中也是唯一的。也就是说同一个用户关注了两个不同的公众账号，他会有两个不同的OpenId。
CreateTime使用的是Unix时间，因此如果使用C#的话，需要做一个转换。
尽量保持官方API中XML节点的顺序，以前微信服务器是使用节点位置的方式读取信息的（node[0]），而非节点名称，现在这个问题似乎有好转，不过还是要小心（￥…………&%&……）。
由于这种特殊的通讯方式，（至少目前为止）所有请求必须从客户端先发起，不要指望光使用API或SDK可以实现由网站服务器主动推送消息到客户端（当然其他办法还是有的，比如模拟登陆）。