Yasutaka Kato 加藤泰孝
<email:y.kato@personal.email.ne.jp>
<email:ykato-ind@umin.ac.jp>
［rfc ディレクトリーのトップへ］
http://www.cis.ohio-state.edu/hypertext/information/rfc.html
Network Working Group N. Freed
Request for Comments: 2045 Innosoft
Obsoletes: 1521, 1522, 1590 N. Borenstein
Category: Standards Track First Virtual
November 1996
Multipurpose Internet Mail Extensions
(MIME) Part One:
Format of Internet Message Bodies
インターネット通信（メッセージ）本体の書式
この覚書の位置付け
この文書はインターネット交流社会のためのインターネット標準過程手順を
特定し、改善への議論と示唆を求めるものです。この手順の標準化状況と位
置付けについては「インターネット公的手順基準」（STD1）の最新の編集を
参照ください。
概要
STD11、RFC 822、はUS-ASCII通信ヘッダーについての詳細を特定する通信表
現手順を定義し、通信内容もしくは通信本文を均一なASCIIテキストのまま
にしている。この一組の文書は、多目的インターネットメール拡張
（Multipurpose Internet Mail Extensions）もしくはMIMEと総称され, 以
下の事項が可能になるよう通信書式を再定義しています。この覚書の配布の
制限はありません。
（1）通信本体でのUS-ASCII以外の文字セットによるテキスト、
（2）通信本体での非テキストの色々な形式への拡張、
（3）多元的通信本体、そして
（4）US-ASCII以外の文字セットによるテキストヘッダー情報
これら文書は、RFC 934、STD 11、と RFC 1049で文書化されている初期の作業
に基づいていますが、これを拡張改訂しています。RFC 822は通信本文につい
て殆ど言及していませんので、これらの文書は（改訂というより）RFC 822と
は別方向のものです。
この最初の文書は、MIME通信（メッセージ）の構造を記載するために使われ
る様々なヘッダーを特定します。二番目の文書、RFC 2046、はメディアタイ
プシステムの一般的な構造を定義しメディアタイプの初期設定を定義しま
す。三番目の文書、RFC 2047、はインターネットメールヘッダー領域
（field）に非ASCIIテキストデーターを可能にするRFC 822の拡張を記載し
ます。
Freed & Borenstein Standards Track [Page 1]
RFC 2045 Internet Message Bodies November 1996
四番目の文書、RFC 2048、はMIME関連装備の色々なIANA登録手順を特定しま
す。五番目で最後の文書、RFC 22049、はMIME適合基準を記載し同時にMIME通
信書式の図解例・謝辞そして文献を提供しています。
これらの文書は、RFCs 1521・1522そして1590の改訂版で、これらそのもの
はRFCs 1341と1342の改訂版でした。RFC 2049の付録に前のバージョンとの
差異と変更点が記載されています。
目次
1. はじめに ............................................ 3
2. 定義・規約と包括的なBNF文法 ......................... 5
2.1 CRLF（改行行先頭） ................................. 5
2.2 文字セット ......................................... 6
2.3 メッセージ ......................................... 6
2.4 実体 ............................................... 6
2.5 ボディ部分 .......................................... 7
2.6 ボディ ............................................. 7
2.7 ７ビットデーター ................................... 7
2.8 ８ビットデーター ................................... 7
2.9 バイナリーデーター.................................. 7
2.10 行 ................................................. 7
3. MIME ヘッダーフィールド .............................. 8
4. MIME-Version ヘッダーフィールド ...................... 8
5. Content-Type ヘッダーフィールド ...................... 10
5.1 内容型のヘッダーフィールドの構文 ................... 12
5.2 内容型のの初期値 ................................... 14
6. Content-Transfer-Encoding ヘッダーフィールド ......... 14
6.1 内容転送符号化の構文（使い方）...................... 14
6.2 内容転送符号化の意味論 ............................. 15
6.3 新規の内容転送符号化 ............................... 16
6.4 解釈と利用 ......................................... 16
6.5 符号化の変換 ....................................... 18
6.6 正式な符号化モデル ................................. 19
6.7 Quoted-Printable 内容転送符号化 .................... 19
6.8 Base64 内容転送符号化 .............................. 24
7. Content-ID ヘッダーフィールド ....................... 26
8. Content-Description ヘッダーフィールド ............. 27
9. 追加MIME ヘッダーフィールド ......................... 27
10. 要約 ................................................ 27
11. 安全性への考慮 ...................................... 27
12. 著者との連絡 ........................................ 28
A. 文法集 .............................................. 29
Freed & Borenstein Standards Track [Page 2]
RFC 2045 Internet Message Bodies November 1996
1. はじめに
1982年に公開されて以来、RFC 822はインターネット上でのテキストメール
通信の標準的な書式を定義してきました。RFC 822書式が成功したのは、
RFC 821で定義されたインターネットとインターネットSMTP転送の限定を超
え、全面的もしくは部分的に、採用されてきたからです。書式が広まると、
ユーザー交流にとって、多くの制限が拘束となることが日増しにわかってき
ました。
RFC 822はテキスト通信の書式を特定する意図でした。そうなので、非テキ
スト通信、音響や画像を含むであろうマルチメディアメッセージなど、は単
に記載されていません。しかしテキストの場合でもRFC 822は、US-ASCII
以外の多くの文字セットの使用が必要な言語を使うメール利用者の要求にも
充分ではありません。RFC 822は、音響・ビデオ・アジア言語テキストもし
くは多くの西欧言語のテキストでさえ、これを内容に持つメール機序を特定
していないので、仕様書の追加が必要です。
RFC 821/822に基づくメールシステムの顕著な制限のひとつは、電子メール
メッセージの内容を7ビットUS ASCIIの比較的短い行（1000文字以内
[RFC-821]）に限定していることです。送りたい非テキストデーターを、ロ
ーカルのメールUA（User Agent表示代行手段、利用者がメールを送信した
り受信するプログラム）に委ねる前に、印字可能なUS ASCII文字とて表現
可能な7-ビットのバイトに変換すること、を強要されます。インターネット
上で最近使われているこの様なコード化の例は、純粋な十六進法・uucoding・
RFC 1421で定義されている3-in-4 base 64体系・Andrew Toolkit
Representation [ATK]など多数のものがあります。
ゲートウェイはRFC 822ホストとX.400ホスト間でメールメッセージの交換が
できるように設計されていると、RFC 822メールの限界がいっそう明らかに
なってきます。X.400[X400]は、電子メールメッセージ内に非テキスト資料
を封入する機構を特定しています。X.400メッセージからのRF C822メッセー
ジへの変換の最近の基準では、X.400非テキスト資料は（コード化されていな
い）IA5Text書式に変換されなければならないかもしくはRFC 822利用者に破
棄が起こったことを知らせて捨てられなければならないと特定しています。
利用者が受け取りたいと思っている情報が失われるので、これは明らかに望
ましくありません。表示代行手段が非テキスト資料を処理することができな
くても、その資料から有益な情報を抽出できる外部機構をUAに持たせられる
かもしれません。さらに、結局そのメッセージをX.400メッセージ取り扱いシス
テムに戻し（いいかえると、X.400メッセージがインターネットメールを突
き抜ける）、そこで非テキスト情報が再び利用できるようになる、といった
ことが許されていません。
Freed & Borenstein Standards Track [Page 3]
RFC 2045 Internet Message Bodies November 1996
この文書は、RFC 822メールの既存の世界との深刻な非互換性を引き起こさ
ないでこれらの問題の大部分を解決するために組み合わされた幾つかの機構
を記載します。特に以下のことを記載しています：
(1) MIME-versionヘッダー領域、これはMIMEに適合する通信を宣言し、
メール処理代行手段がこのような通信と古いもしくは非適合ソフト
ウェアー、これにはそのような領域がないと推定される、で作成さ
れたものとを区別できるようにします。
(2) Content-Type header field、RFC 1049から一般化され、これはメッセ
ージのボディ内のデーターののメディアタイプとサブタイプを特定す
るのに使え、そしてそのようなデーターの自然な表現（基本的な書式）
を全て特定するのに使えます。
(3) Content-Transfer-Encoding header field、これはボディやその結果
のドメイン両者に適用されるコード化変換を特定するのに使えます。
同一の変換以外のコード化変換は、普通、データーや文字セットに制
限があるメール転送機構を通過できるようにするためにデーターに適
用されます。
(4) ボディ内のデーターをさらに記述するのに使える二つの追加できる
ヘッダーフィールド、Content-IDとContent-Description header fields
この文書で定義されているヘッダーフィールドは全て、RFC 822で特定化さ
れたヘッダーフィールド用の一般的な構文的な規則の対象です。特に
Content-Disposition用を除いたヘッダーフィールド全ては、RFC 822コメン
トを含み、コメントはなんら構文的な内容をもたずMIME処理中無視されるべ
きです。
最後に相互操作性を特定促進するために、RFC 2049はこの文書の最低「適
合」レベルを定義する上記の機構のサブセット用に基本的な適用声明を提供
します。
歴史的注記： 一式の文書に記載している機構の幾つかは、一読して何処か
おかしもしくは奇異に見えるかもしれません。既存の標準との互換性と既存
の実践に横たわる苦労が、この一式の文書を開発する作業班の二つの優先度
の高いものでした。特に互換性が常に優雅さより好まれました。
Freed & Borenstein Standards Track [Page 4]
RFC 2045 Internet Message Bodies November 1996
この手順の標準化と位置付けについては、「インターネット公的プロトコー
ル標準"Internet Official Protocol Standards"」の最新篇を参照くださ
い。RFC 822とSTD 3・RFC 1123もMIMEの本質的な背景を提供していて、MIME
の適合装備はそれらと少しも違反しないからです。さらに、その他の情報的
なRFC文書のなかにはMIME手段提供に興味をもっていて、特にRFC 1344・
RFC 1345そしてRFC 1524で。
#^
2. 定義・申し合わせと包括的なBNF文法
この一組の文書で特定されている機構は全て散文体で記載されていますが、
その大部分は拡大されたRFC 822のBNF命名法で正式に記載できます。手段提
供側はこの文書一式を理解するためにこの命名法に馴染んでおく必要があ
り、拡大BNF命名法の完全な説明のためにRFC 822を参照しておきます。
この一式の文書のこの拡大BNFは、指名された参照をRFC 822で定義された構
文規則に作り上げます。次いでこの一式の各文書の付録に収集された文法を
RFC 822とRFC 1123（これは特に`return'・`date'そして`mailbox'の構文を
変更しています）で定義された修正RFC 822のBNFと組み合わせて、完全な正
式の文法が得られます。
この一式の文書では、番号やオクテクの値は全て十進法で記載されます。メ
ディアタイブ（媒体型）の値・サブタイプの値そしてパラメーター名は定義
されたされたように全て大文字小文字を区別しません。しかし、特別なパラ
メーター用に別に定義されていないかぎり、パラメーター値は大文字小文字
を区別します。
書式についての注意：ここにあるような注意は、補足的で非本質的な情報を
提供し、飛ばしてもなんら本質的なものを見逃すことはありません。この非
本質的な注意の主たる目的は、この一式の文書の考えについての情報を伝え、
適切な歴史的もしくは革新的な文脈上の位置にこれらの文書を置くことです。
このような情報は適合性ある装備を作り上げることだけに的を絞っている人
は飛ばして結構ですが、何故ある設計選択がなされたのかを理解したい人に
は役に立つでしょう。
2.1. CRLF
この一式の文書でのCRLFという用語は、二つのUS-ACSII文字であるCR（十進
法13）とLF（十進法10）に対応するオクテット列を参照し、この順番で組に
なってRFC 822で行改行を示します。
Freed & Borenstein Standards Track [Page 5]
RFC 2045 Internet Message Bodies November 1996
2.2. 文字セット（文字一式）
用語"character set"は、オクテット列を文字列に変換する方法を参照する
ためにMIMEで使われます。別の方向への無条件で明白でない変換は要求され
てなく、そこでは全ての文字が一定の文字セットで表現されないないかもし
れないし、文字セットは特殊な文字列を表現するのに一つ以上のオクテット
列を提供するかもしれないことに注意して下さい。
この定義は色々な種類の文字コード化、US-ASCIIのような単純な単一表変換
からISO-2022の技術を使うもののような複雑な表切り替え法まで、が文字
セットとして使えるように考えられています。しかし、MIME文字セット名と
協力する定義は、変換を充分に特定して実行されなくてはなりません。特に
正確な変換を決定するのに外部の輪郭情報は許されていません。
注意： 用語"character set"は、元々単一オクテットから単一文字への単純
な一対一変換であるUS-ASCIIとISO-8859-1のような直接的な体系を記載してい
ます。多元オクテットコード化文字セットや切り替え技術によってこの状況は
より複雑になります。例えば、ある地域では、MIMEが"character set"といっ
ているものに"character encoding"という用語を使っていますし、一方整数
（オクテットでなく）文字への抽象的な変換を指すのに"coded character set"
という句を使用します。
2.3. メッセージ（Message）
「メッセージ」という用語、さらに修正がない場合、はネットワークを転送
される（完全なもしくは"tip-level"の）RFC 822メッセージもしくは
"message/rfc822"や
"message/partial"タイプのボディ部でカプセル化されたメッセージを意味
します。
2.4. 実体（Entity）
用語"entity"は、特にMIME定義ヘッダーフィールドとそのメッセージの内容
もしくは多元実体のボディの一つの部分に当たります。この様な実体の仕様
はMIMEの本質です。実体の内容はしばしばボディ"body"と呼ばれますので、
実体のボディについて語るのは道理に適っています。実体のヘッダーにはど
んな領域（フィールド）でもきますが、実際には"content-"ではじまる名前
のあるフィールドだけがMIMEに関連した意味をもっています。全く意味を
持っていないとはいえないことに注意して下さい -- メッセージでもある実
体が、RFC 822で定義された意味の非MIMEヘッダーを持っています。
Freed & Borenstein Standards Track [Page 6]
RFC 2045 Internet Message Bodies November 1996
2.5. ボディ・パート（Body Part）
"body part"という用語は、多元部分実体の内部の実体に当たります。
2.6. ボディ（Body）
用語"body"は、さらに条件付けがない場合、実体のボディを意味し、つまり
各メッセージのボディもしくはボディ部分のボディです。
注意： 前述の四つの定義は明らかに循環しています。これは避けられない
もので、というのはMIMEメッセージの全体構造は実際再帰的です。
2.7. 7ビット データー（7bit Data）
"７ビット データー"は、CRLF行分離文字列間の988オクテット以内の比較的
短い行として表現されるデーター全てに当たります[RFC-822]。127以上の十
進法値のオクテット、NULs（十進法値0のオクテット）も、許されません。
CR（十進法値13）とLF（十進法値10）オクテットは、CRLF行分離文字列とし
てしかとりません。
2.8. 8ビット データー（8bit Data）
"8ビット データー"は、CRLF行分離文字列[RFC-821]間の998以下の比較的短
い行として表現できるデータ全てにあたります[RFC-821]が、127より多い十
進法値のオクテットは使えます。"７ビット データー"でのように、CRとLF
オクテットはCRLF行分離文字列の一部としてだけおこり、NULsはゆるされま
せん。
2.9. バイナリー データー（Binary Data）
"バイナリー データー"は、それが何であれ、どんなオクテットでも許され
ます。
2.10. 行（Lines）
"行"は、CRLF文字列によって分離されたオクテット列として定義されます。
これはRFC 821とRFC 822で一致しています。"行"だけではメッセージのデー
ターの単位に当たり、実際に表示代行手段で表示されるかもしれないし、さ
れないかもしれません。
#^
Freed & Borenstein Standards Track [Page 7]
RFC 2045 Internet Message Bodies November 1996
3. MIMEヘッダーフィールド
MIMEには、MIME実体の内容を記載するのに使われる新しいRFC 822ヘッダー
フィールドがたくさんあります。これらのヘッダーフィールドは少なくとも
二つの文脈で現われます：
(1) 通常のRFC 822メッセージヘッダー部分として。
(2) 多元部分構造内での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ヘッダーフィールド
RFC 822が1982年に公開されて以来、インターネット通信の唯一の標準書式
でありつづけてき、使用に当たって標準書式を宣言する必要性を知ることは
ありませんでした。この文書は、RFC 822の補足仕様書です。この文書の拡
張はRFC 822と互換性ある方法で定義されていますが、それでも環境によっ
てはメール処理代行手段がメッセージが新しい標準から構成されているかど
うかに配慮することが望ましいこともあります。
Freed & Borenstein Standards Track [Page 8]
RFC 2045 Internet Message Bodies November 1996
従って、この文書は新しいヘッダーフィールド、"MIME-Version"、を定義
し、使用されているインターネット通信ボディ部標準書式のバージョンを宣
言するのに使います。
この文書に準じて構成されているメッセージは、以下と全く同じテキストが
ある、ヘッダーフィールドをもっていなければなりません：
MIME-Version: 1.0
このヘッダーフィールドがあることは、メッセージがこの文書に従って構成
されていることの証しです。
将来の文書はメッセージ書式標準を再び拡張する可能性があるので、正式な
BNFはMIME-Vwesionフィールドの内容は以下のようになっています：
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
かくて、将来の書式仕様、"1.0"を置き換えもしくは拡張する、はピリオドで
分離された二つの統合フィールドになるように強制されます。メッセージが
"1.0"以外のMIME-version値で受け取られた場合、この文書の適合していると
決めてかかることはできません。
MIME-versionヘッダーフィールドはメッセージのトップレベルに必須です。多
元部分実体の各ボディ部のヘッダーには必要ありません。"message/rfc822"も
しくは"message/partial"タイプのボディに組み込まれたヘッダーには必要で
すが、組み込まれたメッセージがそれ自身でMIME適合であることを宣言する場
合そしてこの場合だけです。
この文書で定義されているようにMIMEと適合しているメールリーダーが、将来
"1.0"以外のMIME-Versionの値で到着するメッセージをどのように処理すべき
かを十分に特定することはできません。
特別なメディアタイプのバージョン制御は、MIME_Version機構を使って達成さ
れないということは注意しておくのに値します。特に書式によっては
（application/postscriptのような）、内部にあるバージョン慣例をメディア
書式に持っています。そのような慣例がある場合、MIMEはそれに取って代わる
ために何もしません。そのような慣例がない場合、必要ならMIMEメディアタイ
プはcontent-typeフィールドの"version"パラメーターを使うかもしれませ
ん。
Freed & Borenstein Standards Track [Page 9]
RFC 2045 Internet Message Bodies November 1996
手段提供者への注意：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フィールドのない場合、受信メール表示代行手段（MIME要求に
適合しているか否かを問わず）は、選択的にローカル規格に従ってメッセー
ジボディを解釈することを選ぶかもしれません。このような多くの規約が現
在使用され、実際上非MIMEメッセージはほぼどんなものをも内容にとるとい
うことに注意しておくべきです。
非MIMEメールメッセージが実際にUA-ASCII文字のプレーンテキストであると
確認することはできなく、というのはMIME以前である非標準のローカル規約
のセットを使用して、別の文字セットのテキストもしくは自動的に分からな
い方法で表示される非テキストデーター（例えばuuencod化圧縮UNIXファイ
ル）を含むメッセージであるかもしれません。
#^
5. Content-Type ヘッドフィールド
Content-Typeフィールドの目的はボディにあるデーターについて、受信表示
代行手段が適切な代行手段や機構を選びユーザーにそのデーターを表現する
かもしくは適切な方法で別のやりかたでデーターを処理するのに充分な記載
をすることです。このフィールドの値は、メディアタイプと言われます。
歴史的な注釈： Content-Typeヘッダーフィールドは最初RFC 1049で定義さ
れました。RFC 1049では単純で強力とは言えない構文を使いましたが、ここ
に与えられた機構と殆ど互換性があります。
Content-Typeヘッダーフィールドはメディアタイプとサブタイプ識別子を与
えてそして或種のメディアタイプに必要な補助的な情報を提供して、実体の
ボディのデーターの性質を特定します。メディアタイプとサブタイプ名の後
ろにヘッダーフィールドの残りの部分は単にパラメーターのセットで、
attribute=valueという命名法で特定します。パラメーターの順位には意味が
ありません。
Freed & Borenstein Standards Track [Page 10]
RFC 2045 Internet Message Bodies November 1996
一般的にトップレベルのメディアタイプは、データーの一般的な型を宣言す
るのに使用され、一方サブタイプはデーターのそのタイプに特徴的な書式を
特定します。かくてメディアタイプ"image/xyz"は、そのデーターは画像
（image）であると表示代行手段に充分しらせます、例え画像書式"xyz"がを
特定する知識がなくてもです。例えば、このような情報は認知されないサブ
タイプからの元のデーターをユーザーに示すかどうかを決めるのに使え --
このような動きはテキストの認知されないサブセットでも意味がありますが
画像や音響やビデオの認知されないサブタイプには適していません。この理
由としてテキスト・画像・音響そしてビデオの登録されたサブタイプは、全
く異なるタイプである埋め込まれた情報を含むべきではないからです。この
ような複合書式は、"multipart"もしくは"application"タイプを使って表現
すべきです。
パラメーターは、メディアタイプの修飾語で、そのようなものなので内容の
性質に基本的に影響しません。意味あるパラメーターセットはメディアタイ
プとサブタイプに依存しています。大部分のパラメーターは単一の特別なサ
ブタイプで支援されています。しかし、一定のトップレベルメディアタイプ
はそのタイプの如何なるサブタイプにも適用されるかもしれません。パラ
メーターは内容型もしくはサブタイプ、もしくはそれらは選択性で、を定義
する必要があるかもしれません。MIME装備は分からない名前のパラメーター
は無視しなければなりません。
例えば、"charset"パラメーターはサブタイプである如何なる"text"全てに
適用され、一方"boundary"パラメーターは"multipart"メディアタイプのな
んらかのサブタイプを必要とします。
メディアタイプ全てに適用する汎用的に意味があるマラメーターはありませ
ん。穏当に汎用的な機構は、MIMEモデルでは、追加的なContent-*ヘッダー
フィールドの定義によってうまく呼びかけられます。
七つのトップレベルのメディアタイプの初期設定がRFC 2046で定義されてい
ます。これらのうち五つは個別のタイプで、本質的にMIME過程が関わる限り
の範囲で、その内容は明瞭ではありません。残りの二つは合成タイプで、そ
の内容はMIME処理による追加的な処理が必要です。
トップレベルのメディアタイプの組はかなり完全なものです。サポートされ
ているタイプのこの大きなセットはへの追加は、これらの初期タイプの新し
いサブタイプの創設によって行われると期待されています。将来より多くの
トップレベルのタイプは、この標準の標準過程拡張だけによって定義される
かもしれません。別のトップレベルタイプが何らかのりゆうによって使用さ
れる場合その非標準性を示唆し将来の公式名との潜在的な衝突を回避するた
めに、"X-"で始まる名前を与えられなければなりません。
Freed & Borenstein Standards Track [Page 11]
RFC 2045 Internet Message Bodies November 1996
5.1. Content-Type ヘッダーフィールドの構文
RFC 822の拡大されたBNFでは、Content-Typeヘッダーフィールド値は以下の
ように定義されています：
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
subtype := extension-token / iana-token
iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
Freed & Borenstein Standards Track [Page 12]
RFC 2045 Internet Message Bodies November 1996
"tspecials"の定義は"specials"のRFC 822定義と同じようなもので、 "/"・
"?"と"="がついかされ "."が除かれていることに注意してください。
また、サブタイプ仕様が必須で -- Content-Typeヘッダーフィールドから除
かれないかもしれないことにも注意して下さい。このようにサブタイプ既定
値はありません。
タイプ・サブタイプそしてパラメーターは、大文字小文字をくべつしません。
例えば、TEXT・TextそしてTeXtは皆同じトップレベルのメディアタイプです。
パラメーター値は、普通大文字小文字を区別しますが、時には区別しないや
り方で解釈され、使用目的に依存しています（例えば、多元部分境大文字小
文字を区別しますが、message/External-bodyの"access-type"パラメーター
は区別しません）。
引用符号列パラメーターの値は引用を含まないに注意してください。いいか
えると、引用符号列の引用マークはパラメーターの値の一部ではなく、単に
そのパラメーター値に境を付けるのに使われるだけです。さらに、コメント
は構造化されたヘッダーフィールド用のRFC 822規則のそって許されていま
す。かくて、以下の二つの書式は、
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
全く同じものです。
この構文を超えて、サブタイプ名の定義上の唯一の意味論的な制約はこれら
の使用が衝突してはいけないという要望です。いいかえると、異なる二つの
ものを意味するのに、"Content-Type: application/foobar"を使ている二つ
の異なる交流持つことは望ましくありません。さらに、新しいメディアサブ
タイプを定義する過程は、制限を課せる機構で単に定義と利用を公表する機
構であることを意図してはいけません。従って、新しいメディアサブタイプ
を定義するための受け入れられる機構が二つあります。
(1) 私的な値（"X-"ではじまる）は、外部登録もしくは標準なく、
協力する二つの表示代行手段双方間で定義されるかもしれま
せん。このような値は登録もしくは標準化されません。
(2) 新しい標準値は、RFC 2048で記載されているように、IANAに登録さ
れるべきです。
この一式の文書の二番目の文書、RFC 22046、はMIME用のメディアタイプの初
期設定を定義しています。
Freed & Borenstein Standards Track [Page 13]
RFC 2045 Internet Message Bodies November 1996
5.2. Content-Typeの初期値（既定値）
MIME Content-Type headerのないRFC 822メッセージでの初期値は、US-
ASCII文字セットのプレーンテキスト（平叙文）であるとこの手順では受け
取られ、以下のように明示的に特定されることになります：
Content-type: text/plain; charset=us-ascii
Content-Typeヘッダーフィールドが特定されていない場合この初期値が推定
されます。また、構文的に正しくないContent-Typeヘッダーフィールドに遭
遇した場合もこの初期値を推定するよう薦められています。MIME-Version
ヘッダーフィールドがありContent-Typeヘッダーフィールドがない場合受信
表示代行手段はプレーンUS-ASCIIテキストが送信者の意図であったと推定す
ることもできます。MIME-Versionがない場合もしくは構文的に正しくない
Content-Typeヘッダーフィールドがある場合プレーンUS-ASCIIテキストがや
はり推定されますが、しかし送信者の意図とは違うかもしれません。
#^
6. Content-Transfer-Encoding ヘッダーフィールド
メール経由で有効に転送できる多くのメディアタイプは、それらの「普通
の」書式、8ビット文字もしくはバイナリーデータとして表現されます。こ
のようなデーターを、転送手順によっては転送することができません。例え
ばRFC 821（SMT）はメールメッセージを7ビットUS-ASCIIで引きずっている
CRLF空白分離子も含めて1,000 文字以下の行に制限しています。
従ってこのようなデーターを7ビットの短い行書式にコード化する標準機構
を定義することが、必要になります。制限の少ない転送で直接使用するため
に、符号化されていない資料を制限の少ない書式で適切なラベル付けをする
ことも望ましいものです。この文書は、このようなコード化が新しい
"Content-Transfer-Encoding"ヘッダーフィールドで示唆されるよう特定し
ます。このフィールドを、前のいかなる標準も定義していません。
6.1. 内容転送符号化の構文
Content-Transfer-Encodingフィールド値は符号化のタイプを特定する単一
のトークン（字句）で、以下のように列挙します。書式は：
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
値は大文字小文字を区別しません -- Base64・BASE64・bAsE64は同じです。
7ビットのコード化タイプは、ボディが既に7ビットメール用の表現であるこ
とが必要です。
Freed & Borenstein Standards Track [Page 14]
RFC 2045 Internet Message Bodies November 1996
これが初期値（既定値）で、つまりContent-Transfer-Encodingフィールド
がない場合は "Content-Transfer-Encoding: 7BIT"と推定されます。
6.2. 内容転送符号化の意味
単一の内容転送符号化トークン（字句）は実際上情報の二つの部分を提供し
ます。ボディが影響されるコード化変換の種類は何かそれゆえにどんな復元
化操作が元の書式に戻し、その結果の分野が何であると特定するのか、をそ
れが特定します。
如何なる内容転送符号化の変換部分は、明示的にせよ暗黙的にせよ、単一の
十分に定義された復元化アルゴリズムを特定し、符号化されたオクテット列
のためにそれを符号化されたオクテットの元の列に変換するか、それが符号
化された列としては正しくないことを示します。内容転送符号化は、適切な
操作のために如何なる補足的な外部の特質情報に依存しません。復元化は単
一の十分定義された正しい符号化の出力を作成しなければなりませんが、符
号化にはこの様な限定はありません：一定のクテック列を別の等価の符号化
列に符号化することは、全く正しいのです。
三つの転換が現在定義されていて：そのもの・"quoted-printable"符号化そ
して "base64"符号化です。分野（ドメイン）は "binary"・"8bit"そして
"7bit"です。
内容転送符号化値"7ビット"・"8ビット"そして"バイナリー"は全て、そのま
まの符号化転送（つまり、符号化されない）が施行されるという意味です。
そのように、単にボディデーター分野の指標として役に立ち、ある転送シス
テムでの通過に必要かもしれない符号化の種類についての有用な情報を提供
するだけです。用語"7bit"・"8bit"そして"binary"は、全てセクション2で
定義されています。
quoted-printableとbase64符号化は、入力を任意の形態から"7ビット"幅の
素材に変換し、こうして制限ある転送の中を安全に運びます。その変換の特
別な定義は、以下で与えられます。
適切な内容転送符号化ラベルは必ず使用されなければなりません。8ビット
文字を内容とする符号化されていないデーターを"7ビット"とラベル付けす
ることは許されませんし、符号化されていない行指向のないデーターを
"binary"以外のものとラベル付けすることは許されません。
メディア・サブタイプと違って、内容転送符号化値を増やすことは望ましく
もないし必要もありません。しかし、"7ビット"分野への単一変換だけを確
立することは、できないように思えます。
Freed & Borenstein Standards Track [Page 15]
RFC 2045 Internet Message Bodies November 1996
主にバイナリーデーターのコンパクトで有効な符号化への望みと殆ど、全く
ではないが、7ビットであるデーターである程度判読可能な符号化への望み
の間にはトレードオフ（妥協による交換）があります。この理由から、少な
くとも二つの符号化機構が必要です：多少判読可能な符号化（quoted-
printable）と"高密度"もしくは"均一な"符号化（base64）です。
8ビットデーターのメール転送はRFC 1652で定義されています。この文書の初
期の公開でメールボディの符号化されていないバイナリーデーターを含むこ
とが合法である標準化されたインターネットメール転送はありません。かく
て"バイナリー"内容転送符号化は実際上インターネットメールで正しいとい
う状況はありません。しかし、バイナリーメール転送がインターネットメー
ルで現実のものとなる事態で、MIMEが他のバイナリー可能なメール転送機構
と結び付いて使用される場合、バイナリーボディはこの機構を使用するよう
にラベル化されなければなりません。
注意： 内容転送符号化フィールド用に定義された五つの値は、これで符号
化されるかもしくは符号化されていないなら転送システムが要求するアルゴ
リズム以外のメディアタイプについては何ら示唆をあたえません。
6.3. 新しい 内容転送符号化
手段提供として、必要なら、私的な内容転送符号化値を定義するかもしれま
せんが、"X-"から始まる名前でx-tokenを使い、非標準であると知らせなけ
ればならなく、例えば "Content-Transfer-Encoding: x-my-new-encoding"
というように。追加された標準化された内容転送符号化値は、標準過程RFC
で特定されなければなりません。従わなければならないこのような仕様の要
求は、RFC 2048で与えられています。このように、"X-"ではじまるという以
外は内容転送符号化名前空間は全て将来の使用のためにIETFにはっきりと予
約されます。
メディアタイプとサブタイプとは違って、新しい内容転送符号化値は積極的
に奨励されてなく、というのは潜在的な利点が少ないのに相互操作性を損な
いやすいからです。
6.4. 解釈と利用
内容転送符号化ヘッダーフィールドがメッセージボディ部分にきていたら、
そのメッセージの全ボディに適用されます。内容転送符号化ヘッダーフィー
ルドが実体のヘッダー部分にきていたら、その実体のボディに適用されます。
実体が"multipart"タイプなら、内容転送符号化は"7bit"・"8bit"もしくは
"binary"以外の値を持てません。"message"タイプのサブタイプによっては、
より厳格な制限さえも適用されます。
Freed & Borenstein Standards Track [Page 16]
RFC 2045 Internet Message Bodies November 1996
大部分のメディアタイプはビットでなくオクテット（8ビット）用語で定義
されていて、それ故にここで記載されている機構は任意のオクテット連続
体、ビット連続体でなく、用の機構であることに注意すべきです。ビット連
続体をこれらの機構で符号化する場合、まずネットワーク標準ビット順位
（"big-endian"）、連続体ではじめのビットは8ビット・バイトでのより高
い順位（higher-order）ビットになります。8ビット境界（単位）で符号化
されていないビット連続体は、ゼロで補充されなければなりません。RFC
2046は、application/octet-streamメディアタイプ、"padding"パラメー
ターを持っています、の場合のこのような詰め物の追加を書き留める機構を
提供しています。
ここで明確に定義されている符号化機構は、US-ASCIIで全てのデーターを符
号化します。かくて例えば実体が、以下のようなヘッダーフィールドを持っ
ていると仮定しましょう：
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
これは、ボディは元がISO-8859-1のデーターのbase64 US-ASCII 符号化で文
字セットは再び復元化されることを意味する、と解釈されなければなりませ
ん。
或る内容転送符号化値は、或るメディアタイプでだけ使用されるかもしれな
い。特に、合成メディアタイプ、つまり別の内容転送符号化を再帰的に含む
もの、では"7bit・"8bit"もしくは"binary"以外のどのような符号化を使用
することも表現上禁じられています。現在、唯一の合成メディアタイプは
"multipart"と"message"です。多元部分もしくはメッセージのボディに望ま
れる符号化は全て、最内部のレベルで、符号化される必要のある実際のボ
ディを符号化することで行われなければなりません。
合成実体が7ビットといった内容転送符号化値を持つが封入された実体は 8
ビットといった制限のない値を持つ場合外側に"7bit"とラベル付けすること
は8ビットデーターが含まれているので、定義上間違いであるし、また内側
に"8bit"とラベル付けすることは実際に含まれているデーターは7ビット安
全であるので、転送システムに不必要に高い要求を置くことになるというこ
とに注意すべきです。
符号化制限に関する注意： 合成ボディデーターについての内容転送符号化
使用に体する禁止は余りに制限的であるようにみえるかもしれませんが、入
れ子された符号化を防ぐことが必要で、入れ子された符号化内のデーターは
符号化手順を何回も通過し適切に閲覧するには何回も復元化されなければな
りません。入れ子になった符号化は表示代行手段に非常な複雑さを課せるこ
とになります：このような多元符号化に伴う効率化問題はさておき、メッ
セージの基本的な構造を分かりにくくする可能性があります。特に、幾つか
の復元操作は単にメッセージがどんなボディタイプを含んでいるのかを見付
け出すのに必要であることを意味しています。
Freed & Borenstein Standards Track [Page 17]
RFC 2045 Internet Message Bodies November 1996
入れ子符号化の禁止は或る種のメールゲートウェイの仕事を複雑にするかも
しれませんが、これは表示代行手段側での入れ子符号化の効率に比べて問題
は小さいと思えます。
認識されない内容転送符号化は、"application/octet-stream"の内容転送符
号化であるとして、Content-Typeヘッダーフィールドが実際に何といってい
るのかに関係なく、処理されなければなりません。
内容型と内容転送符号化の関係に関する注意：内容転送符号化は、符号化さ
れたメディア（媒体）の特徴から推測されもしくは少なくとも或る種の内容
転送符号化は特別なメディアタイプの使用に当てられているようである。何
故そうでないかと言う幾つかの理由があります。最初に、メール用に使用さ
れる色々なタイプの転送が与えられると、ある符号化はメディアタイプと転
送の或る組み合わせは適切であるが、別のものにとってはそうではありませ
ん（例えば、8ビット転送で或る種の文字セットのテキストには符号化は必
要がありませんが、一方このような符号化は7ビットSMT用と明確に要求され
ます）。
二番目に、或る種のメディアタイプは異なった環境下で異なった転送符号化
が要求されるかもしれません。例えば、多くのポストスクリプト
（PostScript）ボディは全て7ビットデーターの短い行から構成されている
かもしれなく、それ故に全く符号化を要求されません。別のポストスクリプ
ト・ボディ（特にレベル2ポストスクリプトバイナリー符号化機構を使って
いるもの）は、ただバイナリー転送符号化の使用で適切に表現されるかもし
れません。最後にContent-Typeフィールドは制限のない（open-ended）仕様
機構であることを意図しているので、メディアタイプと符号化の強調で厳格
な仕様でアプリケーション・プロトコールの仕様を特別な低レベル(lower-level)
転送と効果的に結び付けます。メディアタイプの開発者は使用での全ての転
送や何が制限なのかを気配りをする必要がないので、これは望ましいもので
はありません。
6.5. コード化の翻訳（転換）
quoted-printable と base64 符号化はお互いの間で変換が可能なように設
計されています。このような変換の際の生じる唯一の問題は、quoted-
printable符号化出力での意味ある改行（hard line breaks）の取り扱いで
す。quoted-printable から base64への変換の場合、quoted-printable 書
式の意味ある改行はそのデーターの正式な書式のCRLF列（連続体）を表現しま
す。従ってデーターのbase64書式の対応する符号化CRLFに変換されなければな
りません。同様にbase64復元化後に得られるデーターの正式な書式のVRLF列
（連続体）は、quoted-printablの意味ある改行に変換されなければなりませ
んが、テキストデーターを変換する時だけです。
Freed & Borenstein Standards Track [Page 18]
RFC 2045 Internet Message Bodies November 1996
6.6. 正式なコード化モデル（Canonical Encoding Model）
電子メールが正式な書式とコード化されたものに変換されなければならない
場合の、特に、新しい行の表現がシステムからシステムで大きく変わること
を仮定し、この過程がCRLFsと内容転送コード化と文字セットの関係の処理
にどの様に影響するかという場合のモデルについてこのRFCより前のバー
ジョンでは混乱がありました。この理由ゆえに、コード化の正式なモデルが
RFC 2049で表現されています。
6.7. Quoted-Printable 内容転送符号化
Quoted-Printable encodingは、大部分US-ASCII文字セットの印字可能な文
字に相当するオクテット（8ビット）からなっているデーターを表現するよ
う考えられています。コード化されたオクテットがメール転送によって変更
されないような方法でデーターをコード化します。コード化されたデーター
が殆どUS-ASCIIテキストである場合、データーのコード化された書式はそれ
でも人が判読可能です。US-ASCIIの体部も、文字変換や行−折り返しゲート
ウェイを通過するメッセージであるデーターの統一性を確保するために
Quoted-Printableでコード化されるかもしれません。
このコード化では、オクテットは以下の規則によって決められたように表現
されなければなりません：
(1) （一般的な8ビット表現）如何なるオクテット、符号化された
データーの正式（標準）書式のCRLF行改行の部分であるCRもしく
はLFを除いて、も "=" に続くオクテットの値の二つの十六進法指
数表現によって表わされます。十六進法指数アルファベットは、
この目的用に、"0123456789ABCDEF" があります。大文字を使わな
くてはなりません；小文字はゆるされません。かくて、例えば、
十進法の値12（US-ASCII 改行）は"=0C"で表現でき、十進法の値
61（US-ASCII 等式記号）は"=3D"で表現できます。この規則に、
以下の規則によって代替符号化が許される場合を除き、したがわ
ねばなりません。
(2) （文字通りの表現）33から60までと62から126までの十進法値のオ
クテックは、それらのオクテクに対応したUS-ASCII文字として表
現されるかもしれない（感嘆符号からより小さいそしてよりおお
きいからティルダ）。
(3) （空白文字）9と32の値を持つオクテットは、US-ASCIIタブ（HT）
とスペース文字として表現されるかもしれませんが、符号化された
Freed & Borenstein Standards Track [Page 19]
RFC 2045 Internet Message Bodies November 1996
行の終わりでそのように表現されるべきではありません。かくて、符
号化された行のどんなタブ（TH）やスペース文字でも、印字可能な文
字の行で続けられなければなりません。特に符号化された行の終わり
の"="は、ソフト改行を指していて、一つ以上のタブ（TH）やスペース
文字に続くかもしれません。符号化された行の終に現われる十進値9も
しくは32は、規則#1 に従って表現されねばなりません、と続きます。
この規則は必要で、というのも、MTAs（Message Transport Agents＝
メッセージ転送代行手段、ある利用者から別の人へメッセージを転送
もしくはその様な転送の過程を施行するプログラム）によっては、ス
ペースのある行を穴埋めすると理解し、別のものは行の終から空白ス
ペース"white space"を取り除くと理解しています。従って、Quoted-
Printablボディを復元する時、行の末尾の如何なる空白スペースも、
仲介転送代行手段によって必然的に追加されたので、削除されねばな
りません。
(4) （改行）テキストボディの改行は、テキスト正式書式でCRLF列として
表現さてた、はQuoted-Printable符号化でRFC 822改行、これもCRLF列
です、で表現されなければなりません。テキスト以外のメディアタイ
プの正式な表現は、一般的にCRLF列（連続体）としての改行の表現を
ふくんでなく、ハード改行は（すなわち、意味があり利用者に表示さ
れる意図がある改行）このタイプのquoted-printable符号化内にはあ
らわれません。勿論、"=0D"・"=0A"・"=0A=0D"そして"=0D=0A"のよう
なシーケンス（連続体）が、quoted-printableで表現されるテキスト
に現われますが。
多くの手段提供者は、まず正式な書式への変換・符号化そしてローカ
ル表現へ戻り変換ではなく、直接色々な内容タイプのローカル表現を
直接符号化することを選んでいるかもしれません。特にこれは、CRLF
終結シーケンスでなく新しい行慣例を使用しているシステム上でプ
レーンテキスト資料に適用されるかもしれません。このような装備選
択は許され得ますが正式化−符号化段階と結びついたものは三つの段
階を別々に施行することと同じです。
(5) （ソフト改行） Quoted-Printable符号化では、符号化された
行は76文字長を超えないよう、要求されています。より長い
行をthe Quoted-Printableで符号化する場合、"ソフト"改行
Freed & Borenstein Standards Track [Page 20]
RFC 2045 Internet Message Bodies November 1996
を使用しなければなりません。符号化された行での最後の文字と
して等式記号は、符号化されたテキストで意味のない（"ソフト"）
改行を指しています。
かくて行の"元"の書式が、以下のような単一の符号化されていない行なら：
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.
これは長い行を、表示代行手段によって復元されるような方法で、符号化す
る機構を提供します。76文字制限は引きずっているCRLFを数にいれませんが、
その他の文字、如何なる等号記号も含めて、は全て数えます。
ハイフェン文字 ("-") はQuoted-Printable符号化ではそのまま表現されるか
もしれませんので、quoted-printable符号化されたボディを一つ以上の多元部
門内にカプセル化する場合、境界識別子が符号化されたボディの何処にも現わ
れないことを確認する注意が払われなければなりません（いい戦略としては、
quoted-printableボディに決して現われることができない"=_"といった文字列
を含む境界を選択することです。 RFC 2046の多元部門メッセージの定義をみ
てください。）。
注意： quoted-printable符号化は、判読可能性と信頼性の間の折り合いを表
現しています。quoted-printableで符号化されたボディは殆どのメールゲート
ウェイで問題なく働きますが、少数のゲートウェイで完全に働かないかもしれ
なく、とくにEBCDICへの変換を含むゲートウェイではそうです。base64内容転
送符号化は、信頼性の高いものです。EBCDICゲートウェイ経由で十分に信頼で
きる転送を得る方法は、US-ASCII文字も引用で囲うことです。
!"#$@[\]^`{|}~
と規則#1 に従います。
quoted-printableデーターは一般的に行-指向と考えられていますので、
quoted-printableデーターの行間の改行の表現が転送中に、インターネット
メールで新行の慣例が異なるシステム間を通過する際テキストメールは必ず変
更されのと同じやり方がとられ、変更されるかもしれません。この様な変更が
Freed & Borenstein Standards Track [Page 21]
RFC 2045 Internet Message Bodies November 1996
データーの損失を与えやすい場合quoted-printable符号化でなくbase64符号化
を使用するほうが恐らくより賢明です。
注意： サブストリングの種類によってはquoted-printable内容転送符号化の
符号化規則に従って生成出来ないものもあり、それ故にquoted-printable符号
化の出力に現われると公式には間違いです。この覚書は、これらの事例や復元
されたquoted-printableデーターに遭遇した場合このような不正なサブストリ
ングを取り扱う方法の示唆を列挙しています。
(1) 二つの十六進数が続く"="は、その一つもしくは二つとも"abcdef"の小
文字で、公式には間違いです。強力な手段提供者は対応する大文字と
してこれらを認め方を選ぶかもしれません。
(2) 十六進数（"abcdef"をも含む）もCRLF組のCR文字でない文字が続く"="
は正しいものです。このケースは、quoted-printable符号化に従わさ
れない自身を別にして、メッセージのquoted-printable部分に含まさ
れているUS-ASCIIテキストの結果です。強力な手段提供者による納得
のいくアプローチは、復元されたデーターの"="文字と続く文字をなん
ら変換せず含むことで、出来れば利用者に適切な復元がデーターのこ
の点でできなかったことを示唆します。
(3) "="は、符号化される対象の最後や最後から二番目の文字であることは
できません。これは上記の(2)ケースとして取り扱えます。
(4) TABもしくはCRLF組の部分としてのCRとLF以外の制御文字は現われては
いけません。126以上の十進値のオクテットにとっても同じことです。
デコーダーによって中に入ってきたquoted-printableデーターを発見
された場合、強力な手段提供者は復元されたデーターからこれらを排
除し、利用者に不正な文字が発見されたと警告します。
(5) 符号化された行は76文字よりながいといけなく、末尾のCRLFを数に入
れません。より長い行が中に入ってき、符号化されたデーターと分か
ると、強力な手段提供者はそれでも行を復元し、利用者に間違った符
号化を報告します。
Freed & Borenstein Standards Track [Page 22]
RFC 2045 Internet Message Bodies November 1996
手段提供者への警告： バイナリーデーターがquoted-printableで符号化され
る場合、CRとLFをそれぞれ"=0D"と"=0A"として符号化するよう配慮がなさねば
なりません。特にバイナリーデータでのCRLF列がハード改行として表現されて
いた場合異なる改行慣例のプラットフォームで不正確に復元されます。
形式重視主義者には、quoted-printableデーターの構文は以下の文法で記載
される：
quoted-printable := qp-line *(CRLF qp-line)
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-part := qp-section
; Maximum length of 76 characters
qp-segment := qp-section *(SPACE / TAB) "="
; Maximum length of 76 characters
qp-section := [*(ptext / SPACE / TAB) ptext]
ptext := hex-octet / safe-char
safe-char := <any octet with decimal value of 33 through
60 inclusive, and 62 through 126>
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; Octet must be used for characters > 127, =,
; SPACEs or TABs at the ends of lines, and is
; recommended for any character not listed in
; RFC 2049 as "mail-safe".
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
IMPORTANT: The addition of LWSP between the elements shown in this
BNF is NOT allowed since this BNF does not specify a structured
header field.
Freed & Borenstein Standards Track [Page 23]
RFC 2045 Internet Message Bodies November 1996
#^
6.8. Base64 内容転送符号化
base64 Content-Transfer-Encodingは、人が判読する必要がない形式で任意
の一連のオクテット（8ビット）を表現するよう設計されています。コード
化やデコード手順は簡潔で、コード化されたデーターは単に非コード化デー
ターより33％大きくなるだけです。このコード化は、RFC 1421に定義されて
いるように、プライバシー強化メール（Privacy Enhanced Mail (PEM) ）ア
プリケーションで使用されものと同じです。
6ビットで印刷可能な文字を表現することができるために、US-ASCIIの65文
が使われます（例外の65番目の文字、"="、は特別な処理機能を知らせるの
に使われます）。
注意： このサブセットは重要な特質を持っていて、US-ASCIIを含むISO
646の全てのバージョンで同等に表現され、サウブセットの全ての文字も
EBCDICの全てのバージョンで同等に表現されます。その他のよく見られる
コード化、uuencodeユーティリティ・Macintosh binhex 4.0[RFC-1741]そし
てポストスクリプトレベル2の一部として特定されたbase85で使われるコー
ド化など、はこれらの特質はなく、それゆえにメール用のバイナリー転送
コード化が持たねばならない特質要求を満たしていません。
コード化処理は、入力ビットの24ビットグループを四つのコード化文字出力
列で表現します。左から右にすすみ、24ビット入力グループは三つの8ビッ
ト連結状態の書式にします。次いで、これらの24ビットは四つの6ビット連
結状態のグループとして処理され、base64アルファベットでシングル=デジ
タルに変換されます。base64符号化でビット連続体を符号化する場合、この
ビット連続体はまず最も意味のあるビット（most-significant-bit）から並
べられていると推定されなければなりません。言い替えると、連続体（スト
リーム）の最初のビットは最初の8ビット・バイトの高い順位のビット（
high-order bit）で、8番目のビットは低い順位のビット（ low-order
bit）であると。
各6ビットグループは64の印字可能な文字配列へのインデックスとして使用
されます。インデックスによって参照された文字は、出力列に置かれます。
以下のこれらの文字、表1で決められている、は汎用の表現てあるように選
ばれていて、このセットではSTMP（例えば、"."・CR・ LF）やRFC 2046（例
えば、 "-"）で定義されている多元パート境界識別子にとって特に意味をもっ
た文字は除かれています。
Freed & Borenstein Standards Track [Page 24]
RFC 2045 Internet Message Bodies November 1996
テーブル 1: Base64 アルファベット
値 符号化 Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
符号化された出力列は76文字以内で、一行に表現されなければなりません。
改行やテーブル1にない文字はデコードソフトは無視しなければなりません。
base64データーでは、テーブル1以外の文字・改行・空白文字は恐らく伝達
間違であるとことが示唆されていて、伝達間違いについて警告メッセージも
しくは排除メッセージがある状況では適切かもしれません。
コード化するデータの終わりで24ビットより少ない場合特別な処理が行われ
ます。完全にコード化されるものはボディの終わりで必ず完成します。入力
グループで24入力ビットより少ない場合、ゼロビットが（右に）加えられ、
6ビットグループの整数番号を形成します。データの終で補充（padding）
は、"="文字を使って行われます。base64入力は全てオクテットの整数です
ので、以下のケースのみがおこります：(1)コード化する入力の最終量は整
数多元的24ビットです；ここではコード化された出力の最終単位は整数多元
的4文字で "="補充はありません。(2)コード化する入力の最終量が丁度8ビット
である；ここではコード化された出力の最終単位は、二つの文字に続いて二
つ補充文字"="がき、もしくは(3)コード化する入力の最後の量が丁度16ビット
である：ここではコード化された出力の最終単位は三つの文字に続いて一つ
の 補充文字"="がきます。
補充（padding）はデーターの最後にだけきますので、"="文字があればその
データーの終わりに至ったことが明白なこととして受け取られるかもしれま
せん（転送中で省略がなければ）。
Freed & Borenstein Standards Track [Page 25]
RFC 2045 Internet Message Bodies November 1996
しかし、転送されたオクテットが三倍数で "="文字がない場合そのような確
認はできません。
base64アルファベット以外の文字は如何なるものでもbase64符号化データー
では無視されなければなりません。
正式書式に変換されないテキスト資料に直接base64符号化が適用されるな
ら、改行（line breaks）用に適切なオクテットをしようするよう配慮が取
られなければなりません。特にテキスト改行は、base64符号化に先行して
CRLF列に変換されなければなりません。注意すべき重要なことは、手段提供
者によっては正式か段階に先行するするのでなく符号化によって直接これが
施行されるかもしれないことです。
注意： 多元部分実体内のbase64符号化ボディの潜在的な境界識別子を引用
符で囲むことの心配は必要ありません、というのはハウフェン文字は
base64符号化では使用されないからです。
#^
7. Content-ID ヘッダーフィールド
レベルの高い表示代行手段を構築するには、ボディが別のものを参照できる
ようにしたくなるかもしれません。従って、ボディは"Content-ID"ヘッダー
フィールドを使ってラベル付けされ、それは構文的には"Message-ID"ヘッ
ダーフィールドと同じになります。
id := "Content-ID" ":" msg-id
Message-ID値のように、Content-ID値は世界で唯一のも生成しなければなり
ません。
Content-ID値は、幾つかの文脈で、特にmessage/external-body機構により
参照されるキャッシングデーターのために、MIME実体を特異的に識別するた
めに使用されなければなりません。Content-IDヘッダーは一般的には選択性
ですが、その使用は選択性のMIMEメディアタイプ"message/external-body"
のデーターを生成する手段提供者では必須です。いいかえると、各
message/external-body実体は、このようなデーターのキャッシングを許す
Content-IDフィールドをもっていなければなりません。
Content-ID値は、multipart/alternative メディアタイプの場合特別な意味
を持っていることを知っておくことは価値のあることです。これは
multipart/alternativeを処理するRFC 2046のセクションで説明されていま
す。
Freed & Borenstein Standards Track [Page 26]
RFC 2045 Internet Message Bodies November 1996
#^
8. Content-Description ヘッダーフィールド
或るボディに説明的な記載を関連ずけることができることが、望ましいこと
です。例えば、"image"ボディを"Space Shuttle Endeavorの絵"とすること
は有用かもしれません。このようなテキストは、Content-Descriptionヘッ
ダーフィールドに置かれます。このヘッダーフィールドは、常に選択的なも
のです。
description := "Content-Description" ":" *text
この説明は、RFC 2047で特定されたこの機構は非ASCIIContent-Description
値で使用されるかもしれませんが、US-ASCII文字で与えられていると看做さ
れます。
#^
9. 補足的な MIME ヘッダーフィールド
様々な目的のために追加的なMIMEヘッダーフィールドを定義する文書が将来
出て来るかもしれません。将来メッセージ内容を記載する新しいヘッダー
フィールドは、"Content-"文字ではじまるべきで、メッセージボディに現わ
れたこの様なフィールドが普通のRFC 822メッセージヘッダーフィールドと
区別できるようにするためです。
MIME-extension-field := < 列"Content-"ではじまる
RFC 822 ヘッダーフィールド>
#^
10. 要約
MIME-Version・Content-Type（内容型）そしてContent-Transfer-Encoding
（内容転送符号化）ヘッダーフィールドを用いて、標準化された方法で、任
意のデーター型をRFC 822適合メールメッセージに取り込むことが可能で
す。RFC 821もしくはRFC 822両者によって課せられた制限は全く打ち破ら
れ、そしてインターネットメール転送機構特有性によって課せられたさらな
る制限に起因する問題も回避するために注意が払われています（RFC 2049参
照）。
この一式の次の文書は、RFC 2046で、メディアタイプの初期設定を特定し、
このヘッダーを使ってラベル付けられ転送されることが可能です。
#^
11. 安全性の問題
安全性の問題はこの一組の二番目の文書、RFC 2046、で言及されています。
Freed & Borenstein Standards Track [Page 27]
RFC 2045 Internet Message Bodies November 1996
#^
12. 著者への連絡
For more information, the authors of this document are best contacted
via Internet mail:
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.com
Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA
Phone: +1 201 540 8967
Fax: +1 201 993 3032
EMail: nsb@nsb.fv.com
MIME is a result of the work of the Internet Engineering Task Force
Working Group on RFC 822 Extensions. The chairman of that group,
Greg Vaudreuil, may be reached at:
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
EMail: Greg.Vaudreuil@Octel.Com
#^
Freed & Borenstein Standards Track [Page 28]
RFC 2045 Internet Message Bodies November 1996
付録A -- 収集された文法
この付録には、この文書で特定された全構文用の完全なBNF文法がありま
す。
しかし、これだけではこの文法は不完全です。これは名指しでRFC 822で定
義された幾つかの構文規則を参照しています。ここで定義を再定義し両者の
間の意図しない違いの危険をおかすより、この文書はまだ残っている定義に
ついて単に読み手にRFC 822を差し向けるだけです。用語が未定義であって
もRFC 822の定義に照会します。
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
composite-type := "message" / "multipart" / extension-token
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
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")
; Octet must be used for characters > 127, =,
; SPACEs or TABs at the ends of lines, and is
; recommended for any character not listed in
; RFC 2049 as "mail-safe".
iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>
Freed & Borenstein Standards Track [Page 29]
RFC 2045 Internet Message Bodies November 1996
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
id := "Content-ID" ":" msg-id
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
MIME-extension-field := <Any RFC 822 header field which
begins with the string
"Content-">
MIME-message-headers := entity-headers
fields
version CRLF
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.
MIME-part-headers := entity-headers
[fields]
; Any field not beginning with
; "content-" can have no defined
; meaning and may be ignored.
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.
parameter := attribute "=" value
ptext := hex-octet / safe-char
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-part := qp-section
; Maximum length of 76 characters
qp-section := [*(ptext / SPACE / TAB) ptext]
qp-segment := qp-section *(SPACE / TAB) "="
; Maximum length of 76 characters
quoted-printable := qp-line *(CRLF qp-line)
Freed & Borenstein Standards Track [Page 30]
RFC 2045 Internet Message Bodies November 1996
safe-char := <any octet with decimal value of 33 through
60 inclusive, and 62 through 126>
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
subtype := extension-token / iana-token
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
type := discrete-type / composite-type
value := token / quoted-string
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
#^
Freed & Borenstein Standards Track [Page 31]