perl-unicode

Re: RFC 2231 (was Re: Encode::MIME::Header...)

2002-10-09 01:30:06
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/