My previous reply to this post went to /dev/null on Yahoo! Groups, so
this would be just a short version of previous one (yes, I do use web
interface to post messages :)

> r> If we agree, the client-side encoding is always UNICODE_FSS
> r> (which is not too bad I think), then we really do not need all
> r> this conversion. Firebird will do (or is supposed to do) this
> r> automatically. But we then have to require people to set at
> r> least the default database encoding. We just pass the result of
> r> str.getBytes("UTF8") (not str.getBytes() because this will not
> r> be a unicode stream) to engine.
> r> And this is the responsibility of the engine to store data
> r> according to database/column definition.
>
> I'll be very happy if that works!!!!

Check the TestFBEncodings. :)

> r> The main idea in the discussion is whether to provide or not an
> r> option not to convert using this way: national_unicode-
> >>correct_unicode->connection_encoding->byte[], but
> >>national_unicode-
> >>byte[] directly if we assume that national_unicode and
> r> connection_encoding are the same.
>
> Actually now the driver does the following:
> when you read from the database:
> byte[] -> correct_unicode

Right, and byte[] contains data in encoding specified by lc_ctype.

> when you write to the database:
> correct_unicode -> national_unicode -> byte[]

Wrong. Only correct_unicode -> byte[] using the lc_ctype encoding.

"national_unicode" involves JVM default encoding (new String(byte[])
and String.getBytes() methods). That was used before, now the "dark
ages" are over.

> I can ask again what to do with columns with different character
> sets.

Set the lc_ctype to UNICODE_FSS.

> Everything can be implemented ;) Moreover only one boolean field
> should be added to FBManagedConnection, and when is set NONE should

be

> returned by getIscEncoding:
>
> public String getIscEncoding() {
> *****
> if (pleaseDontConvertMyAlreadyConvertedString)
> return "NONE";
> *****
>
>
> try {
> String result = cri.getStringProperty

(GDS.isc_dpb_lc_ctype);

> if (result == null) result = "NONE";
> return result;
> } catch(NullPointerException ex) {
> return "NONE";
> }
> }
>
> That's all. The option can be passed with the Properties in the
> connect() in FBDriver.

Not really. I tried to use the same approach, but 0xF5 char was
converted to '?' by JVM in the str.getBytes() method. I repeat again,
my default JVM encoding is Cp1252.

The code you provided might work, but only if default JVM encodings
during data storing and retrieving are the same (and are the same to
encoding of the data source).

Best regards,
Roman Rokytskyy