I had some issues with LConvEncoding as I wrote in bugtracker issue #0017212
My mistake was essentially the meaning of character encoding "ANSI". Sorry for that.
So I took a deeper view at this unit. It is far not complete concerning existing codepages and support for Unicode. Further, the implementation with string-based encoding-descriptions is not optimal regarding speed and the possibilty to extend the unit. The encoding and decoding of asian-codepages is really suboptimal. (a fast and dirty performance check showed that it is about 3000 times slower than singlebyte codepages like ISO-8859-1)
I would rewrite the entire unit, including most of the codepages from ftp.unicode.org, full support for UTF-8, UTF-16 and UTF-32, including LE and BE variants. And as a further utility, a conversion program for the mentioned codepagefiles, that will create a complete pascal include file with all the necessary tables and conversion functions.
Greetings
______________________________________________________
powered by GLOBER.LU
Luxembourg Internet Service Provider
Hosting. Domain Registration, Webshops, Webdesign, FreeMail ...
Our professional Web Hosting plans include all the features you are looking for at the best possible price.
www.globe.lu
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
