Re: BUG #5661: The character encoding in logfile is confusing.
От | Dave Page |
---|---|
Тема | Re: BUG #5661: The character encoding in logfile is confusing. |
Дата | |
Msg-id | AANLkTinX6kKqwXZ1G3JwLkZBZQriNYrKQ=f5T_FQ6vGA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5661: The character encoding in logfile is confusing. (Craig Ringer <craig@postnewspapers.com.au>) |
Список | pgsql-hackers |
On Wed, Sep 22, 2010 at 12:25 PM, Craig Ringer <craig@postnewspapers.com.au> wrote: > I don't think that's an OK answer, myself. Mixed encodings with no > delineation in one file = bug as far as I'm concerned. You can't even rely > on being able to search the log anymore. You'll only get away with it when > using languages that mostly stick to the 7-bit ASCII subset, so most text is > still readable; with most other languages you'll get logs full of what looks > to the user like garbage. This issue crops up periodically in the pgAdmin lists as well, as the mixed encoding sometimes break the log viewer. > I still wonder if, rather than making this configurable, the right choice is > to force logging to UTF-8 (with BOM) across the board, right from postmaster > startup. It's consistent, all messages in all other encodings can be > converted to UTF-8 for logging, it's platform independent, and text editors > etc tend to understand and recognise UTF-8 especially with the BOM. That would be ideal for us. > Unfortunately, because many unix utilities (grep etc) aren't encoding aware, > that'll cause problems when people go to search log files. For (eg) "広告掲載" But not for others! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: