Dan Kogai <dankogai(_at_)dan(_dot_)co(_dot_)jp> writes:
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.
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).
Right ho.
As I said, the problem is encode()ing since decode()ing is fine already
(tell me if it is not so).
Decoding is fine. Indeed I recently replaced my version with
Encode::MIME::Header
because yours did a better job. The only thing I might add to decode
is to allow the closing ?= to be missing (which seems to be a common
non-compliance in some of SPAM I get). But as it is SPAM I don't really
care.
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!
It _is_ an object. :encoding knows it is an object and uses it that way.
I think the object API should be documented.
One reason for making it an object is to allow derived classes and extra
hooks.
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?...
Despite Nick C's speed comments it may make sense to allow optional args
to encode as well.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
