Re: encoding aliases

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: encoding aliases
Дата
Msg-id 20060315171816.GB6135@svana.org
обсуждение исходный текст
Ответ на encoding aliases  (Vivek Khera <vivek@khera.org>)
Список pgsql-general
On Wed, Mar 15, 2006 at 11:33:25AM -0500, Vivek Khera wrote:
> We're developing a DB that will be storing email messages.  The clear
> winner for the DB encoding is UTF8.  However, I will need to set the
> proper client encoding based on the encoding as defined in the email
> message.

<snip>

Given that the messages directly encode both the encoding and the text
encoded, wouldn't make sense to store the emails in SQL_ASCII, i.e.
don't interpret the data at all, just consider it a bunch-of-bytes.

However, it seems what you're asking is as if you actually want to
interpret the content (i.e. you don't want to get out exactly what you
put in) and preserve semantics for easy searching, yes? I'm not sure
how to do that easily, since different parts of email can be in
different encodings.

To be honest, rather than relying on postgres behaviour, why not build
up a table mapping email encodings to postgres encodings. It costs
little but could save some hassle later on.

BTW, SQL-ASCII really means unknown encoding more than anything else...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Вложения

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

Предыдущее
От: Brendan Duddridge
Дата:
Сообщение: Indexes on array columns
Следующее
От: Randy Yates
Дата:
Сообщение: psqlODBC Unicode 8.01.02.00 Driver "Overflows" On MS-Access Dates