Database->ServerEncoding, ClientEncoding

Поиск
Список
Период
Сортировка
От Jean-Michel POURE
Тема Database->ServerEncoding, ClientEncoding
Дата
Msg-id 200202251712.g1PHCqLx004119@www1.translationforge
обсуждение исходный текст
Ответ на pgSchema Changes  (Dave Page <dpage@vale-housing.co.uk>)
Ответы Re: Database->ServerEncoding, ClientEncoding
Список pgadmin-hackers
Hi Dave,

I used pgSchema today with a Latin1 encoding hack.

Whenever a character does not exist in Latin1 (example : euro sign), an error
is returned. Obviously, this is not always the case: Japanese is transformed
in unreadable characters without error.

My impression is that client encoding is not ***very** secure. A full unicode
chain is a better solution. But we need Client encoding support as it offers
a wide variety of encodings ... and is compatible with VB.

Maybe we could start modifying pgSchema->Databases and pgSchema->pgDatabase.
What would you think if we :
- renamed EncodingName into ServerEncoding,
- added ClientEncoding.

Then, in frmSQLInput, we would add a combo to choose the encoding needed.

This will allow me to view UTF-8 data in Latin1 and export it in UTF-8. Isn't
it marvelous?

Cheers,
Jean-Michel

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

Предыдущее
От: Dave Page
Дата:
Сообщение: pgSchema Changes
Следующее
От: Jean-Michel POURE
Дата:
Сообщение: Re: pgAdmin2 Japanese display