Thread: ...
Hi, I would like some help to solve this problem : A Portuguese-Brazilian PgAdmin user describe me a problem with acentt code, the data on the database wich have acentt is not displayed properly in PgAdmin III but do appear properly in PgAdmin II. Thank´s ===== Ângelo Marcos Rigo AMR Informática (51) 3348 0870 Rua Pe. Alois Kades 400/210 Porto Alegre /RS/Brasil http://amr.freezope.org angelo_rigo@yahoo.com.br Yahoo! Mail - o melhor webmail do Brasil http://mail.yahoo.com.br
Le Mardi 30 Septembre 2003 17:23, Ângelo Marcos Rigo a écrit : > A Portuguese-Brazilian PgAdmin user describe me a > problem with acentt code, the data on the database > wich have acentt is not displayed properly in PgAdmin > III but do appear properly in PgAdmin II. Hi Ângelo, Could you: - click on the database and show properties. What is the encoding of your database: SQL_ASCII or Unicode or anything else? - send me privately an attached file including the definition of the table with one row of data. You can use pg_dump --table=TABLE to dump a table. I will test display here. Are you using our stock binaries or did you compile pgAdmin3 yourself? What OS are you running? Cheers, Jean-Michel
Hi,
I think I have a similar issue... A pgAdmin III user contacted me with the
question why they can't see the data in Russian and how to to solve the
problem. I queried them for more information. I think their data must be
encoded in some other encoding (e.g. KOI8-R) and when it gets to the
client side, it's not converted.
Any other hints aside from below what to try?
-s
On Wed, 1 Oct 2003, Jean-Michel POURE wrote:
> Le Mardi 30 Septembre 2003 17:23, Ãngelo Marcos Rigo a écrit :
> > A Portuguese-Brazilian PgAdmin user describe me a
> > problem with acentt code, the data on the database
> > wich have acentt is not displayed properly in PgAdmin
> > III but do appear properly in PgAdmin II.
>
> Hi Ãngelo,
>
> Could you:
> - click on the database and show properties. What is the encoding of your
> database: SQL_ASCII or Unicode or anything else?
>
> - send me privately an attached file including the definition of the table
> with one row of data. You can use pg_dump --table=TABLE to dump a table. I
> will test display here.
>
> Are you using our stock binaries or did you compile pgAdmin3 yourself? What OS
> are you running?
>
> Cheers, Jean-Michel
--
Serguei A. Mokhov | /~\ The ASCII
Computer Science Department | \ / Ribbon Campaign
Concordia University | X Against HTML
Montreal, Quebec, Canada | / \ Email!
"I swear, education is the only industry, where
the consumer is happier when they get less
for their money" -- Julia Timofeev
Dear Serguei. It is strange. Server has encoding as follows. -- UNICODE --> KOI8R CREATE DEFAULT CONVERSION pg_catalog.utf_8_to_koi8_r FOR 'UNICODE' TO 'KOI8R' FR OM utf8_to_koi8r; -- KOI8R --> UNICODE CREATE DEFAULT CONVERSION pg_catalog.koi8_r_to_utf_8 FOR 'KOI8R' TO 'UNICODE' FR OM koi8r_to_utf8; Please Try psql command. \l <-- list all databases regards Hiroshi Saito ----- Original Message ----- From: "Serguei A. Mokhov" <mokhov@cs.concordia.ca> > Hi, > > I think I have a similar issue... A pgAdmin III user contacted me with the > question why they can't see the data in Russian and how to to solve the > problem. I queried them for more information. I think their data must be > encoded in some other encoding (e.g. KOI8-R) and when it gets to the > client side, it's not converted. > > Any other hints aside from below what to try? > > -s > > On Wed, 1 Oct 2003, Jean-Michel POURE wrote: > > > Le Mardi 30 Septembre 2003 17:23, Ã,ngelo Marcos Rigo a écrit : > > > A Portuguese-Brazilian PgAdmin user describe me a > > > problem with acentt code, the data on the database > > > wich have acentt is not displayed properly in PgAdmin > > > III but do appear properly in PgAdmin II. > > > > Hi Ã,ngelo, > > > > Could you: > > - click on the database and show properties. What is the encoding of your > > database: SQL_ASCII or Unicode or anything else? > > > > - send me privately an attached file including the definition of the table > > with one row of data. You can use pg_dump --table=TABLE to dump a table. I > > will test display here. > > > > Are you using our stock binaries or did you compile pgAdmin3 yourself? What OS > > are you running? > > > > Cheers, Jean-Michel >
Serguei A. Mokhov wrote: >Hi, > >I think I have a similar issue... A pgAdmin III user contacted me with the >question why they can't see the data in Russian and how to to solve the >problem. I queried them for more information. I think their data must be >encoded in some other encoding (e.g. KOI8-R) and when it gets to the >client side, it's not converted. > > This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded database will not be shown because the server doesn't know how to encode it in Unicode. This is fixed for HEAD and BRANCH. Regards, Andreas
From: "Andreas Pflug" <pgadmin@pse-consulting.de> > Serguei A. Mokhov wrote: > > >Hi, > > > >I think I have a similar issue... A pgAdmin III user contacted me with the > >question why they can't see the data in Russian and how to to solve the > >problem. I queried them for more information. I think their data must be > >encoded in some other encoding (e.g. KOI8-R) and when it gets to the > >client side, it's not converted. > > > > > This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded > database will not be shown because the server doesn't know how to encode > it in Unicode. > > This is fixed for HEAD and BRANCH. No. Server encoding as below. -- SQL_ASCII --> UNICODE CREATE DEFAULT CONVERSION pg_catalog.ascii_to_utf_8 FOR 'SQL_ASCII' TO 'UNICODE' FROM ascii_to_utf8; -- UNICODE --> SQL_ASCII CREATE DEFAULT CONVERSION pg_catalog.utf_8_to_ascii FOR 'UNICODE' TO 'SQL_ASCII' FROM utf8_to_ascii; regards, Hiroshi Saito
On Thu, 2 Oct 2003, Hiroshi Saito wrote:
> From: "Andreas Pflug" <pgadmin@pse-consulting.de>
>
> > Serguei A. Mokhov wrote:
> >
> > >Hi,
> > >
> > >I think I have a similar issue... A pgAdmin III user contacted me
> > >with the question why they can't see the data in Russian and how to
> > >to solve the problem. I queried them for more information. I think
> > >their data must be encoded in some other encoding (e.g. KOI8-R) and
> > >when it gets to the client side, it's not converted.
> > >
> > >
> > This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded
> > database will not be shown because the server doesn't know how to
> > encode it in Unicode.
> >
> > This is fixed for HEAD and BRANCH.
>
> No.
> Server encoding as below.
> -- SQL_ASCII --> UNICODE
> CREATE DEFAULT CONVERSION pg_catalog.ascii_to_utf_8 FOR 'SQL_ASCII' TO 'UNICODE' FROM ascii_to_utf8;
> -- UNICODE --> SQL_ASCII
> CREATE DEFAULT CONVERSION pg_catalog.utf_8_to_ascii FOR 'UNICODE' TO 'SQL_ASCII' FROM utf8_to_ascii;
Yes, I know about existance of this conversion (as well as about the
KOI8-R one). It's been there for ages... I'll report back once the user
gets back to me on that. I'm not sure though whether they'd be willing to
pull the stuff from the CVS and compile it -- even you guys recommend to
use the binaries... ;)
> regards,
> Hiroshi Saito
--
Serguei A. Mokhov | /~\ The ASCII
Computer Science Department | \ / Ribbon Campaign
Concordia University | X Against HTML
Montreal, Quebec, Canada | / \ Email!
"I swear, education is the only industry, where
the consumer is happier when they get less
for their money" -- Julia Timofeev
Hiroshi Saito wrote: >From: "Andreas Pflug" <pgadmin@pse-consulting.de> > > > >>Serguei A. Mokhov wrote: >> >> >> >>>Hi, >>> >>>I think I have a similar issue... A pgAdmin III user contacted me with the >>>question why they can't see the data in Russian and how to to solve the >>>problem. I queried them for more information. I think their data must be >>>encoded in some other encoding (e.g. KOI8-R) and when it gets to the >>>client side, it's not converted. >>> >>> >>> >>> >>This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded >>database will not be shown because the server doesn't know how to encode >>it in Unicode. >> >>This is fixed for HEAD and BRANCH. >> >> > >No. >Server encoding as below. > This is not suitable for non-ascii chars, because the upper bit will be chopped off (ascii->utf8), effectively destroying the string, or converted to a bogus char (xx), effectively destroying the string. Regards, Andreas
From: "Andreas Pflug" <pgadmin@pse-consulting.de> (snip) > >>This is correctly diagnosed, non-ascii data in a SQL_ASCII encoded > >>database will not be shown because the server doesn't know how to encode > >>it in Unicode. > >> > >>This is fixed for HEAD and BRANCH. > > > >No. > >Server encoding as below. > > > > This is not suitable for non-ascii chars, because the upper bit will be > chopped off (ascii->utf8), effectively destroying the string, or > converted to a bogus char (xx), effectively destroying the string. Hmm.. Is it a specific code or all code? However, Will you absorb all the bugs of PostgreSQL? regards, Hiroshi Saito
Hiroshi Saito wrote: >Hmm.. >Is it a specific code or all code? >However, >Will you absorb all the bugs of PostgreSQL? > > This is not a bug of PostgreSQL, nor of pgAdmin. SQL_ASCII database *should* contain only 7bit ascii characters. If you use 8-bit characters, conversion is unpredictable (well, it *is* predictable, but probably not what you'd like to see) Regards, Andreas
Le Mercredi 1 Octobre 2003 20:05, Andreas Pflug a écrit : > This is not a bug of PostgreSQL, nor of pgAdmin. > SQL_ASCII database *should* contain only 7bit ascii characters. If you > use 8-bit characters, conversion is unpredictable (well, it *is* > predictable, but probably not what you'd like to see) IMHO, SQL_ASCII database contain more than 7bit characters. I used it several times to store Frenc accentuated text and it worked like a charm. The name "ASCII" may not be well chosen. It contains more than ASCII presently. Cheers, Jean-Michel
Jean-Michel POURE wrote: >Le Mercredi 1 Octobre 2003 20:05, Andreas Pflug a écrit : > > >>This is not a bug of PostgreSQL, nor of pgAdmin. >>SQL_ASCII database *should* contain only 7bit ascii characters. If you >>use 8-bit characters, conversion is unpredictable (well, it *is* >>predictable, but probably not what you'd like to see) >> >> > >IMHO, SQL_ASCII database contain more than 7bit characters. I used it several >times to store Frenc accentuated text and it worked like a charm. The name >"ASCII" may not be well chosen. It contains more than ASCII presently. > > > It's no problem storing non-UTF characters in an UNICODE database either, you will never notice until you try to convert. Misusing the database is not a good idea on the long run. Regards, Andreas
From: "Andreas Pflug" <pgadmin@pse-consulting.de> > Hiroshi Saito wrote: > > >Hmm.. > >Is it a specific code or all code? > >However, > >Will you absorb all the bugs of PostgreSQL? > > > > > > This is not a bug of PostgreSQL, nor of pgAdmin. > SQL_ASCII database *should* contain only 7bit ascii characters. If you > use 8-bit characters, conversion is unpredictable (well, it *is* > predictable, but probably not what you'd like to see) It isn't understood. Shouldn't put it in SQL_ASCII. Database comes to return the result which made a mistake. Or, do you use 256(2^8=256) ASCII? regards, Hiroshi Saito
On Wed, 1 Oct 2003, Jean-Michel POURE wrote:
> Le Mercredi 1 Octobre 2003 20:05, Andreas Pflug a écrit :
> > This is not a bug of PostgreSQL, nor of pgAdmin. SQL_ASCII database
> > *should* contain only 7bit ascii characters. If you use 8-bit
> > characters, conversion is unpredictable (well, it *is* predictable,
> > but probably not what you'd like to see)
>
> IMHO, SQL_ASCII database contain more than 7bit characters. I used it
> several times to store Frenc accentuated text and it worked like a
> charm. The name "ASCII" may not be well chosen. It contains more than
> ASCII presently.
Indeed, no one has forbidden extended-ASCII chars :) Though these would be
interpreted differntly. My 256 char ASCII table is different from yours
presentation-wise. But you can't control it uniformly unless you
explicitly tell how to enterpret. I wanna see my Cyrillic chars and not
the diacritics of Latin chars, for example. An Indian friedn of mind would
like to see their Hindi chars there instead, so... You are lucky because
your accented chars are the deault representation. There could potentially
be a need to tell the UI which ASCII it is, not sure how it is.
--
Serguei A. Mokhov | /~\ The ASCII
Computer Science Department | \ / Ribbon Campaign
Concordia University | X Against HTML
Montreal, Quebec, Canada | / \ Email!
"I swear, education is the only industry, where
the consumer is happier when they get less
for their money" -- Julia Timofeev
Hiroshi Saito wrote: >From: "Andreas Pflug" <pgadmin@pse-consulting.de> > > > >>Hiroshi Saito wrote: >> >> >> >>>Hmm.. >>>Is it a specific code or all code? >>>However, >>>Will you absorb all the bugs of PostgreSQL? >>> >>> >>> >>> >>This is not a bug of PostgreSQL, nor of pgAdmin. >>SQL_ASCII database *should* contain only 7bit ascii characters. If you >>use 8-bit characters, conversion is unpredictable (well, it *is* >>predictable, but probably not what you'd like to see) >> >> > >It isn't understood. >Shouldn't put it in SQL_ASCII. >Database comes to return the result which made a mistake. >Or, do you use 256(2^8=256) ASCII? > The DB will store 8 bit per character, regardless of the db encoding. When it comes to conversion, only 7 bits are valid, if you tell the backend "this is ASCII data". Your fault, if it actually isn't. Regards, Andreas
Le Mercredi 1 Octobre 2003 20:21, Andreas Pflug a écrit : > It's no problem storing non-UTF characters in an UNICODE database > either, you will never notice until you try to convert. > Misusing the database is not a good idea on the long run. Agreed, trash my last e-mail. Cheers, Jean-Michel
Serguei A. Mokhov wrote: >Indeed, no one has forbidden extended-ASCII chars :) Though these would be >interpreted differntly. My 256 char ASCII table is different from yours >presentation-wise. But you can't control it uniformly unless you >explicitly tell how to enterpret. I wanna see my Cyrillic chars and not >the diacritics of Latin chars, for example. An Indian friedn of mind would >like to see their Hindi chars there instead, so... You are lucky because >your accented chars are the deault representation. > :-) >There could potentially >be a need to tell the UI which ASCII it is, not sure how it is. > *NO*, we discussed this. Data encoding is unknown if SQL_ASCII is selected, so we have to leave it up to the gui to display whatever it means. Hopefully it is what the user expected (it probably will, if using the same language settings as he used when inserting the data). For other encodings, all 256 chars are well-known, so the server knows how to recode to UNICODE, and we know how to display. Regards, Andreas
From: "Andreas Pflug" <pgadmin@pse-consulting.de> > Hiroshi Saito wrote: (snip) > >It isn't understood. > >Shouldn't put it in SQL_ASCII. > >Database comes to return the result which made a mistake. > >Or, do you use 256(2^8=256) ASCII? > > > > The DB will store 8 bit per character, regardless of the db encoding. > When it comes to conversion, only 7 bits are valid, if you tell the > backend "this is ASCII data". Your fault, if it actually isn't. However, WHERE of SELECT will go to look for it with 7bit for ENCODING if to be SQL_ASCII. Then, it fails. And, order by, too. Therefore, it is the case which you must not use. regards, Hiroshi Saito