広告
広告
https://www.7key.jp/nw/technology/protocol/mime.html#whatMIMEはRFC822で規定されているテキストベースの電子メールメッセージにおいて、データの内容や長さに制限されないメッセージを送受信可能にするための規格を言います。電子メールの転送を行うSMTPは、ASCII文字をやり取りするために開発されたプロトコルなのでASCII文字しか送信することができません。また、送信可能な1行における最大文字数は1000文字と言う制限もSMTPにはあります。そこで、電子メールにてASCII文字意外の文字（日本語等）を送信できるようにし、文字数の制限をなくし、バイナリデータも添付できるように、MIMEと言う規格が定められたと言うわけです。このことによって、従来からある電子メールのプロトコルやメールサーバソフトを変更することなく、電子メールの仕様を拡張することができるのです。MIMEは電子メールだけでなく、一部の機能はWWWやインスタントメッセージング等でも使われています。
https://www.7key.jp/nw/technology/protocol/mime.html#headerMIMEも他の通信プロトコルと同様、ヘッダとデータ本体と言うフィールド構造になっています。葉書に例えるならば、ヘッダが宛先や住所が書かれている表面、ボディが本文や写真が記載されている裏面と言うことになるでしょう。ヘッダとボディは、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に沿ったメールかどうか、もしそうであればMIMEのバージョンは幾つかを明示し、処理を行うシステムがメッセージがどのようなものか判断し易くする役割があります。
受信側ユーザエージェントが、このメッセージを処理するために必要なデータや符号化の種類を記述するためのフィールドです。記述形式は以下のようになります。
Content-Type:タイプ/サブタイプ[; パラメータ[; パラメータ...]]
| タイプ | 意味 | サブタイプの例と意味 |
|---|---|---|
| text | テキスト形式を示すタイプ | 従来のテキストを示すplainやリッチテキストを示すrichtextなどがある。 |
| multipart | 複数部分からなるコンテンツデータを示す | 複合タイプを示すmixed、その変形であるalternative（同じ内容を異なる複数の形式で記述）、digest（テキスト形式の複数ブロック）、parallel（同時にオープンする複数のブロック）などがある。 |
| application | プログラムデータやバイナリデータであることを示す | バイナリデータを示すoctet-stream、PostScriptデータのpostscriptなどがある。 |
| message | カプセル化されているコンテンツデータを示す | カプセルメッセージを表すrfc822、分割メッセージを示すpartial、そのデータファイルのアクセス方法のみを記述するexternal-bodyがある。 |
| image | 画像等のイメージを示す | jpeg、gifなど。 |
| 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:7bitとして扱います。
Content-Transfer-Encoding:符号化メカニズム
| 符号化メカニズム | 意味 |
|---|---|
| 7bit | 1行が制限内の7bitUS-ASCII文字列。無変換。 |
| 8bit | 1行が制限内の8bit非ASCII文字列。無変換。 |
| binary | 非ASCIIのバイナリ列で1行の長さが制限内では無いもの。無変換。 |
| quoted-printable | CRLFで行が終わる1行76文字以内のデータ。変換の詳細は下記。 |
| base64 | ISO-8859-1で規定されている大英字と小英字、数字及び記号（+と/）、終了パッドとして扱われる=。変換の詳細は下記。 |
7bitのUS-ASCII文字以外を=と16進数2桁で表すよう符号化する変換方式です。=は=3Dのように変換し、長い行は適当な部分で折り返し、行末に文章を折り返した目印として=を付加します。Quoted-printableはヨーロッパ言語のテキストやPostScriptデータの符号化に適しています。
BASE64では、元のデータから8オクテット3文字（24bit）のデータを6オクテット4文字に変換する符号方式です。具体的にはA-Za-z0-9+/の64ASCII文字に変換されます。ただし、3オクテットのデータを6bitごとにASCII文字に割り当てていきますので、データのサイズは約1.3倍となります。元のデータが3オクテットで割り切れ無かった場合は、最後のデータに=を加え、3オクテットのデータを必ず作ります。BASE64を使えば画像ファイルやアプリケーションソフト用のファイル等をASCII文字に変換して、メール本文と一緒に送る（添付）ことができるのです。
| 値 | 符号 | 値 | 符号 | 値 | 符号 | 値 | 符号 | 値 | 符号 |
|---|---|---|---|---|---|---|---|---|---|
| 0 | A | 13 | N | 26 | a | 39 | n | 52 | 0 |
| 1 | B | 14 | O | 27 | b | 40 | o | 53 | 1 |
| 2 | C | 15 | P | 28 | c | 41 | p | 54 | 2 |
| 3 | D | 16 | Q | 29 | d | 42 | q | 55 | 3 |
| 4 | E | 17 | R | 30 | e | 43 | r | 56 | 4 |
| 5 | F | 18 | S | 31 | f | 44 | s | 57 | 5 |
| 6 | G | 19 | T | 32 | g | 45 | t | 58 | 6 |
| 7 | H | 20 | U | 33 | h | 46 | u | 59 | 7 |
| 8 | I | 21 | V | 34 | i | 47 | v | 60 | 8 |
| 9 | J | 22 | W | 35 | j | 48 | w | 61 | 9 |
| 10 | K | 23 | X | 36 | k | 49 | x | 62 | + |
| 11 | L | 24 | Y | 37 | l | 50 | y | 63 | / |
| 12 | M | 25 | Z | 38 | m | 51 | z | (pad) | = |
メッセージ識別のためのヘッダフィールドです。
転送する今テンスtの内容を示すメッセージフィールドです。
パートをファイルに保存する際のファイル名を指定します。
https://www.7key.jp/nw/technology/protocol/mime.html#non_asciiRFC821/822ではメッセージヘッダ内で使用が許されている文字は、7bitのUS-ASCII文字のみでした。その後RFC2047【MIME Part Three:Message Header Extensions for Non-ASCII Text November 1996】で非ASCII文字を符号化することによってメッセージヘッダ内で使用する方法が規定されました。符号化にはQuoted-printableかBASE64が用いられ、以下の形式を採ります。
=?文字セット?符号方式?符号化された文字列?=
Subject:?ISO-2022-JP?B?GyRCPDc4ME1NJFgbKEI=?=
文字セットにはcharsetパラメータと同じ値を使用します。US-ASCIIやiso-8859-X（ヨーロッパ言語）、iso-2022-jp（日本語）等があります。符号方式にはBASE64を表すBとQuoted-printableを表すQがあります。
ISO-2022-JPはRFC1468【Japanese Character Encoding for Internet Message - June 1993】で規定されています。まず電子メールメッセージ本文の日本語を、ASCIIコードと同じ7bitに対応したJISコードに変換します。そしてJISコードの数値をそのままASCII文字で送るのです。
図のように符号化をするのですが、JISコードでは開始を示すエスケープシーケンスとASCIIコードに戻すためのエスケープシーケンスをそれぞれ使用することとなっています。[ESC]$BはJISコードに切り替えるためのエスケープシーケンスで、[ESC](BはASCIIコードに切り替えるためのエスケープシーケンスとなっています（[ESC]は10進数の27(0x1B)と言うコードを持つ特殊な文字）。
https://www.7key.jp/nw/technology/protocol/mime.html#encapsulationMIMEでは、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を使うことにより、テキストだけのメールメッセージだけではなく、様々な添付ファイルをメールメッセージと同時に送信することが可能となるのです。また、このカプセル化は、単に複数のファイルを送るという意味だけではありません。サブタイトルにalternativeやparallel、digestを指定することによりファイルの組み合わせが変わり、さまざまな意味をメッセージに持たせることができるのです。
また、Message/Rfc822をContent-Typeに指定することにより、メッセージをメッセージでカプセル化することができます。これはメールの転送の際等で使用されます。
https://www.7key.jp/nw/technology/protocol/mime.html#supplement拡張規格として、メール内容の暗号化を行なうS/MIME規格等がある。
広告