Re: [INTERFACES] JDBC and character encoding

On 9 Oct 1998, Aleksey Demakov wrote:

>
> There is a problem using JDBC on machine with a character encoding
> different from one used by backend. For instance, Russian version
> of MS Windows uses codepage 1251, while in Russian Unix world most
> widely used encoding is koi8-r.
>
> I don't know whether there's standard way of dealing with this. Maybe
> because I'm novice with Java & JDBC.
>
> But having Java i18n facilities this problem could be easely solved.
> There should be a per-connection property which will contain beckend's
> encoding. So connecting with, say, such url
> "jdbc:postgresql://host/database?encoding=KOI8-R"
> will set this property to "KOI8-R". Functions to convert bytes to
> characters and vice versa all have versions that accept encoding
> argument. They should be used to perform such conversion.
>
> I currently only have the driver from 6.3.2 distribution. I could
> make a patch for it if JDBC maintainers agree with this proposal.

Make a patch, and send it direct to me. There's a few differences between
6.3.2 and 6.4 (not many, but some deal with the network stream), so I'll
be able to make sure nothing breaks.

Adding in the property into the url handling is quite easy.
postgresql.Driver parses the url, and any key=value pairs are placed into
a Properties collection. This is then passed to Connection in it's
constructor. In the constructor, you simply add an entry to fetch the
parameter value, and to store it in a class variable, or act on it. This
scheme allows the parameters to be supplied outside the URL, which is part
of the JDBC spec.

A better way of handling this, would be to write an interface that defines
the methods needed to handle the encoding, then have two classes
implementing it - one for the default, the other for KOI8-R. In
Connection's constructor, we would have some code that looks for the
encoding parameter. If it's not present, it uses the default encoding, and
if present it has the class name of a class to handle the encoding. This
would allow other encodings to be included without modifying the core. The
end user could even write their own encodings, and then don't have to
recompile the core - which in my mind is a good thing.

Peter

--
       Peter T Mount peter@retep.org.uk
      Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
 Java PDF Generator: http://www.retep.org.uk/pdf