You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the 7 bit alphabet, an extended character uses two characters (the escape character and the character itself). This pair is not allowed to be split across messages, so both the escape character and the character itself get shifted into the next message.
The current implementation doesn't handle this properly, and as a result, may miscalculate the number of messages.
An example SMS would be;
The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown f[x jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the.
The '[' at character 152 will become "0x1B[" (2 characters), and become part of the 2nd message, which pushes the last "." at the end of the content into a 3rd message, giving the following 3 messages;
The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown f
[x jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the
.
The current behaviour is that this will return 2 for the number of parts, but it should be returning 3.
The text was updated successfully, but these errors were encountered:
In the 7 bit alphabet, an extended character uses two characters (the escape character and the character itself). This pair is not allowed to be split across messages, so both the escape character and the character itself get shifted into the next message.
The current implementation doesn't handle this properly, and as a result, may miscalculate the number of messages.
An example SMS would be;
The '[' at character 152 will become "0x1B[" (2 characters), and become part of the 2nd message, which pushes the last "." at the end of the content into a 3rd message, giving the following 3 messages;
The current behaviour is that this will return 2 for the number of parts, but it should be returning 3.
The text was updated successfully, but these errors were encountered: