J. Michael Crawford wrote:
> Encoding translations that didn't work:
> a) Getting encoded bytes from the result set. We tried the following
> block five times, once for each different encoding we were trying to
> test with the database:
> b) Getting a string, turning it bytes, and then translating. Same
> process as above, but we use result.getString...
> No matter what, strings showed up as gibberish in one JVM or another,
> depending upon the native encoding of the database. A Latin1 database
> worked in the windows JVM, a Unicode in the Linux JVM, but not the other
> way around.
The "right way" is to just use getString() and not do any translation
yourself. The driver has already done the transcoding from whatever the
DB encoding is, to the internal UTF-16 string representation. You don't
need to mess with byte-based representations.
When you then display that string, you will need to use an appropriate
Can you provide a self-contained testcase that demonstrates getString()
doing the wrong thing?
In response to
pgsql-jdbc by date
|Next:||From: Oliver Jowett||Date: 2004-11-08 22:07:12|
|Subject: Re: 8.0.0beta4: "copy" and "client_encoding"|
|Previous:||From: J. Michael Crawford||Date: 2004-11-08 21:12:45|
|Subject: Re: [JDBC] Using Postgres with Latin1 (ISO8859-1)|
pgsql-general by date
|Next:||From: "Miquel van Smoorenburg" ||Date: 2004-11-08 22:23:31|
|Subject: Re: index not always used when selecting on a date field|
|Previous:||From: Woodchuck Bill||Date: 2004-11-08 21:50:50|
|Subject: Re: The Big 9?|