JISX5810-5:2008 多目的インターネットメール拡張（ＭＩＭＥ）

X 5810-5：2008

（1）

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ページ

序文 ··································································································································· 1

1 総則······························································································································· 1

1.1 適用範囲 ······················································································································ 1

1.2 概要 ···························································································································· 1

1A 引用規格 ······················································································································ 2

2 MIME適合性 ·················································································································· 2

3 電子メールデータ送信の指針 ······························································································ 4

4 正準符号化モデル ············································································································· 6

5 要約······························································································································· 7

6 セキュリティへの考慮 ······································································································· 8

附属書A（参考）複雑なマルチパートの例 ················································································ 9

附属書B（参考）RFC 1521, 1522及び1590からの変更点 ···························································· 12

附属書C（参考）参考文献 ···································································································· 14

X 5810-5：2008

（2）

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

まえがき

この規格は，工業標準化法第12条第1項の規定に基づき，財団法人日本規格協会(JSA)から，工業標準

原案を具して日本工業規格を制定すべきとの申出があり，日本工業標準調査会の審議を経て，経済産業大

臣が制定した日本工業規格である。

この規格は，著作権法で保護対象となっている著作物である。

この規格の一部が，特許権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許

権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案登録出願に係る確認について，責任は

もたない。

JIS X 5810の規格群には，次に示す部編成がある。

JIS X 5810-1 第1部：インターネットメッセージ本体のフォーマット

JIS X 5810-2 第2部：メディア型

JIS X 5810-3 第3部：非ASCIIテキストへのメッセージヘッダ拡張

JIS X 5810-5 第5部：適合基準

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

日本工業規格 JIS

X 5810-5：2008

多目的インターネットメール拡張(MIME)−

第5部：適合基準

Multipurpose Internet Mail Extensions (MIME)−

Part 5: Conformance criteria and examples

序文

この規格は，1996年11月にInternet Engineering Task Force (IETF)から公表されたRFC 2049，Multipurpose

Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examplesを基に，技術的内容及び構成を

変更することなく作成した日本工業規格である。

なお，この規格で側線を施してある箇所は，RFC 2049にない事項である。

インターネット公式プロトコル規定STD 11であるRFC 822では，US-ASCIIメッセージヘッダについて

多くの詳細を規定したメッセージ表現プロトコルを定義しているが，メッセージ内容，すなわち，メッセ

ージ本体については，構造のないUS-ASCIIテキストだけとしている。JIS X 5810の規格群は，多目的イ

ンターネットメール拡張又はMIMEと総称され，次のことを可能とするために，メッセージのフォーマッ

トを再定義する。

a) US-ASCII以外の文字集合でのテキストのメッセージ本体

b) 非テキストのメッセージ本体のための異なるフォーマットの拡張集合

c) マルチパートのメッセージ本体

d) US-ASCII以外の文字集合でのテキストのヘッダ情報

MIMEを規定するJIS X 5810の規格群は，RFC 934，STD 11及びRFC 1049に文書化されている初期の

成果に基づくが，それらを拡張及び改正する。RFC 822では，メッセージ本体についてはごくわずかに示

しているだけなので，JIS X 5810の規格群の大部分は，RFC 822を改正するというより，RFC 822を補う。

総則

1.1

適用範囲

この規格は，JIS X 5810の規格群の第5部であり，MIME適合基準について規定し，それとともに幾つ

かのMIMEメッセージフォーマットの例示及び参考文献を提供する。

注記 JIS X 5810の規格群の第1部(JIS X 5810-1)の原規定はRFC 2045，第2部(JIS X 5810-2)の原規

定はRFC 2046，第3部(JIS X 5810-3)の原規定はRFC 2047，第5部(JIS X 5810-5)の原規定はRFC

2049である。RFC 2045，RFC 2046，RFC 2047及びRFC 2049は，RFC 1521，RFC 1522及びRFC

1590の改正であって，RFC 1521，RFC 1522及びRFC 1590はRFC 1341及びRFC 1342の改正

であった。附属書Bに，過去の版との違い及び変更について記載する。

1.2

概要

MIME関連の一連の規格のうち，1番目のJIS X 5810-1及び2番目のJIS X 5810-2は，MIMEヘッダフ

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ィールド及びMIMEメディア型の初期集合を定義する。3番目のJIS X 5810-3は，US-ASCII以外の文字集

合を可能とするために，RFC 822フォーマットの拡張について規定する。この規格は，MIMEのどの部分

が適合するMIME実装によってサポートされなければならないかを規定する。また，この規格は，現代の

