On Sun, 16 May 2004, Andrea Aime wrote:
> At the geoserver project we are struggling with issue related to encoding.
> Basically we would need to:
> * use the JDBC3 driver;
> * manage a connection pool;
> * set the connection encoding (but it seems to be working only with jdbc2?)
> * change the encoding of an opened connection.
You cannot (and don't want to) change the encoding of the connection.
Internally it translates the data from the database encoding to the JVM
encoding. So for example Statement.setString() takes a string in the JVM
encoding and handles sending this to the database in the database's
encoding. By the same token ResultSet.getString() will return a string in
the JVM encoding as well.
>
> About the latest request, we need to serve data to clients in different
> encodings (geoserver is a network server that usually works on the
> internet), and the encoding is part of the client request (specifically,
> the client specify a charset, but it is the same as encoding in postgresql
> parlance, right?).
Specifying the charSet URL parameter is only applicable when connecting to
7.2 and earlier servers as at that point multibyte support wasn't compiled
in by default and there was no way of knowing what data was actually in
the database, so it had to be specified by the client. Note that this
parameter tells the driver the database encoding, not what encoding to
return results in.
> Now, we we extract a connection from the connection pool, we would need to
> change its enconding to fullfill the client request...
> The other options seems to be to handle a connection pool for each
> encoding (and maybe lazily create the pools) or to re-encode things
> at the client side...
Re-encoding things at the client side is the way to go.
Kris Jurka