On Thu, 26 Jun 2008, Ricardo SIGNES wrote:
RSWow. I had never noticed this bit of HORRIBLENESS before.
Um... thanks?
RSEmail::MIME, once again, is shown to be useful for a very, very small set of
RSemail. That is, email that is not wrong; all correct email won't work
either,
RSbut this email is failing because it's not to-spec.
Yeah. (It was a forwarded Chinese spam, and to complicate things it was
probably forwarded back when Pine didn't deal with weird character sets
either. So there's a high probability even with a known encoding it could
be corrupted.)
Failing would generally be okay, but I'd like it to fail when the
Email::MIME object is created, not spring a surprise on me later. Which is
probably not feasible without an unacceptable performance hit, but I can
still want it.
RSProbably. I'm not sure if the encoding in a encoded-word needs to be in a
RSregistry somewhere, and whether X-UNKNOWN is.
It does, and it isn't. Though needs to be is flexible; you can tell
Encode what to do with it, just Encode::Unicode doesn't apparently respect
your choices.
RSHeaders *must* be encoded into a seven bit format. I have no idea what
RSunicode means as the first arg to encode, but I doubt that it's 7-bit safe.
RSYou'll want to use Encode::MIME::Header, which means you'll need to have a
RSutf-8 string first.
Oh hey, I hadn't thought of that. I'm not really sure what it means
either. Hmm. (I'm still cargo-culting this whole unicode thing. I'm going
to have to dig into how that actually works sooner or later, I've just
been hoping for, y'know, later.)
The critter needs to be unicode'd when it's stored in the database, but I
could do that on the string *after* it's Email::MIME'd.
