Re: Problem of a server gettext message. - Mailing list pgsql-hackers
From | Hiroshi Saito |
---|---|
Subject | Re: Problem of a server gettext message. |
Date | |
Msg-id | 092a01c83ba7$f5dbd060$c601a8c0@HP22720319231 Whole thread Raw |
In response to | Problem of a server gettext message. ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>) |
Responses |
Re: Problem of a server gettext message.
|
List | pgsql-hackers |
Hi Peter-san. Thank you for various. ! ----- Original Message ----- From: "Peter Eisentraut" <peter_e@gmx.net> > Am Montag, 10. Dezember 2007 schrieb Hiroshi Saito: >> Hi. >> >> From: "Peter Eisentraut" <peter_e@gmx.net> >> >> > Am Montag, 10. Dezember 2007 schrieb Hiroshi Saito: >> >> Hi Peter-san. >> >> >> >> It is this. >> >> http://winpg.jp/~saito/pg83/ja.zip >> > >> > Sorry, we need the *po* (text) files, not the *mo* (binary) files. >> >> Ooops, Although it is an object for Version 8.2.5. >> http://www.postgresql.jp/wg/jpugdoc/po/postgresql-8-2-5-nls-patch.gz > > OK, you have > > PO file in EUC-JP > server encoding UTF-8 > client encoding SJIS Yes. > > When the server wants to send an error message to the client, it will convert > them from the server to the client encoding. The English messages are ASCII, > so this will work, because server encodings are required to be ASCII > compatible. The result of the gettext calls, however, is encoded in EUC-JP, > so the server will take the EUC-JP bytes and attempt to do a UTF-8 to SJIS > conversion on them. This will cause a crash. Probably no. GetText is conversion po(EUC_JP) to SJIS. Then, The stderr output of a server is outputted without an error to log by it. That's right message with it similar to start-up. However, The conversion obstacle of a message is encountered at the time of the conditions returned to a client. Conversion of the step of the following it takes place. 1. iconv(GetText) po(EUC_JP) to SJIS. 2. message to client UTF8(server encoding) to SJIS(client encoding) But, this character that should be UTF-8 is a SJIS message(1.). It causes an error. Therefore, this log is proving. http://winpg.jp/~saito/pg83/postgresql-8.3beta4_crash.log Anyway, the current situation is it although there is a problem.. > > What you need to do is set the locale to something compatible with the server > encoding (e.g., ja_JP.utf8). Then gettext will recode its EUC-JP data to > UTF-8 before it is sent to the server. More specifically, you need to set > the LC_CTYPE locale category to make this happen. I understand that users in > Japanese environments like to keep the LC_COLLATE setting to C, and you > should still be able to do that. But without a proper LC_CTYPE setting, this > will not work. > > (That is the explanation for Linux. Windows might be different in the > details, but I suspect it has the same mechanisms.) As for message, the current state is not such.... probably.. It is the problem which arises only by the server with client encoding which can't be used as server encoding. It may be a problem of Japan... If a message text is not used by the server, a problem does not occur. Therefore, It is TODO until it has the margin of time. sorry... I'm very busy now... I am deeply grateful to you for your kindness. Regards, Hiroshi Saito
pgsql-hackers by date: