Erm, ok..
I should have investigated deeper before.
Apparently someone committed in the cvs an with an old, buggy version of
DODS, which was reading the fields with an InputStreamReader, getting the
data with getBinaryStream.
So you can imagine what was happening !
The correct new version uses getCharacterStream, and of course there is no
problem.
Thanx a lot for your help, as it helped me a lot to narrow my
investigation !
Regards,
Alexandre Aufrere
----------------------------------------------------
De : Oliver Jowett <oliver@opencloud.com>
A : alexandre.aufrere@inet6.fr
Objet : Re: [JDBC] Problems with charsets, investigated...
Date : Sun, 08 Aug 2004 23:57:02 +1200
> Alexandre Aufrere wrote:
>
> >>Can you dump out the *characters* of the problem Strings you get from
> >>the driver, one character at a time, and see what numeric values
you're
> >>getting and whether they are the right UTF-16 values you expect? i.e.
> >>
> >> for (int i = 0; i < str.length(); ++i) {
> >> System.out.println(" offset " + i + " value " +
(int)str.charAt(i));
> >> }
> >>
> >>Can you provide a pg_dump (LATIN1 encoding I assume) plus sample
> >>testcase that shows off the problem?
> >
> >
> > well, i'll investigate more tomorrow, at work, and try to set up a
simple
> > test program to try to understand deeper what's going on.
> > currently, we see the problem by doing a debug output (simply a
> > System.out) from Enhydra's DODS (which is the relational-object
layer).
> >>From what i've seen in DODS (maybe, though, i didn't dig enough), DODS
> > does not manipulate Strings coming from the JDBC driver when they are
of
> > type VARCHAR, therefore it shouldn't be the source of the problem.
> > about the charAt thing, it is as well not correct, i tried...
>
> Can you show me the charAt output for some sample data that shows the
> problem? (and the corresponding string as it's stored in the database)
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
