Character @ encoding incorrectly in URL during 2-way

Character @ encoding incorrectly in URL during 2-way SearchSearch
Author Message
Eric Rudisill
New member
Username: Erudisill

Post Number: 1
Registered: 03-2010
Posted on Monday, March 08, 2010 - 07:11 pm:   

We use a http url command for our 2-way communication. When a message with an @ symbol comes across, the URL GET that is generated converts the symbol into an extended ASCII character and breaks our application.
Why is the @ symbol getting converted and how do I prevent this from happening? I've used both the UTF-8 and ISO-8859-1 character sets. Additionally, I have the SMPPDEBUG and SMSDEBUG logs if needed. The message coming in from the SMSC looks like (via SMPPDEBUG):

M TEST @ TEST

.. but the URL that is generated during the 2-way is (via SMSDEBUG):

/NowSmsIn/Default.aspx?s=%2B15332851832&t=M%20TEST%20%A1%20TEST

The '@' is transalted into extended ASCII code A1 (an ornate i.)

Please advise - our software depends on the @ symbol being used in the message.

Thanks,

Eric Rudisill
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1918
Registered: 08-2008
Posted on Wednesday, March 10, 2010 - 05:15 pm:   

Hi Eric,

Apologies for the delay in response. It appears that several of my replies to postings here this week were lost and did not get posted.

If "@" is translated to "¡" (inverted exclamation point), this is usually a simple issue.

In the GSM character set, 0x40 is the character code for "¡". In the iso-8859-1 character set, 0x40 is "@".

NowSMS defaults to using the GSM character set for SMPP connections.

So if you see "@" in the SMPPDEBUG, but "¡" in the SMSDEBUG.LOG, it means that you need to set the "SMSC Character Set" for the SMPP connection to "iso-8859-1".

Note that the character set setting that I am referring to is an SMSC property, not a 2-way command property.

From the "SMSC" page, select your SMPP connection and press "Properties". Under "Advanced Settings", change the "SMSC Character Set" to "iso-8859-1/Latin".

Note that it can be confusing to change this setting. After making the change, press Ok, Ok, and then Apply ... at that point you will be prompted to restart the service, which is necessary for the new setting to take place.

If the problem persists after making this change, it is possible that the SMS provider is using the iso-8859-1 character set, but improperly setting the data_coding flag to indicate that the GSM character set is being used. If this is the case, there is a special setting that can be used to override the data_coding flag in the SMPP message. To do this, edit SMSGW.INI, and under the [SMPP - server:port] section header for your SMSC connection, add SMSCCharsetReceiveTextOverride=Yes.

A colleague forwarded your debug logs to me, and I don't think you need that extra SMSGW.INI setting ... I believe you only need to set the "SMSC Character Set" as I described above.

--
Des
NowSMS Support