> For instance the encoding of a java source is the default encoding

(if you

> use characters outside of the default charset you need to define

as a

> unicode literal (with slashes).
>
> This problem is typical in web applications before servlet 2.3.

The web

> server should identify the character set of the input, but some

browsers

> don't identify it correctly, so you need to use
> servletRequest.setCharacterEncoding() method added in servlet 2.3.
>

I'm already using setCharacterEncoding() which I set to UTF-8 so I
have no problem reading characters inside the JVM.

> The driver converts from the java internal character set (utf-8)

to the

> output, which will be the java equivalent of lc_type or the

default

> character set if the FB encoding is NONE.
>

I also set lc_type to UNICODE_FSS so the driver should do nothing to
convert (since UNICODE_FSS is java equivalent UTF-8).

> Anyway as Roman says the best way to solve that is to get a test

case.
I will try that but it should take me some time. I would rather have
a look in the code because my suspicion is that the driver converts
the PreparedStatement query in the default encoding of JAVA and not
in the encoding set in FB as it should. (The diagram
http://www.softways.gr/images/encoding.gif I think depicts the
situation)