JISX5810-1:2008 多目的インターネットメール拡張（ＭＩＭＥ）－第１部：インターネットメッセージ本体のフォーマット

X 5810-1：2008

（1）

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

ページ

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

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

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

1.2 概要 ···························································································································· 2

1A 引用規格 ······················································································································ 3

2 用語，定義，規約及び共通拡張BNF文法 ············································································· 3

3 MIMEヘッダフィールド ··································································································· 6

4 MIME-Version（MIME版）ヘッダフィールド ······································································· 6

5 Content-Type（内容型）ヘッダフィールド ············································································ 7

5.1 Content-Typeヘッダフィールドの構文 ··············································································· 8

5.2 Content-Typeデフォルト ································································································ 10

6 Content-Transfer-Encoding（内容転送符号化）ヘッダフィールド ·············································· 10

6.1 Content-Transfer-Encoding構文 ······················································································· 10

6.2 Content-Transfer-Encodingセマンティクス ········································································ 11

6.3 新しいContent-Transfer-Encoding ···················································································· 12

6.4 解釈及び使用 ··············································································································· 12

6.5 符号化の変換 ··············································································································· 13

6.6 正準符号化モデル ········································································································· 14

6.7 quoted-printable（印字可能引用）Content-Transfer-Encoding ················································· 14

6.8 Base64 Content-Transfer-Encoding ···················································································· 17

7 Content-ID（内容識別子）ヘッダフィールド ········································································ 19

8 Content-Description（内容記述）ヘッダフィールド ································································ 19

9 追加のMIMEヘッダフィールド ························································································ 19

10 要約 ···························································································································· 20

11 セキュリティへの考慮 ···································································································· 20

附属書A（参考）文法一覧 ···································································································· 21

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

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

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

日本工業規格 JIS

X 5810-1：2008

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

第1部：インターネットメッセージ本体の

フォーマット

Multipurpose Internet Mail Extensions (MIME)−

Part 1: Format of Internet Message Bodies

序文

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

Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies を基に，技術的内容及び構成を変

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

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

インターネット公式プロトコル規定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の規格群の第1部であり，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に，過去の版との違い及び変更について記載する。

X 5810-1：2008

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

1.2

概要

RFC 822は，1982年に出版されて以来，インターネットにおけるテキストのメールメッセージの標準フ

ォーマットを規定してきた。このフォーマットは成功を収め，インターネット及びRFC 821で定義される

インターネットSMTPトランスポートの範囲外においても，RFC 822のフォーマットが全部又は一部採択

されるなどしている。このフォーマットは，広範に使えるように見えるが，利用者コミュニティにとって

制約となる，数々の限界があることが，明らかになってきた。

RFC 822はテキストのメッセージのためのフォーマットを規定することを想定していた。したがって，

音声又は画像を含むかもしれないマルチメディアメッセージなどの，非テキストのメッセージについては

言及していない。テキストの場合であっても，US-ASCIIより豊富な文字集合の使用を必要とする言語を使

うメール利用者の必要を満たさない。RFC 822は，音声，映像及びアジア言語のテキストを含むメールの

ための機構を規定していないばかりでなく，大部分の欧州言語についても，そのテキストを含むメールの

ための機構を規定していないので，追加の規定が必要になる。

RFC 821及びRFC 822に基づくメールシステムの顕著な制限の一つは，電子メールメッセージの内容が，

7 bitのUS-ASCIIの比較的短い行（例えば，1 000文字以下 [RFC 821]）に制限されていることである。こ

のことは，局所的なメールの利用者エージェント（UA，人間の利用者がメールを送信したり受信したりす

るプログラム）を起動する前に，テキストでない送信したいデータを，印字可能なUS-ASCII文字で表現

される7 bitのバイト列に変換することを，利用者に強いる。インターネットで現在使われているこのよう

な符号化の例には，純粋な16進数，uuencode，RFC 1421で規定される3-in-4 base 64方式，Andrewツール

キット表現 [ATK]，及びその他の多くの符号化がある。

RFC 822ホストとX.400ホストとの間のメールメッセージの交換を可能にするために，ゲートウェイが

設計されると，RFC 822メールの制限は更に明らかになった。X.400 [X400] は，電子メールメッセージ内

にテキストでないデータを含める機構を規定する。X.400メッセージにRFC 822メッセージを対応付けす

るための現在の標準的な方法は，テキストでないX.400のデータを，IA5Textフォーマットに（符号化す

るのではなく）変換するか，又は，RFC 822利用者に廃棄が起こったことを通知して廃棄するかのどちら

かでなければならないことを規定する。このことは，利用者が受け取ることを望むかもしれない情報を失

うので，明らかに望ましくない。UAがテキストでないデータを処理する能力をもたない場合であっても，

利用者は，データから利用可能な情報を抽出する機構をUAの外部にもっているかもしれない。さらに，

こうした状況は，メッセージが最終的にX.400メッセージ通信処理システムへゲートウェイによって転送

されて（すなわち，X.400メッセージがインターネットメールを通り抜けるだけで），テキストでない情報

が確かに再び使えるようになる，ということを許容しない。

この規格は，現存するRFC 822の世界に深刻な非互換性をもたらすことなしに，これらの問題の多くを

解決するために組み合わせて使う，幾つかの機構について記述する。特に，次の四つの事項を記述する。

a) MIME-Version（MIME版）ヘッダフィールド MIMEに適合するメッセージを宣言するために版番

号を使用し，MIMEに適合するメッセージと，このようなフィールドがないことを仮定した旧式又は

非適合のソフトウェアによって作成されたメッセージとを，メール処理エージェントが区別すること

を可能にする。

b) Content-Type（内容型）ヘッダフィールド RFC 1049から一般化されたもので，メッセージの本体の

データのメディア型及びメディア下位型を指定するため，並びにメッセージ本体のデータの本来の表

現（正準形式）を完全に指定するために使用することができる。

c) Content-Transfer-Encoding（内容転送符号化）ヘッダフィールド本体に適用された符号化変換及び

X 5810-1：2008

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

その結果の領域の双方を指定するのに使用することができる。同一(identity)変換以外の符号化変換を

データに適用すると，データ又は文字集合についての制限をもつメール転送機構を通り抜けることが

可能になる。

d) Content-IDヘッダフィールド及びContent-Descriptionヘッダフィールド本体内のデータを更に記述

するために使うことができる二つの追加のヘッダフィールドである。

この規格で定義されるすべてのヘッダフィールドは，RFC 822に規定されるヘッダフィールドの一般構

文規則に従っている。特に，Content-Disposition（内容配置）を除くこれらのすべてのフィールドは，意味

的な内容をもたずMIME処理中には無視することが望ましいRFC 822注釈を含むことができる。

相互運用性を規定し促進するために，JIS X 5810-5は，この規格に“適合”する最小限のレベルを定義

する上記機構のサブセットのための，基本的な適用可能性宣言を規定する。

注記 JIS X 5810規格群に規定する機構の多くは，最初に読むときには，幾分不思議又は風変わりに

思われるかもしれない。既存の規定との互換性及び既存の実践における頑健さは，この一連の

規格群の原規定を作成した作業グループの，最優先事項のうちの二つであった。特に，互換性

が，優雅さよりも，常に支持された。このプロトコルの標準化状況及び状態については，“イ

