> "Oliver Elphick" <olly(at)lfix(dot)co(dot)uk> writes:
> > I think this happens when the front-end encoding is SQL_ASCII and the
> > database is using UNICODE. Then, there are misunderstandings between
> > front-end and back-end, so that a single character with the eighth bit
> > set may be sent by the front-end and interpreted by the back-end as the
> > first half of a UNICODE two-byte character.
> I wondered about that, but his examples had one or more characters
> between the eighth-bit-set character and the '|', so this doesn't seem
> to explain the problem.
From Jaume's example:
> SELECT edicion FROM products;
> Espaa|Nacional <-------puts on the same cell either there's an '|' in
> the middle!!!
\361 == 0xf1. UTF-8 assumes that:
if (the first byte) & 0xe0 == 0xe0, then the letter consists of 3
So PostgreSQL believes that "a|" is one UTF-8 letter and eat up
My guess is Jaume made an UNICODE database but provided it ISO 8859-1
or that kind of single-byte latin encoding data.
I'm wondering why so many people are using UTF-8 database even he does
not understand what UTF-8 is:-) I hope 7.1 would solve this kind of
confusion by enabling an automatic encoding conversion between UTF-8
In response to
pgsql-hackers by date
|Next:||From: Rainer Mager||Date: 2001-02-28 01:14:48|
|Subject: RE: Problem with 7.0.3 dump -> 7.1b4 restore|
|Previous:||From: Hiroshi Inoue||Date: 2001-02-27 23:53:31|
|Subject: Re: [ODBC] Re: Release in 2 weeks ...|
pgsql-admin by date
|Next:||From: Enrico Mangano||Date: 2001-02-28 09:09:11|
|Previous:||From: Tom Lane||Date: 2001-02-27 22:29:10|
|Subject: Re: pg_hba.conf changes have no effect on cygwin/NT 4.0 |