Re: How to change the encoding inside the JDBC interface

Dave wrote:

> Hi all,
>
> I have a database which is EUC_TW encoded, but I would like to use
> Big5 to encode my data.  I've tried serveral ways to program my
> program, i.e. using string(in_bytestr, "BIG5") to convert my data.
> However, the interface just use EUC_TW to store my data anyhow.
>
> Any experience can share with  me?
>
> Thanks
> Dave

I had a very similar problem. I don't know if this will be of any help
to Dave but I would like people in this list to see what I did and
comment on any possible side effects.

No matter what I did I could not correctly send an ISO8859_7 encoded
query to the database. The query would reach the servlet OK, but when
passed to the JDBC driver it would change to ISO8859_1.

Now, at least according to this:
   http://www.jguru.com/jguru/faq/view.jsp?EID=78088

the JDBC driver should communicate with the database using the encoding
suggested by the file.encoding property. However the driver was clearly
ignoring my changing file.encoding. So, after a bit of reverse
engineering, I came up with this solution:

I opened the driver source code (file Connection.java, function ExecSQL,
line 296) and replaced the following line:
    buf = sql.getBytes();

with the lines:
   String enc = System.getProperty("file.encoding");   try { buf = sql.getBytes(enc); }   catch
(UnsupportedEncodingExceptione) { buf = sql.getBytes(); }
 

(buf is the byte array containing the query, which immediately after
that is sent to the database). So now, just before the query is passed
by the driver to PostgreSQL, it is converted to whatever is the default
file.encoding and everything works just fine (after I changed
file.encoding via my JRE's configuration files, of course). Moreover,
according to the JDK manual, getBytes() should convert Strings to byte
arrays according to the platform's default character encoding,
therefore, the driver should behave as expected (using
file.encoding to communicate with the database) and my hacking
activities should not be needed. That's why I figured that the whole
problem was a bug in my JDK (I use JDK1.2 in Redhat Linux running on a
Digital Alpha machine). In fact, I never had any similar problems when
my servlets were running under Windows.

I'm worried about possible side effects this could have (although I
haven't seen any so far).