On Tue, 12 Oct 2010, Yoshiki Ohshima wrote:

> At Tue, 12 Oct 2010 23:35:36 +0200,
> Sven Van Caekenberghe wrote:
>>
>> Levente,
>>
>> On 12 Oct 2010, at 23:08, Levente Uzonyi wrote:
>>
>>> Oh. I "fixed" those yesterday. The problem is that UTF16TextConverters are not initialized to the platform's endianness, but the test expects that.
>>
>> OK, so UTF16TextConverters>>#useLittleEndian: should be called with Smalltalk isLittleEndian as argument, yes ?
>> Who ? The client, XTSqueakEncoder>>#encoding: could do it, but not very elegantly. Or would it be better done in an initialize (that is not there) ?
>
>  Hmm, doesn't it sound like the test is wrong?  The endianness in
> UTF16 means the order in two-octet for each code-point.  The external
> data comes as Byte(Array|String) and internal is UTF-32-ish data, so
> the platform endianness should not matter.

According to rfc2781 the test is wrong and Squeak's implementation is 
right:

"4.3 Interpreting text labelled as UTF-16

    Text labelled with the "UTF-16" charset might be serialized in either
    big-endian or little-endian order. If the first two octets of the
    text is 0xFE followed by 0xFF, then the text can be interpreted as
    being big-endian. If the first two octets of the text is 0xFF
    followed by 0xFE, then the text can be interpreted as being little-
    endian. If the first two octets of the text is not 0xFE followed by
    0xFF, and is not 0xFF followed by 0xFE, then the text SHOULD be
    interpreted as being big-endian."


Levente

>
> -- Yoshiki
>
>