ンターネット公式プロトコル規定”の現在の版(URL:http://www.rfc-editor.org/rfcxx00.html)を参

照されたい。RFC 822及びSTD 3であるRFC 1123も，MIMEの適合実装はそれらに違反でき

ないため，MIMEの本質的な背景を供給している。加えて，他の多くの参考情報(Informational)

RFC文書，特に，RFC 1344，RFC 1345及びRFC 1524は興味深い。

引用規格

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

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

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

注記 ISO/IEC 2022 Information technology−Character code structure and extension techniques (IDT)

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

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

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

JIS X 5810-3 多目的インターネットメール拡張(MIME)−第3部：非ASCIIテキストへのメッセージ

ヘッダ拡張

注記 RFC 2047 "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header

Extensions for Non-ASCII Text", November 1996が，この規格に一致している。

JIS X 5810-5 多目的インターネットメール拡張(MIME)−第5部：適合基準

注記 RFC 2049 "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and

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

ISO/IEC 8859-1 Information technology−8-bit single-byte coded graphic character sets−Part 1: Latin

alphabet No.1

用語，定義，規約及び共通拡張BNF文法

JIS X 5810規格群で規定する機構は，すべて通常の文章で記載されているが，そのほとんどはRFC 822

X 5810-1：2008

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

の拡張BNF記法を用いて形式的にも記述される。実装者は，JIS X 5810規格群を理解するために，この記

法に親しむ必要がある（拡張BNF記法の完全な説明は，RFC 822にある。）。

JIS X 5810規格群における拡張BNFの幾つかは，RFC 822で定義される構文規則へ名前付きで参照され

ている。そのため，完全な形式文法は，MIMEを規定する規格の文法一覧の附属書と，RFC 822の拡張BNF

及びRFC 1123で定義されるRFC 822の修正（具体的には，“return”，“date”及び“mailbox”の構文の変更）

とを組み合わせることによって得られる。

JIS X 5810規格群では，すべての数値及びオクテット値は，10進記法で与えられる。JIS X 5810規格群

が定義する，すべてのメディア型値，メディア下位型値及びパラメタ名は，大文字・小文字を区別しない。

しかし，パラメタ値は，特定のパラメタで特に指定される場合を除いて，大文字・小文字を区別する。

注記本質的な事項を失うことなく読み飛ばしてもよい，追加の非本質的な情報は，このような注記

として提供する。これらの非本質的な注記の主な目的は，JIS X 5810規格群の理論的根拠につ

いての情報を与えること，又はJIS X 5810規格群を適切な歴史的又は発展的な文脈に位置付け

ることである。この情報は，とりわけ，適合した実装を構築することだけに注目している人々

は読み飛ばしてもよいが，特定の設計上の選択がなぜなされたかを理解したい人々には有用な

ことがある。

2.1

CRLF（復帰改行）

用語“CRLF”は，JIS X 5810規格群では，CR（10進の値が13）及びLF（10進の値が10）の二つの

US-ASCII文字に対応し，この順番で一緒に用いられ，RFC 822メールでは行区切りを示している，オクテ

ット列とする。

2.2

文字集合，character set

用語“文字集合”は，MIMEでは，オクテット列を文字列に変換する方法とする。無条件であいまい性

のない逆方向への変換は要求されないことに注意する。すなわち，一つの与えられた文字集合において，

それで表現できない文字があってもよいし，二つ以上のオクテット列が，同じ文字列を表現していてもよ

い。

この定義は，US-ASCIIなどの単純な単一の表による対応付けから，JIS X 0202の技法を使う複雑な表切

換え方法まで，多くの種類の文字符号化を，文字集合として使用するために許すことが意図されている。

しかし，MIME文字集合の名前に関連する定義は，実行される対応付けを完全に規定しなければならない。

特に，正確な対応付けを決定する外部プロファイル情報を用いてはならない。

注記用語“文字集合”は，元来は，1オクテットから1文字への単純な1対1写像（対応付け）を

もつ，US-ASCII及びISO-8859-1といった単純な方式を記述するものであった。複数オクテッ

ト符号化文字集合及び切換え技法は，状況をより複雑にしている。例えば，ある人々は，MIME

でいうところの“文字集合( character set )”に対して，“文字符号化( character encoding )”という

用語を使う一方，オクテットではない整数から文字への抽象的な対応付けを表すのに語句“符

号化文字集合( coded character set )”を使う。

2.3

メッセージ，message

用語“メッセージ”は，何も修飾句が付かない場合には，ネットワークに転送される（完全又は最上位

の）RFC 822メッセージを意味するか，又は“message/rfc822”若しくは“message/partial”の型で本体にカプセ

X 5810-1：2008

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

ル化されたメッセージを意味する。

2.4

実体，entity

用語“実体”は，特に，MIMEで定義されたヘッダフィールド及び内容とする。ここで，内容とは，メ

ッセージか，又はマルチパート実体の本体における複数の部分の一つか，それらのいずれかとする。これ

ら実体の規定が，MIMEの本質になっている。実体の内容は“本体”と呼ばれることが多いので，実体の

本体について語ることは意味がある。実体のヘッダには，どのような種類のフィールドも存在してよいが，

実際には，“content-”で始まるフィールドだけがMIMEに関係する意味をもつ。このことは，“content-”で

始まらないフィールドが全く意味をもたないことを意味する訳ではない。RFC 822で意味が定義されてい

る非MIMEヘッダフィールドをもつメッセージも実体である。

2.5

本体部分 ( body part )

用語“本体部分”は，マルチパート実体の内部の実体とする。

2.6

本体，body

用語“本体”は，更に限定されない場合には，実体の本体の意味とする。すなわち，メッセージ又は本

体部分の本体とする。

注記 2.3〜2.6の四つの定義は，明らかに循環的である。MIMEメッセージ全体の構造は実際に再帰

的なので，このことは避けられない。

2.7

7 bitデータ ( 7 bit data )

“7 bitデータ”は，CRLF行分離シーケンスの間の，998オクテット以下の相対的に短い行として表現

されるデータとする[RFC 821]。10進の値が127より大きいオクテットがあってはならず，NUL（10進の

値が0のオクテット）があってはならない。CR（10進の値が13）及びLF（10進の値が10）は，CRLF

行分離シーケンスの一部としてだけ現れる。

2.8

8 bitデータ ( 8 bit data )

“8 bitデータ”は，CRLF行分離シーケンスの間の，998オクテット以下の相対的に短い行として表現

されるデータとする[RFC 821]。10進の値が127より大きいオクテットを用いてもよい。7 bitデータと同

様に，NULがあってはならず，CR（10進の値が13）及びLF（10進の値が10）は，CRLF行分離シーケ

ンスとしてだけ現れる。

2.9

binaryデータ ( binary data )

“binaryデータ”は，どのようなオクテットの列も含むことができるデータとする。

2.10

行 ( lines )

“行”は，CRLFシーケンスによって分離された，オクテットの列として定義される。この定義は，RFC

821及びRFC 822の両方と整合している。“行”は，メッセージの中のデータの単位としてだけ参照され，

UAが実際に表示するものと対応していてもよいし，対応していなくてもよい。

X 5810-1：2008

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

MIMEヘッダフィールド

MIMEは，MIME実体の内容を記述するために使用される多くの新しいRFC 822ヘッダフィールドを定

義する。これらのヘッダフィールドは，少なくとも次の二つの文脈で出現する。

a) 通常のRFC 822メッセージヘッダの一部として

b) マルチパート構成内のMIME本体部分ヘッダの中で

これらのヘッダフィールドの形式定義は，次のとおりとする。

entity-headers := [ content CRLF ]

[ encoding CRLF ]

[ id CRLF ]

[ description CRLF ]

*( MIME-extension-field CRLF )

MIME-message-headers := entity-headers

fields

version CRLF

; この拡張BNF定義が含むヘッダフィールドの順序付けは，

; 無視するほうがよい。

MIME-part-headers := entity-headers

[ fields ]

; “content-”で始まらないすべてのフィールドは，

; 定義された意味をもつことはできず，無視してよい。

; この拡張BNF定義が含むヘッダフィールドの順序付けは，

