Hello.
A few weeks ago I ran into a problem with the JDBC authentication, namely I
wasn't able to connect to a PostgreSQL database whose name used non-ASCII
characters. I've discussed the issue on the pgsql-hackers list and come up
with the attached solution which has been used in an ISO-8859-2 environment
since then.
The purpose of this patch is to allow user names, user passwords and database
names to contain non-ASCII characters. The only restriction upon this was to
make sure that authentications that succeeded before should also succeed
after the patch was applied.
This patch maximizes the chances for the authentication to succeed and on top
of that, it makes possible to configure the PostgreSQL database so as the
authentication could always work. Without it, the behaviour of the current
JDBC driver is UNDETERMINED in a non-ASCII environment (for disbelievers:
check the javadoc for String.getBytes() and String.getBytes(String)).
During the authentication phase, the current JDBC driver uses the poor old
ASCII encoding regardless of the environment it is used in. On the other
side, postgres performs no conversion on the byte representation of the user,
password and database strings submitted by the driver. It is only afterwards
and the server takes into account the use of a UTF-8 encoding that the client
announces.
What I proposed below is for the driver to use the environment's encoding in
an attempt to match the encoding used at server side to store the user,
password and database strings, provided that this local encoding is an ASCII
extension. If it's not, the driver uses the UTF-8 encoding, thus allowing for
a setup where things can work regardless of the environment (specifically,
the database cluster should be (re)created with the UTF-8 encoding).
I suspect that there are CJK encodings that are ASCII extensions; if so,
please add them in the Encoding.isAsciiExtension(String) method. I know next
to nothing about the Asian encodings.
Regards.
