[Lazarus] TProcess, UTF8, Windows

Mattias Gaertner nc-gaertnma at netcologne.de
Mon Apr 16 00:04:41 CEST 2012


On Sun, 15 Apr 2012 15:58:24 +0200
Martin Schreiber <mse00000 at gmail.com> wrote:

> On Sunday 15 April 2012 15:37:15 Marco van de Voort wrote:
> > On Sun, Apr 15, 2012 at 03:24:32PM +0200, Martin Schreiber wrote:
> > > > Basically if you use "utf8string" you get a string that forces UTF-8.
> > >
> > > And if you use "String" (= AnsiString(CP_ACP) if my assumption about
> > > current FPC trunk is correct) it forces it to the 8bit system encoding.
> > > The only stringtype which does not enforce encoding is "RawByteString".
> > > All "AFAIK" of course. ;-)
> >
> > That's correct. But in Windows, you use Windows functions for conversion,
> > and CP_ACP is a valid value there. On *nix, you first have to find out what
> > the local encoding is, and it seems that Mattias is detecting a problem
> > there.
> >
> > Be careful with assuming too much about RawBytestring being a normal type.
> > In Delphi it is afaik only used in parameters (and function return values),
> > more or less as a kind of open array type.
> >
> > There are no variables of the type "rawbytestring" defined.
> >
> And probably Mattias is wrong if he thinks "String" in FPC trunk does not 
> enforce encoding if I understood correctly.

"string" enforces an 8-bit type.
It does not enforce a specific codepage like utf8string. At least under
Linux.
Assign a CP_UTF8 and the string becomes CP_UTF8, assign a CP_ACP and it
becomes CP_ACP, assign a CP_UTF16 and it becomes DefaultSystemCodePage.
I have not tested under Windows.

Probably we should wait until the dust has settled before drawing
conclusions.


Mattias




More information about the Lazarus mailing list