> Is it technically possible to make it all automatic, Java jdbc drivers
> after all should give just unicodes due to java IS unicode already.
> Or to have a special url parameter "encoding=auto" and client would
> decide what to use based on a database default charset.

That is not like you think. The encoding property tells Firebird in which
encoding to deliver the content of database columns. It has very little to
do with the database or column encoding, since Firebird will convert data
from the database or column encoding into the specified encoding
transparently.

So, one can even think that specifying the UTF8 for all databases would
solve the problem, since all encodings are specified as "subsets" of UTF8
and Firebird can always do the translation. But there are also two special
cases - the charset NONE and charset OCTETS which should be handled
differently (well, one can invent some scheme for them too).

The main issue here is the performance. When the encoding specified for the
connection differs from the charset in which content is defined, there's
some job to do for Firebird and there's job to do for JVM too (since even
UTF8 is not UCS-2 which is used for strings in Java).

If no encoding is specified for connection, NONE is used, which works only
for limited cases, therefore it is highly recommended to specify charset for
database as well as encoding for the connection. However, if we use UTF8 as
default encoding for connection, applications working with databases with
default charset NONE will provide incorrect data in 99,999...% of all cases,
which, considering the number of NONE-databases (at least in my experience)
is quite big ammount.

So, if your databases have some encoding specified, just use encoding=UTF8
which is as convenient as encoding=auto and it will do the job, unless you
care about the performance.

But I'm currently inclined to switch from NONE to UTF8 since NONE is the one
that is default for all platforms and that is what people would expect to
happen if nothing is specified. Like it or not, there's some history behind
Firebird and I prefer to follow the common rules unless majority of the Java
community decides the opposite.

Roman