メッセージングシステムの多くの注意点を示し，MIMEが基づいている正準符号化モデルをも規定する。

引用規格

次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの

引用規格は，その最新版（追補を含む。）を適用する。

JIS X 5810-1 多目的インターネットメール拡張(MIME)−第1部：インターネットメッセージ本体の

フォーマット

注記 RFC 2045 "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message

Bodies", November 1996が，この規格に一致している。

JIS X 5810-2 多目的インターネットメール拡張(MIME)−第2部：メディア型

注記 RFC 2046 "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November

1996が，この規格に対応している。

ISO/IEC 8859 (All parts) Information technology−8-bit single-byte coded graphic character sets

MIME適合性

MIME関連規格で示される機構は，拡張に対応している。すべての実装がすべての可能なメディア型を

サポートすることも，それらが同じ拡張を共有することも，全く期待されない。しかし，相互運用性を推

進するため，実装のある水準を定義する“MIME適合性”の概念を定義することは有用であり，これは，

US-ASCIIテキストと異なる内容をもつメッセージの有用な交換を可能にする。箇条2は，この適合性のた

めの要件を規定する。

MIME適合であるメールの利用者エージェントは，次を満たさなければならない。

a) それが作成するすべてのメッセージに，常に“MIME-Version: 1.0”ヘッダフィールドを生成しなければ

ならない。

b) Content-Transfer-Encoding（内容転送符号化）ヘッダフィールドを認識し，quoted-printable実装又は

base64実装のどちらかによって符号化されたすべての受信データを復号しなければならない。7 bit同

一変換，8 bit同一変換及びbinary同一変換も認識されなければならない。

符号化せずに送られるすべての非7 bitデータは，8 bit又はbinaryの内容転送符号化で適切にラベル付

けされなければならない。下層にある転送機構が，8 bit又はbinaryをサポートしないとき（SMTP [RFC

821]がサポートしないように），送信者は，quoted-printable又はbase64などの適切な内容転送符号化を

用いて，データを符号化し，かつ，ラベル付けすることが要求される。

c) 認識できないどのようなContent-Transfer-Encoding（内容転送符号化）も，実際のContent-Typeが認識

されるかどうかにかかわらず，それが“application/octet-stream”のContent-Typeをもつように扱わなく

てはならない。

d) Content-Typeヘッダフィールドを認識し解釈しなければならず，text以外のContent-Typeフィールドを

もつ生データを利用者に見せてはならない。実装は，少なくともtext/plainメッセージを，送ることが

できなければならない。このメッセージの文字集合がUS-ASCIIでない場合には，charsetパラメタで

指定される文字集合で送らなければならない。

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

e) 名前を認識できない内容型のパラメタは無視しなければならない。

次のメディア型値を，少なくとも次の程度まで明示的に処理しなければならない。

text:

1) 文字集合“US-ASCII”をもつ“text”メールを認識し，表示しなければならない。

2) 他の文字集合を，少なくとも，メッセージが使っている文字集合が何であるかについて利用者に知

らせることができる程度まで，認識しなければならない。

3) ISO-8859-X及びUS-ASCIIに共通の文字，すなわちオクテット値1〜127で表現されるすべての文字

を表示できる程度まで，“ISO-8859-X”文字集合を認識しなければならない。

4) 既知の文字集合の認識できないメディア下位型については，正準形式から局所形式への内容変換の

後に“生”の版のデータを，利用者に見せるか見せることを提案しなければならない。

5) 未知の文字集合のデータは，それが“application/octet-stream”であるかのように扱わなければならな

い。

image，audio及びvideo:

1) 少なくとも，すべての認識できないメディア下位型を“application/octet-stream”であるかのように扱

う機能を提供しなければならない。

application:

1) JIS X 5810-1で定義されるquoted-printable符号化又はbase64符号化が使われ，結果の情報が利用者

のファイルに置かれる場合，それを取り除く能力を提示しなければならない。

multipart:

1) 混合のメディア下位型を認識しなければならない。メッセージレベル及び本体部分ヘッダレベルの

すべての関連する情報を表示し，そして，それぞれの本体部分を独立に表示するか又は表示するか

どうかを提案しなければならない。

2) “alternative”メディア下位型を認識し，multipart/alternativeのメールの冗長な部分を利用者に見せるこ

とを避けなければならない。

3) “multipart/digest”メディア下位型を認識しなければならない。特に，“multipart/digest”実体の内部の本

体部分のデフォルトのメディア型として，“text/plain”ではなく“message/rfc822”を使わなければなら

ない。

4) すべての認識できないメディア下位型を“mixed”であるかのように扱わなければならない。

message:

1) 少なくともRFC 822メッセージのカプセル化(message/rfc822)をすべての再帰構造を保持する方法で

認識及び表示しなければならない。すなわち，このメディア型に従ってカプセル化されたデータを，

表示するか又は表示することを提案しなければならない。

2) どんな認識できないメディア下位型も“application/octet-stream”であるかのように扱わなければなら

ない。

g) 認識できないContent-Typeフィールドに遭遇した場合には，実装は，それがパラメタなしの“application /

octet-stream”のメディア型をもつかのように，それを扱わなければならない。これらのデータをどう処

理するかは実装の問題になるが，これらの認識できないデータを処理する可能な選択肢には，メール

転送フォーマットから復号されるファイルにそれを書き込むことを利用者に提供すること，又は復号

されるデータを入力として渡すプログラムを指名することを利用者に提案することが含まれる。

h) 適合利用者エージェントが，US-ASCII以外の文字集合を用いる非MIMEメッセージに対して非標準

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

のサポートを提供する場合，受信メッセージだけにそれを行うことが，適合利用者エージェントに要

求される。適合利用者エージェントは，US-ASCIIテキスト以外を含む非MIMEメッセージを送って

はならない。

特に，MIME-Versionフィールドなしのメールメッセージにおける非US-ASCIIテキストの使用は，

異なる局所変換の領域間でメッセージを送るときに相互運用性を妨げるので，強く非推奨とする。適

合利用者エージェントは，US-ASCII文字集合でプレーンテキスト以外のものを送るとき，正しい

MIMEラベル付けを含まなければならない。

さらに，非MIME利用者エージェントは，たとえMIME中で他の何もサポートしない場合でも，そ

れが送ったメッセージに適切なMIMEヘッダ情報を含むことが可能なように更新されたほうがよい。

この更新は，あったとしても，ほとんど非MIME受信者に影響を与えず，これらのメッセージを正し

く表示するのにMIMEを援助する。これは，他のMIME機能を将来採用することへの円滑な移行の道

筋をも提供する。

適合利用者エージェントは，“=?”で始まり“?=”で終わる“*text”又は“*ctext”の中にある非空白で印字可

能なUS-ASCII文字のどの文字列も，妥当な符号化語(valid encoded-word)であることを保証しなければ

ならない。ここで，“始まる”は，フィールド本体の先頭又は空白の並び(linear-white-space)の直後を

意味し，“終わる”は，フィールド本体の末尾又は線形空白の直前を意味する。さらに，“=?”で始まり

“?=”で終わる“phrase”の中にあるどんな“word”も，妥当な符号化語でなければならない。

適合利用者エージェントは，符号化語がメッセージヘッダ中の適切な位置に現れたらいつでも，箇条

4に規定する規則に従って，符号化語を“text”，“ctext”又は“word”から区別できなければならない。そ

れは，それがサポートするどの文字集合に対しても，“B”符号化及び“Q”符号化の両方をサポートしな

ければならない。そのプログラムは，符号化されないテキストを，文字集合が“US-ASCII”であれば，

表示できなければならない。ISO-8859-X文字集合に関して，メールを読むプログラムは，少なくとも

US-ASCII集合にも含まれる文字を表示できなければならない。

これらの条件に適合する利用者エージェントは，MIME適合であるといえる。この句の意味は，これら

のメールシステムの利用者に，適切にマーク付けされたどんな種類のデータも事実上送ることが，“安全”

であると想定される。それは，これらのシステムが，少なくともそのデータを区別されないbinaryとして

扱うことができ，疑わない利用者の画面上にそれをまき散らすことはないことによる。

MIME適合のフォーマットでデータを送ることは常に“安全”であるというもう一つ意義がある。それ

は，それらのデータが，壊れることはなく，RFC 821及びRFC 822に適合するどんな既知のシステムによ

っても壊されない。MIME適合の利用者エージェントは，利用者がテキストとして見られることを決して

想定しないデータを見せられないという，追加の保証をもつ。

電子メールデータ送信の指針

インターネットメールは，完全で一様なシステムではない。メールは，最終目的地に行く途中の多くの

段階で，壊れてしまうことがある。特に，インターネットを通って送られた電子メールは，多くのネット

ワーク技術を通過し得る。多くのネットワーク技術及びメール技術は，SMTP転送環境で可能な全機能を

サポートするわけではない。これらのシステムを通過するメールは，それが転送され得るように，変更さ

れやすい。

インターネットには，多くの非適合MTA (Message Transfer Agent) がある。これらのMTAは，SMTPプ

