On Sat, Jan 04, 2014 at 10:08:07AM +0000, Graeme Geldenhuys wrote: > > We will have to wait for FPC 2.8.0 (or 3.0) which should have much > better built-in Unicode support. String encoding conversion should then > be taken care of automatically. Unfortunately it seems that the FPC RTL > (there will be two of them) will be AnsiString or UTF-16 only. The RTL > encoding is not configurable! > > So under all Unix-like systems (Linux, MacOSX, FreeBSD - basically every > platform except Microsoft ones) there will be lots of string conversions > from/to the OS or any libraries (which are normally UTF-8) to the FPC > RTL which is going to be UTF-16.
So that's why you use the ansistring RTL there, unless you value Delphi compatibility. On those targets (except a few embedded Linux and OpenBSD ones), the default encoding is utf8 and any ansistring is utf8, case closed. > The constant conversion will also kick > in when you do streaming to/from file or any TCP/IP communications - > which both normally use UTF-8. Please stop with your baseless fearmongering. That's irrelevant, for sources that don't have a compiletime known codepage (if only CP_ACP aka "default"). Those are bytebuffers with an encoding described by headers, and thus fall outside the scope of automated conversions. > I would have thought the Free Pascal team would improve their design > over Delphi. We have consistently chose Delphi compatibility for years, so why you are thinking this is fairly strange. -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
