Devil Killer Is Here MiNi Shell
MiNi SheLL

Current Path : /proc/thread-self/root/usr/local/man/man3/
Linux boscustweb5004.eigbox.net 5.4.91 #1 SMP Wed Jan 20 18:10:28 EST 2021 x86_64
Current File : //proc/thread-self/root/usr/local/man/man3/MIME::Entity.3
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.32
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  | will give a
.\" real vertical bar.  \*(C+ will give a nicer C++.  Capital omega is used to
.\" do unbreakable dashes and therefore won't be available.  \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.tr \(*W-|\(bv\*(Tr
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
.    de IX
.    tm Index:\\$1\t\\n%\t"\\$2"
..
.    nr % 0
.    rr F
.\}
.\"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
.    \" fudge factors for nroff and troff
.if n \{\
.    ds #H 0
.    ds #V .8m
.    ds #F .3m
.    ds #[ \f1
.    ds #] \fP
.\}
.if t \{\
.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
.    ds #V .6m
.    ds #F 0
.    ds #[ \&
.    ds #] \&
.\}
.    \" simple accents for nroff and troff
.if n \{\
.    ds ' \&
.    ds ` \&
.    ds ^ \&
.    ds , \&
.    ds ~ ~
.    ds /
.\}
.if t \{\
.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
.    \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
.    \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
.    \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
.    ds : e
.    ds 8 ss
.    ds o a
.    ds d- d\h'-1'\(ga
.    ds D- D\h'-1'\(hy
.    ds th \o'bp'
.    ds Th \o'LP'
.    ds ae ae
.    ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "MIME::Entity 3"
.TH MIME::Entity 3 "2006-03-17" "perl v5.8.8" "User Contributed Perl Documentation"
.SH "NAME"
MIME::Entity \- class for parsed\-and\-decoded MIME message
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
Before reading further, you should see MIME::Tools to make sure that 
you understand where this module fits into the grand scheme of things.
Go on, do it now.  I'll wait.
.PP
Ready?  Ok...
.PP
.Vb 5
\&    ### Create an entity:
\&    $top = MIME::Entity->build(From    => 'me@myhost.com',
\&                               To      => 'you@yourhost.com',
\&                               Subject => "Hello, nurse!",
\&                               Data    => \e@my_message);
.Ve
.PP
.Vb 4
\&    ### Attach stuff to it:
\&    $top->attach(Path     => $gif_path,
\&                 Type     => "image/gif",
\&                 Encoding => "base64");
.Ve
.PP
.Vb 2
\&    ### Sign it:
\&    $top->sign;
.Ve
.PP
.Vb 2
\&    ### Output it:
\&    $top->print(\e*STDOUT);
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
A subclass of \fBMail::Internet\fR.
.PP
This package provides a class for representing \s-1MIME\s0 message entities,
as specified in \s-1RFC\s0 1521, \fIMultipurpose Internet Mail Extensions\fR.
.SH "EXAMPLES"
.IX Header "EXAMPLES"
.Sh "Construction examples"
.IX Subsection "Construction examples"
Create a document for an ordinary 7\-bit \s-1ASCII\s0 text file (lots of 
stuff is defaulted for us):
.PP
.Vb 1
\&    $ent = MIME::Entity->build(Path=>"english-msg.txt");
.Ve
.PP
Create a document for a text file with 8\-bit (Latin\-1) characters:
.PP
.Vb 4
\&    $ent = MIME::Entity->build(Path     =>"french-msg.txt",
\&                               Encoding =>"quoted-printable",
\&                               From     =>'jean.luc@inria.fr',
\&                               Subject  =>"C'est bon!");
.Ve
.PP
Create a document for a \s-1GIF\s0 file (the description is completely optional;
note that we have to specify content-type and encoding since they're
not the default values):
.PP
.Vb 4
\&    $ent = MIME::Entity->build(Description => "A pretty picture",
\&                               Path        => "./docs/mime-sm.gif",
\&                               Type        => "image/gif",
\&                               Encoding    => "base64");
.Ve
.PP
Create a document that you already have the text for, using \*(L"Data\*(R":
.PP
.Vb 5
\&    $ent = MIME::Entity->build(Type        => "text/plain",
\&                               Encoding    => "quoted-printable",
\&                               Data        => ["First line.\en",
\&                                              "Second line.\en",
\&                                              "Last line.\en"]);
.Ve
.PP
Create a multipart message, with the entire structure given
explicitly:
.PP
.Vb 5
\&    ### Create the top-level, and set up the mail headers:
\&    $top = MIME::Entity->build(Type     => "multipart/mixed",
\&                               From     => 'me@myhost.com',
\&                               To       => 'you@yourhost.com',
\&                               Subject  => "Hello, nurse!");
.Ve
.PP
.Vb 2
\&    ### Attachment #1: a simple text document: 
\&    $top->attach(Path=>"./testin/short.txt");
.Ve
.PP
.Vb 4
\&    ### Attachment #2: a GIF file:
\&    $top->attach(Path        => "./docs/mime-sm.gif",
\&                 Type        => "image/gif",
\&                 Encoding    => "base64");
.Ve
.PP
.Vb 2
\&    ### Attachment #3: text we'll create with text we have on-hand:
\&    $top->attach(Data => $contents);
.Ve
.PP
Suppose you don't know ahead of time that you'll have attachments?
No problem: you can \*(L"attach\*(R" to singleparts as well:
.PP
.Vb 8
\&    $top = MIME::Entity->build(From    => 'me@myhost.com',
\&                               To      => 'you@yourhost.com',
\&                               Subject => "Hello, nurse!",
\&                               Data    => \e@my_message);
\&    if ($GIF_path) { 
\&        $top->attach(Path     => $GIF_path,
\&                     Type     => 'image/gif');
\&    }
.Ve
.PP
Copy an entity (headers, parts... everything but external body data):
.PP
.Vb 1
\&    my $deepcopy = $top->dup;
.Ve
.Sh "Access examples"
.IX Subsection "Access examples"
.Vb 2
\&    ### Get the head, a MIME::Head:
\&    $head = $ent->head;
.Ve
.PP
.Vb 2
\&    ### Get the body, as a MIME::Body;
\&    $bodyh = $ent->bodyhandle;
.Ve
.PP
.Vb 2
\&    ### Get the intended MIME type (as declared in the header):
\&    $type = $ent->mime_type;
.Ve
.PP
.Vb 2
\&    ### Get the effective MIME type (in case decoding failed):
\&    $eff_type = $ent->effective_type;
.Ve
.PP
.Vb 5
\&    ### Get preamble, parts, and epilogue:
\&    $preamble   = $ent->preamble;          ### ref to array of lines
\&    $num_parts  = $ent->parts;
\&    $first_part = $ent->parts(0);          ### an entity
\&    $epilogue   = $ent->epilogue;          ### ref to array of lines
.Ve
.Sh "Manipulation examples"
.IX Subsection "Manipulation examples"
Muck about with the body data:
.PP
.Vb 5
\&    ### Read the (unencoded) body data:
\&    if ($io = $ent->open("r")) {
\&        while (defined($_ = $io->getline)) { print $_ }
\&        $io->close;
\&    }
.Ve
.PP
.Vb 5
\&    ### Write the (unencoded) body data:
\&    if ($io = $ent->open("w")) {
\&        foreach (@lines) { $io->print($_) }
\&        $io->close;
\&    }
.Ve
.PP
.Vb 2
\&    ### Delete the files for any external (on-disk) data:
\&    $ent->purge;
.Ve
.PP
Muck about with the signature:
.PP
.Vb 2
\&    ### Sign it (automatically removes any existing signature):
\&    $top->sign(File=>"$ENV{HOME}/.signature");
.Ve
.PP
.Vb 2
\&    ### Remove any signature within 15 lines of the end:
\&    $top->remove_sig(15);
.Ve
.PP
Muck about with the headers:
.PP
.Vb 3
\&    ### Compute content-lengths for singleparts based on bodies:
\&    ###   (Do this right before you print!)
\&    $entity->sync_headers(Length=>'COMPUTE');
.Ve
.PP
Muck about with the structure:
.PP
.Vb 2
\&    ### If a 0- or 1-part multipart, collapse to a singlepart:
\&    $top->make_singlepart;
.Ve
.PP
.Vb 2
\&    ### If a singlepart, inflate to a multipart with 1 part:
\&    $top->make_multipart;
.Ve
.PP
Delete parts:
.PP
.Vb 3
\&    ### Delete some parts of a multipart message:
\&    my @keep = grep { keep_part($_) } $msg->parts;
\&    $msg->parts(\e@keep);
.Ve
.Sh "Output examples"
.IX Subsection "Output examples"
Print to filehandles:
.PP
.Vb 2
\&    ### Print the entire message:
\&    $top->print(\e*STDOUT);
.Ve
.PP
.Vb 2
\&    ### Print just the header:
\&    $top->print_header(\e*STDOUT);
.Ve
.PP
.Vb 2
\&    ### Print just the (encoded) body... includes parts as well!
\&    $top->print_body(\e*STDOUT);
.Ve
.PP
Stringify... note that \f(CW\*(C`stringify_xx\*(C'\fR can also be written \f(CW\*(C`xx_as_string\*(C'\fR;
the methods are synonymous, and neither form will be deprecated:
.PP
.Vb 2
\&    ### Stringify the entire message:
\&    print $top->stringify;              ### or $top->as_string
.Ve
.PP
.Vb 2
\&    ### Stringify just the header:
\&    print $top->stringify_header;       ### or $top->header_as_string
.Ve
.PP
.Vb 2
\&    ### Stringify just the (encoded) body... includes parts as well!
\&    print $top->stringify_body;         ### or $top->body_as_string
.Ve
.PP
Debug:
.PP
.Vb 2
\&    ### Output debugging info:
\&    $entity->dump_skeleton(\e*STDERR);
.Ve
.SH "PUBLIC INTERFACE"
.IX Header "PUBLIC INTERFACE"
.Sh "Construction"
.IX Subsection "Construction"
.IP "new [\s-1SOURCE\s0]" 4
.IX Item "new [SOURCE]"
\&\fIClass method.\fR
Create a new, empty \s-1MIME\s0 entity.
Basically, this uses the Mail::Internet constructor...
.Sp
If \s-1SOURCE\s0 is an \s-1ARRAYREF\s0, it is assumed to be an array of lines
that will be used to create both the header and an in-core body.
.Sp
Else, if \s-1SOURCE\s0 is defined, it is assumed to be a filehandle
from which the header and in-core body is to be read. 
.Sp
\&\fBNote:\fR in either case, the body will not be \fIparsed:\fR merely read!
.IP "add_part \s-1ENTITY\s0, [\s-1OFFSET\s0]" 4
.IX Item "add_part ENTITY, [OFFSET]"
\&\fIInstance method.\fR
Assuming we are a multipart message, add a body part (a MIME::Entity)
to the array of body parts.  Returns the part that was just added.
.Sp
If \s-1OFFSET\s0 is positive, the new part is added at that offset from the
beginning of the array of parts.  If it is negative, it counts from
the end of the array.  (An \s-1INDEX\s0 of \-1 will place the new part at the
very end of the array, \-2 will place it as the penultimate item in the
array, etc.)  If \s-1OFFSET\s0 is not given, the new part is added to the end
of the array.
\&\fIThanks to Jason L Tibbitts \s-1III\s0 for providing support for \s-1OFFSET\s0.\fR
.Sp
\&\fBWarning:\fR in general, you only want to attach parts to entities
with a content-type of \f(CW\*(C`multipart/*\*(C'\fR).
.IP "attach \s-1PARAMHASH\s0" 4
.IX Item "attach PARAMHASH"
\&\fIInstance method.\fR
The real quick-and-easy way to create multipart messages.
The \s-1PARAMHASH\s0 is used to \f(CW\*(C`build\*(C'\fR a new entity; this method is
basically equivalent to:
.Sp
.Vb 1
\&    $entity->add_part(ref($entity)->build(PARAMHASH, Top=>0));
.Ve
.Sp
\&\fBNote:\fR normally, you attach to multipart entities; however, if you 
attach something to a singlepart (like attaching a \s-1GIF\s0 to a text
message), the singlepart will be coerced into a multipart automatically.
.IP "build \s-1PARAMHASH\s0" 4
.IX Item "build PARAMHASH"
\&\fIClass/instance method.\fR
A quick-and-easy catch-all way to create an entity.  Use it like this
to build a \*(L"normal\*(R" single-part entity:
.Sp
.Vb 5
\&   $ent = MIME::Entity->build(Type     => "image/gif",
\&                              Encoding => "base64",
\&                              Path     => "/path/to/xyz12345.gif",
\&                              Filename => "saveme.gif",
\&                              Disposition => "attachment");
.Ve
.Sp
And like this to build a \*(L"multipart\*(R" entity:
.Sp
.Vb 2
\&   $ent = MIME::Entity->build(Type     => "multipart/mixed",
\&                              Boundary => "---1234567");
.Ve
.Sp
A minimal \s-1MIME\s0 header will be created.  If you want to add or modify
any header fields afterwards, you can of course do so via the underlying 
head object... but hey, there's now a prettier syntax!
.Sp
.Vb 6
\&   $ent = MIME::Entity->build(Type          =>"multipart/mixed",
\&                              From          => $myaddr,
\&                              Subject       => "Hi!",
\&                              'X-Certified' => ['SINED',
\&                                                'SEELED',
\&                                                'DELIVERED']);
.Ve
.Sp
Normally, an \f(CW\*(C`X\-Mailer\*(C'\fR header field is output which contains this 
toolkit's name and version (plus this module's \s-1RCS\s0 version).
This will allow any bad \s-1MIME\s0 we generate to be traced back to us.
You can of course overwrite that header with your own:
.Sp
.Vb 2
\&   $ent = MIME::Entity->build(Type        => "multipart/mixed",
\&                              'X-Mailer'  => "myprog 1.1");
.Ve
.Sp
Or remove it entirely:
.Sp
.Vb 2
\&   $ent = MIME::Entity->build(Type       => "multipart/mixed",
\&                              'X-Mailer' => undef);
.Ve
.Sp
\&\s-1OK\s0, enough hype.  The parameters are:
.RS 4
.IP "(\s-1FIELDNAME\s0)" 4
.IX Item "(FIELDNAME)"
Any field you want placed in the message header, taken from the
standard list of header fields (you don't need to worry about case):
.Sp
.Vb 6
\&    Bcc           Encrypted     Received      Sender         
\&    Cc            From          References    Subject 
\&    Comments      Keywords      Reply-To      To 
\&    Content-*     Message-ID    Resent-*      X-*
\&    Date          MIME-Version  Return-Path   
\&                  Organization
.Ve
.Sp
To give experienced users some veto power, these fields will be set 
\&\fIafter\fR the ones I set... so be careful: \fIdon't set any \s-1MIME\s0 fields\fR
(like \f(CW\*(C`Content\-type\*(C'\fR) unless you know what you're doing!
.Sp
To specify a fieldname that's \fInot\fR in the above list, even one that's
identical to an option below, just give it with a trailing \f(CW":"\fR,
like \f(CW"My\-field:"\fR.  When in doubt, that \fIalways\fR signals a mail 
field (and it sort of looks like one too).
.IP "Boundary" 4
.IX Item "Boundary"
\&\fIMultipart entities only. Optional.\fR  
The boundary string.  As per \s-1RFC\-1521\s0, it must consist only
of the characters \f(CW\*(C`[0\-9a\-zA\-Z'()+_,\-./:=?]\*(C'\fR and space (you'll be
warned, and your boundary will be ignored, if this is not the case).
If you omit this, a random string will be chosen... which is probably 
safer.
.IP "Charset" 4
.IX Item "Charset"
\&\fIOptional.\fR  
The character set.
.IP "Data" 4
.IX Item "Data"
\&\fISingle-part entities only. Optional.\fR  
An alternative to Path (q.v.): the actual data, either as a scalar
or an array reference (whose elements are joined together to make
the actual scalar).  The body is opened on the data using 
MIME::Body::InCore.
.IP "Description" 4
.IX Item "Description"
\&\fIOptional.\fR  
The text of the content\-description.  
If you don't specify it, the field is not put in the header.
.IP "Disposition" 4
.IX Item "Disposition"
\&\fIOptional.\fR  
The basic content-disposition (\f(CW"attachment"\fR or \f(CW"inline"\fR).
If you don't specify it, it defaults to \*(L"inline\*(R" for backwards
compatibility.  \fIThanks to Kurt Freytag for suggesting this feature.\fR
.IP "Encoding" 4
.IX Item "Encoding"
\&\fIOptional.\fR  
The content\-transfer\-encoding.
If you don't specify it, a reasonable default is put in.
You can also give the special value '\-SUGGEST', to have it chosen for 
you in a heavy-duty fashion which scans the data itself.
.IP "Filename" 4
.IX Item "Filename"
\&\fISingle-part entities only. Optional.\fR  
The recommended filename.  Overrides any name extracted from \f(CW\*(C`Path\*(C'\fR.
The information is stored both the deprecated (content\-type) and
preferred (content\-disposition) locations.  If you explicitly want to 
\&\fIavoid\fR a recommended filename (even when Path is used), supply this 
as empty or undef.
.IP "Id" 4
.IX Item "Id"
\&\fIOptional.\fR
Set the content\-id.
.IP "Path" 4
.IX Item "Path"
\&\fISingle-part entities only. Optional.\fR  
The path to the file to attach.  The body is opened on that file
using MIME::Body::File.
.IP "Top" 4
.IX Item "Top"
\&\fIOptional.\fR  
Is this a top-level entity?  If so, it must sport a MIME\-Version.
The default is true.  (\s-1NB:\s0 look at how \f(CW\*(C`attach()\*(C'\fR uses it.)
.IP "Type" 4
.IX Item "Type"
\&\fIOptional.\fR  
The basic content-type (\f(CW"text/plain"\fR, etc.). 
If you don't specify it, it defaults to \f(CW"text/plain"\fR 
as per \s-1RFC\-1521\s0.  \fIDo yourself a favor: put it in.\fR
.RE
.RS 4
.RE
.IP "dup" 4
.IX Item "dup"
\&\fIInstance method.\fR 
Duplicate the entity.  Does a deep, recursive copy, \fIbut beware:\fR
external data in bodyhandles is \fInot\fR copied to new files!  
Changing the data in one entity's data file, or purging that entity, 
\&\fIwill\fR affect its duplicate.  Entities with in-core data probably need
not worry.
.Sh "Access"
.IX Subsection "Access"
.IP "body [\s-1VALUE\s0]" 4
.IX Item "body [VALUE]"
\&\fIInstance method.\fR
Get the \fIencoded\fR (transport\-ready) body, as an array of lines. 
This is a read-only data structure: changing its contents will have 
no effect.  Its contents are identical to what is printed by 
\&\fIprint_body()\fR.
.Sp
Provided for compatibility with Mail::Internet, so that methods
like \f(CW\*(C`smtpsend()\*(C'\fR will work.  Note however that if \s-1VALUE\s0 is given, 
a fatal exception is thrown, since you cannot use this method to 
\&\fIset\fR the lines of the encoded message.  
.Sp
If you want the raw (unencoded) body data, use the \fIbodyhandle()\fR
method to get and use a MIME::Body.  The content-type of the entity
will tell you whether that body is best read as text (via \fIgetline()\fR)
or raw data (via \fIread()\fR).
.IP "bodyhandle [\s-1VALUE\s0]" 4
.IX Item "bodyhandle [VALUE]"
\&\fIInstance method.\fR
Get or set an abstract object representing the body of the message.
The body holds the decoded message data.
.Sp
\&\fBNote that not all entities have bodies!\fR
An entity will have either a body or parts: not both.
This method will \fIonly\fR return an object if this entity can 
have a body; otherwise, it will return undefined. 
Whether-or-not a given entity can have a body is determined by 
(1) its content type, and (2) whether-or-not the parser was told to 
extract nested messages:
.Sp
.Vb 6
\&    Type:        | Extract nested? | bodyhandle() | parts()
\&    -----------------------------------------------------------------------
\&    multipart/*  | -               | undef        | 0 or more MIME::Entity
\&    message/*    | true            | undef        | 0 or 1 MIME::Entity
\&    message/*    | false           | MIME::Body   | empty list
\&    (other)      | -               | MIME::Body   | empty list
.Ve
.Sp
If \f(CW\*(C`VALUE\*(C'\fR \fIis not\fR given, the current bodyhandle is returned,
or undef if the entity cannot have a body.
.Sp
If \f(CW\*(C`VALUE\*(C'\fR \fIis\fR given, the bodyhandle is set to the new value,
and the previous value is returned.
.Sp
See \*(L"parts\*(R" for more info.
.IP "effective_type [\s-1MIMETYPE\s0]" 4
.IX Item "effective_type [MIMETYPE]"
\&\fIInstance method.\fR
Set/get the \fIeffective\fR \s-1MIME\s0 type of this entity.  This is \fIusually\fR
identical to the actual (or defaulted) \s-1MIME\s0 type, but in some cases 
it differs.  For example, from \s-1RFC\-2045:\s0
.Sp
.Vb 3
\&   Any entity with an unrecognized Content-Transfer-Encoding must be
\&   treated as if it has a Content-Type of "application/octet-stream",
\&   regardless of what the Content-Type header field actually says.
.Ve
.Sp
Why? because if we can't decode the message, then we have to take
the bytes as\-is, in their (unrecognized) encoded form.  So the
message ceases to be a \*(L"text/foobar\*(R" and becomes a bunch of undecipherable
bytes \*(-- in other words, an \*(L"application/octet\-stream\*(R".
.Sp
Such an entity, if parsed, would have its \fIeffective_type()\fR set to
\&\f(CW"application/octet_stream"\fR, although the \fImime_type()\fR and the contents 
of the header would remain the same.
.Sp
If there is no effective type, the method just returns what 
\&\fImime_type()\fR would.
.Sp
\&\fBWarning:\fR the effective type is \*(L"sticky\*(R"; once set, that \fIeffective_type()\fR
will always be returned even if the conditions that necessitated setting
the effective type become no longer true.
.IP "epilogue [\s-1LINES\s0]" 4
.IX Item "epilogue [LINES]"
\&\fIInstance method.\fR
Get/set the text of the epilogue, as an array of newline-terminated \s-1LINES\s0.
Returns a reference to the array of lines, or undef if no epilogue exists.
.Sp
If there is a epilogue, it is output when printing this entity; otherwise,
a default epilogue is used.  Setting the epilogue to undef (not []!) causes 
it to fallback to the default.
.IP "head [\s-1VALUE\s0]" 4
.IX Item "head [VALUE]"
\&\fIInstance method.\fR
Get/set the head. 
.Sp
If there is no \s-1VALUE\s0 given, returns the current head.  If none
exists, an empty instance of MIME::Head is created, set, and returned.
.Sp
\&\fBNote:\fR This is a patch over a problem in Mail::Internet, which doesn't 
provide a method for setting the head to some given object.
.IP "is_multipart" 4
.IX Item "is_multipart"
\&\fIInstance method.\fR
Does this entity's effective \s-1MIME\s0 type indicate that it's a multipart entity?
Returns undef (false) if the answer couldn't be determined, 0 (false)
if it was determined to be false, and true otherwise.
Note that this says nothing about whether or not parts were extracted.
.Sp
\&\s-1NOTE:\s0 we switched to effective_type so that multiparts with 
bad or missing boundaries could be coerced to an effective type
of \f(CW\*(C`application/x\-unparseable\-multipart\*(C'\fR.
.IP "mime_type" 4
.IX Item "mime_type"
\&\fIInstance method.\fR
A purely-for-convenience method.  This simply relays the request to the 
associated MIME::Head object. 
If there is no head, returns undef in a scalar context and
the empty array in a list context.
.Sp
\&\fBBefore you use this,\fR consider using \fIeffective_type()\fR instead,
especially if you obtained the entity from a MIME::Parser.
.IP "open \s-1READWRITE\s0" 4
.IX Item "open READWRITE"
\&\fIInstance method.\fR
A purely-for-convenience method.  This simply relays the request to the 
associated MIME::Body object (see \fIMIME::Body::open()\fR). 
\&\s-1READWRITE\s0 is either 'r' (open for read) or 'w' (open for write).
.Sp
If there is no body, returns false.
.IP "parts" 4
.IX Item "parts"
.PD 0
.IP "parts \s-1INDEX\s0" 4
.IX Item "parts INDEX"
.IP "parts \s-1ARRAYREF\s0" 4
.IX Item "parts ARRAYREF"
.PD
\&\fIInstance method.\fR
Return the MIME::Entity objects which are the sub parts of this
entity (if any).
.Sp
\&\fIIf no argument is given,\fR returns the array of all sub parts, 
returning the empty array if there are none (e.g., if this is a single 
part message, or a degenerate multipart).  In a scalar context, this 
returns you the number of parts.
.Sp
\&\fIIf an integer \s-1INDEX\s0 is given,\fR return the INDEXed part, 
or undef if it doesn't exist.
.Sp
\&\fIIf an \s-1ARRAYREF\s0 to an array of parts is given,\fR then this method \fIsets\fR 
the parts to a copy of that array, and returns the parts.  This can
be used to delete parts, as follows:
.Sp
.Vb 2
\&    ### Delete some parts of a multipart message:
\&    $msg->parts([ grep { keep_part($_) } $msg->parts ]);
.Ve
.Sp
\&\fBNote:\fR for multipart messages, the preamble and epilogue are \fInot\fR 
considered parts.  If you need them, use the \f(CW\*(C`preamble()\*(C'\fR and \f(CW\*(C`epilogue()\*(C'\fR 
methods.
.Sp
\&\fBNote:\fR there are ways of parsing with a MIME::Parser which cause
certain message parts (such as those of type \f(CW\*(C`message/rfc822\*(C'\fR)
to be \*(L"reparsed\*(R" into pseudo-multipart entities.  You should read the
documentation for those options carefully: it \fIis\fR possible for
a diddled entity to not be multipart, but still have parts attached to it! 
.Sp
See \*(L"bodyhandle\*(R" for a discussion of parts vs. bodies.
.IP "parts_DFS" 4
.IX Item "parts_DFS"
\&\fIInstance method.\fR
Return the list of all MIME::Entity objects included in the entity,
starting with the entity itself, in depth-first-search order.  
If the entity has no parts, it alone will be returned.
.Sp
\&\fIThanks to Xavier Armengou for suggesting this method.\fR
.IP "preamble [\s-1LINES\s0]" 4
.IX Item "preamble [LINES]"
\&\fIInstance method.\fR
Get/set the text of the preamble, as an array of newline-terminated \s-1LINES\s0.
Returns a reference to the array of lines, or undef if no preamble exists
(e.g., if this is a single-part entity).
.Sp
If there is a preamble, it is output when printing this entity; otherwise,
a default preamble is used.  Setting the preamble to undef (not []!) causes 
it to fallback to the default.
.Sh "Manipulation"
.IX Subsection "Manipulation"
.IP "make_multipart [\s-1SUBTYPE\s0], \s-1OPTSHASH\s0..." 4
.IX Item "make_multipart [SUBTYPE], OPTSHASH..."
\&\fIInstance method.\fR
Force the entity to be a multipart, if it isn't already.
We do this by replacing the original [singlepart] entity with a new
multipart that has the same non-MIME headers (\*(L"From\*(R", \*(L"Subject\*(R", etc.),
but all-new \s-1MIME\s0 headers (\*(L"Content\-type\*(R", etc.).  We then create
a copy of the original singlepart, \fIstrip out\fR the non-MIME headers
from that, and make it a part of the new multipart.  So this:
.Sp
.Vb 4
\&    From: me
\&    To: you
\&    Content-type: text/plain
\&    Content-length: 12
.Ve
.Sp
.Vb 1
\&    Hello there!
.Ve
.Sp
Becomes something like this:
.Sp
.Vb 3
\&    From: me
\&    To: you
\&    Content-type: multipart/mixed; boundary="----abc----"
.Ve
.Sp
.Vb 3
\&    ------abc----
\&    Content-type: text/plain
\&    Content-length: 12
.Ve
.Sp
.Vb 2
\&    Hello there!
\&    ------abc------
.Ve
.Sp
The actual type of the new top-level multipart will be \*(L"multipart/SUBTYPE\*(R" 
(default \s-1SUBTYPE\s0 is \*(L"mixed\*(R").
.Sp
Returns '\s-1DONE\s0'    if we really did inflate a singlepart to a multipart.
Returns '\s-1ALREADY\s0' (and does nothing) if entity is \fIalready\fR multipart
and Force was not chosen.
.Sp
If \s-1OPTSHASH\s0 contains Force=>1, then we \fIalways\fR bump the top\-level's
content and content-headers down to a subpart of this entity, even if 
this entity is already a multipart.  This is apparently of use to 
people who are tweaking messages after parsing them.
.IP "make_singlepart" 4
.IX Item "make_singlepart"
\&\fIInstance method.\fR
If the entity is a multipart message with one part, this tries hard to
rewrite it as a singlepart, by replacing the content (and content headers)
of the top level with those of the part.  Also crunches 0\-part multiparts
into singleparts.
.Sp
Returns '\s-1DONE\s0'    if we really did collapse a multipart to a singlepart.
Returns '\s-1ALREADY\s0' (and does nothing) if entity is already a singlepart. 
Returns '0'       (and does nothing) if it can't be made into a singlepart.
.IP "purge" 4
.IX Item "purge"
\&\fIInstance method.\fR
Recursively purge (e.g., unlink) all external (e.g., on\-disk) body parts 
in this message.  See \fIMIME::Body::purge()\fR for details.
.Sp
\&\fBNote:\fR this does \fInot\fR delete the directories that those body parts
are contained in; only the actual message data files are deleted.
This is because some parsers may be customized to create intermediate
directories while others are not, and it's impossible for this class
to know what directories are safe to remove.  Only your application
program truly knows that.
.Sp
\&\fBIf you really want to \*(L"clean everything up\*(R",\fR one good way is to
use \f(CW\*(C`MIME::Parser::file_under()\*(C'\fR, and then do this before parsing
your next message:
.Sp
.Vb 1
\&    $parser->filer->purge();
.Ve
.Sp
I wouldn't attempt to read those body files after you do this, for
obvious reasons.  As of MIME-tools 4.x, each body's path \fIis\fR undefined
after this operation.  I warned you I might do this; truly I did.
.Sp
\&\fIThanks to Jason L. Tibbitts \s-1III\s0 for suggesting this method.\fR
.IP "remove_sig [\s-1NLINES\s0]" 4
.IX Item "remove_sig [NLINES]"
\&\fIInstance method, override.\fR
Attempts to remove a user's signature from the body of a message. 
.Sp
It does this by looking for a line matching \f(CW\*(C`/^\-\- $/\*(C'\fR within the last 
\&\f(CW\*(C`NLINES\*(C'\fR of the message.  If found then that line and all lines after 
it will be removed. If \f(CW\*(C`NLINES\*(C'\fR is not given, a default value of 10 
will be used.  This would be of most use in auto-reply scripts.
.Sp
For \s-1MIME\s0 entity, this method is reasonably cautious: it will only
attempt to un-sign a message with a content-type of \f(CW\*(C`text/*\*(C'\fR.
.Sp
If you send \fIremove_sig()\fR to a multipart entity, it will relay it to 
the first part (the others usually being the \*(L"attachments\*(R").
.Sp
\&\fBWarning:\fR currently slurps the whole message-part into core as an
array of lines, so you probably don't want to use this on extremely 
long messages.
.Sp
Returns truth on success, false on error.
.IP "sign \s-1PARAMHASH\s0" 4
.IX Item "sign PARAMHASH"
\&\fIInstance method, override.\fR
Append a signature to the message.  The params are:
.RS 4
.IP "Attach" 4
.IX Item "Attach"
Instead of appending the text, add it to the message as an attachment.
The disposition will be \f(CW\*(C`inline\*(C'\fR, and the description will indicate
that it is a signature.  The default behavior is to append the signature 
to the text of the message (or the text of its first part if multipart).
\&\fIMIME\-specific; new in this subclass.\fR
.IP "File" 4
.IX Item "File"
Use the contents of this file as the signature.  
Fatal error if it can't be read.
\&\fIAs per superclass method.\fR
.IP "Force" 4
.IX Item "Force"
Sign it even if the content-type isn't \f(CW\*(C`text/*\*(C'\fR.  Useful for
non-standard types like \f(CW\*(C`x\-foobar\*(C'\fR, but be careful!
\&\fIMIME\-specific; new in this subclass.\fR
.IP "Remove" 4
.IX Item "Remove"
Normally, we attempt to strip out any existing signature.
If true, this gives us the \s-1NLINES\s0 parameter of the remove_sig call.
If zero but defined, tells us \fInot\fR to remove any existing signature.
If undefined, removal is done with the default of 10 lines.
\&\fINew in this subclass.\fR
.IP "Signature" 4
.IX Item "Signature"
Use this text as the signature.  You can supply it as either
a scalar, or as a ref to an array of newline-terminated scalars.
\&\fIAs per superclass method.\fR
.RE
.RS 4
.Sp
For \s-1MIME\s0 messages, this method is reasonably cautious: it will only
attempt to sign a message with a content-type of \f(CW\*(C`text/*\*(C'\fR, unless
\&\f(CW\*(C`Force\*(C'\fR is specified.
.Sp
If you send this message to a multipart entity, it will relay it to 
the first part (the others usually being the \*(L"attachments\*(R").
.Sp
\&\fBWarning:\fR currently slurps the whole message-part into core as an
array of lines, so you probably don't want to use this on extremely 
long messages.
.Sp
Returns true on success, false otherwise.
.RE
.IP "suggest_encoding" 4
.IX Item "suggest_encoding"
\&\fIInstance method.\fR
Based on the effective content type, return a good suggested encoding.
.Sp
\&\f(CW\*(C`text\*(C'\fR and \f(CW\*(C`message\*(C'\fR types have their bodies scanned line-by-line
for 8\-bit characters and long lines; lack of either means that the
message is 7bit\-ok.  Other types are chosen independent of their body:
.Sp
.Vb 8
\&    Major type:      7bit ok?    Suggested encoding:
\&    -----------------------------------------------------------
\&    text             yes         7bit
\&    text             no          quoted-printable    
\&    message          yes         7bit
\&    message          no          binary    
\&    multipart        *           binary (in case some parts are bad)
\&    image, etc...    *           base64
.Ve
.IP "sync_headers \s-1OPTIONS\s0" 4
.IX Item "sync_headers OPTIONS"
\&\fIInstance method.\fR
This method does a variety of activities which ensure that
the \s-1MIME\s0 headers of an entity \*(L"tree\*(R" are in-synch with the body parts 
they describe.  It can be as expensive an operation as printing
if it involves pre-encoding the body parts; however, the aim is to
produce fairly clean \s-1MIME\s0.  \fBYou will usually only need to invoke
this if processing and re-sending \s-1MIME\s0 from an outside source.\fR
.Sp
The \s-1OPTIONS\s0 is a hash, which describes what is to be done.
.RS 4
.IP "Length" 4
.IX Item "Length"
One of the \*(L"official unofficial\*(R" \s-1MIME\s0 fields is \*(L"Content\-Length\*(R".
Normally, one doesn't care a whit about this field; however, if
you are preparing output destined for \s-1HTTP\s0, you may.  The value of
this option dictates what will be done:
.Sp
\&\fB\s-1COMPUTE\s0\fR means to set a \f(CW\*(C`Content\-Length\*(C'\fR field for every non-multipart 
part in the entity, and to blank that field out for every multipart 
part in the entity. 
.Sp
\&\fB\s-1ERASE\s0\fR means that \f(CW\*(C`Content\-Length\*(C'\fR fields will all
be blanked out.  This is fast, painless, and safe.
.Sp
\&\fBAny false value\fR (the default) means to take no action.
.IP "Nonstandard" 4
.IX Item "Nonstandard"
Any header field beginning with \*(L"Content\-\*(R" is, according to the \s-1RFC\s0,
a \s-1MIME\s0 field.  However, some are non\-standard, and may cause problems
with certain \s-1MIME\s0 readers which interpret them in different ways.
.Sp
\&\fB\s-1ERASE\s0\fR means that all such fields will be blanked out.  This is
done \fIbefore\fR the \fBLength\fR option (q.v.) is examined and acted upon.
.Sp
\&\fBAny false value\fR (the default) means to take no action.
.RE
.RS 4
.Sp
Returns a true value if everything went okay, a false value otherwise.
.RE
.IP "tidy_body" 4
.IX Item "tidy_body"
\&\fIInstance method, override.\fR
Currently unimplemented for \s-1MIME\s0 messages.  Does nothing, returns false.
.Sh "Output"
.IX Subsection "Output"
.IP "dump_skeleton [\s-1FILEHANDLE\s0]" 4
.IX Item "dump_skeleton [FILEHANDLE]"
\&\fIInstance method.\fR
Dump the skeleton of the entity to the given \s-1FILEHANDLE\s0, or
to the currently-selected one if none given.  
.Sp
Each entity is output with an appropriate indentation level,
the following selection of attributes:
.Sp
.Vb 5
\&    Content-type: multipart/mixed
\&    Effective-type: multipart/mixed
\&    Body-file: NONE
\&    Subject: Hey there!
\&    Num-parts: 2
.Ve
.Sp
This is really just useful for debugging purposes; I make no guarantees
about the consistency of the output format over time.
.IP "print [\s-1OUTSTREAM\s0]" 4
.IX Item "print [OUTSTREAM]"
\&\fIInstance method, override.\fR
Print the entity to the given \s-1OUTSTREAM\s0, or to the currently-selected
filehandle if none given.  \s-1OUTSTREAM\s0 can be a filehandle, or any object 
that reponds to a \fIprint()\fR message. 
.Sp
The entity is output as a valid \s-1MIME\s0 stream!  This means that the 
header is always output first, and the body data (if any) will be 
encoded if the header says that it should be.
For example, your output may look like this:
.Sp
.Vb 2
\&    Subject: Greetings
\&    Content-transfer-encoding: base64
.Ve
.Sp
.Vb 1
\&    SGkgdGhlcmUhCkJ5ZSB0aGVyZSEK
.Ve
.Sp
\&\fIIf this entity has \s-1MIME\s0 type \*(L"multipart/*\*(R",\fR 
the preamble, parts, and epilogue are all output with appropriate
boundaries separating each.  
Any bodyhandle is ignored:
.Sp
.Vb 2
\&    Content-type: multipart/mixed; boundary="*----*"
\&    Content-transfer-encoding: 7bit
.Ve
.Sp
.Vb 7
\&    [Preamble]
\&    --*----*
\&    [Entity: Part 0]
\&    --*----*
\&    [Entity: Part 1]
\&    --*----*--
\&    [Epilogue]
.Ve
.Sp
\&\fIIf this entity has a single-part \s-1MIME\s0 type with no attached parts,\fR
then we're looking at a normal singlepart entity: the body is output 
according to the encoding specified by the header.  
If no body exists, a warning is output and the body is treated as empty:
.Sp
.Vb 2
\&    Content-type: image/gif
\&    Content-transfer-encoding: base64
.Ve
.Sp
.Vb 1
\&    [Encoded body]
.Ve
.Sp
\&\fIIf this entity has a single-part \s-1MIME\s0 type but it also has parts,\fR 
then we're probably looking at a \*(L"re\-parsed\*(R" singlepart, usually one
of type \f(CW\*(C`message/*\*(C'\fR (you can get entities like this if you set the 
\&\f(CW\*(C`parse_nested_messages(NEST)\*(C'\fR option on the parser to true).
In this case, the parts are output with single blank lines separating each,
and any bodyhandle is ignored:
.Sp
.Vb 2
\&    Content-type: message/rfc822
\&    Content-transfer-encoding: 7bit
.Ve
.Sp
.Vb 1
\&    [Entity: Part 0]
.Ve
.Sp
.Vb 1
\&    [Entity: Part 1]
.Ve
.Sp
In all cases, when outputting a \*(L"part\*(R" of the entity, this method 
is invoked recursively.
.Sp
\&\fBNote:\fR the output is very likely \fInot\fR going to be identical
to any input you parsed to get this entity.  If you're building
some sort of email handler, it's up to you to save this information.
.IP "print_body [\s-1OUTSTREAM\s0]" 4
.IX Item "print_body [OUTSTREAM]"
\&\fIInstance method, override.\fR
Print the body of the entity to the given \s-1OUTSTREAM\s0, or to the 
currently-selected filehandle if none given.  \s-1OUTSTREAM\s0 can be a 
filehandle, or any object that reponds to a \fIprint()\fR message. 
.Sp
The body is output for inclusion in a valid \s-1MIME\s0 stream; this means 
that the body data will be encoded if the header says that it should be.
.Sp
\&\fBNote:\fR by \*(L"body\*(R", we mean \*(L"the stuff following the header\*(R".
A printed multipart body includes the printed representations of its subparts.
.Sp
\&\fBNote:\fR The body is \fIstored\fR in an un-encoded form; however, the idea is that
the transfer encoding is used to determine how it should be \fIoutput.\fR
This means that the \f(CW\*(C`print()\*(C'\fR method is always guaranteed to get you
a sendmail-ready stream whose body is consistent with its head.
If you want the \fIraw body data\fR to be output, you can either read it from
the bodyhandle yourself, or use:
.Sp
.Vb 1
\&    $ent->bodyhandle->print($outstream);
.Ve
.Sp
which uses \fIread()\fR calls to extract the information, and thus will 
work with both text and binary bodies.
.Sp
\&\fBWarning:\fR Please supply an \s-1OUTSTREAM\s0.  This override method differs
from Mail::Internet's behavior, which outputs to the \s-1STDOUT\s0 if no 
filehandle is given: this may lead to confusion.
.IP "print_header [\s-1OUTSTREAM\s0]" 4
.IX Item "print_header [OUTSTREAM]"
\&\fIInstance method, inherited.\fR
Output the header to the given \s-1OUTSTREAM\s0.  You really should supply 
the \s-1OUTSTREAM\s0.
.IP "stringify" 4
.IX Item "stringify"
\&\fIInstance method.\fR
Return the entity as a string, exactly as \f(CW\*(C`print\*(C'\fR would print it. 
The body will be encoded as necessary, and will contain any subparts.  
You can also use \f(CW\*(C`as_string()\*(C'\fR.
.IP "stringify_body" 4
.IX Item "stringify_body"
\&\fIInstance method.\fR
Return the \fIencoded\fR message body as a string, exactly as \f(CW\*(C`print_body\*(C'\fR 
would print it.  You can also use \f(CW\*(C`body_as_string()\*(C'\fR.
.Sp
If you want the \fIunencoded\fR body, and you are dealing with a
singlepart message (like a \*(L"text/plain\*(R"), use \f(CW\*(C`bodyhandle()\*(C'\fR instead:
.Sp
.Vb 6
\&    if ($ent->bodyhandle) {
\&        $unencoded_data = $ent->bodyhandle->as_string;
\&    }
\&    else {
\&        ### this message has no body data (but it might have parts!)
\&    }
.Ve
.IP "stringify_header" 4
.IX Item "stringify_header"
\&\fIInstance method.\fR
Return the header as a string, exactly as \f(CW\*(C`print_header\*(C'\fR would print it.
You can also use \f(CW\*(C`header_as_string()\*(C'\fR.
.SH "NOTES"
.IX Header "NOTES"
.Sh "Under the hood"
.IX Subsection "Under the hood"
A \fBMIME::Entity\fR is composed of the following elements:
.IP "\(bu" 4
A \fIhead\fR, which is a reference to a MIME::Head object
containing the header information.
.IP "\(bu" 4
A \fIbodyhandle\fR, which is a reference to a MIME::Body object
containing the decoded body data.  This is only defined if 
the message is a \*(L"singlepart\*(R" type:
.Sp
.Vb 5
\&    application/*
\&    audio/*
\&    image/*
\&    text/*
\&    video/*
.Ve
.IP "\(bu" 4
An array of \fIparts\fR, where each part is a MIME::Entity object.  
The number of parts will only be nonzero if the content-type 
is \fInot\fR one of the \*(L"singlepart\*(R" types:
.Sp
.Vb 2
\&    message/*        (should have exactly one part)
\&    multipart/*      (should have one or more parts)
.Ve
.ie n .Sh "The ""two\-body problem"""
.el .Sh "The ``two\-body problem''"
.IX Subsection "The two-body problem"
MIME::Entity and Mail::Internet see message bodies differently,
and this can cause confusion and some inconvenience.  Sadly, I can't 
change the behavior of MIME::Entity without breaking lots of code already
out there.  But let's open up the floor for a few questions...
.ie n .IP "What is the difference between a ""message"" and an ""entity""?" 4
.el .IP "What is the difference between a ``message'' and an ``entity''?" 4
.IX Item "What is the difference between a message and an entity?"
A \fBmessage\fR is the actual data being sent or received; usually
this means a stream of newline-terminated lines.
An \fBentity\fR is the representation of a message as an object.
.Sp
This means that you get a \*(L"message\*(R" when you print an \*(L"entity\*(R" 
\&\fIto\fR a filehandle, and you get an \*(L"entity\*(R" when you parse a message
\&\fIfrom\fR a filehandle.
.IP "What is a message body?" 4
.IX Item "What is a message body?"
\&\fBMail::Internet:\fR 
The portion of the printed message after the header.
.Sp
\&\fBMIME::Entity:\fR
The portion of the printed message after the header.
.IP "How is a message body stored in an entity?" 4
.IX Item "How is a message body stored in an entity?"
\&\fBMail::Internet:\fR 
As an array of lines.
.Sp
\&\fBMIME::Entity:\fR 
It depends on the content-type of the message.
For \*(L"container\*(R" types (\f(CW\*(C`multipart/*\*(C'\fR, \f(CW\*(C`message/*\*(C'\fR), we store the
contained entities as an array of \*(L"parts\*(R", accessed via the \f(CW\*(C`parts()\*(C'\fR
method, where each part is a complete MIME::Entity.
For \*(L"singlepart\*(R" types (\f(CW\*(C`text/*\*(C'\fR, \f(CW\*(C`image/*\*(C'\fR, etc.), the unencoded
body data is referenced via a MIME::Body object, accessed via 
the \f(CW\*(C`bodyhandle()\*(C'\fR method:
.Sp
.Vb 11
\&                      bodyhandle()   parts()
\&    Content-type:     returns:       returns:
\&    ------------------------------------------------------------
\&    application/*     MIME::Body     empty
\&    audio/*           MIME::Body     empty     
\&    image/*           MIME::Body     empty      
\&    message/*         undef          MIME::Entity list (usually 1)
\&    multipart/*       undef          MIME::Entity list (usually >0)
\&    text/*            MIME::Body     empty     
\&    video/*           MIME::Body     empty     
\&    x-*/*             MIME::Body     empty
.Ve
.Sp
As a special case, \f(CW\*(C`message/*\*(C'\fR is currently ambiguous: depending 
on the parser, a \f(CW\*(C`message/*\*(C'\fR might be treated as a singlepart,
with a MIME::Body and no parts.  Use \fIbodyhandle()\fR as the final 
arbiter.
.IP "What does the \fIbody()\fR method return?" 4
.IX Item "What does the body() method return?"
\&\fBMail::Internet:\fR 
As an array of lines, ready for sending.
.Sp
\&\fBMIME::Entity:\fR 
As an array of lines, ready for sending.
.IP "If an entity has a body, does it have a soul as well?" 4
.IX Item "If an entity has a body, does it have a soul as well?"
The soul does not exist in a corporeal sense, the way the body does; 
it is not a solid [Perl] object.  Rather, it is a virtual object
which is only visible when you \fIprint()\fR an entity to a file... in other
words, the \*(L"soul\*(R" it is all that is left after the body is \s-1DESTROY\s0'ed.  
.IP "What's the best way to get at the body data?" 4
.IX Item "What's the best way to get at the body data?"
\&\fBMail::Internet:\fR 
Use the \fIbody()\fR method.
.Sp
\&\fBMIME::Entity:\fR 
Depends on what you want... the \fIencoded\fR data (as it is 
transported), or the \fIunencoded\fR data?  Keep reading...
.ie n .IP "How do I get the ""encoded"" body data?" 4
.el .IP "How do I get the ``encoded'' body data?" 4
.IX Item "How do I get the encoded body data?"
\&\fBMail::Internet:\fR 
Use the \fIbody()\fR method.
.Sp
\&\fBMIME::Entity:\fR 
Use the \fIbody()\fR method.  You can also use:
.Sp
.Vb 2
\&    $entity->print_body()
\&    $entity->stringify_body()   ### a.k.a. $entity->body_as_string()
.Ve
.ie n .IP "How do I get the ""unencoded"" body data?" 4
.el .IP "How do I get the ``unencoded'' body data?" 4
.IX Item "How do I get the unencoded body data?"
\&\fBMail::Internet:\fR 
Use the \fIbody()\fR method.
.Sp
\&\fBMIME::Entity:\fR 
Use the \fI\fIbodyhandle()\fI\fR method!
If \fIbodyhandle()\fR method returns true, then that value is a 
MIME::Body which can be used to access the data via 
its \fIopen()\fR method.  If \fIbodyhandle()\fR method returns an undefined value, 
then the entity is probably a \*(L"container\*(R" that has no real body data of
its own (e.g., a \*(L"multipart\*(R" message): in this case, you should access
the components via the \fIparts()\fR method.  Like this:
.Sp
.Vb 10
\&    if ($bh = $entity->bodyhandle) {
\&        $io = $bh->open;
\&        ...access unencoded data via $io->getline or $io->read...
\&        $io->close;
\&    }
\&    else {
\&        foreach my $part (@parts) {
\&            ...do something with the part...
\&        }
\&    }
.Ve
.Sp
You can also use:
.Sp
.Vb 6
\&    if ($bh = $entity->bodyhandle) {
\&        $unencoded_data = $bh->as_string;
\&    }
\&    else {
\&        ...do stuff with the parts...
\&    }
.Ve
.IP "What does the \fIbody()\fR method return?" 4
.IX Item "What does the body() method return?"
\&\fBMail::Internet:\fR 
The transport-encoded message body, as an array of lines.
.Sp
\&\fBMIME::Entity:\fR   
The transport-encoded message body, as an array of lines.
.IP "What does \fIprint_body()\fR print?" 4
.IX Item "What does print_body() print?"
\&\fBMail::Internet:\fR 
Exactly what \fIbody()\fR would return to you.
.Sp
\&\fBMIME::Entity:\fR 
Exactly what \fIbody()\fR would return to you.
.ie n .IP "Say I have an entity which might be either singlepart or multipart. How do I print out just ""the stuff after the header""?" 4
.el .IP "Say I have an entity which might be either singlepart or multipart. How do I print out just ``the stuff after the header''?" 4
.IX Item "Say I have an entity which might be either singlepart or multipart. How do I print out just the stuff after the header?"
\&\fBMail::Internet:\fR 
Use \fIprint_body()\fR.
.Sp
\&\fBMIME::Entity:\fR 
Use \fIprint_body()\fR. 
.IP "Why is MIME::Entity so different from Mail::Internet?" 4
.IX Item "Why is MIME::Entity so different from Mail::Internet?"
Because \s-1MIME\s0 streams are expected to have non-textual data...
possibly, quite a lot of it, such as a tar file. 
.Sp
Because \s-1MIME\s0 messages can consist of multiple parts, which are most-easily 
manipulated as MIME::Entity objects themselves.
.Sp
Because in the simpler world of Mail::Internet, the data of a message
and its printed representation are \fIidentical\fR... and in the \s-1MIME\s0
world, they're not.
.Sp
Because parsing multipart bodies on\-the\-fly, or formatting multipart 
bodies for output, is a non-trivial task.
.IP "This is confusing.  Can the two classes be made more compatible?" 4
.IX Item "This is confusing.  Can the two classes be made more compatible?"
Not easily; their implementations are necessarily quite different.
Mail::Internet is a simple, efficient way of dealing with a \*(L"black box\*(R"
mail message... one whose internal data you don't care much about.  
MIME::Entity, in contrast, cares \fIvery much\fR about the message contents: 
that's its job!
.Sh "Design issues"
.IX Subsection "Design issues"
.IP "Some things just can't be ignored" 4
.IX Item "Some things just can't be ignored"
In multipart messages, the \fI\*(L"preamble\*(R"\fR is the portion that precedes
the first encapsulation boundary, and the \fI\*(L"epilogue\*(R"\fR is the portion
that follows the last encapsulation boundary.
.Sp
According to \s-1RFC\-1521:\s0
.Sp
.Vb 5
\&    There appears to be room for additional information prior 
\&    to the first encapsulation boundary and following the final 
\&    boundary.  These areas should generally be left blank, and
\&    implementations must ignore anything that appears before the 
\&    first boundary or after the last one.
.Ve
.Sp
.Vb 9
\&    NOTE: These "preamble" and "epilogue" areas are generally 
\&    not used because of the lack of proper typing of these parts 
\&    and the lack of clear semantics for handling these areas at 
\&    gateways, particularly X.400 gateways.  However, rather than 
\&    leaving the preamble area blank, many MIME implementations 
\&    have found this to be a convenient place to insert an 
\&    explanatory note for recipients who read the message with 
\&    pre-MIME software, since such notes will be ignored by 
\&    MIME-compliant software.
.Ve
.Sp
In the world of standards\-and\-practices, that's the standard.  
Now for the practice: 
.Sp
\&\fISome \*(L"\s-1MIME\s0\*(R" mailers may incorrectly put a \*(L"part\*(R" in the preamble\fR.
Since we have to parse over the stuff \fIanyway\fR, in the future I
\&\fImay\fR allow the parser option of creating special MIME::Entity objects 
for the preamble and epilogue, with bogus MIME::Head objects.
.Sp
For now, though, we're MIME\-compliant, so I probably won't change
how we work.
.SH "AUTHOR"
.IX Header "AUTHOR"
Eryq (\fIeryq@zeegee.com\fR), ZeeGee Software Inc (\fIhttp://www.zeegee.com\fR).
David F. Skoll (dfs@roaringpenguin.com) http://www.roaringpenguin.com
.PP
All rights reserved.  This program is free software; you can redistribute 
it and/or modify it under the same terms as Perl itself.
.SH "VERSION"
.IX Header "VERSION"
$Revision: 1.18 $ \f(CW$Date:\fR 2006/03/17 21:15:49 $
Creat By MiNi SheLL
Email: devilkiller@gmail.com