Re: Dumping in LATIN1 and restoring in UTF-8
От | Tino Wildenhain |
---|---|
Тема | Re: Dumping in LATIN1 and restoring in UTF-8 |
Дата | |
Msg-id | 44ACC28E.60605@wildenhain.de обсуждение исходный текст |
Ответ на | Re: Dumping in LATIN1 and restoring in UTF-8 ("Marco Bizzarri" <marco.bizzarri@gmail.com>) |
Ответы |
Re: Dumping in LATIN1 and restoring in UTF-8
|
Список | pgsql-general |
... >> Yes, its actually quite esay: you dump as you feel apropriate, >> then create the database with the encoding you want, >> restore w/o creating database and you are done. >> Restore sets the client encoding to what it actually was >> in the dump data (in your case latin-1) and the database >> would be utf-8 - postgres automatically recodes. No need >> for iconv and friends. >> >> Regards >> Tino >> > > First of all, thank you for your answer. However, I suspect I did not > understand your answer, since the commands I used were: > > 1) pg_dump -Ft -b -f dump.sql.tar database > 2) dropdb database > 3) createdb -E UNICODE database > 4) pg_restore -d database dump.sql.tar > > According to my experience, this produces a "double encoding". As you > can see, I hand-created the database, with the proper encoding. > However, when I reimported the database, the result was a latin1 > encoded in utf-8, rather than a pure utf-8. > > How my procedure was different with respect to yours? That was the correct way. I wonder if you have recoding support enabled? Did you build postgres yourself? Latin-1 double encoded into utf-8 seems not like possible... utf-8 barfs on most latin-1 characters, current 8.1 is very picky about it. So maybe you can work with a small test table to find out what's going wrong here. (The changing of the client_enccoding setting in the backup is only needed in the case when you had data in the wrong encoding - like SQLAscii filled with latin-1 or something) Regards Tino
В списке pgsql-general по дате отправления: