Обсуждение: ? (question mark) characters
Ok, I tried all the drivers currently available at http://jdbc.fastcrypt.com. They all seem to correct the problem with long (>8k) SQL statements, but they're all broken considering Portuguese characters like áéíóú (aeiou with accent)... they are replaced by question marks (?)... any ideas? Should I try to compile my own drivers? How? BTW I am using JDK 1.3 from Sun (Solaris and Linux)... -- Ricardo Pardini rpardini@organox.com.br
> Ok, I tried all the drivers currently available at http://jdbc.fastcrypt.com. > They all seem to correct the problem with long (>8k) SQL statements, but > they're all broken considering Portuguese characters like áéíóú (aeiou with > accent)... they are replaced by question marks (?)... any ideas? Should I try > to compile my own drivers? How? > BTW I am using JDK 1.3 from Sun (Solaris and Linux)... I suspect the problem is not with the jdbc driver but with the way you have configured postgres, try building postgres with: ./configure --with-java --enable-multibyte=UNICODE --enable-unicode-conversion And use initdb with the -E UNICODE option: initdb -E UNICODE -D [path to data directory] And see if that works, good luck! Michael
Ricardo Pardini wrote: > they're all broken considering Portuguese characters > like áéíóú (aeiou with accent)... they are replaced > by question marks (?)... any ideas? What's the character encoding of the database? See http://postgresql.demunnikservices.nl/users-lounge/docs/7.1/admi n/multibyte.html (this documentation is about character encoding, not just multibyte support like the title suggests). And see also http://fts.postgresql.org/db/mw/msg.html?mid=1029464 about how multibyte support relates to character encoding support. Are these special characters converted when you store them in the database, or when you retrieve them from he database? >Should I try to compile my own drivers? No, that won't fix it. Regards, René Pijlman
Thank you all for your help:
Dia Thursday, 30 de August, 2001 10:42, Rene Pijlman wrote:
> > like áéíóú (aeiou with accent)... they are replaced
> > by question marks (?)... any ideas?
> What's the character encoding of the database?
It doesn't matter. I have tried it with SQL_ASCII, ISO-8859-1, and with an
installation on Solaris which doesn't have encodings ("psql -l" doesnt list
the Encoding field).
Strange thing is, if I use the jdbc7.0-1.2.jar from
http://jdbc.postgresql.org, the special characters work ok. But then I have
the 8k statement limitation problem.
> Are these special characters converted when you store them in
> the database, or when you retrieve them from he database?
They're converted when I insert. I can insert the same characters directly
into psql (into the same table) and it works ok (I can retrieve them without
problems). I can use LIBPQ apps (PHP, PGACCESS etc) and it works ok with all
backends (running with encodings SQL_ASCII, ISO, etc)...
--
Ricardo Pardini
rpardini@organox.com.br
Ricardo, Is your database compiled for multibyte support? And what character set is the database you are connecting to created with? (to get the database character set do a 'psql -l'). If the answer to the first question is no or the answer to the second question is 'SQL_ASCII', then only 7bit characters are supported. thanks, --Barry Ricardo Pardini wrote: > Ok, I tried all the drivers currently available at http://jdbc.fastcrypt.com. > They all seem to correct the problem with long (>8k) SQL statements, but > they're all broken considering Portuguese characters like áéíóú (aeiou with > accent)... they are replaced by question marks (?)... any ideas? Should I try > to compile my own drivers? How? > BTW I am using JDK 1.3 from Sun (Solaris and Linux)... > >
On Thu, 2001-08-30 at 18:41, Barry Lind wrote: > Ricardo, > > Is your database compiled for multibyte support? And what character set > is the database you are connecting to created with? (to get the > database character set do a 'psql -l'). If the answer to the first > question is no or the answer to the second question is 'SQL_ASCII', then > only 7bit characters are supported. : > > Ok, I tried all the drivers currently available at http://jdbc.fastcrypt.com. > > They all seem to correct the problem with long (>8k) SQL statements, but > > they're all broken considering Portuguese characters like áéíóú (aeiou with > > accent)... they are replaced by question marks (?)... any ideas? Should I try > > to compile my own drivers? How? > > BTW I am using JDK 1.3 from Sun (Solaris and Linux)... For portugese you should be using -E LATIN1 Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html
On Thu, 30 Aug 2001 11:06:13 -0300, you wrote:
>Thank you all for your help:
>Dia Thursday, 30 de August, 2001 10:42, Rene Pijlman wrote:
>> > like áéíóú (aeiou with accent)... they are replaced
>> > by question marks (?)... any ideas?
>> What's the character encoding of the database?
>
>It doesn't matter. I have tried it with SQL_ASCII, ISO-8859-1, and with an
>installation on Solaris which doesn't have encodings ("psql -l" doesnt list
>the Encoding field).
Have you tried it with a database which was created with -E
LATIN1 and with an installation configured with
--enable-multibyte?
If so, can you post a small Java program that reproduces the
problem?
Regards,
René Pijlman <rene@lab.applinet.nl>
* Rene Pijlman <rene@lab.applinet.nl> wrote: | | Have you tried it with a database which was created with -E | LATIN1 and with an installation configured with | --enable-multibyte? You don't need multibyte for iso-8859-1. A simple test case reproducing the problem would be nice though. I don't have any 7.1 servers in production, but the 7.0 series doesn't have any problems at all with iso-8859-1. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
On 02 Sep 2001 03:35:29 +0200, you wrote: >You don't need multibyte for iso-8859-1. That's what I thought. But with current CVS (7.2) creating a database with -E LATIN1 fails without multibyte support. See the link in one of my previous postings in this thread. Regards, René Pijlman <rene@lab.applinet.nl>