[fpc-devel] utf8 in 2.6.0

[Anton Kavalenka]

On 15.12.2012 21:35, Martin wrote:
> I am trying to figure out how to do that, or what I do wrong. I found 
> a page about $codepage, but it did not help 
> http://wiki.freepascal.org/LCL_Unicode_Support
> I didnt find the fpc specific page, if exists (I suspect it does)
>
>
> I am calling a function "function Foo(A:string)" {$mode objfpc}{$H+}
> I call it with a constant, that contains an german umlaut. Checked 
> with a hex editor, the constant in the source file is utf8
>
> - If I save the source (in utf8), without a utf8 BOM, then it works 
> fine on windows.
> - If I had a bom, then the string received by the function appears to 
> be ascii (checked memory dump in debugger "oe" becomes d6
> - if I add {$codepage utf8} it also becomes ascii
>
> If I do *not* add that, it seems something gos wrong with the encoding 
> on a PowerPC Mac. Unfortunately this is someone else's pc, and I have 
> no more info.
> If I add it things also go wrong, only different. Again no more info.
>
> -----------
>
> I know the provided info, is very little. If there is anything obvious 
> then tell me.
>
> Thanks
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel

Probably this is due to significant change in FPC 2.7 RTL

*String* type implies the encoding inside
under WIndows it is ANSI by default.

Try to write simple application that concatenates (s:=a+b) two strings 
with umlauted letters.
The resulting string loose the umlauts under Windows.

The only thing that help at the RTL level -
{$ifdef FPC}
SetMultiByteConversionCodePage(CP_UTF8);
{$endif}

This brings similar behaviour for RTL functions ether in Windows and 
UNIX but completely breaks file IO.
You wont be able to open file which names translates to 
more-than-one-byte per symbol.
because RTL IO is ANSI-specific under Windows.

Other approach - use the *UnicodeString*. Forget the *string* type.

regards,
Anton










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20121218/be079f57/attachment.html>