; 無視するほうがよい。

種々の特定のMIMEヘッダフィールドの構文は，箇条4以降に示す。

MIME-Version（MIME版）ヘッダフィールド

1982年にRFC 822が公開されて以来，それがインターネットメッセージのフォーマット規定として唯一

のものであり，使われているフォーマットの規定を宣言する必要性はほとんど認知されていなかった。こ

の規格は，RFC 822を補完する独立の規定とする。この規格で，拡張は，RFC 822と互換性のある方法で

定義されてはいるが，そうであっても，新しい規定を用いてメッセージが作成されたかどうかを，メール

処理エージェントが知っていることが望ましいかもしれない状況が存在する。

そのために，この規格は，使われているインターネットメッセージ本体のフォーマット規定の版を宣言

するために使用する，新しいヘッダフィールド“MIME-Version”を定義する。

この規格に従って作成されるメッセージは，このヘッダフィールドを，次のテキストでそのまま，含ま

なければならない。

MIME-Version: 1.0

このヘッダフィールドがあることは，メッセージがこの規格に従って作成されていることを明言してい

る。

将来の規格がメッセージフォーマットの規定を再び拡張するかもしれないことを可能とするので，

X 5810-1：2008

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

MIME-Versionヘッダフィールドの内容のための形式拡張BNFは，次による。

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

そこで，“1.0”を置き換える又は拡張するかもしれない，将来のフォーマット指定子は，ピリオドで分離

された二つの整数フィールドに制限される。“MIME-Version”の値が“1.0”以外のメッセージを受け取る場合，

この規格に適合するとみなすことはできない。

MIME-Versionヘッダフィールドは，メッセージの最上位にあることが要求されることに注意する。マル

チパート実体のそれぞれの本体部分には要求されない。“message/rfc822”型又は“message/partial”型の本体に

組み込まれたヘッダに対しては，組み込まれたメッセージそれ自体がMIME適合になっていると主張され

る場合に限り，要求される。

この規格で定義されるとおりにMIMEと適合するメールリーダが，将来到着するかもしれない“1.0”以外

のMIME-Versionの値をもつメッセージをどう扱うのがよいかを，完全に規定することは可能ではない。

特定のメディア型の版管理は，MIME-Version機構を使っては，達成されないことに注意する。特に，

application/postscriptといった幾つかのフォーマットは，メディアフォーマット内部に版番号付け規約をも

つ。これら規約が存在する場合には，MIMEはそれにとって代わることはしない。これら規約が存在しな

い場合には，必要があれば，MIMEメディア型は，内容型フィールドの中で“version”パラメタを使うかも

しれない。

注記 MIME-Versionの値を検査するとき，RFC 822注釈文字列がある場合には，それらを無視する。

特に，次の四つのMIME-Versionヘッダフィールドは等価とする。

MIME-Version: 1.0

MIME-Version: 1.0 (produced by MetaSend Vx.x)

MIME-Version: (produced by MetaSend Vx.x) 1.0

MIME-Version: 1.(produced by MetaSend Vx.x)0

MIME-Versionヘッダフィールドがなかった場合，受信側のメールUAは，MIME要件に適合していても

していなくても，局所的な規約に基づき，メッセージの本体を解釈することを選んでよい。多くのこれら

規約は現在使われており，実際には非MIMEメッセージが，ほとんど何でも含むことができることに注意

したほうがよい。

非MIMEメールメッセージが，実際にUS-ASCII文字集合を用いたプレーンテキストであるかは，確実

ではない。これは，MIME以前の非標準の局所的な規約の集合を使って，他の文字集合を用いたテキスト，

又は例えば圧縮( compress )されてuuencodeされたUNIX tarファイルなどの，自動的には認識できない方

法によって表現されたテキストでないデータを含むメッセージであるかもしれないことによる。

Content-Type（内容型）ヘッダフィールド

Content-Typeフィールドは，受信側のUAが，利用者にデータを表示するために，適切なエージェント

若しくは機構を選ぶこと，又は適切な方法でデータを扱うことができるほど十分に，本体に含まれるデー

タを記述することを目的としている。このフィールドに含まれる値は，メディア型と呼ばれる。

注記 Content-Typeヘッダフィールドは，最初，RFC 1049で定義された。RFC 1049では，より単純

で強力ではない構文を使っていたが，その多くは，この規格（及び原規定のRFC 2045）で与え

る機構と大部分は互換性がある。

Content-Typeヘッダフィールドは，メディア型及びメディア下位型の識別子を与えること，及びある種

のメディア型が要求することのある補助情報を提供することによって，実体の本体中のデータの性質を指

X 5810-1：2008

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

定する。メディア型及びメディア下位型の名前の後の，ヘッダフィールドの残りは，単に，“属性=値”の記

法で指定されたパラメタの集合とする。パラメタの順番は意味をもたない。

一般に，最上位のメディア型は，データの一般的な型を指定し，メディア下位型は，そのデータの型に

対する特定のフォーマットを指定する。そこで，メディア型“image/xyz”は，UAが“xyz”という特定の画像

フォーマットを知らなかったとしても，データが画像であることを知らせるのに十分である。このような

情報は，例えば，認識されないメディア下位型からの生データを利用者に見せるかどうかを決定するため

に利用できる。テキストの場合には，認識されないメディア下位型の生データを利用者に見せるのが妥当

であっても，画像又は音声の場合には妥当でないことがあるので，最上位のメディア型を使うことが必要

となる。このように，認識されないメディア下位型の処理の問題があるので，テキスト，画像，音声及び

映像の登録されたメディア下位型は，より下位において認識できない型への分化を生むような組込み情報

を含まないほうがよい。これら複合フォーマットは，“multipart”型又は“application”型を用いて表したほう

がよい。

パラメタは，メディア下位型の修飾子であって，内容の性質には，基本的には影響しない。意味のある

パラメタの集合は，メディア型及びメディア下位型に依存する。ほとんどのパラメタは，単一の特定のメ

ディア下位型に関連する。ただし，与えられた最上位のメディア型が，その型のどのメディア下位型へも

適用可能なパラメタを定義してもよい。内容型又はメディア下位型の定義によって，パラメタは必す（須）

であってもよいし，オプションであってもよい。MIME実装は，認識しない名前のパラメタを無視しなけ

ればならない。

例えば，“charset”パラメタは，“text”のあらゆるメディア下位型に適用でき，“boundary”パラメタは，

“multipart”メディア型のあらゆるメディア下位型に要求される。

すべてのメディア型に適用される大域的に意味のあるパラメタは存在しない。真に大域的な機構は，

MIMEモデルでは，付加的なContent-*ヘッダフィールドの定義によって，最もよく言及される。

七つの最上位メディア型の初期集合は，JIS X 5810-2で定義される。そのうち五つは，MIME処理が関

係する限りにおいては，本質的に不透明な内容をもつ別々の型とする。残りの二つは，MIME処理系によ

って追加の処理が必要な内容の複合型とする。

最上位メディア型のこの集合は，実質的に，完全となることを意図している。一般に，サポートされる

型のより大きな集合への追加は，これら初期の型の新しいメディア下位型を作ることによって，達成され

る。将来，この規格への標準化手続の拡張によってだけ，より多くの最上位の型を定義してよい。何らか

の理由によって他の最上位型を使うことが望ましい場合，非標準の状況を示すため，及び将来の公式の名

前と衝突する可能性を避けるために，その型には，“X-”で開始する名前を与えなければならない。

5.1

Content-Typeヘッダフィールドの構文

Content-Typeヘッダフィールドの値は，RFC 822の拡張BNF記法を用いて，次のとおりに定義される。

content := "Content-Type" ":" type "/" subtype

