Hello,

As I understand, AnsiString and AnsiChar contain the environment type of string (it can be ISO8859x, utf-8 etc...).
If that so, how can I know the size (in bytes) of AnsiChar ?

Thanks,
Ido

On Mon, November 5, 2012 11:49, ik wrote:

Hello Ido,

As I understand, AnsiString and AnsiChar contain the environment type of string (it can be ISO8859x, utf-8 etc...). If that so, how can I know the size (in bytes) of AnsiChar ?

As far as I understand it, AnsiChar is always 1 byte, i.e. it cannot hold (whole) multi-byte encoded characters like UTF-8 (at least at the moment; I'm not sure if this is supposed to stay like that also in the future or not).

HTH

Tomas

Thank you

ik wrote / napísal(a):

You can also try (in 2.7) : function StringElementSize(const S : RawByteString): Word;
-Laco.

ik wrote

As I understand, AnsiString and AnsiChar contain the environment type of string (it can be ISO8859x, utf-8 etc...). If that so, how can I know the size (in bytes) of AnsiChar ?

The size of the type "AnsiChar" is always one byte. It is impossible to give the size of a generic "character" in a 1-byte string, because in e.g. UTF-8 the size depends on the code point. To get the size of a specific character, you can use
widestringmanager.codepointlengthproc(pchar,maxlookahead)

"maxlookahead" is the maximum number of bytes that routine is allowed to check to find the complete character (e.g.
"widestringmanager
.codepointlengthproc(@ansistringvar[3],length(ansistringvar)-2)"). It seems this routine has not yet been implemented for the Windows widestringmanager though.

Jonas

Hi,

Just to go a step further, even in a UTF16 String, the "Code Element Size" probably returns 2, but there is still no guarantee that every character will be handled by one element. For example, all common characters from European languages, Korean, and Japanese can be handled in 2 bytes in UTF16, but some uncommon special characters in Japanese might need an additional 2 bytes. (And for example, the Unicode points for Egyption hiroglyphic characters require surrogate pairs).

At any rate, I wish more of this stuff would be handled by the base runtime transparently. For example, the original pascal spec for Copy() says it will copy X Characters, not X bytes - but FPC copies X bytes. (This means we have to use different functions to handle f.e. UTF8 strings properly). Wishing won''t make it come true, but...

Thank you,
Noah Silva

2012/11/5 Jonas Maebe