From: | Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr> |
---|---|
To: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Database->ServerEncoding, ClientEncoding |
Date: | 2002-02-25 17:12:52 |
Message-ID: | 200202251712.g1PHCqLx004119@www1.translationforge |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
Hi Dave,
I used pgSchema today with a Latin1 encoding hack.
Whenever a character does not exist in Latin1 (example : euro sign), an error
is returned. Obviously, this is not always the case: Japanese is transformed
in unreadable characters without error.
My impression is that client encoding is not ***very** secure. A full unicode
chain is a better solution. But we need Client encoding support as it offers
a wide variety of encodings ... and is compatible with VB.
Maybe we could start modifying pgSchema->Databases and pgSchema->pgDatabase.
What would you think if we :
- renamed EncodingName into ServerEncoding,
- added ClientEncoding.
Then, in frmSQLInput, we would add a combo to choose the encoding needed.
This will allow me to view UTF-8 data in Latin1 and export it in UTF-8. Isn't
it marvelous?
Cheers,
Jean-Michel
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2002-02-25 17:20:18 | Re: pgAdmin2 Japanese display |
Previous Message | Hiroshi Inoue | 2002-02-25 16:19:19 | Re: pgAdmin2 Japanese display |