Re: Encoding conversion problem

Andrea wrote:
> Hi Sabine,
>> I'm guessing, but maybe if the databse tells the JDBC driver it's
>> ISO-8859-1 *and* your application tells it the same encoding, it won't
>> bother trying to transform anything...
> Yes that's what I was thinking too... but I tried to change the
> encoding of the JVM (tried Cp850, ...) but it keeps on working...
> 
> Hi Lew,
>>> I was thinking only about the DB encoding while the problem is mainly
>>> in the JVM encoding (now it's clear to me that Java can't handle
>>> characters outside the encoding of the JVM, I wasn't thinking about
>>> it, sorry...).
>> "The encoding of the JVM" is Unicode-16 with surrogate pairs; every
Unicode
>> character is representable in the JVM, including the Euro character. 
There is
>> no Unicode character that the JVM cannot represent.
> With "encoding of the JVM" I was referring to the file.encoding
> property used by the JVM. If the JVM runs with:
> - ISO-8859-1 then I can't read or write the EURO character to DB (it
> becomes garbage) and ISO-8859-1 doesn't include that character;
> - Cp1252 then I can read and write the EURO character to DB and Cp1252
> includes that character.

I uinderstand my confusion now - it stemmed from the phrase "the encoding
of 
the JVM".  The JVM itself only uses one encoding; it translates to and
from 
other encoding on I/O.  So to make sure I understood you correctly, were
you 
referring to the encoding specified by the I/O call?

Generally if the encoding you specify for I/O is different from the
encoding 
in your data store, it will cause trouble.  This is not limited to Java. 
Over 
in the Postgres newsgroups one finds people have trouble with character 
encoding from all sorts of platforms, mostly stemming from trying to store

characters in a column that are not part of the specified character
encoding 
for the DB.  If such things don't match, then problems will hatch.

-- 
Lew