On Thu, 4 May 2017 23:20:33 +0100
Graeme Geldenhuys via Lazarus <lazarus@lists.lazarus-ide.org> wrote:
>[...]
> Since FPC 3.0 you must add the flag -FcUTF8 or add {$codepage UTF8} at the
> beginning of the unit.
>
> * Note: This changes all string literals to UTF-16, increasing the size of
> the binary and slowing it down. That's why Lazarus does not add it by default.
> "
>
> That makes NO sense to me. My units are always saved as UTF-8 encoded text.
> By helping the compiler out by explicitly telling it my files are UTF-8
> encoded using -FcUTF8 or adding {$codepage UTF8} or saving the unit with a
> BOM marker breaks writeln() output under Linux/FreeBSD. Who knows what else
> it breaks. Apparently the breakage is because of the "NOTE" quoted above. Why
> the hell does FPC consider string literals UTF-16 when I explicitly told it
> the whole unit is UTF-8 encoded? FPC is doing the opposite of what I told it!
I added a FAQ:
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus#What_happens_when_I_use_.24codepage_utf8.3F
> I simply can't see myself moving past FPC 2.6.4 at this point. FPC 3.x just
> doesn't make any sense.
AFAIK you are using UTF-8 in AnsiString in FPC 2.6.4. That works in
many cases, because of double fooling the compiler. This trick does not
work on Windows with RTL file functions though.
The good news is that the same trick works in FPC 3.0. And with some new
tricks it is now possible to make the RTL file functions support UTF-8.
Of course it would be nicer, if we don't need tricks to get Unicode.
Mattias
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
