I have a JSF application running on tomcat6 in Fedora 17 using firebird as the database and all the registers coming from the database to the application are coming with a encod
When you don't specify the connection character set in Jaybird (either property encoding
using the Firebird character set name, or charSet
with a Java character set name), then Jaybird falls back to the Firebird concept of connection character set NONE
, which means as much as that the server will not transliterate characters from the storage representation of a (VAR)CHAR column and sends its bytes as is.
This means that Jaybird receives a sequence of bytes in an unknown character set. Jaybird will then use the default character set of your Java installation to convert those bytes to strings. So if the db (or column) character set does not match your Java character set, then it can produce incorrect results. Even worse: reading and writing this way from different systems with different default java character sets can produce total garbage or transliteration errors.
The solution: always specify an explicit connection character set. Even better is to make sure your database has a default character set (or that every (VAR)CHAR
column has its character set explicitly defined).
The next version of Jaybird (2.3) will probably refuse to connect if no explicit connection character set was specified to force users to consider this issue (and if they still want the old behavior then they can explicitly specify encoding=NONE
).