Subject | Connection charset UTF8, column charset ASCII: right padded char fields |
---|---|
Author | skoczian |
Post date | 2008-12-09T11:45:45Z |
Hello,
I've seen the discussion about right padded char(n) fields sent from
the Firebird server if the field has character set UTF8. But even if
a char column with fixed length is declared with character set ASCII
the clients I've used seem to pad it with blanks, if the connection
character set is UTF8. Is that right? I could understand it for
columns declared as, say, ISO8859_1, because transliteration to UTF8
might need more bytes. But that can't happen with an ASCII column,
so why those blanks?
Even with "SELECT TRIM(TRAILING FROM asciifield) FROM mytable" this
happens. It doesn't happen with "SELECT asciifield || '' FROM
mytable" which might serve as ugly workaround, but again: why?
Using Firebird 2.1.1.17910.0 on Gentoo Linux
Besides ISQL I tried with FlameRobin 0.8.6 and Python with
kinterbasdb 3.2.2.
System charset is UTF8.
Thank you for hints and explanations,
Herta
I've seen the discussion about right padded char(n) fields sent from
the Firebird server if the field has character set UTF8. But even if
a char column with fixed length is declared with character set ASCII
the clients I've used seem to pad it with blanks, if the connection
character set is UTF8. Is that right? I could understand it for
columns declared as, say, ISO8859_1, because transliteration to UTF8
might need more bytes. But that can't happen with an ASCII column,
so why those blanks?
Even with "SELECT TRIM(TRAILING FROM asciifield) FROM mytable" this
happens. It doesn't happen with "SELECT asciifield || '' FROM
mytable" which might serve as ugly workaround, but again: why?
Using Firebird 2.1.1.17910.0 on Gentoo Linux
Besides ISQL I tried with FlameRobin 0.8.6 and Python with
kinterbasdb 3.2.2.
System charset is UTF8.
Thank you for hints and explanations,
Herta