ロトコルで交信するときに，それが実装されているホストの内部データ構造を利用して動作中にメッセー

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ジを改変するか，又ははっきりと壊される。

次の指針は，最も広範なネットワーク技術及び既知の壊れたMTAで無きずに生き残るために想定され

るデータフォーマット（メディア型）を工夫する人に有用であろう。base64符号化で符号化されるものは，

これらの規則を満たすが，よく知られた機構，とりわけUNIXのuuencode機能はそれを満たさないことに

注意されたい。quoted-printable符号化で符号化されたものは，大部分のゲートウェイで無きずに生き残る

が，EBCDIC文字集合を使うシステムへの幾つかのゲートウェイでは生き残れない可能性がある。

a) 幾つかの状況下では，通常のゲートウェイの一部又は利用者エージェント操作として，データに使わ

れる符号化が変更されることがある。特に，base64からquoted-printableへの変換及びその逆変換は，

避けがたいことがある。これは，テキスト本体中の行区切りで，CRLF列の混乱を起こすかもしれな

い。そうであるから，行区切りではないものとしてのCRLFの保存性は，信頼してはならない。

b) 多くのシステムは，システム固有の改行規約を使って，テキストデータを表示し，保存することを選

択することがある。システム固有の改行規約は，RFC 822のCRLF規約には一致しないことがある。

例えば，CRだけ，LFだけ，CRLF，又は文字数区切りレコードを使うシステムが知られている。その

結果，孤立したCR文字及びLF文字は，一般には許されない。それらは，あるシステムでは，失われ

るか又は区切り子に変換されるかもしれないので，信頼してはならない。

c) NUL（US-ASCII値の0）の転送は，インターネットメールでは問題がある。これは，プログラム言語

Cにおいて多くの標準ランタイムライブラリルーチンによって終端文字として使われているNULの

結果によるところが大きい。終端文字としてのNULの使用の実行は，今では確立されたものだから，

メッセージが保存されることを信じないほうがよい。

d) TAB (HT)文字は，誤って解釈され得るか，異なる数のスペースへ自動的に変換されるかもしれない。

これは，ある環境では，特にUS-ASCII文字集合に基づかない環境では，避けられない。これらの変

換は，強く非推奨とするが，もしそれが起きる場合には，メールフォーマットはTAB(HT)文字の保存

性に依存してはならない。

e) 76文字より長い行は，ある環境では，折り返されるか又は切り取られる。メール転送で行われる行の

折返し又は切取りは，強く非推奨とするが，幾つかの場合には避けられない。長い行を要求するアプ

リケーションは，無指定(soft)行区切りと指定(hard)行区切りとを何とかして区別しなければならない。

これを行う簡単な方法に，quoted-printable符号化の使用がある。

行の末尾の“空白”文字[SPACE，TAB (HT)]は，ある転送エージェントで捨てられるかもしれない。

他の転送エージェントが，これらの文字で行を埋めて，メールファイル中のすべての行を同じ長さに

することもある。したがって，末尾の空白の保存性をあてにしてはならない。

g) 多くのメールドメインは，US-ASCII文字集合での変種を使うか，又はUS-ASCIIの文字の多くを含む

がすべては含んでいないEBCDICなどの文字集合を使う。“不変の”集合にない文字の正しい翻訳は，

文字変換ゲートウェイに頼ることはできない。例えば，この状況は，uuencodeされた情報を，EBCDIC

システムであるBITNETを通して送る場合に問題となる。多くのインターネットのホストは，内部で

はUS-ASCII以外の文字集合を使うので，類似の問題は，ゲートウェイを通さない場合にも起こる。

X.400におけるPrintable String（印字可能文字列）の定義は，ある特定の場合に更に制限を加えている。

特に，すべてのゲートウェイを通して一貫性があると知られている文字は，大文字のAからZまで，

小文字のaからzまで，0から9までの10数字，及び次の11の特別な文字である73文字だけである。

“'” (US-ASCIIの10進値で39)

“(” (US-ASCIIの10進値で40)

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

“)” (US-ASCIIの10進値で41)

“+” (US-ASCIIの10進値で43)

“,” (US-ASCIIの10進値で44)

“-” (US-ASCIIの10進値で45)

“.” (US-ASCIIの10進値で46)

“/” (US-ASCIIの10進値で47)

“:” (US-ASCIIの10進値で58)

“=” (US-ASCIIの10進値で61)

“?” (US-ASCIIの10進値で63)

最も大きな可搬性のあるメール表現は，73文字のこの集合から意味のある文字だけを使ったテキス

トの比較的短い行に限ることになる。base64符号化はこの規則に従う。

h) 幾つかのメール転送エージェントは，ある文字列を含むデータを壊す。特に，ピリオド(“.”)だけの行

は，幾つかの（正しくない）SMTP実装によって壊されることが知られており，“From ”の5文字（最

後の文字はSPACE）で始まる行も通常壊される。注意深い作成エージェントは，そのデータを符号化

することによって破壊を防ぐことができる。例えば，quoted-printable符号化において行の先頭にある

“From ”の場所に“=46rom”を使い，行の“.”だけの場所には“=2E”を使う。

上記の一覧は，MTAに関する推奨される実行の一覧ではないことに注意されたい。RFC 821のMTAは，

空白の文字を変更すること又は長い行を折り返すことを禁止している。これらの悪い不正な実行は，設置

されたネットワークで起こることが知られていて，実装は，それらが引き起こし得る悪い影響を扱う場合

に頑健であることが望ましい。

正準符号化モデル

MIME規定の初期の版では，混乱があった。それは，どのようなときに電子メールデータが正準形式に

変換し符号化されるか，そして，システムごとに改行の表現が大きく異なるとき，この変換・符号化がCRLF

の振る舞いにどのように影響するかについてのモデルに関する混乱であった。このため，符号化の正準モ

デルを次に示す。

MIME実体を作成する過程は，幾つかの段階で行われるものとしてモデル化できる。これらの段階は，

大雑把にいって，PEM [RFC 1421]で使われる段階と似ていて，それぞれの“最も内側のレベル”の本体に

対して実行される。

a) 局所形式の作成システムの固有フォーマットで，転送する本体を生成する。固有の文字集合が使わ

れ，適切であれば，同様に局所的な行の終端の変換が行われる。本体は，UNIXスタイルのテキスト

ファイル，Sunのラスタ画像，VMSのインデックス付きファイル，メモリ内だけに保存される形式の

システム依存の音声データ，又は情報のある形式の表現のための局所的なモデルに対応するその他の

ものであってもよい。基本的に，データは，メディア型で指定される型に対応する“固有の”形式で

作成される。

b) 正準形式への変換レコード長，可能なファイル属性情報などの“out-of-band”情報を含むすべての本

体は，普遍的な正準形式に変換される。本体の特定のメディア型及び関連する属性は，使われる正準

形式の性質を指示する。正しい正準形式への変換は，文字集合の変換，音声データの変換，圧縮，又

は様々なメディア型に固有の多くの他の操作を含んでよい。しかし文字集合の変換を含む場合には，

どんな文字集合の変換にも強い意味をもつであろう，メディア型のセマンティクス（例えば，plain以

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

外のテキストメディア下位型においては，ある種の文字が構文上の意味をもつ。）について注意を払わ

なければならない。例えば，text/plainデータの場合，テキストはサポートされる文字集合に変換され

なければならず，RFC 822に従ってCRLF区切り子で行を区切らなければならない。ただし，次の段

階でquoted-printable符号化又はbase64符号化のどちらかを用いるならば，RFC 822に伴う行の長さの

制限はなくなる。

c) 内容転送符号化の適用メッセージの本体に適切なContent-Transfer-Encoding（内容転送符号化）を適

用する。メディア型と内容転送符号化との間には固定的な関係はないことに注意する。特に，base64

かquoted-printableの選択の基礎を，本体の与えられたインスタンスに固有の文字頻度数に置くことは

適切であろう。

d) 実体への挿入符号化された本体は，MIME実体に適切なヘッダとともに挿入される。それから実体

は，必要に応じてもっと高いレベルの実体（メッセージ又はマルチパート）に挿入される。

実体形式から局所形式への変換は，これらの段階を逆にすることによって達成される。元の形式と最終

的な局所形式とが同じである保証はないので，これらの段階の逆は異なる結果を生成するかもしれないこ

とに注意する。

これらの段階はモデルにすぎないことに注意することは重要である。これらは，実際のシステムがどの

ように構築されるかの青写真では決してない。特にモデルは，次の二つの共通設計を説明できない。

a) 多くの場合，符号化に先立つ正準形式への変換は，局所フォーマットを直接理解できる符号化器その

ものに含まれる。例えば，テキスト本体の局所的な改行の変換は，そのフォーマットが何であるかの

知識に基づいて，符号化器そのものを通して実行されるであろう。

b) 符号化器の出力は，メッセージとして転送される前に，一つ以上の追加の段階を通らなければならな

いかもしれない。したがって，符号化器の出力は，RFC 822に規定されるフォーマットに適合しない

かもしれない。特に，変換器の出力が，標準的なRFC 822のCRLF区切り子を使うのではなく，局所

的な改行変換を使って表現されることが再び適切であるかもしれない。

他の実装上の多様性も同様に考えられる。この議論の重要な点は，要求される段階を崩したり追加処理

を挿入したりする最適化にかかわらず，結果のメッセージはここに示されたモデルによって生成されたも

のと整合していなければならないことである。例えば，次のヘッダファイルをもつメッセージは，始めに

text/foo形式で表現され，それから必要に応じて，“bar”文字集合によって表現され，最後にbase64アルゴ

リズムによってmail-safe形式に変換されなければならない。

Content-type: text/foo; charset=bar

Content-Transfer-Encoding: base64

注記 RFC 822のCRLF変換と異なる局所的な改行変換を使うフォーマットでメッセージを表現する

システムによって，ある混乱が起きていた。これらのフォーマットが正準なRFC 822/MIMEで

はないことに注意することは，重要である。これらのフォーマットは，メッセージの正準表現

におけるCRLF列が局所的な改行変換として符号化される，RFC 822の代理“符号化”である。

例えば，CRLF行分離列の部分でないLFオクテットを含むbinaryデータを含むMIMEメッセ

ージを表現できないことに注意。

要約

この規格では，MIME適合が何を意味するかを定義した。それは，インターネットの電子メールシステ

ムに存在することが知られている様々な問題，及びこれらを克服するためにMIMEをどのように使うかを

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書A

（参考）

複雑なマルチパートの例

この附属書は，本体に関連する事柄を補足するものであって，規定の一部ではない。

複雑なマルチパートメッセージの概要を，次に示す。このメッセージは，連続的に表示される五つの部

分，すなわち，二つの導入のプレーンテキストオブジェクト，組み込まれたマルチパートメッセージ，

text/enrichedオブジェクト，非ASCII文字集合でのカプセル化された最後のテキストからなる。組み込ま

れたマルチパートメッセージ自体は，並列的に表示される二つのオブジェクト，つまり写真及び音声素片

を含む。

MIME-Version: 1.0

From: Nathaniel Borenstein

To: Ned Freed

Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)

Subject: A multipart example

Content-Type: multipart/mixed;

boundary=unique-boundary-1

ここはマルチパートの前文の領域である。マルチパート

フォーマットを理解するメールリーダはこの前文を無視

したほうがよい。

あなたがこのテキストを読んでいる場合，マルチパート

メッセージを正しく表示する方法を理解するメールリーダへ

変更することを検討したほうがよいかもしれない。

--unique-boundary-1

... テキスト(US-ASCII)が書かれている ...

[このパートの境界とテキストの開始との間の空白は，

ヘッダフィールドが与えられなかったことを意味し，

これはUS-ASCII文字集合でのテキストである。

次の部分のように，明示的に打ち込むこともできる。]

--unique-boundary-1

Content-type: text/plain; charset=US-ASCII

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

これは前の部分の一部とすることもできるが，ここでは

本体部分の打込みの明示対暗黙の対比として示す。

--unique-boundary-1

Content-Type: multipart/parallel; boundary=unique-boundary-2

--unique-boundary-2

Content-Type: audio/basic

Content-Transfer-Encoding: base64

... ここにbase64符号化された，8 000 Hzの

... mu-lawフォーマットの音声データが置かれる ...

--unique-boundary-2

Content-Type: image/jpeg

Content-Transfer-Encoding: base64

... ここにbase64符号化された画像が置かれる ...

--unique-boundary-2--

--unique-boundary-1

Content-type: text/enriched

This is<italic>enriched.</italic>であり，

<smaller>as defined in RFC 1896</smaller>

(これはRFC 1896に定義されているとおり，フォーマット付きである。)

Isn't it

(これはすばらしいですか。)

--unique-boundary-1

Content-Type: message/rfc822

From: (mailbox in US-ASCII)

To: (address in US-ASCII)

Subject: (subject in US-ASCII)

Content-Type: Text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: Quoted-printable

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書B

（参考）

RFC 1521, 1522及び1590からの変更点

この附属書は，本体に関連する事柄を補足するものであって，規定の一部ではない。

MIME関連のJIS X 5810規格群は，RFC 1521，1522及び1590の改正である。RFC 1521，1522及び1590

を熟知している人に便利なように，RFC 1521，1522及び1590からの変更点をこの附属書に要約する。そ

れ以前の履歴に関して，RFC 1521がその前の版のRFC 1341とどのように異なるかをRFC 1521のAppendix

Hが示している。

a) RFC 1521，1522及び1590は完全に再構成され，複数の規格に分割された。これは，参照原稿である

ために必要とされる，RFC 1521，1522及び1590のプレーンテキスト版の品質を高めるために行われ

た。

b) MIMEオブジェクトヘッダの全体構成を記述する拡張BNFが追加された。これは，文書化の変更だけ

で，根本的な構文は変わっていない。

c) MIMEの七つのメディア型のための固有の拡張BNFは削除された。この拡張BNFは，不正確で，不

完全で，型独立の拡張BNFと矛盾していた。型独立の拡張BNFは既に多くのMIMEヘッダの構文を

完全に規定しているので，型固有の拡張BNFは，結局，完全に不要であり，かえって問題を起こした。

d) RFC 1521，1522及び1590の多くの部分における非公式の用語であるASCIIの使用は，もっと固有の

“US-ASCII”という文字集合名に置き換えられた。

e) 主メディア下位型という非公式の概念を削除した。

用語“オブジェクト”は，一貫性なしに用いられていた。この用語の定義は，関連の用語“本体”，“本

体部分”及び“実体”とともに明確化され，用法は適切に訂正された。

g) 境界マーカに先行するCRLFが，先行する本体部分ではなくマーカそのものの一部であることを明確

にするため，マルチパートメディア型のための拡張BNFは再整理された。

h) マルチパートオブジェクト内の本体部分は，境界パラメタ文字列で始まる行を含んではならないこと

を明確にするため，マルチパートメディア型を記述する普通文及び拡張BNFは変更された。

“message/partial”MIME実体を再組立する規則において，内部メッセージからとるために，ヘッダの一

覧に“Subject”が追加され，この点を明確にするため例が修正された。

“message/partial”素片化子は，行境界でのMIMEオブジェクトの分割だけに制限される。

k) application/postscript型の議論において，PostScript MIME実体の中でのbinaryデータの組込みによって

引き起こされる可能性のある相互運用可能性の問題についての警告をする追加の段落を加えた。

次の二つの形式を明確にするために，Content-Typeヘッダフィールドのための基本構文規則に対して

明確化の注記を加えた。

Content-type: text/plain; charset=us-ascii (comment)

Content-type: text/plain; charset="us-ascii"

これらは，完全に等価である。

m) MIME-Versionヘッダの議論から次の文を削除した。“しかし，適合ソフトウェアは，版番号を検査し，

認識できないMIME-Versionに遭遇したとき，利用者に少なくとも警告することが推奨される。”

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

n) “message/external-body”ではなく“application/external-body”とした誤植を修正した。

o) 要件を明確にするため，文字集合の定義を再構成した。

p) “image/gif”メディア型の定義は，別文書に移した。この変更は，特許で保護された技術の標準化を管

理するIETF規則と矛盾が生じる可能性があるため，行われた。

q) “7 bit”及び“8 bit”の定義を厳しくしたので，はだかのCR及びLFは行終端列として使用されるだけと

した。この規格はまた，NUL文字を保存することをもはや要求しない。それは，MIMEを実世界の実

装と整合させる。

r) MIMEにおける正準テキストの定義を厳しくしたため，行区切りはCRLF列で表現されなければなら

ない。CR文字及びLF文字は，この用法以外には許容されない。それに伴って，quoted-printable符号

化の定義が変更された。

quoted-printable符号化の定義は，quoted-printable符号化器が不適切に符号化されたデータをどう扱う

のが最もよいかについて，今では多くの推奨を含む。

“8 bit”又は“binary”データにカプセル化するメッセージ実体又はマルチパートで，“7 bit”，“8 bit”及び

“binary”の内容転送符号化の使用を明確にする普通文を加えた。

u) MIME適合性の箇条において，最小限のMIME適合性に関する要件の一覧に“multipart/digest”のサポー

トを追加した。“message/rfc822”のサポートのための用件も，再帰構造を認識することの重要性を明確

にするために，強化された。

v) “message”のメディア下位型の様々な制限は，今ではメディア下位型ごとに完全に規定されている。

w) “message/rfc822”の定義は，“From”，“Subject”又は“Date”ヘッダの少なくとも一つが存在しなければな

らないことを示すように変更した。

x) 認識できないメディア下位型の“application/octet-stream”としての必す（須）処理は，型定義の節及び

適合性指針の両方において，もっと明示的に作成された。

y) text/richtextを用いた例は，text/enrichedに変更された。

z) メディア下位型の拡張BNF定義は，IANA登録済みメディア下位型又は非標準の“X-”メディア下位型

のどちらかがContent-Typeヘッダフィールドで使わなければならないことを明らかにするために変更

された。

aa) 使用するために単に登録されるMIMEメディア型と，IETFによって標準化されるMIMEメディア型

とは，今ではMIME 拡張BNFにおいて区別される。

ab) 様々なMIME登録手続のすべてを広範囲に改正した。文字集合に関するIANA登録手続は，このJIS X

5810規格群の規定に含まれない別の規格に移動した。

ac) RFC 1521，1522及び1590が定義しているUS-ASCII文字集合及びISO-8859-X文字集合におけるエス

ケープ機構及びシフト機構の使用を明確にした。これらの機構は，これらの文字集合，及びそれらの

使用が定義されないときの影響と一緒に用いてはならない。

ad) message/external-bodyのためのAFSアクセス型の定義を削除した。

ae) multipart/alternativeとmessage/external-bodyとの組合せの処理には，今は特に言及していない。

af) message/external-bodyに固有のセキュリティの課題は，今では細かく示されている。

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書C
（参考）
参考文献

この附属書は，参考文献について記載するものであって，規定の一部ではない。

ATK Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, Prentice-Hall,

1990

ISO/IEC 646:1991, 3rd ed., Information technology−ISO 7-bit coded character set for information interchange

注記 JIS X 0201:1997 7ビット及び8ビットの情報交換用符号化文字集合 (MOD)

JIS X 0202 情報技術−文字符号の構造及び拡張法

注記 ISO/IEC 2022:1994, 4th ed., Information technology−Character code structure and extension

techniques (IDT)

JPEG JPEG Draft Standard ISO/IEC 10918-1 CD

MPEG Video Coding Draft Standard ISO/IEC 11172 CD, ISO/IEC JTC1/SC2/WG11 (Motion Picture Experts

Group), May, 1991

PCM CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code Modulation (PCM) of Voice Frequencies",

Geneva, 1972

POSTSCRIPT Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, 1985

POSTSCRIPT2 Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Ed., 1990

RFC 783 Sollins, K.R., "TFTP Protocol (revision 2)", RFC 783, MIT, June 1981

RFC 821 Postel, J.B., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute,

August 1982

RFC 822 Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL,

August 1982

RFC 934 Rose, M. and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, Delaware and

NMA, January 1985

RFC 959 Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute,

October 1985

RFC 1049 Sirbu, M., "Content-Type Header Field for Internet Messages", RFC 1049, CMU, March 1988

RFC 1154 Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1154, Prime

Computer, Inc., April 1990

RFC 1341 Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for

Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992

RFC 1342 Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC 1342, University of

Tennessee, June 1992

RFC 1344 Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC 1344, Bellcore, June 1992

RFC 1345 Simonsen, K., "Character Mnemonics and Character Sets", RFC 1345, Rationel Almen Planlaegning,

June 1992

X 5810-5：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

RFC 1421 Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and

Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993

RFC 1422 Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key

Management", RFC 1422, IAB IRTF PSRG, IETF PEM WG, February 1993

RFC 1423 Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and

Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993

RFC 1424 Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and

Related Services", IAB IRTF PSRG, IETF PEM WG, February 1993

RFC 1521 Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms

for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,

September, 1993

RFC 1522 Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for

Non-ASCII Text", RFC 1522, University of Tennessee, September 1993

RFC 1524 Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information",

RFC 1524, Bellcore, September 1993

RFC 1543 Postel, J., "Instructions to RFC Authors", RFC 1543, USC/Information Sciences Institute, October 1993

RFC 1556 Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC 1556, Israeli Inter-University

Computer Center, December 1993

RFC 1590 Postel, J., "Media Type Registration Procedure", RFC 1590, USC/Information Sciences Institute, March

1994

RFC 1602 Internet Architecture Board, Internet Engineering, Steering Group, Huitema, C., Gross, P., "The Internet

Standards Process−Revision 2", March 1994

RFC 1652 Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and Crocker, D., "SMTP Service

Extension for 8-bit-MIME transport", RFC 1652, United Nations University, Innosoft, Dover Beach Consulting,

Inc., Network Management Associates, Inc., The Branch Office, July 1994

RFC 1700 Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute,

October 1994

RFC 1741 Faltstrom, P., Crocker, D., and Fair, E., "MIME Content Type for BinHex Encoded Files", December

1994

RFC 1896 Resnick, P., and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February, 1996

RFC 2048 Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four:

Registration Procedures", RFC 2048, Innosoft, MCI, ISI, November 1996

US-ASCII Coded Character Set−7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986

X400 Schicker, Pietro, "Message Handling Systems, X.400", Message Handling Systems and Distributed

Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41