Joost van der Sluis  wrote / nap?sal(a):
On Wed, 2011-01-12 at 14:59 +0100, LacaK wrote:

No. It is mandatory that you send/receive UTF8 to/from GUI LCL
elements.
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 ?

The encoding you've specified. In the connection-string or some other
database-server dependent setting.
ok.
But then there is problem in buffer size allocated for TStringField (ftString), does not ?
See please at bug report: http://bugs.freepascal.org/view.php?id=17376
There is described situation with SQLite (TSQLite3Connectin) , which returns UTF-8 strings, so there is no problem in encoding, 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.
So IMHO there must be:
1. allocated space in record buffer in size 4*TFieldDef.Size+1 (and so on)
or
2. redefine meaning of Size property (as number of bytes not characters) and create fielddefs with Size*4 hm, according to http://docwiki.embarcadero.com/VCL/XE/en/DB.TStringField.Size is Size number of characters but according to http://docwiki.embarcadero.com/VCL/en/DB.TFieldDef.Size is Size number of bytes in underlaying database

but TField is created from TFieldDef and TField.Size=TFieldDef.Size ... so isn't it curious ?
Not that when you want to use UTF-16 (or 32) you have to use
TWideStringFields.

So TWideStringField is "no-encoding-agnostic" field (is it designed to be everytime UTF-16 encoded) ?

-Laco.

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to