Subject Re: Firebird client connection charset, server charsets and encoding
Author skoczian
--- In firebird-support@yahoogroups.com, Milan Babuskov <milanb@...>
wrote:

> You have multiple character sets involved:
>
> 1. charset of the operating system desktop environment
> 2. connection charset
> 3. character set of a database table column
>
> There is also a database default charset which is only used as
default
> when creating new columns and is completely irrelevant here.
>
> When you connect it Firebird assumes that all data you send and
receive
> is encoded with (2), so if you system charset(1) is different, you
need
> to transliterate back and forth in your application code (or
database
> access library).
>
> Once data gets to Firebird, it transliterates between (2) and (3),
and
> also back when you read the data.
>

At the moment I don't know what character set to use with a new
database. OS is Linux, system character set is UTF8. All the data
are numbers, some single character columns (pure ASCII) and german
words, no names at all. ISO8859_1 covers everything I need and I'm
really certain that this won't change.

But: using ISO8859_1 as database default charset and as connection
charset gives me wrong umlaut characters in ISQL and empty fields in
FlameRobin, if the field contains a non ASCII character.

Using UTF8 as database default charset I can't get my single
character columns as single characters in my python scripts (using
kinterbasdb 3.2.2). Even declaring such a column with charset ASCII
doesn't help. In the python script they appear as u'X...' (. stands
for the space character).

Using ISO8859_1 as database default charset and UTF8 as connection
charset gives me a FlameRobin warning and I don't know if this is a
dangerous practice or not. But if I read your post correctly, it
would be quite reasonable, as in this case only the Firebird server
would have to transliterate anything, and it is well able to do so.
Right?

Thank you for advice
Herta