On 2016-05-11 12:48, Michael Van Canneyt wrote:
> No, it does not save you, where did you get that from ?
It helps. Any encoding to UTF-16 (or UTF-8) is safe. The other way round
is not. There is no guarantee that String (or AnsiString) is using a
Unicode encoding. So depending on where you get
On Wed, 11 May 2016, Graeme Geldenhuys wrote:
On 2016-05-11 10:48, Michael Van Canneyt wrote:
Honestly, I don't understand this preoccupation with {$modeswitch
unicodestrings}
It just means that
Var
a : string;
is read by the compiler as
Var
a : unicodestring;
No more, no less.
On 2016-05-11 10:43, Marco van de Voort wrote:
>> The problem as I see it, is that I already lost data when SqlDB
>> converted it to Latin-1. Am I not understanding the problem?
>
> It depends. Sqldb assigned non ansistring data to an ansistring. In the old
> (2.6.4, old delphi) logic it would
On 2016-05-11 10:48, Michael Van Canneyt wrote:
> Honestly, I don't understand this preoccupation with {$modeswitch
> unicodestrings}
>
> It just means that
>
> Var
> a : string;
>
> is read by the compiler as
>
> Var
> a : unicodestring;
>
> No more, no less.
It saves you from data
On Wed, 11 May 2016, Jonas Maebe wrote:
Graeme Geldenhuys wrote on Wed, 11 May 2016:
In my application I enable unicodestring mode. So I'm reading data from
a Firebird database. The data is stored as UTF-8 in a VarChar field. The
DB connection is set up as UTF-8. Now lets assume my
In other cases, like LacaK said, you will have to read the data as plain
bytes into e.g. a RawByteString and next use
http://www.freepascal.org/docs-html/rtl/system/setcodepage.html (with
the last parameter set to "false") to afterwards specify the code page
this data has.
But this is where
In our previous episode, Graeme Geldenhuys said:
> > In other cases, like LacaK said, you will have to read the data as plain
> > bytes into e.g. a RawByteString and next use
> > http://www.freepascal.org/docs-html/rtl/system/setcodepage.html (with
> > the last parameter set to "false") to
On 11/05/16 10:18, Graeme Geldenhuys wrote:
In my application I enable unicodestring mode. So I'm reading data from
a Firebird database. The data is stored as UTF-8 in a VarChar field. The
DB connection is set up as UTF-8. Now lets assume my FreeBSD box is set
up with a default encoding of
Graeme Geldenhuys wrote on Wed, 11 May 2016:
In my application I enable unicodestring mode. So I'm reading data from
a Firebird database. The data is stored as UTF-8 in a VarChar field. The
DB connection is set up as UTF-8. Now lets assume my FreeBSD box is set
up with a default encoding of
On 2016-05-11 09:21, Jonas Maebe wrote:
> In other cases, like LacaK said, you will have to read the data as plain
> bytes into e.g. a RawByteString and next use
> http://www.freepascal.org/docs-html/rtl/system/setcodepage.html (with
> the last parameter set to "false") to afterwards specify
Mazo Winst wrote:
Suppose that my app needs to read a file encoded with UTF-8. Suppose
that my app runs on Windows, where the system codepage is most likely to
be Windows ANSI. As RTL will use the system codepage, Windows ANSI
doesn't support the full range of unicode chars and need to use RTL
How the sqldb package handles this point?
sqlDB does not perform any character translation.
Only stores data in record buffers as they arrive.
So it expects, that programmer is aware of that and sets correct
"connection encoding".
In case of Lazarus it is often UTF-8, because Lazarus
Hello all,
I am very confused about the way the system codepage are determined.
>From what i understand, the string codepage is determined at runtime in a
platform dependent manner. Suppose that my app needs to read a file encoded
with UTF-8. Suppose that my app runs on Windows, where the system
13 matches
Mail list logo
