Ann,

Le 17-févr.-05 à 00:31, Ann W. Harrison a écrit :

> I wrote...
>>> The difference is actually that UNICODE-FSS is guaranteed not to have
>>> null bytes within a string - making it file system safe. The
>>> internal
>>> null bytes in UTF-8 are causing the truncation.
>> Brad Pepers wrote:
>> UTF-8 doesn't have internal null bytes.
> Which is of course right - and I mean to type UTF16, which was the
> source of the original question and the original error.

Why we are at this Ann, may I ask you to confirm to us all how
UNICODE_FSS is stored inside (memory and disk storage) ? There have
been posts making people believe it is stored as UTF-8, but an UTF-8
format where the fourth byte would not be used. There are others, like
me, who believe (and could check from the source code but have not
found time to do so), that UNICODE_FSS is actually handled, begin to
end, as a triplet of bytes, both in memory and on the disk structure (a
kind of integer on 24 bits). And that this 24 bits quantity is the same
thing as the 32 bits UTF-32 value (because UTF-32 fourth byte is always
zero).

Which view is the right one ?

--
Olivier Mascia