Subject | Re: [firebird-support] UNICODE_FSS, what's this beast after all ? |
---|---|
Author | Scott Morgan |
Post date | 2005-02-10T16:00:51Z |
Olivier Mascia wrote:
UNICODE_FSS field, via the fbclient.dll API, without losing any
information (test data was some Chinese text with some English mixed in,
will try out some other stuff soon). However this could just be the API
treating the UTF-8 as local code page 8 bit data, I can't be sure
without accessing the DB on a system with another locale.
I'm guessing that the FSS 3 byte encoding is internal to the FB system,
it seems large enough to handle all the current Unicode code points (in
the range 0 -> 0x10FFFF last time I checked, might get larger in the
future), yet more space efficient than UTF-32 encoding. If it is
internal to FB then it's not really a problem, the problem is the
ambiguity of how users can access Unicode data.
Scott
>Hello,I seem to be able to send and retrieve UTF-8 encoded data to a
>
>What for a beast is our InterBase(R) and Firebird UNICODE_FSS encoding?
>Where does it come from?
>To what standard does it adhere to?
>What is the encoding scheme exactly (algorithm)?
>Is there any paper giving a complete technical reference of this
>UNICODE_FSS encoding (except of course the Firebird source code)?
>
>
UNICODE_FSS field, via the fbclient.dll API, without losing any
information (test data was some Chinese text with some English mixed in,
will try out some other stuff soon). However this could just be the API
treating the UTF-8 as local code page 8 bit data, I can't be sure
without accessing the DB on a system with another locale.
I'm guessing that the FSS 3 byte encoding is internal to the FB system,
it seems large enough to handle all the current Unicode code points (in
the range 0 -> 0x10FFFF last time I checked, might get larger in the
future), yet more space efficient than UTF-32 encoding. If it is
internal to FB then it's not really a problem, the problem is the
ambiguity of how users can access Unicode data.
Scott