Thu, 20 Sep 2001 12:46:49 -0700 (PDT), Kenneth Whistler <kenw@sybase.com> pisze:
> If you are expecting better performance from a library that takes UTF-8
> API's and then does all its internal processing in UTF-8 *without*
> converting to UTF-16, then I think you are mistaken. UTF-8 is a bad
> form for much of the kind of internal processing that ICU has to do
> for all kinds of things -- particularly for collation weighting, for
> example. Any library worth its salt would *first* convert to UTF-16
> (or UTF-32) internally, anyway, before doing any significant semantic
> manipulation of the characters.
Why would UTF-16 be easier for internal processing than UTF-8?
Both are variable-length encodings.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
This archive was generated by hypermail 2.1.2 : Sat Sep 22 2001 - 05:34:36 EDT