*(";" parameter)

; メディア型及びメディア下位型の合致は，

; 常に大文字・小文字を区別しない。

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" /

X 5810-1：2008

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

"application" / extension-token

composite-type := "message" / "multipart" / extension-token

extension-token := ietf-token / x-token

ietf-token := <標準化手続のRFCによって定義され，IANAで登録された拡張トークン>

x-token := <“X-”又は“x-”の2文字で始まり，空白を含まない，任意のトークン。>

subtype := extension-token / iana-token

iana-token := <公式に定義された拡張トークン。

この形式のトークンは，RFC 2048で規定されるとおりに

IANAに登録されなければならない。>

parameter := attribute "=" value

attribute := token

; 属性の合致は，

; 常に大文字・小文字を区別しない。

value := token / quoted-string

token := 1*<SPACE，CTL，tspecialsを除く，任意の(US-ASCII) CHAR>

tspecials := "(" / ")" / "<" / ">" / "@" /

"," / ";" / ":" / "\" / <">

"/" / "[" / "]" / "?" / "="

; パラメタ値内で使うため，

; quoted-stringでなければならない。

tspecialsの定義は，“/”，“?”及び“=”の3文字を追加したこと，並びに“.”を削除したこと以外は，RFC 822

のspecialの定義と同じであることに注意する。

メディア下位型の指定は必す（須）であることにも注意する。すなわち，メディア下位型の指定は，

Content-Typeヘッダフィールドから省いてはならない。このように，デフォルトのメディア下位型は存在

しない。

メディア型名，メディア下位型名及びパラメタ名は，大文字・小文字を区別しない。例えば，TEXT，

Text及びTeXtは，等価な最上位のメディア型とする。パラメタ値は，通常，大文字・小文字を区別するが，

意図される使用によっては，大文字・小文字を区別しないように解釈されることがある。例えば，マルチ

パート境界は大文字・小文字を区別するが，message/External-bodyの“access-type”パラメタは大文字・小文

X 5810-1：2008

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

字を区別しない。

引用文字列( quoted-string )パラメタの値は引用符を含まないことに注意する。すなわち，quoted-stringの

中の引用符はパラメタ値の一部ではなく，単にパラメタ値を区切るのに使われる。さらに，構造化ヘッダ

フィールドに関するRFC 822規則に従う注釈は許される。そこで，次の二つの形式は完全に等価とする。

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

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

この構文以外の，メディア下位型名の定義における構文上の唯一の制約は，それらの使用は重複しては

ならないという要求とする。すなわち，二つの異なる意味の“Content-Type: application/foobar”を使う，二つ

の異なるコミュニティがあることは望ましくない。そこで，新しいメディア下位型を定義する過程は，制

限を課すための機構を意図しているのでなく，単純にそれらの定義及び使い方を公にする機構とする。そ

のために，新しいメディア下位型を定義するための受入可能な次の二つの機構が存在する。

a) “X-”で始まる私的な値は，外部での登録又は標準化なしに二つの協力的エージェントの間で双方で（合

意して）定義してよい。これらの値は，登録又は標準化することはできない。

b) 新しい標準の値は，RFC 2048に記述されるとおりにIANAに登録することが望ましい。

MIMEを規定する2番目の規格( JIS X 5810-2 )では，MIMEのメディア型の初期集合を定義する。

5.2

Content-Typeデフォルト

MIMEのContent-TypeヘッダなしのデフォルトのRFC 822メッセージは，このプロトコルによって，

US-ASCII文字集合によるプレーンテキストとされ，明示的に次のとおりに指定できる。

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

このデフォルトは，Content-Typeヘッダフィールドが指定されなかった場合を想定している。構文的に

有効でないContent-Typeヘッダフィールドに遭遇したときにも，このデフォルトを想定することが望まし

い。MIME-Versionヘッダフィールドが存在し，Content-Typeヘッダフィールドが存在しない場合，受信側

のUAは，プレーンUS-ASCIIテキストが送信者の意図であったと想定することもできる。MIME-Version

が存在しない，又は構文上有効でないContent-Typeヘッダフィールドが存在する場合であって，送信者の

意図によらず，プレーンUS-ASCIIテキストを想定してもよい。

Content-Transfer-Encoding（内容転送符号化）ヘッダフィールド

電子メールによって便利に転送できる多くのメディア型は，8 bit文字又はbinaryデータとして，“自然

な”フォーマットで表現される。これらのデータは，幾つかの転送プロトコルでは転送することができな

い。例えば，RFC 821 ( SMTP ) は，メールメッセージを，末尾のCRLF行分離子を含む1 000文字以下の

行をもった7 bitUS-ASCIIデータに制限する。

したがって，これらデータを7 bitの短い行のフォーマットに符号化する標準的な機構を定義する必要が

ある。制限の少ないトランスポート上での直接使用のために，制限の少ないフォーマットの中での符号化

されていないデータを適切にラベル付けすることも望まれる。この規格は，これら符号化が新しい

“Content-Transfer-Encoding”ヘッダフィールドによって指示されることを規定する。このフィールドは，今

までのいかなる規定によっても定義されていない。

6.1

Content-Transfer-Encoding構文

Content-Transfer-Encodingフィールド値は，次に列挙されるとおり，符号化の型を指定する単一トークン

とする。形式文法は次による。

encoding := "Content-Transfer-Encoding" ":" mechanism

X 5810-1：2008

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

mechanism := "7bit" / "8bit" / "binary" /

"quoted-printable" / "base64" /

ietf-token / x-token

これらの値は大文字・小文字を区別しない。Base64，BASE64及びbAsE64はすべて等価とする。7 bit

の符号化型は，本体が既に7 bitメールに使える表現であることを要求する。これは，デフォルト値とする。

すなわち，Content-Transfer-Encodingフィールドがない場合は，“Content-Transfer-Encoding: 7bit”が仮定され

る。

6.2

Content-Transfer-Encodingセマンティクス

この単一のContent-Transfer-Encodingトークンは，実際には，二つの情報を提供する。これは，本体がど

んな種類の符号化変換に従っているか（そのために，それを元の形式に戻すためにどの復号操作を使わな

ければならないか）及び結果の領域が何になるかを指定する。

Content-Transfer-Encodingの提供する二つの情報のうちの変換に関する部分は，単一の明確に定義された

復号アルゴリズムを，明示的に又は暗黙的に，指定する。このアルゴリズムは，符号化されたオクテット

のすべての列に対して，符号化される前の元のオクテット列に変換するか，又は符号化列として不正であ

ることを示すかのいずれかを行う。Content-Transfer-Encodingは，適切な操作のために追加される外部プロ

ファイル情報に依存することはない。復号器は，有効な符号化に対して，単一の明確に定義された出力を

生成しなければならないが，符号化器にはこのような制限はないことに注意する。すなわち，与えられた

同じオクテット列を，場合によって異なる等価な符号化列へと符号化することは完全に正しい。

同一（符号化変換），“quoted-printable”（印字可能引用）符号化及び“base64”符号化の三つの変換が，現

在定義されている。その（変換）領域は，“binary”，“8 bit”及び“7 bit”とする。

Content-Transfer-Encoding値の“7 bit”，“8 bit”及び“binary”は，すべて同一符号化変換がなされること，す

なわち，いかなる符号化変換もなされないことを意味する。このように，それらは単に本体データの領域

の指示子として役に立ち，与えられたトランスポートシステムにおいて転送のために必要かもしれない符

号化の種類についての有用な情報を提供する。用語“7 bitデータ”，“8 bitデータ”及び“binaryデータ”

は，すべて箇条2で定義されている。

quoted-printable符号化及びbase64符号化は，任意の領域からの入力を“7 bit”範囲のデータへと変換する

ので，制限のあるトランスポートシステムで運ぶことを安全にする。変換の特定の定義は，後に示す。

正しいContent-Transfer-Encodingラベルが常に使われなければならない。8 bit文字を含む符号化されて

いないデータを“7 bit”とラベル付けしてはならず，行に基づかない符号化されていないデータを“binary”以

外にラベル付けしてはならない。

メディア下位型と違って，Content-Transfer-Encoding値の増加は望ましくないし不必要でもある。しかし，

“7 bit”領域への単一の変換だけを制定する訳にはいかない。多くのbinaryデータの小規模で効率的な符号

化に対する要望と，ほとんどが7 bitだがすべてではないデータのある程度可読性のある符号化に対する要

望との間にはトレードオフが存在する。この理由によって，少なくとも二つの符号化機構，すなわち，多

かれ少なかれ可読性のある符号化(quoted-printable)及び“密な”又は“一様な”符号化( base64 )が，必要で

あった。

符号化されていない8 bitデータのメールトランスポートは，RFC 1652で定義されている。この規格の

原規定の初期の公開のときには，メール本体に符号化されていないbinaryデータを含めるのに適正な，標

準化されたインターネットメールトランスポートは存在しなかった。そこで，インターネットメールにお

X 5810-1：2008

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

いて“binary”Content-Transfer-Encodingが実際に有効である状況は存在しなかった。しかし，binaryメールト

ランスポートがインターネットメールで現実のものとなるか，又はMIMEが他のbinary可能なメールトラ

ンスポート機構と一緒に使われる場合には，binaryの本体は，この機構を使うものとしてラベル付けされ

なければならない。

注記 Content-Transfer-Encodingフィールドのために定義される五つの値は，そのフィールドが符号化

されたアルゴリズム，又は符号化されない場合にはトランスポートシステム要件以外は，メデ

ィア型について何も示唆しない。

6.3

新しいContent-Transfer-Encoding

実装者は，必要ならば，私的Content-Transfer-Encoding値を定義してよいが，非標準の状態を示す“X-”

で始まる名前の，x-tokenを使わなければならない（例えば，“Content-Transfer-Encoding: x-my-new-encoding”）。

標準として追加するContent-Transfer-Encoding値は標準化手続のRFCによって規定されなければならない。

これら規定が満たさなければならない要件は，RFC 2048で与えられる。このようにして，“X-”で始まるも

のを除き，すべての内容転送符号化の名前空間は，IETFで将来の使用のために明示的に予約されている。

注記 Content-Transfer-Encoding値は大文字・小文字を区別しないので，“X-”と“x-”とは同等である。

メディア型及びメディア下位型と異なり，新しいContent-Transfer-Encoding値の生成は，ほとんど可能性

のない利益のために互換性を妨げることが多いと考えられるので，強く非推奨とする。

6.4

解釈及び使用

Content-Transfer-Encodingヘッダフィールドが，メッセージヘッダの一部として現れる場合，そのメッセ

ージの本体全体に適用される。Content-Transfer-Encodingヘッダフィールドが，実体ヘッダの一部として現

れる場合，その実体全体に適用される。実体が“multipart”の型である場合，Content-Transfer-Encodingは，“7

bit”，“8 bit”又は“binary”以外の値をもってはならない。“message”型の幾つかのメディア下位型へは，更に

厳しい制限を適用する。

ほとんどのメディア型は，bitでなくオクテットを用いて定義されていて，ここで示される機構は，ビッ

トストリームではなく，任意のオクテットストリームを符号化するための機構となっていることに注意す

るほうがよい。これらの機構のうちの一つを通してビットストリームが符号化される場合，ネットワーク

で標準のビット順（ビッグエンディアン），すなわち，ストリームの中で最初のほうのビットが，8 bitバ

イトの中の高位ビットになるように，まず最初にビットストリームが8 bitバイトストリームに変換されな

ければならない。8 bit境界で終わらないビットストリームは，0を用いてパディングされなければならな

い。JIS X 5810-2は，“padding”パラメタをもつapplication/octet-streamメディア型の場合に，それらパディ

ングの追加に言及する機構を提供する。

ここで定義する符号化機構は，US-ASCIIのすべてのデータを明示的に符号化する。そこで，例えば，次

のヘッダフィールドをもつ実体を想定する。

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

Content-Transfer-Encoding: base64

これは，本体が，元はISO-8859-1だったデータのbase64 US-ASCII符号化であって，復号後は，その文

字集合になることを意味すると，解釈されなければならない。

あるContent-Transfer-Encoding値は，あるメディア型だけに使われ，他のメディア型には使えないことが

ある。特に，“7 bit”，“8 bit”又は“binary”以外の符号化を複合的なメディア型（他のContent-Typeフィール

ドを再帰的に含むメディア型。）に使用することは，明確に禁止される。現在，複合的なメディア型は，

“multipart”及び“message”だけである。multipart型又はmessage型の本体の符号化は，すべて，最も内側の

X 5810-1：2008

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

レベル，すなわち符号化されることが必要な実際の本体のところでなされなければならない。

複合的な実体が“7 bit”になる内容転送符号化値をもつが，それに取り囲まれた実体の一つが“8 bit”といっ

たより制限のゆるい値をもつ場合，内側に実際に8 bitデータが含まれていて，外側の“7 bit”というラベル

付けが，エラーであるか，又は内側に実際に含まれているデータが実は7 bit安全なデータであって，内側

の“8 bit”というラベル付けが，トランスポートシステムに不必要な高い要求を課しているのか，そのいず

れかであることが明らかだということを注意しておく。

注記1 複合的な本体データに内容転送符号化( Content-Transfer-Encoding )を使うことを禁止するの

は過度に制限的と思われるかもしれないが，これは，データが一つの符号化アルゴリズムを

複数回通過し，適切に見るために複数回復号をしなければならないという，入れ子になった

符号化を防ぐために必要とする。入れ子になった符号化は，UAに相当な複雑さを加える。

これら複数回符号化の明白な効率の問題とは別に，入れ子になった符号化は，メッセージの

基本構造を不明りょうにすることがある。特に，入れ子になった符号化は，メッセージがど

んな型の本体を含むかを単に見付けるために，何回もの復号操作が必要になることを示唆す

る。入れ子になった符号化を禁止することは，特定のメールゲートウェイの仕事を複雑にす

るかもしれないが，入れ子になった符号化がUAへ及ぼす影響に比べれば，問題が少ないよ

うに思われる。

認識されないContent-Transfer-Encodingをもつ実体は，Content-Typeヘッダフィールドに実際に何と書い

てあるかにかかわらず，“application/octet-stream”のContent-Typeをもつものとして取り扱われなければな

らない。

注記2 Content-Transfer-Encodingは，符号化されるメディアの特質から推測できるか，又は少なくと

もあるContent-Transfer-Encodingを特定のメディア型とともに使用するのが必す（須）となる

ものと思われるかもしれない。これが事実でない幾つもの理由がある。まず，メールに使わ

れるトランスポートの様々な型を与えた場合，ある符号化はメディア型とトランスポートと

のある組合せに対して適切だが，他の組合せには適切でなくともよい。例えば，8 bitトラン

スポートでは，特定の文字集合によるテキストに対して符号化は必要でないが，7 bitSMTP

では，それら符号化が明白に必要とされる。

次に，特定のメディア型は，異なる状況では異なる型の内容転送符号化を要求することがあ

る。例えば，多くのPostScriptの本体は，全体的には7 bitデータの短い行から構成されるかも

しれないので，その場合，符号化は必要でない。他のPostScriptの本体，特に，レベル2 PostScript

のbinary符号化機構を使った本体は，binaryトランスポート符号化を使った場合にだけ適切に

