On Tue, Aug 21, 2012 at 9:53 AM, Martin Schreiber <mse00...@gmail.com> wrote: > Am 21.08.2012 09:31, schrieb Graeme Geldenhuys: > > > Ehm, I did both. In the beginning MSEgui switched from Widestring to utf-8 > encoded Ansistring because of the buggy FPC widestring implementation > (MSEgui started with Delphi/Kylix). Some weeks later I switched back to > widestring and bite the bullet to write FPC bug reports until it reached > usable stability. > > > But if you are such a UTF-16 (actually UCS-2 as >> >> that is what MSEgui supports) fan, why isn't MSEgui source code stored >> in UTF-16 encoding either? ;-) > > > Sure, MSEgui uses utf-8 for external storing and exchanging text data. > Internal all is 16 bit UnicodeString. Use the best encoding for the task. > ;-)
+1 There are lot of encodings around, but for different areas of application: - external text assets could be in any encoding (system-locale encoding, UTF8, UTF16 both BE and LE - for example, MS Excel export UTF16 text file) - Windows system calls are UTF16, on (most of) other platforms UTF8 - input translation (physical keyboard to Unicode character) - internal application representation is choice of developer The problem here is that libraries floating around (including RTL and FCL) use different string types (UnicodeString, UTF8String, AnsiString), so the question is - is it possible to (re)write those libraries in a generic way (RawByteString?), so they can work with any string type? In my experience, only about 1% of applications requires handling of individual Unicode characters (input, rendering, GUI text editing). Other parts of application can happily without that knowledge :-) Aleksa _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
