| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> |
| Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Problem of a server gettext message. |
| Date: | 2007-12-11 03:53:52 |
| Message-ID: | 27688.1197345232@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> writes:
> 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.
Are you sure about that? Why would gettext be converting to SJIS, when
SJIS is nowhere in the environment it can see? I believe that Peter's
hypothesis is that gettext is leaving the string in EUC_JP because
it sees locale = C and so has no basis for doing any conversion.
We still end up with a failure, because the basic problem is that the
string isn't UTF8, but it's important to be sure we understand the exact
mechanism.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2007-12-11 04:08:31 | Re: Release Note Changes |
| Previous Message | Hiroshi Saito | 2007-12-11 03:43:14 | Re: Problem of a server gettext message. |