表現されてよい。最後に，Content-Typeフィールドは拡張可能な指定機構となることを意図し

ているので，メディア型と符号化との間の関連の厳密な指定が，応用プロトコルの指定と特定

の下位トランスポートとを効果的に結び付けることになる。このことは，メディア型の開発者

が，使われているすべてのトランスポート及びそれらの制限について意識しなければならない

ので，望ましくない。

6.5

符号化の変換

quoted-printable符号化及びbase64符号化は，それらの間の変換が可能なように設計されている。これら

変換において生じる唯一の課題は，quoted-printable符号化出力での原文内( hard )行区切りの扱いである。

quoted-printableからbase64に変換するとき，quoted-printable形式の原文内( hard )行区切りは，データの正

準形式のCRLF列で表現される。そこで，その行区切りは，データのbase64形式での対応する符号化され

X 5810-1：2008

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

たCRLFへ変換されなければならない。同様に，base64復号後に得られるデータの正準形式でのCRLF列

は，テキストデータを変換するときにだけ，quoted-printableでの原文内( hard )行区切りに変換されなけれ

ばならない。

6.6

正準符号化モデル

この規格の原規定であるRFCの以前の版では，電子メールデータが正準形式に変換され符号化されると

きのモデルについて，特に，システムごとに改行の表現が非常に異なっているときに，この（変換）処理

が，CRLFの振る舞いにどう影響するか，及び内容転送符号化と文字集合との間の関係にどう影響するか

について，多少の混乱があった。この理由から，符号化のための正準モデルが，JIS X 5810-5で提示され

る。

6.7

quoted-printable（印字可能引用）Content-Transfer-Encoding

quoted-printable符号化は，大部分がUS-ASCII文字集合の中の印字可能文字に対応するオクテットから

構成されるデータを表現することを意図している。この符号化は，結果として生じるオクテットがメール

トランスポートによって変更されることはまずないといった方法で，データを符号化する。符号化される

データがほとんどUS-ASCIIテキストの場合，データの符号化された形式は，人によって大部分認識可能

なままになっている。全体がUS-ASCIIである本体も，文字変換及び／又は行折返しを行うゲートウェイ

をメッセージが通過する場合に，データの完全性を保証するために，quoted-printableによって符号化して

もよい。

この符号化では，オクテットは，次の規則によって決定されるとおりに表現されるのが望ましい。

a) 一般8 bit表現符号化されるデータの正準形式（標準形式）のCRLF行区切りの一部であるCR又は

LFを除くあらゆるオクテットは，一つの“=”にそのオクテットの値の16進表現の二つの数字（2けた

の16進数）を続けたもので表してよい。この目的のために使う16進の数字は，“0123456789ABCDEF”

とする。大文字を使わなければならず，小文字は使ってはならない。例えば，10進の値が12( US-ASCII

form feed )は“=0C”で表現でき，10進の値が61( US-ASCII EQUAL SIGN )は“=3D”で表現できる。後続

の規則が代替の符号化を許す場合を除き，この規則には従わなければならない。

b) 文字表現 10進の値が33以上60以下及び62以上126以下のオクテットは，それらのオクテットに

対応するUS-ASCII文字，それぞれ，EXCLAMATION POINTからLESS THANまで及びGREATER

THANからTILDEまで，として表現してよい。

c) 空白 10進の値が9及び32のオクテットは，US-ASCIIのTAB( HT )文字及びSPACE文字として表現

してよいが，符号化された行の末尾で表現してはならない。符号化された行のTAB( HT )文字及び

SPACE文字には，印字可能文字がその行で後続しなければならない。符号化された行の末尾の“=”は，

無指定( soft )行区切り［規則e)を参照］を示しているが，一つ以上のTAB( HT )文字又はSPACE文字

に続いてもよい。これは，符号化された行の末尾で10進の値が9又は32のオクテットは，1番目の

規則によって表現されなければならないことに従っている。MTA［Message Transport Agent（メッセー

ジ転送エージェント），すなわち，一人の利用者から他の利用者へのメッセージを転送する，又はそれ

ら転送の一部を実行するプログラム］の中には，テキストの行をSPACEでパディングするものがあ

ることが知られていて，更に行末から“空白”文字を取り除くものも知られているので，この規則が必

要になる。そのために，中間の転送エージェントによって空白が加えられることが避けがたいので，

quoted-printable本体を復号するとき，行の末尾に付いているすべての空白を削除しなければならない。

d) 改行テキストの正準形式ではCRLF列として表現される，テキスト本体中の行区切りは，

quoted-printable符号化では，やはりCRLF列であるRFC 822の行区切りによって表現されなければな

X 5810-1：2008

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

らない。テキスト以外のメディア型の正準表現は一般にはCRLF列としての行区切りの表現を含まな

いので，原文内( hard )行区切り（すなわち，意味があり，利用者に表示されることを意図している行

区切り）は，これらの型のquoted-printableには出現できない。もちろん，quoted-printableで表現され

たテキストでないデータには，“=0D”，“=0A”，“=0A=0D”及び“=0D=0A”といった列は，機械的に現れ

ることがある。

多くの実装は，まず正準形式に変換し，符号化し，それから局所的な表現に戻すのではなく，直接

に様々な内容型の局所的な表現を符号化することを選んでもよいことに注意する。特に，このことを，

CRLF終端子列ではない改行規約を使うシステムで，プレーンテキストのデータに適用してもよい。

このような実装の最適化は許されるが，（それと）組み合わされた正準化符号化の段階が，三つの段階

を別々に実施するのと等価な場合だけに限る。

e) 符号化時(soft)行区切り quoted-printable符号化では，符号化された行が76文字を超えてはならない。

quoted-printable符号化でそれより長い行が符号化される場合，“符号化時( soft )”行区切りが使われな

ければならない。符号化された行の最後の文字としての等号は，符号化されたテキストの中で意味が

ない“符号化時( soft )”行区切りを示す。

そこで，行の“元の( raw )”形式が，次の符号化されていない単一の行の場合を考える。

Now's the time for all folk to come to the aid of their country.

quoted-printable符号化では，これを次のとおりに表せる。

Now's the time =

for all folk to come=

to the aid of their country.

これは，UAによって元に戻されるといった方法で，長い行を符号化する機構を提供する。76文字制限

は，末尾のCRLFを数えないが，等号を含めた他のすべての文字を数える。

ハイフン文字(“-”)は，それ自体，quoted-printable符号化で表現してよいので，一つ以上のマルチパート

実体の内部にquoted-printableで符号化された本体をカプセル化するときには，その境界区切り子1)が，符

号化された本体のどこにも現れないことを保証するために，注意をしなければならない。よい戦略として

は，quoted-printable（で符号化された）本体には現れることのない“=̲” といった文字列を境界に選ぶこと

がある。JIS X 5810-2のマルチパートメッセージの定義を参照1)。

注記1 quoted-printable符号化は，可読性と転送における信頼性との折衷的なものを表現している。

quoted-printable符号化で符号化された本体は，ほとんどのメールゲートウェイにおいて高い

信頼性で動作するが，少数のゲートウェイ，特に，EBCDICへの変換を伴うものでは完全に

は動かないかもしれない。より高いレベルの信頼性は，base64 Content-Transfer-Encodingによ

って提供される。EBCDICゲートウェイを通る妥当な信頼性のある転送を得る方法は，次の

US-ASCII文字も，前の1番目の規則で示した16進表現にすることである。

!"#$@[\]^̀{|}~

quoted-printableデータは一般に行に基づくことを仮定しているので，改行規約の異なるシス

テム間で渡されるとき，インターネットメールにおいてプレーンテキストメールが常に変更

されてきたのと同じように，quoted-printableデータの行の間の区切りの表現は，転送中に変

更されるかもしれないと予想される。これら変更が，データの変造を引き起こす可能性があ

る場合，quoted-printable符号化ではなく，base64符号化を使うことがおそらくより賢明とい

える。

X 5810-1：2008

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

注記2 quoted-printable内容転送符号化のための符号化規則に従って，ある種の部分文字列を生成す

ることはできない。したがって，quoted-printable符号化器の出力にそれらが出現する場合は，

形式的には不正とする。この注記は，これらの場合を列挙し，復号されるquoted-printableデ

ータの中で次のどれかに出会う場合，それら不正な部分文字列を取り扱う方法を示す。

a) 一つ又は両方が“abcdef”のうちのいずれかの小文字となっている二つの16進数字に後続

される“=”は，形式的には不正とする。頑健な実装は，それらを対応する大文字として認

識するとよいかもしれない。

b) “abcdef”の場合を含む16進の数字でなく，CRLF対のCR文字でもない文字に後続され

る“=”は，不正とする。この場合は，それ自体がquoted-printable符号化に従っていない，

メッセージのquoted-printable部分に含まれている，US-ASCIIテキストの結果の可能性

がある。頑健な実装による理にかなった方針は，復号されたデータに，“=”文字及びそれ

に後続する（一つの）文字を変換せずに含ませ，可能な場合には，利用者に，データの

この箇所で適切な復号ができなかったことを示すことかもしれない。

c) “=”は，符号化されたオブジェクトの中で最後又は最後から2番目の文字となることはで

きない。これは，前項の場合として取り扱ってよい。

d) TAB，又はCRLF対の一部としてのCR及びLF，以外の制御文字は現れてはならない。

10進の値が126より大きい値のオクテットに対しても同じとする。それらの文字が，復

号器によって，到着したquoted-printableデータの中に発見された場合，頑健な実装は，

復号されたデータからそれら文字を除外し，利用者に不正文字が発見されたことを警告

するとよいかもしれない。

e) 符号化した行は，末尾のCRLFを数えずに，76文字より長くてはならない。より長い行

が到着した符号化されたデータの中に発見された場合，頑健な実装は，エラーではある

がその行を復号し，利用者にエラーのある符号化であることを報告するとよいかもしれ

ない。

注記3 binaryデータがquoted-printableで符号化される場合，CR文字及びLF文字をそれぞれ“=0D”

及び“=0A”として符号化することに注意しなければならない。特に，binaryデータでのCRLF

列は，“=0D=0A”と符号化するのがよい。そうでない場合であって，CRLFが指定( hard )行区

切りとして表現される場合，異なった行区切り規約をもつプラットホームでは，正しく復号

されないかもしれない。

注1) JIS X 5810-2において，境界区切り子は，ハイフン文字を使って定義されている。

quoted-printableデータの構文は，次の形式文法で記述される。

quoted-printable := qp-line *(CRLF qp-line)

qp-line := *(qp-segment transport-padding CRLF)

qp-part transport-padding

qp-part := qp-section

; 最大長76文字。

qp-segment := qp-section *(SPACE / TAB) "="

X 5810-1：2008

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

; 最大長76文字。

qp-section := [*(ptext / SPACE / TAB) ptext]

ptext := hex-octet / safe-char

safe-char := <10進の値が33〜60及び62〜126をもつ任意のオクテット>

; 更に，JIS X 5810-5の“mail-safe”の一覧にない

; 文字も推奨しない。

hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

; 127より大きな文字，=，又は行末のSPACE若しくはTABには

; hex-octetが使われなければならず，

; JIS X 5810-5で“mail-safe”の一覧にない文字のためには

; hex-octetが推奨される。

transport-padding := *LWSP-char

; 送信者は，長さが0ではないトランスポート

; パディングを生成してはならないが，

; 受信者は，メッセージトランスポート

; によって追加されたパディングを

; 処理できなければならない。

この拡張BNFでは構造化ヘッダフィールドを規定していないので，この拡張BNFに示される要素間で

のLWSP（空白の並び）の追加は許されない。このことは，重要である。

6.8

Base64 Content-Transfer-Encoding

Base64 Content-Transfer-Encodingは，任意のオクテット列を，人が読めなくともよい形式で，表現するた

めに設計された。符号化及び復号のアルゴリズムは単純だが，符号化されたデータは，符号化されていな

いデータに比べ，一貫しておよそ33パーセントほど大きい。この符号化は，実質的に，RFC 1421で定義

されている，Privacy Enhanced Mail ( PEM ) アプリケーションと同等になっている。

US-ASCIIの65文字の部分集合を使用し，印字可能な一つの文字ごとに6 bitを表現可能とする。65番

目の文字“=”は，特別な処理機能を意味するために使用する。

注記1 この部分集合は，US-ASCIIを含むISO/IEC 646のすべての版で同一に表現されるという，重

要な特性をもち，このすべての文字は，EBCDICのすべての版でも，同一に表現される。

uuencodeユティリティ，Macintoshのbinhex 4.0 [RFC 1741]及びレベル 2 PostScriptの一部と

して規定されるbase85符号化といった，他のよく利用される符号化は，この特性を共有せず，

そのために，メール用のbinary内容転送符号化が満たさなければならない可搬性要件を満足

しない。

符号化処理は，四つの符号化文字の出力列として，入力ビットの24 bit（単位の）群( 24-bit group )を表

現する。左から右へと進めて，一つの24 bitの入力群が，三つの8 bit入力群を連結することによって，形

X 5810-1：2008

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

成される。次に，これらの24 bitを，四つの連結された6 bit群として取り扱い，それぞれをbase64アルフ

ァベット（base64の構成単位）における単一の数字へと変換する。base64符号化を通じてビットストリー

ムを符号化する場合，ビットストリームは，最上位ビットが先になる順番と仮定されていなければならな

い。すなわち，ビットストリームの最初のビットは，最初の8 bit（単位の）バイトの中の上位ビットとな

り，8番目のビットは，最初の8 bit（単位の）バイトの中の下位ビットとなる，など，以下同様とする。

それぞれの6 bit群は，64個の印字可能文字の配列へのインデクスとして使われる。インデクスによっ

て参照される文字が，出力列の中に置かれる。次の表1で識別されるこれらの文字は，広い範囲で表現可

能なように選ばれ，例えば，“.”，CR，LFなどの，SMTPに対して特定の意味をもつ文字，及び例えば“-”

などのJIS X 5810-2で定義されるマルチパート境界区切り子に対して特定の意味をもつ文字を除外してあ

る。

表1−Base64アルファベット

値

符号

値

符号

値

符号

値

符号

(pad)

符号化された出力ストリームは，それぞれ76文字を超えない行で表現されなければならない。すべての

行区切り又は表1にない他の文字は，復号ソフトウェアによって，無視されなければならない。base64デ

ータの中の，表1以外の文字，行区切り及びその他の空白は，おそらく，ある状況では警告メッセージ又

はメッセージ拒否が適切かもしれない，転送誤りを示す。

符号化されるデータの末尾において，24 bitに満たない場合には，特別な処理が実行される。本体の末

尾では常に欠けることのない符号化の分量で完結する。入力群の中で，24よりも少ない入力ビットが存在

する場合，値0のビットが右に追加され，6 bit群を単位とする整数倍の数へと整形される。データの末尾

へのパディングは“=”文字を使って実行される。すべてのbase64入力はオクテットの整数倍の数なので，

次の場合だけが発生する。

a) 符号化入力の最後の分量が，24 bitの整数倍になっている。この場合，符号化出力の最後の単位（か

たまり）は，“=”パディングなしで4文字の整数倍となる。

