Mattias Gaertner schrieb:
On Thu, 04 Dec 2014 07:00:59 +0100
Hans-Peter Diettrich <drdiettri...@aol.com> wrote:
UTF8Console is needed, when your source is UTF-8, but the compiler
thinks it is Windows CP. UTF8Console is defined in LazUTF8.
An alternative is UTF8Decode.
Thanks :-)
Just tested on WinXP:
program test;
var a: AnsiString;
begin
a := 'äöü';
WriteLn(a,'äöü');
end;
works differently with file encoding Ansi, UTF-8 and UTF-8bom. The
latter correctly shows 'äöüäöü', else a mix of several encodings shows
up in the console.
I see.
Only after testing the string encodings I found out that $codepage does
not affect CP_ACP, this was unclear to me before. A new Lazarus version
instead may try to set DefaultSystemCodePage to UTF-8, in order to
preserve compatibility with the current assumption about UTF-8 encoding
with AnsiStrings.
Indeed I never tried passing a constant in writeln.
You never wrote text or separtors?
Does Delphi also pass constants unconverted to writeln?
Delphi does not convert anything in console output, the user must
convert everything to CP_OEM :-(
{$codepage UTF8} requires UTF-8 file encoding as well, doesn't
compile when stored as Ansi.
What do you mean with "doesn't compile"? What compiler error?
Hmm, until yesterday the error message was "illegal character..." - or
was it "file I/O error"? - with non-ASCII characters in string literals.
Just tested, the error has disappeared, instead garbage is displayed at
runtime. Now string literals seem to be stored as UTF-8 (file encoding),
with 0 (CP_ACP) for the encoding. That means that the UTF-8 bytes are
treated at runtime as being DefaultSystemCodePage characters. You
certainly can imagine what happens in a conversion of these bytes into a
different encoding :-(
DoDi
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
