On Tue, December 15, 2009 01:22, Daniel Willmann wrote: > 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.
Yes, thank you for your explanation. Still, how do I save the binary payload to a file? > > > Regards, > Daniel Willmann > > _______________________________________________ > Shr-User mailing list > [email protected] > http://lists.shr-project.org/mailman/listinfo/shr-user > _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
