Re: Locale/encoding problem/question - Mailing list pgsql-general

From henka@cityweb.co.za
Subject Re: Locale/encoding problem/question
Date
Msg-id 63442.196.23.181.69.1154685502.squirrel@support.metroweb.co.za
Whole thread Raw
In response to Re: Locale/encoding problem/question  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Locale/encoding problem/question  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-general

> On Fri, Aug 04, 2006 at 10:48:17AM +0200, henka@cityweb.co.za wrote:
>> Hello all,
>>
>> I somehow managed to stuff up the encoding (or locale or something) in a
>> transfer of a database from one machine to another (also different linux
>> distribution).
>>
>> The problem is this:  the origional database was created and populated
>> with data using whatever default locale/encoding was installed on the
>> first machine.
>
> Two big questions:
>
> 1. What encoding are the two database (\l will tell you)?
> 2. What encoding are the clients expecting?


Thanks for the response, Martijn.

I *think* the client_encoding origionally in the db was UTF-8 (but I could
be wrong, it might have been LATIN1).  I would imagine that LATIN1 would
be the right one, since it needs to display standard english, plus some
others (such as é ä ë è etc).

The multibyte chars show up in xterm (putty) -and- when the data is
displayed using php in a browser - both incorrectly.

I've even tried using LATIN1 (ie, explicitly setting it to latin1 using
initdb, and then restoring the database after changing the 'utf-8' strings
in the dump data to 'latin1').  This still yields the funny chars.

To be honest, I have no idea what the origional encoding was.

Can you suggest any other approaches I can try to restore the database so
that those chars display correctly?

All comments are welcome.

Regards
Henk




pgsql-general by date:

Previous
From: Flemming Frandsen
Date:
Subject: Re: LISTEN considered dangerous
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Locale/encoding problem/question