検索
連載

MIME（Multipurpose Internet Mail Extensions）〜前編：インターネット・プロトコル詳説（3）

Share
Tweet
LINE
Hatena

メール転送プロトコルにはメール・フォーマットが前提にある

　メールプロトコルについて解説する前に、インターネットで使用されるメールのフォーマットについて説明しよう。なぜなら、SMTP、POP、IMAPといったプロトコルが、インターネットメールの標準フォーマットを前提にしているからだ。

　インターネットメールのフォーマットは、基本となるインターネットメールのフォーマットに、MIMEと呼ばれる拡張形式を含めて確立されていると考えてよい（表1・2）。

1972年 ARPAネット用に最初のメールシステムを移植
1973年 最初の標準化されたメールフォーマットがRFC561として発表される。
ヘッダ／ボディやヘッダ行の概念などは、このころまでに確立していた
1982年 ARPAネットでのメールフォーマットの標準仕様としてRFC822が公開
1993年 MIME規格（RFC1521／RFC1522）が公開
1996年 あいまいだったり不十分だったりした部分を修正して、RFC2045〜RFC2049が公開
表1　MIMEの歴史年表

　なお、本連載では、RFC822（STD11）およびRFC2045からRFC2049までの最新のMIME仕様に準じて説明している。そのため、RFC2045からRFC2049によって置き換えられたRFC1521およびRFC1522とは異なる部分がある可能性があるので、その点は了解してほしい。

RFC822
（STD11）		 Standard for ARPA Internet Text Messages
RFC2045 Multipurpose Internet Mail Extensions (MIME)
Part One:Format of Internet Message Bodies
RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two:Media Types
RFC2047 MIME (Multipurpose Internet Mail Extensions)
Part Three:Message Header Extensions for Non-ASCII Text
RFC2048 Multipurpose Internet Mail Extensions (MIME)
Part Four:Registration Procedures
（IANAに対するメディアタイプの登録方法に関しての解説）
RFC2049 Multipurpose Internet Mail Extensions (MIME)
Part Five:Conformance Criteria and Examples
RFC2076 Common Internet Message Headers
（一般に使用されるメールヘッダについての情報）
RFC1521 MIME (Multipurpose Internet Mail Extensions)
Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
（最初のMIME仕様。RFC2045〜RFC2049に置き換えられている）
RFC1522 MIME (Multipurpose Internet Mail Extensions)
Part Two: Message Header Extensions for Non-ASCII Text
RFC1468 Japanese Character Encoding for Internet Messages
（ISO-2022-JP利用の指針）
RFC2298 An Extensible Message Format for Message Disposition Notifications
RFC2231 MIME Parameter Value and Encoded Word Extensions:
Character Sets, Languages, and Continuations
RFC2183 Communicating Presentation Information in Internet Messages:
The Content-Disposition Header Field
表2　MIME関連の標準仕様

すべてのメールはテキスト形式

　現在、多くの人がインターネットメールを利用している。このとき、本文のテキストだけのものから、ワープロや表計算ソフトのファイルを添付するものまで、さまざまなものがあるだろう。この利用方法を大ざっぱに分類すると、インターネットメールには、テキストを送る機能とテキスト以外のファイルを添付して送る機能があるといえる。

　インターネットメールは、もともとテキストベースのメールシステムであった。つまり、テキストしか送れないシステムである。さらに、英語圏で生まれたシステムのため、英語の使用が前提となっている。

　それではまず、テキストとテキスト以外では、何が異なっているのかを見ていこう。まず、下の表3を見てほしい。これはASCIIコードと呼ばれる文字コード表である。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　 ASCIIコードは、おもに英語圏で使用される文字セット体系である（文字コードの表記では、US-ASCIIなどと示される）。一般にテキストとは、このASCIIコードのことをいう。特に文章で使われる「目に見える文字（可視コードという）」は、0x00から0x7fまでの範囲に分類されている。

　これがテキストの範囲となる。この領域以外は拡張域として「英語圏」では通常使用されていない。言い方を変えると、勝手に利用してもよい領域となる。なお、ASCIIコードは8ビット中の下位7ビットまでしか使用していないため、「7ビットコード」とも呼ばれる。

　インターネットメールが送受信する際に前提とするのは、この範囲のコードだけである。現在では、それ以外のコードを送受信しても問題にならないことが多いが、メールサーバによっては受け付けないこともある。従って、仕様もそれを色濃く反映したものとなっている。

　しかし、可視コードではないフルビット（8ビット）で表現されたデータも当然存在する。例えば、ワープロや表計算ソフトなどのアプリケーション・データ（バイナリコード）や、日本語などの英語以外の言語コード（8ビットコード）がある場合だ。

　そこに、MIMEという仕様が登場するのである。MIMEには、次のことが定義されている。

  • バイナリや8ビットコード・データなどの「コンテンツ」を、7ビットに変換する「可視コード化」の仕様（符号化）
  • コンテンツをアプリケーションや言語と関連付けて格納する仕組み（構造化）

　つまり、MIMEによってあらゆるデータをテキスト（正確には、英語圏の人間にとってのテキスト）に変換して送受信しようとするのが、インターネットメールの根本的な考え方である。つまり、普段よく利用するインターネットメールへのファイルの添付とは、ファイルをテキスト化する作業のことになる。

　何とも時代錯誤の仕様であるが、これも古い歴史を持ったプロトコルのための特徴といえるだろう。

メール・フォーマットの概要

　ここでは、一般的なインターネットメールのフォーマットから見てみることにしよう。

　下の図1は、インターネットメールの模式図である。この例では、最もシンプルなメール形式、単純なテキストだけのメールである（つまりMIMEメールではない）。

ヘッダ Return-Path: taro@anywhare.ne.jp
Received: from smtp.anywhare.ne.jp (smtp.anywhare.ne.jp [219.219.219.1])
by smtp1.kaisya.co.jp (8.8.8/8.8.8) with ESMTP id EAA13892
;Mon, 19 Feb 2001 04:14:50 +0900 (JST)
(envelope-from taro@anywhare.ne.jp)
Received from taropc (taropc.anywhare.ne.jp [219.199.199.199])
by smtp.anywhare.ne.jp (8.9.3/3.7W) with ESMTP id EAA26267
; Mon, 19 Feb 2001 04:15:22 +0900 (JST)
Date: Mon, 19 Feb 2001 04:17:19 +0900
From: “Taro Yamada"
To: hanako@kigyou.co.jp, miho@kigyou.co.jp
Subject: Helo!
Cc: sjiro@example.com
Reply-To: taro@somewhare.com
Message-Id: <20010219041709.802C@anywhare.ne.jp>
X-Mailer: Becky! ver. 2.00
X-UIDL: 3673b7d0cb1f2ce3678d4175fe99914e
空行 空行（CR（0x0d）＋LF（0x0a）のみの行）
ボディ Hi! How are you?
This is a test mail, Please ignore me.
Thank you.
（略）
図1　シンプルなメールの例

　HTTPメッセージのように、インターネットメールのメールメッセージも、ヘッダとボディとに分けられる。ボディは、実際に送受信したいメールの本文となる。これは、はがきの裏に書く本文に当たる。ヘッダは、あて先や差出人、そのほか配達に必要な情報を表している。すなわち、はがきの表書きに当たる。両者の境界は、空行によって見分けることが可能だ。

　ヘッダは、ヘッダ・フィールドと呼ばれる行によって構成されている。行の終端はCR（キャリッジリターン：16進の0x0d）とLF（ラインフィード：16進の0x0a）によって示される。続く行の先頭が空白か水平タブ（0x09）の場合は、前行からの続きであると見なされる。各行の最大文字数は、通常70から80文字までに制限される。この制限を超える場合には、複数行に分割しなければならない。

　フィールドは、次のようなフォーマットとなる。

フィールド名:フィールド値[; パラメータ名=パラメータ値]

　フィールド名が示す内容がフィールド値である。フィールドによっては、「;」（セミコロン）で区切られた複数のパラメータが続く場合がある。パラメータは、フィールドを補足するための値である。前回までの本連載を読まれた読者は、ヘッダからフォーマットまで、考え方はHTTPメッセージとまったく同じであることに気づかれただろう。

　それでは、実際のヘッダの中身を見てみよう。おもなヘッダの種類はRFC821などに定義されている。メールのヘッダ定義は基本的なもの以外にも、機能を追加するため、別の仕様としてさまざまな標準仕様が追加されたもの、標準仕様にはないが、歴史的な経緯によって利用されてきたものなどがあり、非常に複雑である。そこで、普段よく使われるヘッダを標準／非標準問わず一覧で解説しているRFC2076がある＊1。すべてのヘッダが掲載されているわけではないが、ぜひ参考にしてほしい。

　また、先頭が「X-」で始まるフィールドは、メーラなどのアプリケーションが独自に採用したもので、自由に含めてもよい。ほとんどの場合、アプリケーション固有のもので互換性はないが、なかには有名になり、多くのアプリケーションが共通して採用しているものもある。

　Fromはメールの差出人、Toはあて先、そしてccはCC（カーボンコピー）先を表す。複数のあて先やCC先を指定する場合は、「,」（カンマ）でアドレスをくくる。ここで、Bcc（ブラインド・カーボンコピー）が存在するのを意外に思う読者がいるかもしれない。このフィールドがメールに残っていたら、Bccの意味をなさないからだ。しかし、実はメールの送信時にはBccフィールドがあっても、メールサーバが転送するときに取り除いてしまうのである。つまり、送信時にのみ存在する特殊なフィールドである。

　SenderはFromに似ているが、「実際の送信者」を示す。例えば、Fromには差し出しに同意したグループメンバー全員のアドレスを入れ、Senderには実際に出した人のアドレスを入れるような場合を想定している。そのため、Senderのアドレスは1つしか入れられないことになっている。

　Reply-Toは返信先である。このフィールドがないと、メーラは通常返信メールのあて先をFromのアドレスだと判断する。ただし、上で述べたように厳密にいうとFromは差出人ではない。また、メールを出したアドレスとは別のアドレスに返信してほしいことがある。そのような場合に、Reply-Toをあらかじめ指定しておく。

　そのほか、頻出するヘッダを別表にまとめておいたので、参考にしてほしい（ここをクリックすると、別ウィンドウでメールヘッダの一覧を表示します）。

＊1RFC2076には、メールのヘッダと同時にネットニュース（Usenet：NNTPで利用されるインターネットニュース）で使用するヘッダも同時に記載されている。これは、ニュースではメールとほぼ同様のフォーマットを使用するため。また、RFC2076に一度は目を通してほしい。現在ではほとんど使われなくなったヘッダも含めて、さまざまなヘッダがあり得ることが実感できるからだ。それらのヘッダは、これまでのメールが歩んできた紛れもない歴史の一端であるのだ


MIMEとメディアタイプ

　それでは、実際にMIMEメールを見てみよう。次のリスト1は、メールに本文はなく、画像ファイルを1つだけ添付した例だ。

Return-Path: taro@anywhare.**.jp
Received: from smtp.anywhare.**.jp (smtp.anywhare.**.jp [219.219.219.1])
  by smtp1.kaisya.**.jp (8.8.8/8.8.8) with ESMTP id 
EAA13892;
  Mon, 19 Feb 2001 05:47:59 +0900 (JST)
  (envelope-from taro@anywhare.**.jp)
Received: from taropc (taropc.anywhare.**.jp [219.199.199.199]) 
  by smtp.anywhare.**.jp (8.9.3/3.7W) with ESMTP id 
EAA26267
  ; Mon, 19 Feb 2001 05:48:31 +0900 (JST)
Date: Mon, 19 Feb 2001 05:46:28 +0900
From: "Taro Yamada" <taro@anywhare.**.jp>
To: "Hanako Suzuki" <hanako@kaisya.**.jp>
Subject: 画像です
Message-Id: <20010219054950.8032@anywhare.**.jp>MIME-Version: 1.0
Content-Type: image/gif;
  name="＠ＩＴロゴマーク.gi
  f"
Content-Disposition: attachment;
  filename="＠ＩＴロゴマーク.gi
  f"
Content-Transfer-Encoding: base64
X-Mailer: Becky! ver. 2.00
X-UIDL: c77a7ce4659ef0977f1ec2cc1574344b 
R0lGODlhcwA4AOYAAP/////++Pj9+/749fn49/H2+eX27+/v7+H07N3z6eXs8dXw5OLl6N/l68/u
4Nfi7Mjs3NXe5sTq2tjb4L3n1bjm0tDY4czY5bTkz67iy8jS3Krgx8zMzKXexMHI1Jrbv7fG1rnE
0JbZvJDXt7i/x4vWta29zobUsqS70ofRrKu4xaS3y3zQq6S0xaCzx3LMpZyvw52vwW7LombMmZSq
（中略）
4uBHAgEU4AtnLGTjaJlIMsDBBcaoIS+5QAxgNq6HALjBF1VgAwA04Ixo4GIxQOBMMhwRAEWQJiV+
0wM40rN+Q/SA9baJRCAor3smWEERVGDG3bVABVcYpA1U8IQhqKAIT2Ao964AAhoAQQVDGGQMVFCF
QZJhpFU4ggogyEseqACGj0Pp+dDwhje0IQ6vfFwc4mDSN8RhDTfNHk4ft4aa+rSelPCpScmgVDYM
VYVxGKjjlEqJQAAAOw==
リスト1　画像ファイルを1つだけ添付したメールの例

　普通のメールと変わらないように見えるが、MIMEにかかわるヘッダが幾つかあるのがわかる。

MIME-Version：

　MIMEのバージョン番号を示す。現在は1.0しか存在しない。

MIME-Version: パージョン番号

Content-Type：

　「メディアタイプ」と呼ばれるボディ部分の属性を示すヘッダだ。MIMEのコア部分のヘッダである。ここで、MIMEの「構造化」機能を提供する。

Content-Type: タイプサブタイプ[; charset=文字コード 等のパラメータ]

　MIMEは、さまざまな添付ファイルを格納する可能性がある。データを単に受け取っただけでは、メールの受信者は何のファイルで、どのアプリケーションを使って開けばよいのかわからない。そこで、データのタイプを指定して受信者に教えるのがこのヘッダである。タイプでアプリケーション種別の大項目を、サブタイプで詳細を示す＊2。

＊2ファイルから関連したアプリケーションのタイプを知るだけなら、拡張子を見ればわかるという声が、Windowsユーザーから聞こえてきそうだ。しかし、拡張子はすべてのOSに共通したものではない。そこで、OSに依存しないメディアタイプのような方法が必要となるのである


　タイプには、次の8つが定義されており、トップレベル・メディアタイプと呼ばれることもある。

（1）text
　一般的なテキストファイルやHTMLファイル、リッチテキストなど

（2）application
　アプリケーションのデータファイル。ワープロや表計算ソフトのファイルなど

（3）image
　GIFやJPEGなどの画像ファイル

（4）audio
　WAVEやAUなどの音声ファイル

（5）video
　MPEGやQuickTimeなどの動画ファイル

（6）model
　2Dや3Dグラフィックスのためのオブジェクト・データ。RFC2077で追加されたもの

（7）message
　RFC822に準拠したメール・メッセージなど

（8）multipart
　マルチパート型メッセージ

　見るとわかるが、メールに添付しそうなファイルの種別はほとんど網羅されている。messageは、メールなどのメッセージを指す。つまり、ボディとして別のメール・メッセージそのものを含むなど、複雑な場合に必要となるタイプである。multipartについては後編で詳しく説明するが、messageとmultipartは複数のファイルから構成されるタイプのため、複合タイプと呼ばれることがある。

　サブタイプは、具体的なアプリケーションやデータの種別となる。IANA（Internet Assigned Number Authority）が登録と管理を行っており、民間からの任意申請も可能だ。登録方法はRFC2048で解説されている。

　そのため、自社のアプリケーション用に、さまざまなベンダーが登録している。別表に、原稿アップ時点で定義されているタイプとサブタイプの対象表を掲載した（ここをクリックすると別ウィンドウでタイプ／サブタイプの一覧を表示します）。また、最新のタイプ／サブタイプは、ここから入手できる。

　これを見ると、HTMLやGIFなどのオーソドックスなタイプから、見慣れたMicrosoft Wordなどのアプリケーションまで、さまざまなタイプがあるのがわかる。メーラは、内部でこのタイプ／サブタイプと対応アプリケーションの対照表を管理しており、必要に応じて対応アプリケーションを起動させることになる。

　アプリケーションが特定できない場合などには、application/octet−streamという汎用的なタイプが指定される。受信側はほかの付属ヘッダなどからタイプを推測することになる。

●Microsoft Word文書の添付例

Content-Type: application/msword;

name="退職願.doc"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

filename="退職願.doc"

●XMLファイルの添付例

Content-Type: text/xml; name="sample.xml"

Content-Transfer-Encoding: quoted-printable

Content-Disposition: attachment; filename="sample.xml"

リスト2　さまざまなContent-Typeの例

　また、各タイプ／サブタイプごとに、必要なパラメータを取ることがある。パラメータは、メッセージへの付加的な情報を示している。

　例えば、text/plainは通常のテキストを示しているが、

