Re: USTRING "encoding" behavior different from STRING's?

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'.
>
>
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