Re: Character Encoding Question
| От | Don Parris |
|---|---|
| Тема | Re: Character Encoding Question |
| Дата | |
| Msg-id | CAJ-7yon4nBs=EC--Pxyj1ERc3Mp=JYqZ_wUu-kr8zfiX=Tj+kw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Character Encoding Question (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
| Ответы |
Re: Character Encoding Question
|
| Список | psycopg |
On Thu, Mar 28, 2013 at 7:07 PM, Daniele Varrazzo <daniele.varrazzo@gmail.com> wrote:
On Thu, Mar 28, 2013 at 8:49 PM, Don Parris <parrisdc@gmail.com> wrote:<SNIP>
> On Thu, Mar 28, 2013 at 1:30 PM, Daniele Varrazzo
Your database is probably fine and perfectly encoded. If there's
anything to be understood is why psycopg connects by default with a
SQL_ASCII encoding - which is not good to transfer the ñ char or any
other char with ascii value > 127. The answer could be, from the most
general to the most specific, in the postgresql.conf (global setting),
in the pg_user view (per-user setting), in some environment variable
(per-connection setting). Which one of these settings say
client_encoding=sql_ascii?
I bet it's the first.
-- Daniele
Aha! As it turns out, I started looking into the character set support in the postgresql documentation, and discovered the psql -l command. It showed this test database is actually *not* encoded in UTF-8 at all, but rather in ASCII. I am not sure how I managed to do that, but I did. I was sure I had used the same DB creation script and just changed the DB name, but clearly, I missed something. I am not sure if it is necessary to drop and re-create the database to correct this, but that is what I have done.
When I tried using \encoding or SET client_encoding, I got no errors, but I still saw this test DB set as ASCII when running the psql -l command. Anyway, I'll have to pursue this further later. Many thanks for the help!
--
D.C. Parris, FMP, Linux+, ESL Certificate
Minister, Security/FM Coordinator, Free Software Advocate
GPG Key ID: F5E179BE
В списке psycopg по дате отправления: