MIME
電子メールで、文字の種類、画像や添付ファイルなどを扱うための拡張規則。本文の種類や転送時の表現をヘッダーで指定し、表示名などの非ASCII文字はencoded-wordによる表記も利用できる。
イマシルちゃんの解説
メールで文章と一緒に写真や資料を送りたいとき、内容の種類を相手へ伝える必要があるよ。
MIMEは、文字や画像などをメールで扱えるようにする形式の拡張規則なんだ。
データの種類を示すContent-Typeというヘッダーで、受信側へ内容の扱い方を伝えるよ。
本文と添付ファイルを一緒に入れるときは、multipartという形式で部分ごとに区切り、それぞれの種類を示すんだ。
使える文字が限られた配送経路を通すために、画像などを英数字中心の文字列へ変換するBase64も使うよ。
受信側はこうした情報を手掛かりに元のデータを取り出せるから、異なる種類の内容を一通にまとめて送れるんだ。
この解説はわかりやすかったですか?
より深い解説
メールを拡張する規則
MIMEはRFC 2045〜2049などで定義される。文字だけのメールを越えて、複数の種類の内容を扱えるようにする。送信や配送そのものはSMTPなどが担当する。
| フィールド | 役割 |
|---|---|
| Content-Type | text/plainやimage/pngなど、内容の種類を示す |
| Content-Transfer-Encoding | 本文を転送用にどう表すかを示す |
| MIME-Version | MIMEの版を示す |
文字の符号化方式と、転送時の表現は別の観点である。たとえばUTF-8の文字列を、さらに転送用の符号化へ変換することがある。
バイナリデータを文字で表す
Base64は、バイト列を限定された文字集合で表す方式である。基本的には3バイトを4文字へ変換するため、データ量は概ね4/3倍になる。末尾には長さを整えるためのパディングが付く場合がある。
この変換は暗号化ではない。規則を知っていれば元へ戻せるため、情報を秘密にする目的には使えない。配送のために表現を変えることと、内容を保護することを区別する。
表示名とアドレスの書き方
RFC 5322の名前付きアドレスでは、表示名を先に書き、実際のメールアドレスを山かっこで囲む。独自の例を示す。
From: Support Team <[email protected]>
表示名は人が読むための名前であり、それだけでは送信者の本人確認にならない。メール配送で使われるエンベロープの送信元と、Fromフィールドの値も別である。
ヘッダー内の文字の表現
RFC 2047では、ヘッダーの指定された位置で非ASCII文字を表すencoded-wordを定める。
=?文字セット?符号化方式?符号化した文字列?=
| 要素 | 意味 |
|---|---|
| 文字セット | 元の文字列をどの文字コードで表したか |
| B | Base64による符号化 |
| Q | 印字可能な文字を多く残す符号化 |
この表記は表示名などで使う。メールアドレス全体をこの形へ置き換えるものではない。UTF-8を直接利用する国際化メールの拡張とは、適用する規則が異なる。
複数の部分をまとめる
本文と添付などを一つのメールで扱う場合、multipartの構造を使う。各部分をboundaryで区切り、それぞれに内容の種類などを指定する。
S/MIMEは、メールの署名や暗号化を扱う別の拡張である。MIME形式で表現できることだけで、機密性や送信者の正当性が保証されるわけではない。
HTTPとの関係
Content-Typeで使うメディアタイプやmultipartの構造は、HTTPでも利用される。たとえば、HTTPの応答は受け取った内容の種類をメディアタイプで示し、フォーム送信では複数の部分に分けたデータを扱う場合がある。MIMEの仕組みをメール配送のプロトコルそのものと混同しない。
マルチパートという呼び方
マルチパートは、複数の部分を区切りでまとめるmultipart形式の日本語での呼び方である。メール本文と添付ファイル、通常文とHTML版など、別々の内容を一つのメッセージで扱う。複数の物理ポートを束ねるリンクアグリゲーションや、複数アンテナを使うMIMOとは、まとめる対象が異なる。