mimemfc.shtml
来自「mfc资源大全包含MFC编程各个方面的源码」· SHTML 代码 · 共 430 行 · 第 1/2 页
SHTML
430 行
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Author" CONTENT="Zafir Anjum">
<TITLE>Internet - E-Mail file attachment using MIME</TITLE>
</HEAD>
<body background="../fancyhome/back.gif" bgcolor="#FFFFFF" >
<table WIDTH="100%">
<tr WIDTH="100%">
<td align=center><!--#exec cgi="/cgi/ads.cgi"--><td>
</tr>
</table>
<CENTER><H3><FONT COLOR="#AOAO99">E-Mail file attachment using MIME</FONT></H3></CENTER>
<HR>
<p>This article was contributed by <a
href="mailto:clyburnw@enmu.edu">Wes Clyburn</a></p>
<p>The classes presented in this article extend those described
in "SMTP MFC Classes" to handle messages using the
Multipurpose Internet Mail Extensions (MIME) protocol. MIME is an
e-mail message protocol (described in RFCs 1521 and 1522) that
allows messages to incorporate non-text content while still
remaining compliant with RFC 822.</p>
<p>This non-text content could be embedded audio or video, an
"external" message (meaning the content is not stored
in the message itself, but at an external location), or one or
more binary file attachments. Not all of these content types are
supported by the classes in this article, but you can easily
extend them to do so.</p>
<h2>How MIME Works</h2>
<p>RFC 822 describes a generic message format, and specifies some
standard header information. It says almost nothing about the
body of the messages, except that it is a chunk of ASCII text.</p>
<p>MIME takes advantage of that by superimposing a format for the
body text, and it also defines some header lines of its own. The
neat thing is that since the body is still just a chunk of text,
it doesn't break any rules established by RFC 822. This means
that any RFC 822-compliant transport system can handle MIME
messages without modification. The transport system expects a
message to have a chunk of 7-bit text, and MIME messages happily
oblige them. The transport system neither knows, nor has reason
to care, that lines 50 through 700 of the text chunk actually
represent an executable file. For that matter, it doesn't care
that the chunk of text in a non-MIME message represents the
English sentence "Attack at dawn". As far as a mail
server transporting the message is concerned, it's all just a
bunch of 7-bit characters to send up the chain.</p>
<p>Of course, the receiving clients of the message <em>do</em>
care because that chunk of text has to be converted back into a
binary file. They can do this only if they know about the format
of the message, i.e., only if they are MIME-compliant mail
readers. </p>
<h3 align="center">MIME Headers</h3>
<p>MIME defines five additional header lines that inform the
receiving client about how the body should be interpreted.</p>
<div align="center"><center>
<table border="0" cellpadding="2" cellspacing="3" width="100%">
<tr>
<th bgcolor="#008080"><font color="#FFFFFF">Header</font></th>
<th bgcolor="#008080"><font color="#FFFFFF">Meaning</font></th>
</tr>
<tr>
<td bgcolor="#C0C0C0" nowrap><p align="left"><strong>Content-Type</strong></p>
</td>
<td bgcolor="#C0C0C0"><font size="2">Specifies the type
of data contained in the message</font></td>
</tr>
<tr>
<td nowrap><strong>Content-Transfer-Encoding</strong></td>
<td><font size="2">Specifies how the data is converted
into 7-bit text</font></td>
</tr>
<tr>
<td bgcolor="#C0C0C0" nowrap><strong>MIME-Version</strong></td>
<td bgcolor="#C0C0C0"><font size="2">Indicates the MIME
compliance level to which the message is encoded.</font></td>
</tr>
<tr>
<td nowrap><strong>Content-ID</strong></td>
<td><font size="2">Uniquely identifies the body. This is
used for splitting the contents of large messages into
smaller messages.</font></td>
</tr>
<tr>
<td bgcolor="#C0C0C0" nowrap><strong>Content-Description</strong></td>
<td bgcolor="#C0C0C0"><font size="2">Ignored by MIME
applications. Gives a human reader an indication of the
content.</font></td>
</tr>
</table>
</center></div>
<p>The <strong>Content-Type</strong> header tells decoders what
kind of data is contained in the body, giving both a broad data
type (such as "image"), and a specific type (such as
"GIF") separated by a forward slash ("/").
Following the type information, the Content-Type header may
include additional parameters in <em>name=value</em> pairs, each
separated by a semi-colon (";"). What these additional
parameters are depends on the type of data.</p>
<p>Everyone, and their mothers, and their mothers' dogs, are
proposing new content types (along with their parameters) all the
time, so you'll have to go swimming in an ocean of standards
documents to discover them all.</p>
<p>Example:</p>
<pre>Content-Type: text/plain; charset="iso-8859-1"</pre>
<p>The more content types your mail reader can handle, the more
capable it is. Outlook supports <em>text/html</em>, so it can
display HTML messages to the user directly. It supports <em>image/jpeg</em>,
so it can show you pictures right there in the message.</p>
<p>Any content type that the mail reader can't support itself
should be saved to disk so that the user can open it with
something that knows how to handle it.</p>
<p>In other words, there's no such thing as a "file
attachment"; there are only content types that are encoded
and decoded. What you do after decoding is up to you. Do you
support <em>application/zip</em>? Then unzip the binary block. If
not, save it to disk and let someone think of it as a "file
attachment".</p>
<p>What most people think of as a file attachment is usually a
body of type <em>application/octet-stream</em>. That signifies a
chunk of 8-bit bytes... but that could be anything! Without more
concrete information about the data, there's really nothing the
mail reader can do except save it to disk.</p>
<p>The <strong>Content-Transfer-Encoding</strong> header
identifies the mechanism a decoder should use in order to convert
the message body back into its original form. </p>
<p>The biggies are <em>7bit, 8bit, Binary, Quoted-Printable,</em>
and <em>Base64. </em>Regardless of what content types your mail
reader supports, you need to be able to decode the message in the
first place. You don't have to support <em>image/gif</em>, but
you need to be able to turn the body into a GIF file that you can
save to disk. Your program can't do this unless it handles all
encoding mechanisms (you can't control how someone else's program
encoded it, so you need to handle them all). You can get away
with supporting only <em>text/plain</em> because you can just
dump other types of data to disk, but you can't do anything if
you can't read the data to begin with.</p>
<p>Luckily, only Base64 encoding could be considered even
slightly difficult to implement.</p>
<h3 align="center">Multi-Part Messages</h3>
<p>MIME completes the illusion of file attachments by allowing
the message body to be divided into distinct parts, each with
their own headers. The content type <em>multipart/mixed</em>
means that the content of the body is divided into blocks
separated by "--" + a unique string guaranteed to not
be found anywhere else in the message. If you say that your
boundary string is "MyBoundaryString", then all
occurrences of that string will be treated as a boundary. So it
better not be in the message the user typed or it won't be
decoded correctly.</p>
<p>The boundary string is specified as a parameter to the
Content-Type header:</p>
<pre>Content-Type: multipart/mixed; boundary="MyBoundaryString"</pre>
<p>Do not include the preceding "--" in the value. The
parts should then be separated with this:</p>
<pre>--MyBoundaryString</pre>
<p>And the end of the entire message will be indicated with a
trailing "--" as well:</p>
<pre>--MyBoundaryString--</pre>
<p>Text before the first boundary and after the end-of-message
boundary is ignored by decoders, but since a non-MIME reader will
simply display the whole thing as text, these areas can be used
to tell the user to get a better mail reader.</p>
<pre>From: me@here.com
To: you@there.com
Subject: In One Ear and Out Your Mother
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MyBoundaryString"</pre>
<pre>This is a MIME message. If the next few lines look like gibberish,
then your mail reader sucks.</pre>
<pre>If you are using a MIME reader, then you aren't even seeing this.</pre>
<pre>--MyBoundaryString
Content-Type: text/plain
Content-Transfer-Encoding: 7bit</pre>
<pre>The charset= parameter is omitted and will default to US-ASCII.
In fact, I could have had a blank line as my header and it would have
defaulted to exactly what I specified on those header lines.</pre>
<pre>--MyBoundaryString
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?