MIME【Multipurpose Internet Mail Extensions】

広告

広告

MIMEとは

最終更新
2005-12-25T17:25:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/mime.html#what

MIMERFC822で規定されているテキストベースの電子メールメッセージにおいて、データの内容や長さに制限されないメッセージを送受信可能にするための規格を言います。電子メールの転送を行うSMTPは、ASCII文字をやり取りするために開発されたプロトコルなのでASCII文字しか送信することができません。また、送信可能な1行における最大文字数は1000文字と言う制限もSMTPにはあります。そこで、電子メールにてASCII文字意外の文字(日本語等)を送信できるようにし、文字数の制限をなくし、バイナリデータも添付できるように、MIMEと言う規格が定められたと言うわけです。このことによって、従来からある電子メールのプロトコルやメールサーバソフトを変更することなく、電子メールの仕様を拡張することができるのです。MIMEは電子メールだけでなく、一部の機能はWWWやインスタントメッセージング等でも使われています。

最終更新
2005-12-25T21:07:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/mime.html#header

MIMEも他の通信プロトコルと同様、ヘッダとデータ本体と言うフィールド構造になっています。葉書に例えるならば、ヘッダが宛先や住所が書かれている表面、ボディが本文や写真が記載されている裏面と言うことになるでしょう。ヘッダとボディは、CRLF(0x0d0x0a)のみからなる1行によって分割されます。

メールヘッダサンプル

From: from@sample.com
To: piyopiyo@sample.com
MIME-Version: 1.0
Subject:?ISO-2022-JP?B?GyRCPDc4ME1NJFgbKEI=?=
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Date: Sat, 24 Sep 2005 14:35:17 +0900 (JST)

MIME-Version

このメッセージがMIMEに沿ったメールかどうか、もしそうであればMIMEのバージョンは幾つかを明示し、処理を行うシステムがメッセージがどのようなものか判断し易くする役割があります。

Content-Type

受信側ユーザエージェントが、このメッセージを処理するために必要なデータや符号化の種類を記述するためのフィールドです。記述形式は以下のようになります。

Content-Type:タイプ/サブタイプ[; パラメータ[; パラメータ...]]
Content-Typeにおけるタイプとサブタイプ
タイプ意味サブタイプの例と意味
textテキスト形式を示すタイプ従来のテキストを示すplainやリッチテキストを示すrichtextなどがある。
multipart複数部分からなるコンテンツデータを示す複合タイプを示すmixed、その変形であるalternative(同じ内容を異なる複数の形式で記述)、digest(テキスト形式の複数ブロック)、parallel(同時にオープンする複数のブロック)などがある。
applicationプログラムデータやバイナリデータであることを示すバイナリデータを示すoctet-stream、PostScriptデータのpostscriptなどがある。
messageカプセル化されているコンテンツデータを示すカプセルメッセージを表すrfc822、分割メッセージを示すpartial、そのデータファイルのアクセス方法のみを記述するexternal-bodyがある。
image画像等のイメージを示すjpeggifなど。
audio音楽や音声データを示すbasic
videoビデオや動画像データを示すmpeg

受信側ユーザエージェントは、知らないContent-Typeが来たら、それぞれのタイプに対して定義してあるデフォルトのサブタイプとして扱います。例えば、Text/Enrichedを知らないユーザエージェントは、そのメッセージをText/Plainとして扱います。これがContent/Typeがタイプとサブタイプに分けられている理由なのです。ただし受け取ったメッセージにContent-Typeが存在しない場合は、そのメッセージをText/Plain; charset=US-ASCIIとして扱います。

RFC1590【Media Type Registration Procedure April 1994】にてメディアタイプの登録手順が規定されています。

Content-Transfer-Encoding

符号化の指定形式を示すフィールドです。受け取ったメッセージにContent-Transfer-Encoding:が存在しない場合は、そのメッセージをContent-Transfer-Encoding:7bitとして扱います。

Content-Transfer-Encoding:符号化メカニズム
符号化メカニズム
符号化メカニズム意味
7bit1行が制限内の7bitUS-ASCII文字列。無変換。
8bit1行が制限内の8bit非ASCII文字列。無変換。
binary非ASCIIのバイナリ列で1行の長さが制限内では無いもの。無変換。
quoted-printableCRLFで行が終わる1行76文字以内のデータ。変換の詳細は下記。
base64ISO-8859-1で規定されている大英字と小英字、数字及び記号(+と/)、終了パッドとして扱われる=。変換の詳細は下記。

Quoted-printable

7bitのUS-ASCII文字以外を=と16進数2桁で表すよう符号化する変換方式です。==3Dのように変換し、長い行は適当な部分で折り返し、行末に文章を折り返した目印として=を付加します。Quoted-printableはヨーロッパ言語のテキストやPostScriptデータの符号化に適しています。

