[fpc-devel] TStringField, String and UnicodeString and UTF8String

Joost van der Sluis joost at cnoc.nl
Thu Jan 13 15:06:27 CET 2011


On Thu, 2011-01-13 at 09:49 +0100, LacaK wrote:

> So IMHO there must be:
> 1. allocated space in record buffer in size 4*TFieldDef.Size+1 

> 2. redefine meaning of Size property (as number of bytes not
> characters) and create fielddefs with Size*4

Yes, those are the possible solutions. Good thing about the second
option, is that a user can do that on his own if he wants to use UTF-8,
just create persistent fields with a field size of 4*the amount of
characters. I'm not sure if we have to change this. It's a problem the
programmer has to deal with, I think...

> 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

Yes, that's indeed the problem. But there's also the .DataSize property,
so we could use that.

Maybe... if the pressure on the bugtracker gets too high, I'll bow and
change this. (I think 25% of all existing db bugs are related to this
and people who do not understand anything about encodings.)

> 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) ?

No. It's designed to contain an array of two-bytes records. In fact you
can use it to store UCS-2 data, but not UTF-16. Same story as with
ansi/UTF-8.

Joost.




More information about the fpc-devel mailing list