Reporting of SMS Garbled text messages or empty text messages in some provinces

?

20040626 report on text message garbled text messages in some provinces

Simple Description:
When sending text messages, some provincial text messages cannot be received normally.

Symptom:
Enterprise communications network-wide users use Unicode or GB to send text messages. users in the following provinces receive empty text messages or Garbled text messages:
Jilin/Shanxi/HeNan/Fujian
At the same time, users in the following provinces receive messages normally:
Tianjin/Shanghai/Hunan/Shenzhen/Jiangsu

However, it is normal for Henan users to receive Unicode Big-Endian text messages from SendSm in the cmppapi package provided by Asiainfo. This shows that the CMPPAPI is compatible with the SMS gateways of each province. The problem is that some of our coding practices are incompatible with gateways in some provinces.

Cause:
In fact, when sending Unicode text messages, our platform always converts the text message content to Unicode Big-Endian encoding. This conversion algorithm is correct.
To simulate the CMPPAPI test program, I added the Unicode 16-bit Big-Endian code mark 0xFE 0xFF at the beginning of the text message, indicating that it was a UTF-16BE data. In fact, you do not need to add it.
However, this is still ineffective.

After several days of debugging, the most likely reason was determined:
Clearly the CMPPAPI header file defines the text message content parameter of CMPPSendSingle as char *, but when our developers wrote these two components a few years ago, however, the interface parameters of the text message content should be declared as unsigned char *, that is, the number of unsigned characters.
After I changed the text message content parameter short_message to char *, I found that when calling the CMPPAPI function, the developer forced conversion of the text message content parameter to unsigned short * by using the LPCTSTR function *!
This is an inexplicable programming habit. Why cannot it be consistent with the parameter types specified in the Protocol?

???? Developers Define the text message content as the number of unsigned characters. In fact, Chinese characters and punctuation marks must be signed during the GB/Unicode encoding.
For example, after the word "" is converted to Unicode16 BE, the memory is displayed as 0x4E 0x86.
For char, The 0x86 is-122,
For unsigned char, The 0x86 is 134.

Of course, the conversion to the unsigned number does not affect the original data of the actual text message content. Therefore, you can see that the text message reception in many provinces is normal, no matter which method is used for sending.
If the gateway code in some provinces is not standard, Garbled text messages or empty text messages may be converted.
Therefore, this problem is actually caused by improper handling of provincial gateways when we call CMPPAPI.

Solution:
After the above two locations are modified, users in Henan and Shanxi Yuncheng can receive normal text messages in both the GB and Unicode modes.

User feedback:
I sent a Unicode/GB-encoded text message to the Shanxi Yuncheng user asking if the message is correct. Both of them replied "normal ".

Zhengyun.

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