Android: Unicode/Charset Problems When Sending an Sms (Sendtextmessage)

Android: Unicode/Charset problems when sending an SMS (sendTextMessage)

Ok, this seems to have been solved by simply using sendMultipartTextMessage instead of sendTextMessage for the messages.

Who would've thought... it kind of makes sense because unicode characters use more "space" than "normal" ones.

Android: How to send unicode sms programatically and receive it on the other side correctly?

This looks like a problem of emulator. I use SmsManager.sendMultipartTextMessage() method for sending Russian text, and no real user report about any problems. Try on real device please.

Send SMS with accents

Thanks to all of you. Yes, it is what you said.
Here is the solution:

ArrayList<String> arrSMS = smsManager.divideMessage("Text to send");
smsManager.sendMultipartTextMessage("Number", null, arrSMS, null, null);

Android: send an SMS to different carriers (@ is translated to ?)

The third parameter of sendTextMessage() is an ordinary String. There is no need to convert a String to a UTF-8 encoded byte[] array and then back to a String again (especially since you are not doing that last conversion correctly). Get rid of getBytes() altogether and just use "@" as-is:

String message = "@";
manager.sendTextMessage(phonenumber, null, message, piSend, piDelivered);

Or simply:

manager.sendTextMessage(phonenumber, null, "@", piSend, piDelivered);

It does make sense to use getBytes() when using sendDataMessage() instead.

Update: doing some research, I see that SMS can use one of three different character encodings. In GSM-03.38 encoding, a @ character is usually encoded as octet 0x00, not as octet 0x40 like it is in standard ASCII-compatible charsets. So that might be causing some issues for your carriers if your device is using GSM encoding internally. You may have to use sendDataMessage() instead so you can encode the String data to UTF-16, if your device does not automatically handle that for you (I would expect Android to handle that internally, but who knows if it really does). You might have to do that anyway if you want to send international or other non-alphanumeric characters:

manager.sendDataMessage(phonenumber, null, 8091, message.getBytes("UTF-16"), piSend,     

piDelivered);

Android app sending SMS with wrong characters

There are special charsets for SMS, see this link from Wikipedia: https://en.wikipedia.org/wiki/GSM_03.38

The characters { and }, that are wrong on your phone, are in the Basic Character Set Extension. Try other are characters like , |, ] and so on. When these characters also do not work on your phone, I suppose your problem is related to this charset extension.

Characters from the extension need to be escaped with 0x1B (escape character in SMS). This is only a conjecture, maybe there could be a problem with the escaping.

sendTextMessage In android phone

give the pending intent in your 48th line as given bellow

String sent = "android.telephony.SmsManager.STATUS_ON_ICC_SENT";
PendingIntent piSent = PendingIntent.getBroadcast(smsActivity.this, 0,new Intent(sent), 0);

sms.sendTextMessage("12345678901", null, "hello!", piSent, null);

am sure it works :)

Why is a @ being translated to ¿ when sent through SMS on Android 2.3?

Really seems like an encoding issue. It might be that you try to send as ASCII but the receiver tries to parse it in a different encoding. If you explicitly specify encoding on both sender and receiver end it should work.

EDIT:

This would get the character array and create a string from it all using US-ASCII encoding.

String newString = new String(oldString.getBytes("US-ASCII"), "US-ASCII"));

EDIT2:

Turns out GSM doesn't use regular US-ASCII, rather it uses it's own GSM alphabet. What seems to be happening is that the @ (ASCII 0x40) is translated into the GSM alphabet directly as ¡ (Upside down exlamation mark, GSM 0x40). This won't affect regular text characters as they share the same addresses (same for the plus sign 0x2B). Then when converted back it tries to convert it frow what it assumes is GSM-alphabet to ASCII, meaning the 0x40 of the earlier @ sign is now an upside down exclamation mark. This is a sign that does not exist in regular ASCII and is therefore replaced by an unknown character symbol, apparently an upside down question mark in Android 2.3 and a space in the GSM receiver. This lack of conversion from ASCII to GSM seems to have been fixed between Android 2.3 and Android 4.3.

If you try to specify to Android that this is an ASCII string by using new String ("A@@","ISO-8859-1") it might do the conversion in it's own. If not you might have to do it yourself (Something like this might help). If @ is the only special character you need to support then you could of course encode that single character yourself(\0\0 for @@).

EDIT3:

Edit2 included multiple actions, what did you try? To explain the whole GSM/ASCII thing:
ASCII uses it's first 32 characters as control characters. These characters were deemed unnecessary for GSM and so they were replaced with other characters. The null character, on computers used to terminate a string, is not used for text messages. They are set at 140 octets and any empty space is simply filled with filler characters. So the null character 0x00 in ASCII is used for something else, the @ character. If you look at the GSM alphabet and the ASCII alphabet you will see that the 32 first characters are replaced by Greek characters and some others. If you look at the remaining characters they are mostly in the right place, the @ character is one of the ones that aren't. If you for example try to type in _ you should get similar results. When you say that @ comes out as A do you then mean that A@@ becomes A or that it becomes AAA? I also found something interesting while looking through Unicode conversion supplied by Unicode Inc.:

0x00 is NULL (when followed only by 0x00 up to the
end of (fixed byte length) message, possibly also up to
FORM FEED. But 0x00 is also the code for COMMERCIAL AT
when some other character (CARRIAGE RETURN if nothing else)
comes after the 0x00.

So if you tried to send only A@@ then the two last @s might be interpreted as padding characters instead of @ characters. Regardless it seems like the carriers in your area does some conversion between them, have you tried to send the characters with sendDataMessage as raw data bytes? The function byte[] stringToGsm7BitPacked(String data) throws EncodeException from telephony.GsmAlphabet should help convert your string to the GSM alphabet.



Related Topics



Leave a reply



Submit