Subject | RE: [IBO] UTF8 as Client Character Set |
---|---|
Author | Jason Wharton |
Post date | 2007-08-30T03:59:37Z |
I added in the use of Delphi's Encode/Decode functions when the CharSet
property is set to UTF8. Have you used these methods and are they
undesirable? I could make it so that you can override them with your own,
or just none at all.
Being that I don't have first-hand practical experience with character sets
I depend quite a bit on you all out there helping me understand the issues
you face when dealing with multiple character sets.
Jason
property is set to UTF8. Have you used these methods and are they
undesirable? I could make it so that you can override them with your own,
or just none at all.
Being that I don't have first-hand practical experience with character sets
I depend quite a bit on you all out there helping me understand the issues
you face when dealing with multiple character sets.
Jason
> -----Original Message-----
> Subject: [IBO] UTF8 as Client Character Set
>
>
> I finally found the time to test the 4.8 release (vs. 4.6, which I
> used until now).
>
> IMHO there is something wrong with the Client Character Set handling.
> (You pass the Client Character Set using the CharSet property of
> TIB_Connection.)
>
> I have a Firebird 2.0.1 database with (default) character set UTF8
> (this is the Server Charset).
>
> In my application I want to process all strings from/to the database
> as UTF-8 strings. So I specify 'UTF8' for the CharSet property of my
> TIB_Connection. I now expect to get a UTF-8 string from the database
> when I do a SELECT and I will pass UTF-8 strings in my INSERT/UPDATE
> commands. As the database also is UTF-8, no transliteration or
> transformation has to be done, neither by IBO, nor by the fbclient.dll
> nor by the database itself. This used to work correctly with IBO4.6.
>
> However, when I use IBO 4.8.7, there seems to be a transformation of
> strings somewhere (probably in IBO) that leads to malformed UTF-8
> strings in the database. Only when I use an empty string for the
> CharSet property, everything seems to work fine. But now, there's no
> Client Character Set defined which may lead to unexpected results for
> fields that have another character set than the default character set
> ...
>
> Is that a bug or is it my misconception?
>
>
> Regards
>
> Stefan