Re: [JDBC] Using Postgres with Latin1 (ISO8859-1)

<<The "right way" is to just use getString() and not do any translation
yourself.>>

That was the first thing we tried. Sorry I didn't mention it.

The next step was getting a string, turning it into bytes, and
translating the bytes. The third step was getting bytes. Nothing worked
in our Java GUI, the console, or the web page returned.

Maybe it was just something weird in our system. Perhaps Postgres just
wanted to send Latin1 characters out of our database, which at the time was
Latin1. I don't know. Whatever it was sending we couldn't use, regardless
of the translation attempted. Forcing it to Unicode (improperly) did the
trick for us. Now that our database is unicode, I'm not sure we'd get the
same problem.

If there's a better way to make sure Postgres is sending out Unicode in
our JVM session, while simultaneously sending out other encodings to other
apps that access the database using different encodings, I'm all ears.

<<When you then display that string, you will need to use an appropriate
encoding, obviously..>>

Definitely.

<<Can you provide a self-contained testcase that demonstrates getString()
doing the wrong thing?>>

I can try. If I can find a copy of the old Latin1 database, and
replicate the error, I'll let you know via email.

---

Thanks for your attention on this, both this time, and back in the
summer when I was asking questions before we arrived at our "fix". You and
Kris really carry this discussion group, and we're all lucky to have you do
it.

My goal was to add something to the group so that I could do more than
just receive help. I also wanted something in the archives that would help
"newbie" searchers who haven't yet had to deal with the encoding process in
a java servlet -- we searched for weeks without finding anything that
covered all the bases. If there's a way to remove/correct/comment my
posting, I'm fine with that.

- Mike

At 04:55 PM 11/8/2004, Oliver Jowett wrote:
>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
>encoding, obviously..
>
>Can you provide a self-contained testcase that demonstrates getString()
>doing the wrong thing?
>
>-O