Обсуждение: encoding aliases

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.

Looking at the docs (http://www.postgresql.org/docs/8.1/static/
multibyte.html), there are many encodings that I can use for the
client.  However they do not match the canonical names used in
email.  For example, WINDOWS-1252 is accepted, presumably as an alias
for WIN1252, though it is not listed as an alias. The commentary in
utils/mb/encnames.c indicates that the dashes are irrelevant, so we
know ISO-8859-1 and ISO88591 are equivalent.

I've only tried a handful of encoding values found in email so far,
but the only one that is not accepted is US-ASCII.

My only concern is that names like WINDOWS-1252 is really an alias
for WIN1252.  What would make this 100% clear is if "SHOW
client_encoding" would report the canonical name rather than the name
passed to it.  The source shows it is, but the docs do not.

So, is it fair to assume that the longer form names are safe to use
(ie, should I submit a doc patch)?

And does it make sense to make US-ASCII an alias for SQL-ASCII?

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.