b) 符号化入力の最後の分量が，ちょうど8 bitになっている。この場合，符号化出力の最後の単位（かた

まり）は，二つの文字に，二つの“=”パディング文字が後続したものとなる。

X 5810-1：2008

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

c) 符号化入力の最後の分量が，ちょうど16 bitになっている。この場合，符号化出力の最後の単位（か

たまり）は，三つの文字に，一つの“=”パディング文字が後続したものとなる。

“=”文字はデータの最後のパディングのためだけに用いられるので，途中で切り取られなかった場合には，

“=”文字の出現はデータの最後に到達した証拠とみなしてもよい。しかし，転送されたオクテットの数が3

の倍数であって“=”文字が存在しないときは，このような保証は可能ではない。

base64アルファベット以外の文字は，base64符号化データの中では，無視するのが望ましい。

正準形式に変換されていないテキストデータに対してbase64符号化を直接に適用する場合には，行区切

りのために適切なオクテットを使うように注意しなければならない。特に，テキストの行区切りは，base64

符号化の前に，CRLF列に変換されなければならない。実装の中には，この変換を，先行する正準化段階

ではなく，符号化器によって直接に行うものもあるという点に注意することが重要である。

注記2 マルチパート実体の内部のbase64符号化本体内で，存在する可能性のある境界区切り子を引

用する( quote )ことについては，心配する必要はない。これは，base64符号化では“-”（ハイ

フン）文字は使用されないことによる。

Content-ID（内容識別子）ヘッダフィールド

高機能のUAを作成するとき，ある本体が他の本体への参照を行うのを可能にすることが望まれる場合

がある。それに従って，本体は，構文的にはMessage-IDヘッダフィールドと同一の，Content-IDヘッダフ

ィールドを使ってラベル付けしてよい。

id := "Content-ID" ":" msg-id

Message-ID値と同様に，Content-ID値は，世界で一意となるように生成されなければならない。

注記世界で一意とする方法については，この規格では規定しない。

Content-ID値は，幾つかの文脈においてMIME実体を一意に識別するために，特に，message/external-body

機構によって参照されるデータをキャッシュするために使ってよい。Content-IDは一般にオプションだが，

オプションのMIMEメディア型である“message/external-body”のデータを生成する実装では，その使用は必

す（須）とする。すなわち，それぞれのmessage/external-body実体は，これらデータのキャッシュ化を許

すためにContent-IDフィールドをもたなければならない。

Content-ID値は，multipart/alternativeメディア型の場合には特別なセマンティクスをもつことに注意する

ことも重要である。このことは，JIS X 5810-2において，multipart/alternativeについて扱う箇条で示される。

Content-Description（内容記述）ヘッダフィールド

説明的な情報を与えられた本体と関連付ける能力が，望まれることが多い。例えば，“image”本体に“ス

ペースシャトルエンデバーの写真”といった印を付けることは役に立つかもしれない。それらテキストは，

Content-Descriptionヘッダフィールドの中に置いてよい。このヘッダフィールドは，常にオプションとする。

description := "Content-Description" ":" *text

この記述( description )は，US-ASCII文字集合で与えられることを想定する。ただし，JIS X 5810-3で規

定される機構を使って，非US-ASCII文字をContent-Descriptionフィールドの値としてもよい。

追加のMIMEヘッダフィールド

将来の規定では，種々の目的のために追加のMIMEヘッダフィールドを定義することを決定してもよい。

メッセージの内容を更に記述する新しいヘッダフィールドは，メッセージヘッダに現れるそれらフィール

X 5810-1：2008

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

附属書A

（参考）
文法一覧

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

この附属書は，この規格で規定されるすべての構文の，完全な拡張BNF文法を示す。

しかし，この文法は，それ自体だけでは不完全である。この文法は，RFC 822で定義される幾つかの構

文規則を名前によって参照する。これらの定義をここで再び示し，二つの間で意図しない差異を生じる危

険を冒すのではなく，残りの定義については，読者にRFC 822を参照してもらうことにした。用語（term。

構文の中の終端子又は非終端子。）が定義されていない場合には，それは，RFC 822の定義を参照している。

attribute := token

; 属性の合致は，

; 常に大文字・小文字を区別しない。

composite-type := "message" / "multipart" / extension-token

content := "Content-Type" ":" type "/" subtype

*(";" parameter)

; メディア型及びメディア下位型の合致は，

; 常に大文字・小文字を区別しない。

description := "Content-Description" ":" *text

discrete-type := "text" / "image" / "audio" / "video" /

"application" / extension-token

encoding := "Content-Transfer-Encoding" ":" mechanism

entity-headers := [ content CRLF ]

[ encoding CRLF ]

[ id CRLF ]

[ description CRLF ]

*( MIME-extension-field CRLF )

extension-token := ietf-token / x-token

hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

; 127より大きな文字，=，又は行末のSPACE若しくはTABには

X 5810-1：2008

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

; オクテットが使われなければならず，

; JIS X 5810-5で“mail-safe”の一覧にない文字のためには

; オクテットが推奨される。

iana-token := <公式に定義された拡張トークン。

この形式のトークンは，RFC 2048で規定されるとおりに

IANAに登録されなければならない。>

ietf-token := <標準化手続のRFCによって定義され，IANAで登録された拡張トークン>

id := "Content-ID" ":" msg-id

mechanism := "7bit" / "8bit" / "binary" /

"quoted-printable" / "base64" /

ietf-token / x-token

MIME-extension-field := <文字列“Content-”で始まる

任意のRFC 822ヘッダフィールド。>

MIME-message-headers := entity-headers

fields

version CRLF

; この拡張BNF定義が含むヘッダフィールドの順序付けは，

; 無視するほうがよい。

MIME-part-headers := entity-headers

[ fields ]

;“content-”で始まらないすべてのフィールドは，

; 定義された意味をもつことはできず，無視してよい。

; この拡張BNF定義が含むヘッダフィールドの順序付けは，

; 無視するほうがよい。

parameter := attribute "=" value

ptext := hex-octet / safe-char

qp-line := *(qp-segment transport-padding CRLF)

qp-part transport-padding

qp-part := qp-section

X 5810-1：2008

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

; 最大長は76文字。

qp-section := [*(ptext / SPACE / TAB) ptext]

qp-segment := qp-section *(SPACE / TAB) "="

; 最大長は76文字。

quoted-printable := qp-line *(CRLF qp-line)

safe-char := <10進の値が33〜60及び62〜126をもつ任意のオクテット>

; 更に，JIS X 5810-5の“mail-safe”の一覧にない

; 文字も推奨しない。

subtype := extension-token / iana-token

token := 1*<SPACE，CTL，tspecialsを除く，任意の(US-ASCII) CHAR>

transport-padding := *LWSP-char

; 送信者は，長さが0ではないトランスポート

; パディングを生成してはならないが，

; 受信者は，メッセージトランスポート

; によって追加されたパディングを

; 処理できなければならない。

tspecials := "(" / ")" / "<" / ">" / "@" /

"," / ";" / ":" / "\" / <">

"/" / "[" / "]" / "?" / "="

; パラメタ値内で使うため，

; quoted-stringでなければならない。

type := discrete-type / composite-type

value := token / quoted-string

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

x-token := <“X-”又は“x-”の2文字で始まり，空白を含まない，任意のトークン。>

X 5810-1：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ヘッダの議論から次の文を削除した。“しかし，適合ソフトウェアは，版番号を検査し，

X 5810-1：2008

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

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

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-1：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)

ISO/IEC 8859( Part 2〜Part 10 ) Information technology −8-bit single-byte coded graphic character sets

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 1123 Internet Engineering Task Force Braden,R., Editor, "Requirements for Internet Hosts−Application and

Support", October 1989

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-1：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