今までのメール、正確には RFC822 メールは、本文にテキストしか格納できない 規格でした。MIME は RFC822 を拡張した多目的メールです。
MIME は、ヘッダに
MIME-Version: 1.0
というフィールドを持ちます。このフィールドがない場合は、RFC822メールです。 MIME では、データの型を示す Content-Type: と符号化方式を示す Content-Transfer-Encoding: が重要なフィールドです。以下ではこれらのフィー ルドや MIME の特徴について説明します。
MIME では、Content-Type:(以下 CT:)というフィールドにデータの型を指定でき ます。以下は、本文が US-ASCII である MIME の例です。
MIME-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Subject: hello From: Kazu Hi all,
CT: が省略された場合は、text/plain; charset=us-ascii として取り扱われま す。また、CT: text/plain のときに、charset が省略されると US-ASCII と解 釈されます。
このように MIME では、CT: がテキストの場合は、charset で文字コードを指定 できます。日本語には ISO 2022 JP を使います。
MIME では、本文に複数のデータを格納できます。これをマルチパートといいま す。マルチパートのそれぞれのパートは、コンテントヘッダとコンテントボディ から構成されています。CT: はヘッダだけでなく、コンテントヘッダ中にも現れ ます。逆に、ヘッダは特殊なコンテントヘッダだと考えても構いません。
詳しくは、See section マルチパート を参照して下さい。
以下に重要な CT: を示します。
以前からバイナリを配送するために uuencode という符号化プログラムが使われ ていました。uuencode は、8ビット3文字を6ビット4文字に変換しますが、変換 後にたくさんの記号が現れます。これらの記号はメールのヘッダで特殊な意味を 持つものが含まれており、ヘッダの拡張のためには利用できません。
また、空白文字も使われているのも厄介です。なぜなら、BITNET のファイルシ ステムには、行末に空白がありえないのです。もし、uuencode で符号化したと きに、行末にたまたま空白が現れたとしましょう。これを BITNET のメールゲー トウェイが受け取ると、当然行末の空白を削ってしまいます。よって、受信者は 元のバイナリファイルを復元できません。
そこで、MIME では本文用に 2 つの符号化方式を定めました。
各コンテントヘッダ中の Content-Transfer-Encoding:(CTE:)で符号化方式を指 定します。取りうる値は以下の通りです。
CTE: が省略された場合は `7bit' して扱われます。
ISO 2022 JP は7ビットの文字コードですから、CTE: は 7bit です。つまり、 CTE: は省略して構いません。もちろん、base64 や quoted-printable で符号化 しても構いませんが、フォルダにあるメールを more などで直接読めなくなるの で、お勧めではありません。
CT: が Multipart である場合、そのコンテントボディには複数のデータが格納 されることを意味します。データの境界は boundary に指定された文字列で区切 られます。以下に例を示します。
Message-Id: <13060.789566615@is.aist-nara.ac.jp>
From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=
<kazu@is.aist-nara.ac.jp>
Subject: =?ISO-2022-JP?B?GyRCPC8kTjMoGyhC?=
To: m-sakura@ccs.mt.nec.co.jp
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary=simple
--simple
Content-Type: Text/Plain; charset=us-ascii
奈良名物「鹿」の絵を送ります。
--かず
--simple
Content-Type: Image/Gif
Content-Transfer-Encoding: base64
Content-Description: "Deer on the Nara park"
R0lGODdhFwG8ANUAABETDCoYDC8lFi4dJxcnKTMwLkUUC04uG2opEkgeJ04yMWg4Ly1FLVJG
NWdSMywyTks1Tmc3RjdRVjNcalRMUG9UU1xbY051eG9pcIcxEp5bM8d1NI1VSJhrVrRwUpR0
cKZ1dcN9WXuHOWmHc7WJN6yLbcyEWNCZdDZjjml0i5t7im+TmGeRonWly5aLlrCLlK+arJmn
pbettMabktWumM+zsrnCrtTLua21ycq6x6/J3NbQ1+bk29na5dzp8+7w8ywAAAAAFwG8AAAG
/8CLcPhYtVgNyirWasZYEgDhIWGxRiXWcTIATHS/Hs6K2+1wt59azYtdJnBhKrVaWYcp7==
--simple--
この例では、"simple" という文字列で区切られています。boundary に指定され た文字列には、先頭に "--" が付きます。最後の区切りには、後ろにも "--" が 付きます。
各パートは、コンテントヘッダとコンテントボディから構成されます。両者は、 ヘッダと本文のように空行で区切られます。逆にいうと、ヘッダと本文は、それ ぞれ特殊なコンテントヘッダとコンテントボディです。
テキスト以外を MIME で送信する場合は、必ずマルチパートを利用するようにし ましょう。たとえば、本文にいきなり audio/basic を格納できますが、そんな メールを受け取ったらびっくりします。パート1に説明のテキスト、パート2に audio/basic を入れた方が親切でしょう。
マルチパートは、入れ子構造にできます。つまり、マルチパートのマルチパート なども作成できます。
ちなみに境界ですが、前後の改行まで含みます。上記の例では、 "CRLF--simpleCRLF" が区切りです。
ヘッダはメールの配送に関わる情報を格納しているため、配送プログラムが誤動 作するような文字列を入れるべきではありません。MIME では、ヘッダに以下の ような形式で非 ASCII を安全な文字列を符号化し挿入します。
=?<charset>?<encoding>?<encoded-string>?=
指定できる <charset> は CT: text/plain の charset と同じです。<encoding> には、`B' と `Q' 符号化方式があり、前者は Base64 符号化方式、 後者は Quoted-Printable 符号化方式の亜種を意味します。
ISO 2022 JP には、`B' 符号化方式が奨励されていますが、`Q' 符号 化方式でも構いません。しかし、`Q' 符号化方式に対応しているインター フェイスはあまりないようです(もちろん Mew は対応していますが)。
たとえば、「山本和彦」をこの形式で符号化すると
=?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=
となります。
Go to the first, previous, next, last section, table of contents.