Re: Problem of a server gettext message.

Поиск
Список
Период
Сортировка
От Hiroshi Saito
Тема Re: Problem of a server gettext message.
Дата
Msg-id 015501c83c6b$6ce62b10$c601a8c0@HP22720319231
обсуждение исходный текст
Ответ на Problem of a server gettext message.  ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>)
Список pgsql-hackers
Hi.

Yeah, As a part from which a problem happens, it is your suggestion.

This is only the check. 
http://winpg.jp/~saito/pg83/message_check/gtext2.c
Therefore, a message needed is acquirable in the next operation.
gtext2 C UTF-8
http://winpg.jp/~saito/pg83/message_check/codeset_utf8_msg.txt
gtext2 C EUC_JP
http://winpg.jp/~saito/pg83/message_check/codeset_eucjp_msg.txt

However, The check of accuracy is not settled yet. If all server encodings 
are possible, I will want to work. But but, It is not desirable that more 
encodings are intermingled as a log message.... Then, here is no still good 
method. Furthermore, a good solution plan is desired. probably..

Thanks!

Regards,
Hiroshi Saito

----- Original Message ----- 
From: "Zeugswetter Andreas ADI SD" <Andreas.Zeugswetter@s-itsolutions.at>

> > GetText is conversion po(EUC_JP) to SJIS.

Yes.

> Are you sure about that?  Why would gettext be converting to SJIS,
when
> SJIS is nowhere in the environment it can see?

gettext is using GetACP () on Windows, wherever that gets it's info from
...
"chcp" did change the GetACP codepage in Hiroshi's example, but chcp
does not reflect in LC_*

Seems we may want to use bind_textdomain_codeset.

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: [hensa22@yahoo.es: Re: [pgsql-es-ayuda] SLL error 100% cpu]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [hensa22@yahoo.es: Re: [pgsql-es-ayuda] SLL error 100% cpu]