假如服务器无法保证在五秒内处理并回复,可以直接回复空串,微信服务器不会对此座任何处理,并且不会发起重试。需要注意的是:这里说的回复空串并不是回复空的文本消息,而是直接Response.Write(“”)即可。
下面简要对各普通消息说明一下。
文本消息:
<xml> <ToUserName><![CDATA[toUser]]></ToUserName> <FromUserName><![CDATA[fromUser]]></FromUserName> <CreateTime>1348831860</CreateTime> <MsgType><![CDATA[text]]></MsgType> <Content><![CDATA[this is a test]]></Content> <MsgId>1234567890123456</MsgId> </xml>
图片消息:
<xml> <ToUserName><![CDATA[toUser]]></ToUserName> <FromUserName><![CDATA[fromUser]]></FromUserName> <CreateTime>1348831860</CreateTime> <MsgType><![CDATA[image]]></MsgType> <PicUrl><![CDATA[this is a url]]></PicUrl> <MediaId><![CDATA[media_id]]></MediaId> <MsgId>1234567890123456</MsgId> </xml>
语音消息:
<xml><ToUserName><![CDATA[toUser]]></ToUserName><FromUserName><![CDATA[fromUser]]></FromUserName><CreateTime>1357290913</CreateTime><MsgType><![CDATA[voice]]></MsgType><MediaId><![CDATA[media_id]]></MediaId><Format><![CDATA[Format]]></Format><MsgId>1234567890123456</MsgId></xml>
视频消息:
<xml><ToUserName><![CDATA[toUser]]></ToUserName><FromUserName><![CDATA[fromUser]]></FromUserName><CreateTime>1357290913</CreateTime><MsgType><![CDATA[video]]></MsgType><MediaId><![CDATA[media_id]]></MediaId><ThumbMediaId><![CDATA[thumb_media_id]]></ThumbMediaId><MsgId>1234567890123456</MsgId></xml>
地理位置消息:
<xml><ToUserName><![CDATA[toUser]]></ToUserName><FromUserName><![CDATA[fromUser]]></FromUserName><CreateTime>1351776360</CreateTime><MsgType><![CDATA[location]]></MsgType><Location_X>23.134521</Location_X><Location_Y>113.358803</Location_Y><Scale>20</Scale><Label><![CDATA[位置信息]]></Label><MsgId>1234567890123456</MsgId></xml>
链接消息:
<xml><ToUserName><![CDATA[toUser]]></ToUserName><FromUserName><![CDATA[fromUser]]></FromUserName><CreateTime>1351776360</CreateTime><MsgType><![CDATA[link]]></MsgType><Title><![CDATA[公众平台官网链接]]></Title><Description><![CDATA[公众平台官网链接]]></Description><Url><![CDATA[url]]></Url><MsgId>1234567890123456</MsgId></xml>
细心的程序猿应该发现了,所有的消息中(包括事件消息),都包含下面几个字段
| 参数 | 描述 |
|---|---|
| ToUserName | 接收方微信号 |
| FromUserName | 发送方微信号,若为普通用户,则是一个OpenID |
| CreateTime | 消息创建时间 |
| MsgType | 消息类型 |
而消息的类型在文章开头已经讲了,分别是:文本(text),图片(image),语音(voice),视频(video),地理位置(location),链接(link),事件(event)
为了方便管理和代码编写,我们可以把这些消息类型写一个枚举。如下:
/// <summary>
/// 消息类型枚举 /// </summary>
public enum MsgType
{ /// <summary>
///文本类型 /// </summary> TEXT, /// <summary>
/// 图片类型 /// </summary> IMAGE, /// <summary>
/// 语音类型 /// </summary> VOICE, /// <summary>
/// 视频类型 /// </summary> VIDEO, /// <summary>
/// 地理位置类型 /// </summary> LOCATION, /// <summary>
/// 链接类型 /// </summary> LINK, /// <summary>
/// 事件类型 /// </summary> EVENT
}这里说明下,C#中event是关键字,所以event在枚举中就不能使用了,所以为了统一,我这里的枚举全部使用大写的。
既然所有的消息体都有上面的几个字段,那就可以写一个基类,然后不同的消息实体继承这个基类。(一直在纠结一个问题,以前我都是将所有的消息体中的字段写在一个类中,调用起来也很方便,只是类中的字段越来越多,看着都不爽。再加上本人才疏学浅,面向对象也使用的不熟练,所以一直都是在一个类中罗列所有的字段
调用的时候直接 var ss = WeiXinRequest.RequestHelper(token, EncodingAESKey, appid);
返回一个WeiXinRequest,然后再对消息类型和事件类型判断,做出响应。
今天重新做了下调整,也就是分了子类基类,代码可读性提高了,调用起来却没有之前方便了,各位朋友给点建议呗。
)
下面是各消息实体
基类:
public abstract class BaseMessage
{ /// <summary>
/// 开发者微信号 /// </summary>
public string ToUserName { get; set; } /// <summary>
/// 发送方帐号(一个OpenID) /// </summary>
public string FromUserName { get; set; } /// <summary>
/// 消息创建时间 (整型) /// </summary>
public string CreateTime { get; set; } /// <summary>
/// 消息类型 /// </summary>
public MsgType MsgType { get; set; } public virtual void ResponseNull()
{
Utils.ResponseWrite("");
} public virtual void ResText(EnterParam param, string content)
{
} /// <summary>
/// 回复消息(音乐) /// </summary>
public void ResMusic(EnterParam param, Music mu)
{
} public void ResVideo(EnterParam param, Video v)
{ } /// <summary>
/// 回复消息(图片) /// </summary>
public void ResPicture(EnterParam param, Picture pic, string domain)
{
} /// <summary>
/// 回复消息(图文列表) /// </summary>
/// <param name="param"></param>
/// <param name="art"></param>
public void ResArticles(EnterParam param, List<Articles> art)
{ } /// <summary>
/// 多客服转发 /// </summary>
/// <param name="param"></param>
public void ResDKF(EnterParam param)
{
} /// <summary>
/// 多客服转发如果指定的客服没有接入能力(不在线、没有开启自动接入或者自动接入已满),该用户会一直等待指定客服有接入能力后才会被接入,而不会被其他客服接待。建议在指定客服时,先查询客服的接入能力指定到有能力接入的客服,保证客户能够及时得到服务。 /// </summary>
/// <param name="param">用户发送的消息

