The following bug has been logged online:

Bug reference: 2861
Logged by: goodsforyou
Email address: goodsforyou@gmail.com
PostgreSQL version: 8.2.0 win32
Operating system: Windows xp sp2 Simplified Chinese Version
Description: when backup UTF-8 database,pgdump add comments not
encoded in UTF-8
Details:

When I make a backup of a UTF8 database then pg_dump add some comment to
backup file:

-- Started on 2006-12-23 11:04:38 ä¸*国æ*‡å‡†æ—¶é—´
....
....
-- Completed on 2006-12-23 11:04:40 ä¸*国æ*‡å‡†æ—¶é—´

'ä¸*国æ*‡å‡†æ—¶é—´' means in English 'China standard
time'. Unfortunately it is encoded incorretly in GBK, not in UTF-8. It makes
following error during restore:

pg_restore: connecting to database for restore

pg_restore: [archiver (db)] Error while INITIALIZING:

pg_restore: [archiver (db)] could not execute query: ERROR: invalid byte
sequence for encoding "UTF8": 0xd6d0

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"goodsforyou" <goodsforyou@gmail.com> writes:
> PostgreSQL version: 8.2.0 win32

> When I make a backup of a UTF8 database then pg_dump add some comment to
> backup file:
> -- Started on 2006-12-23 11:04:38 ä¸*国æ*‡å‡†æ—¶é—´

You *sure* that pg_dump is 8.2.0? Because we fixed that before 8.2 rc1 ...

2006-11-21 17:19 tgl

* src/: backend/utils/error/elog.c,
bin/pg_dump/pg_backup_archiver.c, bin/pg_dump/pg_dumpall.c:
Suppress timezone (%Z) part of timestamp display when running on
Windows, because on that platform strftime produces localized zone
names in varying encodings. Even though it's only in a comment,
this can cause encoding errors when reloading the dump script. Per
suggestion from Andreas Seltenreich. Also, suppress %Z on Windows
in the %s escape of log_line_prefix ... not sure why this one is
different from the other two, but it shouldn't be.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match