BASE64

BASE64では、元のデータから8オクテット3文字(24bit)のデータを6オクテット4文字に変換する符号方式です。具体的にはA-Za-z0-9+/の64ASCII文字に変換されます。ただし、3オクテットのデータを6bitごとにASCII文字に割り当てていきますので、データのサイズは約1.3倍となります。元のデータが3オクテットで割り切れ無かった場合は、最後のデータに=を加え、3オクテットのデータを必ず作ります。BASE64を使えば画像ファイルやアプリケーションソフト用のファイル等をASCII文字に変換して、メール本文と一緒に送る(添付)ことができるのです。

BASE64符号化文字
符号符号符号符号符号
0A13N26a39n520
1B14O27b40o531
2C15P28c41p542
3D16Q29d42q553
4E17R30e43r564
5F18S31f44s575
6G19T32g45t586
7H20U33h46u597
8I21V34i47v608
9J22W35j48w619
10K23X36k49x62+
11L24Y37l50y63/
12M25Z38m51z(pad)=

Content-ID

メッセージ識別のためのヘッダフィールドです。

Content-Description

転送する今テンスtの内容を示すメッセージフィールドです。

Content-Disposition

パートをファイルに保存する際のファイル名を指定します。

非ASCII文字列によるメッセージヘッダ

最終更新
2005-12-25T21:36:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/mime.html#non_ascii

RFC821/822ではメッセージヘッダ内で使用が許されている文字は、7bitのUS-ASCII文字のみでした。その後RFC2047MIME Part Three:Message Header Extensions for Non-ASCII Text November 1996】で非ASCII文字を符号化することによってメッセージヘッダ内で使用する方法が規定されました。符号化にはQuoted-printableBASE64が用いられ、以下の形式を採ります。

=?文字セット?符号方式?符号化された文字列?=
Subject:?ISO-2022-JP?B?GyRCPDc4ME1NJFgbKEI=?=

文字セットにはcharsetパラメータと同じ値を使用します。US-ASCIIiso-8859-X(ヨーロッパ言語)、iso-2022-jp(日本語)等があります。符号方式にはBASE64を表すBとQuoted-printableを表すQがあります。

ISO-2022-JP

ISO-2022-JPRFC1468【Japanese Character Encoding for Internet Message - June 1993】で規定されています。まず電子メールメッセージ本文の日本語を、ASCIIコードと同じ7bitに対応したJISコードに変換します。そしてJISコードの数値をそのままASCII文字で送るのです。

BASE64符号化

図のように符号化をするのですが、JISコードでは開始を示すエスケープシーケンスとASCIIコードに戻すためのエスケープシーケンスをそれぞれ使用することとなっています。[ESC]$BはJISコードに切り替えるためのエスケープシーケンスで、[ESC](BはASCIIコードに切り替えるためのエスケープシーケンスとなっています([ESC]は10進数の27(0x1B)と言うコードを持つ特殊な文字)。

メッセージのカプセル化

最終更新
2005-12-25T22:14:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/mime.html#encapsulation

MIMEでは、Content-Type:multipart/...Content-Type:message/...のデータ型を使って本文をカプセル化することができます。ディレクトリの中にメール本文や様々なファイルを保存することができるように、Multipartの中にMultipartを作成し、電子メールメッセージ内を構造化することができるのです。その際に重要な役割を果たすのがboundaryパラメータです。このパラメータが指す文字列によって、格納する複数のパートが区切られているのです。

Content-Type: Multipart/Mixed; boundary="boundary_str"
Content-Transfer-Encoding: 7bit

--boundary_str ← 境界
Content-Type: Text/Plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hellow!!

--boundary_str ← 境界
Content-Type: image/gif;
Content-Transfer-Encoding: base64

(BASE64エンコードされた画像データ)

--boundary_str-- ← 最後の境界

上記のMultipartを使うことにより、テキストだけのメールメッセージだけではなく、様々な添付ファイルをメールメッセージと同時に送信することが可能となるのです。また、このカプセル化は、単に複数のファイルを送るという意味だけではありません。サブタイトルにalternativeparalleldigestを指定することによりファイルの組み合わせが変わり、さまざまな意味をメッセージに持たせることができるのです。

また、Message/Rfc822をContent-Typeに指定することにより、メッセージをメッセージでカプセル化することができます。これはメールの転送の際等で使用されます。

補足知識

最終更新
2005-12-25T13:44:00+09:00
この記事のURI参照
https://www.7key.jp/nw/technology/protocol/mime.html#supplement

拡張規格として、メール内容の暗号化を行なうS/MIME規格等がある。

広告

当ページ作成にあたり、参考にさせてもらったリソース

Copyright (C) 2005 七鍵 key@do.ai 初版:2005年12月25日 最終更新:2005年12月25日