Use GSM(packed) to encode and then decode, there is an extra '@' character about go-smpp HOT 4 OPEN

There is another question. As mentioned in GSM 03.38, if the first 7 bits of the last byte are all 0 after packing, a CR(0x0d) should be filled to the last byte to avoid confusion with @.

When there are 7 spare bits in the last octet of a message, these bits are set to the 7-bit code of the CR control (also used as a padding filler) instead of being set to zero (where they would be confused with the 7-bit code of an '@' character).

For example, the source input is "1234567890abcdefghijklm". After encoding and packing, we will get

m := []byte{49,217,140,86,179,221,112,57,88,88,60,38,151,205,103,116,90,189,102,183,1}

the last byte is '1', 0000 0001, which matches the scenario mentioned in the above article. So a CR(0x0d) should be filled to it, 1 | (0x0d << 1) = 27, as 0001 1011. Then the new encode result should be:

m1 := []byte{49,217,140,86,179,221,112,57,88,88,60,38,151,205,103,116,90,189,102,183,27}

But when I tried to decode m1, I got

"1234567890abcdefghijklm\r"

Yes, the extra characters become '\r'.

from go-smpp.

After my deduction, when the encoded length of the original input satisfies the arithmetic sequence
$a_n=8*n-1$
, the above situation will occur.

For example：

• s1 = 1234567890abcdefghijklm, The original length is 23, there is no escape character, and the encoded length is also 23；
• s2 = 12345678[abcdefghijklm, The original length is 21, with the escape character '[', occupying two bytes. The length after encoding is also 23；

from go-smpp.

here it is the fix: #109

from go-smpp.

@fiorix

from go-smpp.