text/plain; charset=文字コード

とすることで、テキストの文字コードを示すことができる。

Content-Description／Content-Disposition

　この2つは、MIMEヘッダによく使用される。Content-Descriptionは、一種のコメント域となる。例えば、次のように使用される。

Content-Description: "This is My Picture(BMP)"

　Content-Dispositionは、ボディに含まれるファイルなどのデータの属性を指定する 。

　ヘッダ値として取られるinlineは、メール本文など、そのほかの要素と一緒に表示することをメーラに指示する。attachmentは、通常の添付ファイルとしての扱いを示す。必ずしも強制力を伴わないが、送信側の意図を伝える意味で使用される。さらにfilenameパラメータを用いて、オリジナルの添付ファイル名を伝えることも大きな目的である。

Content-Transfer-Encoding：

　実際のデータの格納方法を示すのがこのフィールドだ。格納方法とは、ほとんどの場合はテキストへの変換（「可視コード化」とも呼ぶ）を指す。つまり、MIMEの「符号化」機能を提供する。

Content-Transfer-Encoding: 格納方法

　格納方法には、以下のものがある。

●7bit
ボディがもともと7ビットのテキストコードであることを示す

●8bit
ボディが8ビットのテキストコードであることを示す

●binary
テキスト以外のバイナリ・データ。もちろん7ビットではない

●quoted-printable
Quoted Printable形式データ。7ビット

●base64
Base64形式データ。7ビット

　8ビット（8bits）とバイナリ（binary）が定義されている点に注意してほしい。最近インターネットメールを8ビット・データに対応させようという動きがあるが、その際に8ビットのままで利用するための定義である。しかし、こうした活動は限定的なもので、厳密にはこの2つの方法は仕様違反だと思ってほしい。そのため、われわれが目にするのはほとんどが7ビットとbase64となるはずだ。

　この例では、Base64が指定されている。Base64の詳細はコラムを参照してほしいが、要するに8ビット・データを何とか7ビット・データにする方法のことである。これをエンコード＊3と呼ぶ。現在の最新メーラであれば、画像や動画、アプリケーション・データは、ほとんどBase64でエンコードされているはずだ。

　そのほかについては、別表を参照してほしい（ここをクリックすると別ウィンドウでMIME関連のメールヘッダの一覧を表示します）。

＊3具体的に解説すると、ここでいうエンコードとは、圧縮のことを指しているわけではない。実際には、圧縮どころか、ファイルサイズが大きくなることのほうが多い。つまり、単なるコード変換でしかない


エンコード形式の種類

　メールに限らないが、インターネット・プロトコルではバイナリ・データから7ビット・データへ変換するエンコード手法がよく利用される。その目的は本文で説明したとおりだが、テキスト化という意味から「可視化」とも呼ばれる。ここでは、おもなエンコード形式を紹介しよう。

●Base64
　バイナリ・データから3バイトずつ切り出し、これらを6ビット（10進では0から63に該当する）ごとに64種類のASCIIコードへそれぞれ割り当てていくエンコード方法のこと。元データの3バイトが4バイトに変換されることになるので、サイズは約1.3倍になる。

　もっとも、すべて元データがぴったり3バイトごとに割り切れるわけではない。そこで足りない部分にはパディングとして、「＝」（イコール）を付加する。

元データ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
変換後 A B C D E F G H I J K L M N O P
元データ 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
変換後 Q R S T U V W X Y Z a b c d e f
元データ 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
変換後 g h i j k l m n o p q r s t u v
元データ 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
変換後 w x y z 0 1 2 3 4 5 6 7 8 9 + /

　例えば、「＠ＩＴ」（シフトJIS）は、16進では次のようになる。

0x81 0x97 0x82 0x68 0x82 0x73

　そのため、Base64では次のように表現できる。

gZeCaIJz

●Quoted Printable
　ASCII文字（＝（イコール）を除く）、空白、水平タブ以外を次のように表記する。

=16進表記数値

　「＠ＩＴ」であれば、次のとおりになる。

=81=97=82=68=82=73

　ASCIIコード以外のデータが多少混ざる程度のデータであれば効率的だが、通常のバイナリであればBase64のほうがサイズは格段に小さくなる。これそうした理由から、Quoted Printableは欧米でよく使われるが、日本ではあまり使われない傾向にあるようだ。


「MIME〜後編」へ


「インターネット・プロトコル詳説」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る