[BitPim-devel] USTRING "encoding" behavior different from STRING's?

[Perry Nguyen]

Hi,

I was using the "encoding" kwarg for STRING to automatically encode my string
to utf16_be, however, it seems when the packet is never written with the
encoding when using USTRING. STRING has been deprecated in favor of USTRING,
is the behavior of encoding supposed to change?

I'm in the process of writing support for my Motorola V3c (VZW), and I mostly
have the OBEX support complete. The advantage of using OBEX is that I can use
bitpim using the DUN/serial access over bluetooth rather than only USB.
However I still haven't figured out how to switch from mode OBEX back to
MODEM. I noticed that there's the V710 being added recently and it does share
a lot of common features that should possibly moved to a superclass.
com_motov.py maybe.

[Simon C]

Post by Perry Nguyen
I was using the "encoding" kwarg for STRING to automatically encode my string
to utf16_be, however, it seems when the packet is never written with the
encoding when using USTRING. STRING has been deprecated in favor of USTRING,
is the behavior of encoding supposed to change?

The encoding keyword was only temporary in the STRING class, we decided not
to include it in favor of introducing USTRING and deprecating STRING to
reduce impact on existing code.
You should not use STRING any more.

It sounds like you are having a problem with the USTRING class. Do you have
the latest updates? Can you provide an example of the packet you defined?

Simon

[Perry Nguyen]

Indeed, I do have a problem with the USTRING class, and my packet looks like
as follows:

PACKET obex_header:
P DATA data "the actual header data"
1 UINT headerId "one of the OBEX_HDR types"
if self.headerId & com_obex.OBEX_HI_MASK == com_obex.OBEX_UNICODE:
# additional +1 to account for terminator
# utf_16be = big endian, seems obex goes by this?
2 UINT { 'value': htons(len(self.data.encode("utf_16be")) + 4) }
+headerSize
* USTRING { 'encoding': "utf_16be", 'value': self.data } +headerData
if self.headerId & com_obex.OBEX_HI_MASK == com_obex.OBEX_BYTE_STREAM:
2 UINT { 'value': htons(len(self.data) + 3) } +headerSize
* DATA { 'value': self.data } +headerData
if self.headerId & com_obex.OBEX_HI_MASK == com_obex.OBEX_BYTE:
1 UINT { 'value': self.data } +headerData
if self.headerId & com_obex.OBEX_HI_MASK == com_obex.OBEX_INT:
4 UINT { 'value': htonl(self.data) } +headerData

Basically, I call p_obex.obex_header(), set the headerId and data fields, when
it comes time to write the packet, headerData and headerSize are populated
automatically. Previously, with STRING, the UNICODE headerData would be
populated correctly with the encoded value of 'data'.

Anyway, excuse me if I exercised bad practice in the packet setup, I'm a newb
when it comes to python.

Post by Simon C
The encoding keyword was only temporary in the STRING class, we decided
not to include it in favor of introducing USTRING and deprecating STRING
to reduce impact on existing code.
You should not use STRING any more.
It sounds like you are having a problem with the USTRING class. Do you
have the latest updates? Can you provide an example of the packet you
defined?
Simon

[Simon C]

Post by Perry Nguyen
P DATA data "the actual header data"
1 UINT headerId "one of the OBEX_HDR types"
# additional +1 to account for terminator
# utf_16be = big endian, seems obex goes by this?
2 UINT { 'value': htons(len(self.data.encode("utf_16be")) + 4) }
+headerSize
* USTRING { 'encoding': "utf_16be", 'value': self.data } +headerData
if self.headerId & com_obex.OBEX_HI_MASK ==
2 UINT { 'value': htons(len(self.data) + 3) } +headerSize
* DATA { 'value': self.data } +headerData
1 UINT { 'value': self.data } +headerData
4 UINT { 'value': htonl(self.data) } +headerData
Basically, I call p_obex.obex_header(), set the headerId and data fields, when
it comes time to write the packet, headerData and headerSize are populated
automatically. Previously, with STRING, the UNICODE headerData would be
populated correctly with the encoded value of 'data'.

The packet looks OK to me.

I think that there is a bug in the USTRING with the value keyword, it is not
converting to unicode internally when the value is set this way and this
will prevent it from being encoded when the packet is created. I'll check in
a fix for this later tonight and let you know.
A possible workaround might be to encode the string you are setting data to
into unicode.

Simon

Simon

Simon

[Perry Nguyen]

Post by Simon C
The packet looks OK to me.
I think that there is a bug in the USTRING with the value keyword, it is
not converting to unicode internally when the value is set this way and
this will prevent it from being encoded when the packet is created. I'll
check in a fix for this later tonight and let you know.
A possible workaround might be to encode the string you are setting data
to into unicode.

Simon,

Right, I just wasn't sure if this was intended behavior or not, and my current
workaround was to encode manually, despite the 'encoding' value set. I'll
grab the latest code and see if it helps.

Thanks.

[Simon C]

encoded when the packet is created. I'll check in a fix for
this later tonight and let you know.

I've checked in a fix, let me know if this works.

Simon