Thread: The encoding problem of a server log.
Hi All. Although pgAdmin has the check display of a server log, it has a problem. This problem exists on extension of the problem which a Postgres server has. Then, It is very difficult to solve this problem immediately.:( The character code of the message text as a log to a translation result is unsettled. Therefore, this problem as which a log is not displayed by pgAdmin will correspond after it. ex.) (Include Shuft_JIS) http://winpg.jp/~saito/pgAdmin/postgresql-2009-01-18_001837.log (log is not displayed.) http://winpg.jp/~saito/pgAdmin/20090118_ServerLog1.png at the fource patch. == str = line + wxTextBuffer::Translate(wxString(raw, set->GetConversion()), wxTextFileType_Unix); to str = line + wxString(wxString(raw,wxConvLibc),wxConvUTF8); == http://winpg.jp/~saito/pgAdmin/20090118_ServerLog2.png But,but but... log is not displayed.... (log is Include Shift_JIS and UTF-8) http://winpg.jp/~saito/pgAdmin/postgresql-2009-01-18_020238.log I consider the proposal of log_encoding(GUC) for the purpose of ver 8.5 or over. However, adjustment is now difficult.... much time is needed for it. Therefore, I wish to recognize this problem as TODO. or, are there some ideas? Regards, Hiroshi Saito
On Sun, Jan 18, 2009 at 6:35 AM, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: > Hi All. > > Although pgAdmin has the check display of a server log, it has a problem. > This problem exists on extension of the problem which a Postgres server > has. Then, It is very difficult to solve this problem immediately.:( > > The character code of the message text as a log to a translation result is > unsettled. Therefore, this problem as which a log is not displayed by > pgAdmin will correspond after it. > ex.) > (Include Shuft_JIS) > http://winpg.jp/~saito/pgAdmin/postgresql-2009-01-18_001837.log > (log is not displayed.) > http://winpg.jp/~saito/pgAdmin/20090118_ServerLog1.png Yuck. > at the fource patch. > == > str = line + wxTextBuffer::Translate(wxString(raw, set->GetConversion()), > wxTextFileType_Unix); > to > str = line + wxString(wxString(raw,wxConvLibc),wxConvUTF8); > == > http://winpg.jp/~saito/pgAdmin/20090118_ServerLog2.png Well, that's an improvement. > But,but but... log is not displayed.... > (log is Include Shift_JIS and UTF-8) > http://winpg.jp/~saito/pgAdmin/postgresql-2009-01-18_020238.log Can we at least detect the problem and warn the user? It might be useful to provide a 'save log' button to allow the user to save the raw log locally for further examination using other tools. Also, note that I suggested to Guillaume (who is working on frmStatus) that we should replace the listview used for the log with a text control. That may be able to display the messed up encodings more usefully. > I consider the proposal of log_encoding(GUC) for the purpose of ver 8.5 or > over. However, adjustment is now difficult.... much time is needed for it. > Therefore, I wish to recognize this problem as TODO. or, are there some > ideas? Only the workaround above (which I think we should consider now) :-( -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Hi. > Can we at least detect the problem and warn the user? It might be > useful to provide a 'save log' button to allow the user to save the > raw log locally for further examination using other tools. Ahh, It is useful to specify the reason which can't be displayed. > > Also, note that I suggested to Guillaume (who is working on frmStatus) > that we should replace the listview used for the log with a text > control. That may be able to display the messed up encodings more > usefully. Um, It seems that the problem can't be solved by pgAdmin. :-( == Sorry, this is japanese == HIROSHI=# SELECT pg_file_read(filename, 0, 500) FROM pg_logdir_ls() HIROSHI-# AS A(filetime timestamp, filename text) ORDER BY filetime ASC LIMIT 1; ERROR: 符号化方式"UTF8"で無効なバイトシーケンスです: 0x83 HINT: サーバが想定する符号化方式に合わないバイトシーケンスが存在した場合にもこ のエラーが発生します。これは"client_encoding"で制御されます。 HIROSHI=# > >> I consider the proposal of log_encoding(GUC) for the purpose of ver 8.5 or >> over. However, adjustment is now difficult.... much time is needed for it. >> Therefore, I wish to recognize this problem as TODO. or, are there some >> ideas? > > Only the workaround above (which I think we should consider now) :-( Yeah, I hopeful it. Thanks! Regards, Hiroshi Saito