Ok, I think this means we may be fine, if we just require users to use
postgres 7.3 or later (I'm pretty sure my user for this was on 7.2). I
should do more testing, but it looks like it'll probably get things
right in java. And I think we do encode correctly with our responses,
by setting the mime type. This obviously needs more testing, hopefully
some international users will sound in and try stuff out.
Thanks for emailing Andrea.
Chris
Quoting Kris Jurka <books@anonymised.com>:
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
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/