部分省短信乱码或空短信问题的汇报

<iframe align="top" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog01.html" frameborder="0" width="728" scrolling="no" height="90"></iframe>

?

20040626 部分省短信乱码问题的汇报

简单描述：
企信通发送短信时，一部分省短信接收不正常。

现象：
企信通全网用户使用Unicode或者GB方式发送短信，以下几省的用户接收到空短信或者乱码：
吉林/山西/河南/福建
同时，以下几省的用户接收正常：
天津/上海/湖南/深圳/江苏

但是，用亚信提供的CMPPAPI包中的SendSm发送Unicode Big-Endian编码短信，河南用户接收是正常的。这说明，CMPPAPI开发包本身可以兼容各省的短信网关。问题在于我们自己的某些编码做法，和部分省的网关不兼容。

原因：
实际上，我们平台在发送Unicode短信时，一直是把短信内容转换为Unicode Big-Endian编码的，这个转换算法是不会错的。
为了模拟CMPPAPI测试程序，于是我在短信内容最前面加上Unicode 16位Big-Endian编码标志0xFE 0xFF，表明这是一个UTF-16BE数据。其实一般来说，可以不用加的。
但是这样做完，还是没有效果。

最终经过几天的调试，确定了可能性最大的原因：
明明CMPPAPI头文件中定义了CMPPSendSingle的短信内容参数为char *，但是我们的开发人员几年前写这两个组件时，偏偏要把各处的短信内容接口参数都声明为unsigned char *，即无符号数。
我把各处的短信内容参数short_message定义改为char*后，发现开发人员在调用CMPPAPI函数时，又用LPCTSTR来强制转换短信内容参数到unsigned short *！
真是莫名其妙的编程习惯啊，为什么不能和协议的规定参数类型保持一致呢?

????开发人员定义短信内容为无符号数，但实际上在GB/Unicode编码时汉字啦、标点啦，绝对都应该是有符号的。
比如，“了”这个字，转换为Unicode16 BE后，内存显示为：0x4E 0x86
对于char,这个0x86就是-122了，
对于unsigned char,这个0x86就是134了。

当然，被转换为无符号数，并不影响实际的短信内容原始数据，所以你会看到很多省份的短信接收是很正常的，无论用哪一种方式发送。
如果某些省的网关代码不规范，那可能就转换出了乱码短信或者空短信。
所以这一问题，实际上是我们的调用CMPPAPI不规范碰上了某些省网关的处理失当造成的。

解决：
修改了以上两处之后，无论用GB还是Unicode方式，河南和山西运城用户都可以收到正常的短信了。

用户的反馈：
我给山西运城用户发送了Unicode/GB编码的短信询问是否显示正确，这两个人都回复说“正常”。

zhengyun 立此存照。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=37224