> From: Pedro Fernandes Macedo <webmaster@xxxxxxxxxxxxxxxxxxx>
> Not exactly... The issue is the input file.
> In RH 9 , the input file probably was iso8859-1 and then it was
> processed without any conversion , as the whole system was using
> iso8859-1. Now in fedora , the input file has to be converted by the
> app to UTF8 , so this extra step means that FC will be a bit slower
In general this is true, but in this case, not exactly :-).
Glibc internal encoding is UTF32/UCS4, and modern toolkits, thus
major desktop apps as well, OOo, all internal encoding is UTF-8,
on RH9 as well.
Even you set the locale to *.iso8859-1, and keep file contents in
iso8859-1 encoding on RH9, whenever apps open it, it is converted to
UTF-8 for processing upon reading, and convert back to iso8859-1 when
apps saves it, even though it appeared as the whole system was using
iso8859-1.
This architecture is unchanged between RH9 to FC2, so encoding
conversion happens everywhere on the fly.
So regardless of RH9 or FC2, and regardless with the locale
you set(*.UTF-8 or *.iso8859-1 or whatever), at least the files
encoded in UTF-8 takes less for I/O than other encodings.
Regards,
--
hiura@{freestandards.org,OpenI18N.org,li18nux.org,unicode.org,sun.com}
Chair, OpenI18N.org/The Free Standards Group http://www.OpenI18N.org
Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA eFAX: 509-693-8356
