<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=x-mac-ce" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Joost van der SluisÊ wrote / nap’sal(a):
<blockquote cite="mid:1294843780.26572.62.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">On Wed, 2011-01-12 at 14:59 +0100, LacaK wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">No. It is mandatory that you send/receive UTF8 to/from GUI LCL
elements.
</pre>
</blockquote>
<pre wrap="">As LCL elements are using TStringField.Text property, then this property
should return UTF8String, right (not AnsiString in ANSI code page) ?
If yes, then also TStringField must store internaly data in any unicode
format (to not lose any characters), right ?
So it can be UTF-8, UTF-16 or UTF-32 ... in all cases we must allocate
space 4*[max.number of characters in field], right ?
So in what encoding are string data stored now in TStringField ?
</pre>
</blockquote>
<pre wrap=""><!---->
The encoding you've specified. In the connection-string or some other
database-server dependent setting.
</pre>
</blockquote>
ok.<br>
But then there is problem in buffer size allocated for TStringField
(ftString), does not ?<br>
See please at bug report: <a class="moz-txt-link-freetext" href="http://bugs.freepascal.org/view.php?id=17376">http://bugs.freepascal.org/view.php?id=17376</a><br>
There is described situation with SQLite (TSQLite3Connectin) , which
returns UTF-8 strings, so there is no problem in encoding,<br>
Êbut problem is in fact, that for char(n),varchar(n) fields is created
TStringField with Size=n and in record buffer is also allocated space
with Size+1, where n is number of characters (not bytes). So truncation
of data occurs, when writting UTF-8 encoded string into record buffer.<br>
So IMHO there must be:<br>
1. allocated space in record buffer in size 4*TFieldDef.Size+1 (and so
on)<br>
or<br>
2. redefine meaning of Size property (as number of bytes not
characters) and create fielddefs with Size*4<br>
hm, according to
<a class="moz-txt-link-freetext" href="http://docwiki.embarcadero.com/VCL/XE/en/DB.TStringField.Size">http://docwiki.embarcadero.com/VCL/XE/en/DB.TStringField.Size</a> is Size
number of characters<br>
but according to
<a class="moz-txt-link-freetext" href="http://docwiki.embarcadero.com/VCL/en/DB.TFieldDef.Size">http://docwiki.embarcadero.com/VCL/en/DB.TFieldDef.Size</a> is Size number
of bytes in underlaying database<br>
<br>
but TField is created from TFieldDef and TField.Size=TFieldDef.Size ...
so isn't it curious ?<br>
<blockquote cite="mid:1294843780.26572.62.camel@wsjoost.cnoc.lan"
type="cite">
<pre wrap="">
Not that when you want to use UTF-16 (or 32) you have to use
TWideStringFields.
</pre>
</blockquote>
So TWideStringField is "no-encoding-agnostic" field (is it designed to
be everytime UTF-16 encoded) ?<br>
<br>
-Laco.<br>
<br>
</body>
</html>