Hello, On 12/14/2009 07:49 PM, Helge Hafting wrote: > Patryk Benderz wrote: >> [cut] >>> What is this and how can I read this? Is it possible to 'cat' this to a >> Most likely it is an MMS. > > Earlier, MMS came through as a WAP url, instead of being hidden behind > the opaque "this is a binary message".
> Of course, there is no way to download the image/ringtone/whatever on > the FR. (Unless you write the necessary software.) But the old way was a > bit better anyway, because at least you could type that URL into some > other phone. let me explain why it is the way it is: SMS have a field that specifies the data coding (called alphabet). This can be GSM default, UCS2 (unicode) or binary. GSM default as well as UCS2 are intended for text and so they will not have null bytes somewhere in the middle of the string. In fact in the GSM default alphabet (which is 7 bit per character) the 0 maps onto the character '@'. The binary data coding scheme however has no such restrictions. These are just any number (within the constraints of an SMS) of octets that can be whatever value you choose. Now some old version of the framework didn't care about the distinction binary or not and just sent the text after it was decoded through dbus. This dbus field was a string (a unicode string as that's all there is in terms of strings in dbus). So far so good, but there is an additional restriction - this time within dbus. Dbus strings are not allowed to contain null bytes so if the occasional SMS with a null byte arrived the whole daemon just crashed. The solution was to special case binary SMS. The payload is still there, it's just not in the test field (since that is a string). If you look at the properties map there will be a field called data which is an array of bytes which contains the original payload. Now why didn't we change text to be an array of bytes you might ask. It would simplify handling of different types of SMS as you don't need to check two cases. There are two reasons actually: 1. Binary SMS are different and need to be handled differently. They usually contain a port header with an address that specifies which application should handle this particular type (vcards are another example). 2. The common case of handling a regular text SMS should be simple to use. If the text was encapsulated as a byte array you would have to deal with iterating over the elements, concatenating the characters and taking care of Unicode encoding/decoding in every application that uses that interface. I hope this clears up some of the confusion. Regards, Daniel Willmann
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
