viewmail-info
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VM] searching in mime encoded email


From: Julian Bradfield
Subject: Re: [VM] searching in mime encoded email
Date: Sun, 22 Jan 2012 12:34:59 +0000
User-agent: slrn/0.9.9p1 (Linux)

On 2012-01-21, Uday Reddy <address@hidden> wrote:
> My idea is not to transcode in anything.  Just decode it to Emacs internal
> coding and leave it at that.  The folder can be saved to disk using whatever

That is transcoding...

> coding Emacs or the users chooses.  It could be an ISO coding, for instance.
> The coding used to save the folder is not VM's concern.

Only if, as you suggested, you prohibit any manipulation of the folder
file outside VM.
Suppose you use ISO2022. That's a stateful encoding, so if you have,
say, two Japanese messages in a row, if you pull out the second one by
itself from the disk file, you won't know that it's Japanese.
What will you do with win1252 messages, a character/coding set that
has no internal representation, even in the Emacs super-ISO
(ESC-quoted) coding system? You will, by necessity, transcode them to
a standard set.
Or character sets that exist, but which the Emacs installation you're
currently using doesn't happen to have defined? (For example, I don't
have the legacy Thai or Indian systems defined in my Emacs, because I
need the limited charset space for other things.)

Another trouble is that Emacs (certainly XEmacs, but I think also Emacs)
is not robust wrt character encodings. Generally, you can lose data
without being aware of it, because (de/en)coding happens so low down
that there's no easy way to return an error.
For example, half a year's worth of my non-English mail is
unrecoverably mangled by one of the many VM coding-system problems
I've fixed over the years - because I got no warning at the time that
anything was going wrong. (Now I've patched my XEmacs to at least warn
of trouble.)

>> Why no charset headers? If you're munging a mime message, you should
>> ensure that it remains a valid mime message.
> Is it not valid mime to have text/plain parts without a charset parameter?

Oh, it's valid - but a missing charset parameter MUST be treated as
us-ascii.

I'm not saying your scheme is impossible - or even difficult to do -
just that there are an awful lot of things to be very careful about.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]