On Wednesday, Oct 9, 2002, at 16:15 Asia/Tokyo, Nick Ing-Simmons wrote:
But given that Encode::MIME::Header exists and is "cluttering up" my
machine's memory it is a pity it does not do a _little_ more.
You've got a point. Both Perl::Tk and Encode are huge and user would
not want yet another dependency to more modules....
Is there any volunteer to write MIME::Header ?
I need _something_ for tkmail, I can either submit patches for
existing module(s) or write Yet-Another-MIME module.
(tkmail is an interactive mail tool - as such some of existing modules
are a little sluggish when handling mailboxes of 2000 MIME messages.)
Patches welcome -- so long as it passes ext/Encode/t/mime.t (which test
strings I shamelessly copied and pasted from very RFC except for a very
longish Japanese).
There is MIME::Head
already, included in authors/id/E/ER/ERYQ/MIME-tools-5.411a but does
it
do header encoding?
No. It doesn't do body encoding either - it will give you the octets
and
you can pattern match for charset in Content-Type.
So you cannot depend on yet another huge module. Hmm....
As I said, the problem is encode()ing since decode()ing is fine already
(tell me if it is not so). To allow more granular control you need to
feed more args but that breaks the API.... wait! the Encoding thingy
under the food is just a blessed hashref we boldly call an object!
Counter-intuitive it may be, you can pass extra 'tips' to that thingy
like....
my $e = find_encoding('MIME-Header');
$e->{charset} = ISO-8859-1; # or $e->charset('ISO-8859-1') if we
define a method
my $encoded = $e->encode($str); # now uses =?ISO-8859-1?B?...
is still possible. Hmm....
At any rate patches welcome.
Dan the Man Sandwitched by Double Encoding Called MIME Header
