原典 RFC2045
ftp://ds.internic.net/rfc/rfc2045.txt
翻訳開始98.3.10 進行中98.5.25
http://www.bekkoame.ne.jp/%7Epoetlabo/WWW/rfc2045J.html
訳文に関するご意見はHTML研究室専用掲示板へどうぞ
Copyleft: 1998, 魔術幻燈
Network Working Group
Request for Comments: 2045
Obsoletes: 1521, 1522, 1590
Category: Standards Track
N. Freed
Innosoft
N. Borenstein
First Virtual
November 1996
この文書は、インターネット社会のためのインターネット標準過程となる作法を決めるものであり、その改良のための議論や提案を求めるものです。標準化の状況とこの作法の地位については、最新版の "Internet Official Protocol Standards" (STD 1)を参照してください。この書き付けの配布は無制限です。
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
通信文表現作法を定義しているSTD 11 （ RFC 822 ）は、US-ASCII通信文ヘッダについて重要な詳細を指定していますが、通信文内容や通常のUS-ASCII文章となる通信文本体については放置しています。この文書一式は、総じてMultipurpose Internet Mail ExtensionsもしくはMIMEと呼ばれ、以下を可能にするような通信文の形式を再定義するものです。
STD 11, RFC 822, defines a message representation protocol specifying
considerable detail about US-ASCII message headers, and leaves the
message content, or message body, as flat US-ASCII text. This set of
documents, collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to allow for
これらの文書は、 RFC 934 と STD 11 と RFC 1049 で文書化された以前の研究に基づきますが、なおそれらを拡張し、改訂するものです。
RFC 822 は通信文本体についてほとんど触れていないので、これらの文書は RFC 822 の大部分を（改訂というより）補完するものです。
These documents are based on earlier work documented in RFC 934, STD
11, and RFC 1049, but extends and revises them. Because RFC 822 said
so little about message bodies, these documents are largely
orthogonal to (rather than a revision of) RFC 822.
この最初の文書では、 MIME 通信文の構造を描写するのに使われる種々のヘッダを指定します。
２番目の文書（ RFC 2046 ）は MIME メディアタイプシステムの一般的な構造を定義し、メディアタイプの既定のセットを定義します。
第３の文書（ RFC 2047 ）はインターネットメールヘッダフィールドに non-US-ASCII 文章データを使えるようにするための RFC 822 の拡張について描写します。
４番目の文書（ RFC 2048 ）は MIME-related 設備の種々の IANA 登録手順を指定します。
５番目の、そして最後の文書（ RFC 2049 ）は MIME conformance 基準について描写した上、 MIME 通信文形式の実用例と謝辞と参考文献一覧を提供します。
This initial document specifies the various headers used to describe
the structure of MIME messages. The second document, RFC 2046,
defines the general structure of the MIME media typing system and
defines an initial set of media types. The third document, RFC 2047,
describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields. The fourth document, RFC 2048, specifies
various IANA registration procedures for MIME-related facilities. The
fifth and final document, RFC 2049, describes MIME conformance
criteria as well as providing some illustrative examples of MIME
message formats, acknowledgements, and the bibliography.
これらの文書は、それ自体が RFC 1341 と RFC 1342 の改訂であった RFC 1521 と RFC 1522 と RFC 1590 の改訂です。
RFC 2049 の付録では、以前のものとの相違と変化について描写します。
These documents are revisions of RFCs 1521, 1522, and 1590, which
themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
2049 describes differences and changes from previous versions.
1982年の発表以来、 RFC 822 はインターネットにおけるメール通信文本体の標準形式を定義しています。
全体的にせよ部分的にせよ、RFC 822 形式の採用の成功は、インターネットと RFC 821 によって定義されるインターネット SMTP 輸送との境界を乗り越えるものでした。
この形式がより広く使用されていくにつれて、多くの制限が利用者コミュニティにとってますます窮屈になっていくと判明しました。
Since its publication in 1982, RFC 822 has defined the standard
format of textual mail messages on the Internet. Its success has
been such that the RFC 822 format has been adopted, wholly or
partially, well beyond the confines of the Internet and the Internet
SMTP transport defined by RFC 821. As the format has seen wider use,
a number of limitations have proven increasingly restrictive for the
user community.
RFC 822 は、文章通信文の形式を指定するためのものでした。
そういうわけで、音声や画像を取り込めるマルチメディア通信文のような非テキスト通信文については、単に述べられていません。
しかしながら RFC 822 は文章の場合でも、US-ASCIIより豊富な文字セットを使う必要がある言語によるメール利用者の要求には十分に答えられません。
音声や動画やアジアの言語による文章を伴っているもの、あるいはほとんどのヨーロッパの言語による文章についてさえも、メールの機構についてRFC 822 が指定していない以上、追加の仕様書が必要です。
RFC 822 was intended to specify a format for text messages. As such,
non-text messages, such as multimedia messages that might include
audio or images, are simply not mentioned. Even in the case of text,
however, RFC 822 is inadequate for the needs of mail users whose
languages require the use of character sets richer than US-ASCII.
Since RFC 822 does not specify mechanisms for mail containing audio,
video, Asian language text, or even text in most European languages,
additional specifications are needed.
RFC 821/822 準拠メールシステムの顕著な制限の１つは、電子郵便通信文の内容が7ビットUS-ASCIIの比較的短い行（1,000文字あるいはそれ未満など[RFC-821]）に制限されるという事実です。
このため、利用者が送ろうとするどんな非文章データも、ローカルなメール UA （利用者エージェント、すなわち人間の利用者がメールを送受信するプログラム）が動く前に、印刷用US-ASCII文字として表示可能な7ビットバイトへ変換することを強いられます。
現在インターネットで用いられているそのような符号化方式の例としては、純粋の16進数や uuencode や RFC 1421 で指定された 3-in-4 base 64 スキームや Andrew Toolkit Representation [ATK] や、ほか多数のものがあります。
One of the notable limitations of RFC 821/822 based mail systems is
the fact that they limit the contents of electronic mail messages to
relatively short lines (e.g. 1000 characters or less [RFC-821]) of
7bit US-ASCII. This forces users to convert any non-textual data
that they may wish to send into seven-bit bytes representable as
printable US-ASCII characters before invoking a local mail UA (User
Agent, a program with which human users send and receive mail).
Examples of such encodings currently used in the Internet include
pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in
RFC 1421, the Andrew Toolkit Representation [ATK], and many others.
RFC 822 メールの限界は、 RFC 822 ホストと X.400 ホストとのメール通信文交換を考慮に入れたゲートウェイを設計するときに、より明白になります。
X.400 [ X400 ] は、電子郵便通信文へ入れる非文章素材のための機構を定めます。
X.400 通信文を RFC 822 通信文へ写像変換する現行の基準では、X.400非文章素材が（符号化されずに） IA5Text 形式に変換されなければならないこと、あるいはそれが捨てられなければならなかった場合、遺棄が発生したことをRFC 822 利用者に通知することを定めています。
利用者が受信しようとする情報が失われるのでは、これは明らかに望ましくありません。
利用者エージェントには非文章素材を取り扱う能力がなくても、利用者には、材料から有用な情報を引き出すことができる UA 外部の機構があるかもしれないのにです。
さらに、これでは通信文をなんとかして（非文章の情報が明確に再び有用になる）X.400 通信文操作システムにゲートウェイで返すということができません。つまり、インターネットメールから、X.400 通信文がこぼれてしまいます。
The limitations of RFC 822 mail become even more apparent as gateways
are designed to allow for the exchange of mail messages between RFC
822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
inclusion of non-textual material within electronic mail messages.
The current standards for the mapping of X.400 messages to RFC 822
messages specify either that X.400 non-textual material must be
converted to (not encoded in) IA5Text format, or that they must be
discarded, notifying the RFC 822 user that discarding has occurred.
This is clearly undesirable, as information that a user may wish to
receive is lost. Even though a user agent may not have the
capability of dealing with the non-textual material, the user might
have some mechanism external to the UA that can extract useful
information from the material. Moreover, it does not allow for the
fact that the message may eventually be gatewayed back into an X.400
message handling system (i.e., the X.400 message is "tunneled"
through Internet mail), where the non-textual information would
definitely become useful again.
この文書は、RFC 822 メールの世界に重大な非互換性を一切来すことなく、これらの問題のほとんどを解決するために組み合わせる、いくつかの機構について説明するものです。
特に：
This document describes several mechanisms that combine to solve most
of these problems without introducing any serious incompatibilities
with the existing world of RFC 822 mail. In particular, it
describes:
この文書で定義されるすべてのヘッダフィールドは、 RFC 822 で指定されたヘッダフィールドに関する一般的な語法の規則に従っています。
特に、Content-Dispositionを除くすべてのヘッダフィールドに、 RFC 822 コメントを入れることができます。これは、意味に関する内容を持たず、MIME処理過程を通じて無視されるべきものです。
All of the header fields defined in this document are subject to the
general syntactic rules for header fields specified in RFC 822. In
particular, all of these header fields except for Content-Disposition
can include RFC 822 comments, which have no semantic content and
should be ignored during MIME processing.
最後に、定義づけと互換性の増進のために、 RFC 2049 はこの文書での『 準拠 』最小レベルを定義する上記機構のサブセットのための基本的な applicability 声明を規定します。
Finally, to specify and promote interoperability, RFC 2049 provides a
basic applicability statement for a subset of the above mechanisms
that defines a minimal level of "conformance" with this document.
この文書一式で定義される機構はどれも散文で描写されるのではありますが、ほとんどは RFC 822 の拡張 BNF 表記法でも正式に描写されます。
実装者は文書のこのセットを理解するために、この表記法に精通する必要があります。拡張 BNF 表記法に関する完全な説明については、 RFC 822 が参照されます。
Although the mechanisms specified in this set of documents are all
described in prose, most are also described formally in the augmented
BNF notation of RFC 822. Implementors will need to be familiar with
this notation in order to understand this set of documents, and are
referred to RFC 822 for a complete explanation of the augmented BNF
notation.
この文書一式にある拡張 BNF の中には、 RFC 822 で定義された語法規則への指定された参照をするものがあります。
それで完全な形式の文法が、 RFC 822 に RFC 1123 で定義された RFC 822 への修正（特に「return」と「date」そして「mailbox」語法を変更する）を加えた BNF をもってこのセットの各々の文書から集められた文法付録を結合させることによって得られることになります。
Some of the augmented BNF in this set of documents makes named
references to syntax rules defined in RFC 822. A complete formal
grammar, then, is obtained by combining the collected grammar
appendices in each document in this set with the BNF of RFC 822 plus
the modifications to RFC 822 defined in RFC 1123 (which specifically
changes the syntax for `return', `date' and `mailbox').
文書のこのセットでは、全ての数字とオクテット値は十進法で与えられます。
定義された全てのメディア種別値と副種別値と変数名は、大文字・小文字を区別しません。
しかしながら、変数の値は、特定の変数のための指定がない限り、大文字・小文字を区別します。
All numeric and octet values are given in decimal notation in this
set of documents. All media type values, subtype values, and
parameter names as defined are case-insensitive. However, parameter
values are case-sensitive unless otherwise specified for the specific
parameter.
この文書一式での用語 CRLF は、この順序で一緒にされて、 RFC 822 メールの行の切れ目を示す2つのUS-ASCII文字、 CR （十進法値 13 ）と LF （十進法値 10 ）に相当する1バイトの単位2つを言います。
The term CRLF, in this set of documents, refers to the sequence of
octets corresponding to the two US-ASCII characters CR (decimal value
13) and LF (decimal value 10) which, taken together, in this order,
denote a line break in RFC 822 mail.
MIMEでは、用語『文字セット』をもって、バイト一揃いを文字一揃いに変換する方法を言います。
逆方向への無条件で明確な変換は必要とされないことに注意してください。これは、与えられた文字セットによっては全ての文字が表せないかもしれず、文字セットが特定の文字一揃いを表すのに複数のバイト揃いを与えるかもしれないからです。
The term "character set" is used in MIME to refer to a method of
converting a sequence of octets into a sequence of characters. Note
that unconditional and unambiguous conversion in the other direction
is not required, in that not all characters may be representable by a
given character set and a character set may provide more than one
sequence of octets to represent a particular sequence of characters.
この定義は、US-ASCIIのような単純な単表写像変換からISO 2022の技術として使用されるような切り換え方式の複雑な表まで、文字符号化方式の多くの種類を文字セットとして使用できるように考えられています。
しかしながら mime 文字セット名に結合した定義は、機能する写像変換を完全に指定しなければなりません。
特に、正確な写像変換を確定するために、外部プロファイリング情報の使用は許されません。
This definition is intended to allow various kinds of character
encodings, from simple single-table mappings such as US-ASCII to
complex table switching methods such as those that use ISO 2022's
techniques, to be used as character sets. However, the definition
associated with a MIME character set name must fully specify the
mapping to be performed. In particular, use of external profiling
information to determine the exact mapping is not permitted.
特に断っていない限り、用語『通信文』は、ネットワーク上で転送される（完全或いは『トップ-レベル』の） RFC 822 通信文か、本体にタイプ『 message/rfc822 』か『 message/partial 』を含んだ通信文の、どちらをも意味します。
The term "message", when not further qualified, means either a
(complete or "top-level") RFC 822 message being transferred on a
network, or a message encapsulated in a body of type "message/rfc822"
or "message/partial".
用語『実体』は、特に MIMEで定義されたヘッダ-フィールドと、通信文か multipart 実体の本体の一部の内容を言います。
そのような実体の仕様書こそ、MIMEの真髄と申せましょう。
実体の内容がしばしば『本体』と呼ばれるため、それは実体の本体について話すような感覚を形成することとなります。
実体のヘッダには、フィールドのどんな分類を表してもよいのですが、実際に MIMEに関連した何らかの意味を持つのは、名前が『 content- 』で始まるフィールドだけです。
これは、それらが全く無意味だと言っているのではないことに気をつけてください。実体は、その意味が RFC 822 によって定義される非MIMEヘッダフィールドを持つ通信文でもあります。
The term "entity", refers specifically to the MIME-defined header
fields and contents of either a message or one of the parts in the
body of a multipart entity. The specification of such entities is
the essence of MIME. Since the contents of an entity are often
called the "body", it makes sense to speak about the body of an
entity. Any sort of field may be present in the header of an entity,
but only those fields whose names begin with "content-" actually have
any MIME-related meaning. Note that this does NOT imply thay they
have no meaning at all -- an entity that is also a message has non-
MIME header fields whose meanings are defined by RFC 822.
用語『本体部分』は、 multipart 実体内部の実体を言います。
The term "body part" refers to an entity inside of a multipart
entity.
用語『本体』は、特に断っていない限り、実体の本体、つまり通信文か本体部分の本体を意味します。
The term "body", when not further qualified, means the body of an
entity, that is, the body of either a message or of a body part.
『 7ビットデータ』は、 998 オクテットの比較的短い行か、それより短い CRLF 行分離単位 [ RFC-821 ] までの行を表わすデータ全てを言います。
十進法値で127 を越えるオクテットや NULs （十進法値 0 のオクテット）は許されません。
CR （十進法値 13 ）と LF （十進法値 10 ）オクテットは、 CRLF 行分離単位の一部としてのみ存在します。
"7bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]. No octets with decimal values greater than 127
are allowed and neither are NULs (octets with decimal value 0). CR
(decimal value 13) and LF (decimal value 10) octets only occur as
part of CRLF line separation sequences.
『 8ビットデータ』は、 998 オクテットの比較的短い行か、それより短い CRLF 行分離単位 [ RFC-821 ] までの行を表わすデータ全てを言いますが、 127 より大きい十進法値のオクテットを使用することができます。
『 7ビットデータ』におけると同様、 CR と LF オクテットは CRLF 行分離単位の一部としてだけ存在し、 NULs は許されません。
"8bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]), but octets with decimal values greater than 127
may be used. As with "7bit data" CR and LF octets only occur as part
of CRLF line separation sequences and no NULs are allowed.
『バイナリデータ』は、どんなオクテットの連続も全て許されているデータを言うものです。
"Binary data" refers to data where any sequence of octets whatsoever
is allowed.
『行』は、 CRLF 単位によって区切られたオクテットの連続として定義されます。
この定義は RFC 821 と RFC 822 に一致するものです。
『行』は通信文中のデータ一山だけを言うのですが、これは実際にユーザエージェントによって表示される物事に相当するかもしれないし、相当しないかもしれません。
"Lines" are defined as sequences of octets separated by a CRLF
sequences. This is consistent with both RFC 821 and RFC 822.
"Lines" only refers to a unit of data in a message, which may or may
not correspond to something that is actually displayed by a user
agent.
MIME は MIME 実体の内容について描写するのに使われる多数の新しい RFC 822 ヘッダフィールドを定義します。
これらのヘッダフィールドは、少なくとも2つの状況で出てきます。
MIME defines a number of new RFC 822 header fields that are used to
describe the content of a MIME entity. These header fields occur in
at least two contexts:
これらのヘッダフィールドの正式な定義は、以下のとおりです。
The formal definition of these header fields is as follows:
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
MIME-message-headers := entity-headers
fields
version CRLF
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.
この BNF 定義によって示された
ヘッダフィールドの順序は無視すべきです。
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.
『 content- 』で始まっていないフィールドは、
その意味の定義がないので、無視してかまいません。
この BNF 定義によって示されたヘッダフィールドの
順序は無視すべきです。
さまざまな MIME ヘッダフィールドの具体的な構文は、次の項で描写されます。
The syntax of the various specific MIME header fields will be
described in the following sections.
RFC 822 が 1982 年に出されて以来、インターネット通信文の標準形式は１つだけしかありませんでしたので、用いられる標準形式を宣言する必要はごく漠然としか理解されてきませんでした。
この文書は、 RFC 822 を補完する独立した仕様書です。
この文書における拡張が、 RFC 822 と互換的であるような方法で定義されているとはいうものの、依然として、通信文が新しい標準をもって作られたどうかがメール処理プログラムにわかるようにしたほうが望ましいかもしれない状況があることを含んでおいてください。
かくしてこの文書は、新しいヘッダフィールド、"MIME-Version"を定義します。これは用いられているインターネット通信文本体標準形式の版を宣言するために使用されます。
Since RFC 822 was published in 1982, there has really been only one
format standard for Internet messages, and there has been little
perceived need to declare the format standard in use. This document
is an independent specification that complements RFC 822. Although
the extensions in this document have been defined in such a way as to
be compatible with RFC 822, there are still circumstances in which it
might be desirable for a mail-processing agent to know whether a
message was composed with the new standard in mind.
Therefore, this document defines a new header field, "MIME-Version",
which is to be used to declare the version of the Internet message
body format standard in use.
この文書に従って作られた通信文は、次の逐語的な文によるヘッダフィールドというものを必ず含まなければなりません。
Messages composed in accordance with this document MUST include such
a header field, with the following verbatim text:
MIME-Version: 1.0
このヘッダフィールドの存在は、その通信文がこの文書に従って書かれているということを確言するものです。
The presence of this header field is an assertion that the message
has been composed in compliance with this document.
未来の文書が通信文形式標準を再び拡張するであろうことを考えて、 MIME-Version フィールドの内容には正式の BNF が与えられています：
Since it is possible that a future document might extend the message
format standard again, a formal BNF is given for the content of the
MIME-Version field:
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
こうして、『 1.0 』を更新あるいは拡張するであろう未来の形式識別子は、終止符によって区切られた２つの整数フィールドであるように決められています。
もし通信文が『 1.0 』以外の MIME-version 値をもって受信されたなら、それはこの文書に従うものと看做すことはできません。
Thus, future format specifiers, which might replace or extend "1.0",
are constrained to be two integer fields, separated by a period. If
a message is received with a MIME-version value other than "1.0", it
cannot be assumed to conform with this document.
通信文にはMIME-Version ヘッダフィールドが最優先で要求されることに注意してください。
これは多元実体の各々の本体部分のために必要とされるわけではありません。
これはタイプ『 message/rfc822 』か『 message/partial 』の本体に埋め込まれたヘッダのために、埋め込まれた通信文それ自体が MIME 準拠であると確言する場合、その場合に限り、必要とされます。
Note that the MIME-Version header field is required at the top level
of a message. It is not required for each body part of a multipart
entity. It is required for the embedded headers of a body of type
"message/rfc822" or "message/partial" if and only if the embedded
message is itself claimed to be MIME-conformant.
この文書で定義される MIME に従う郵便読み取り機が、将来は『 1.0 』以外の MIME-Version の値をもって届けられるであろう通信文を、どのように扱うべきであるかまで完全に指定することはできません。
It is not possible to fully specify how a mail reader that conforms
with MIME as defined in this document should treat a message that
might arrive in the future with some value of MIME-Version other than
"1.0".
具体的な媒体種別のためのバージョンコントロールが、MIME-Version 機構を使って成されるわけではないことは、注意したほうがいいでしょう。
特に、形式によっては application/postscript など、媒体形式の内部にバージョン番号を付ける取り決めのあるものもあります。
そのような取り決めが存在する場合、 MIME がそれにとって代わることはありません。
そのような取り決めがいっさい存在しない場合、 MIME 媒体種別は必要に応じ、内容-種別フィールドの中の『バージョン』引き数を使ってかまいません。
It is also worth noting that version control for specific media types
is not accomplished using the MIME-Version mechanism. In particular,
some formats (such as application/postscript) have version numbering
conventions that are internal to the media format. Where such
conventions exist, MIME does nothing to supersede them. Where no
such conventions exist, a MIME media type might use a "version"
parameter in the content-type field if necessary.
MIME-Version フィールドがない場合、 それを受けとる郵便ユーザエージェントは（MIME 必要条件を満たしていてもいなくても）任意にローカルな取り決めによる通信文本体の解釈をするようにしてかまいません。
これに類するさまざまな取り決めが現在用いられており、そして実際には 非MIME 通信文がほとんどどんなものも含むことができることに注意すべきでしょう。
In the absence of a MIME-Version field, a receiving mail user agent
(whether conforming to MIME requirements or not) may optionally
choose to interpret the body of the message according to local
conventions. Many such conventions are currently in use and it
should be noted that in practice non-MIME messages can contain just
about anything.
非MIME 郵便通信文が実際にはUS-ASCII文字セットによる通常文であると言い切ることはできません。なぜならそれは、他の文字セットによる文章か自動的に識別できない方法（ uuencodeして圧縮された UNIX tarファイルなど）で表された非文章的本文データを含む、MIME 以前の標準外でローカルな取り決めのセットを使う通信文であるかもしれないからです。
It is impossible to be certain that a non-MIME mail message is
actually plain text in the US-ASCII character set since it might well
be a message that, using some set of nonstandard local conventions
that predate MIME, includes text in another character set or non-
textual data presented in a manner that cannot be automatically
recognized (e.g., a uuencoded compressed UNIX tar file).
Content-Type フィールドの目的は、本体に入っているデータについて、利用者へデータを提供するのに適切なエージェントか機構、でなければデータを扱う適切な方法を、受信するユーザエージェントが選ぶのに十分な描写をすることにあります。
このフィールドの値は、媒体種別と呼ばれます。
The purpose of the Content-Type field is to describe the data
contained in the body fully enough that the receiving user agent can
pick an appropriate agent or mechanism to present the data to the
user, or otherwise deal with the data in an appropriate manner. The
value in this field is called a media type.
Content-Type ヘッダフィールドは、媒体種別と副種別識別子を与えることにより、また特定の媒体種別のために必要とされるかもしれない補助的情報を与えることによって、実体における本体に含まれるデータの性質を指定するものです。
媒体種別と副種別名前の後に来るヘッダフィールドの残りは、属性=値 表記法で指定される簡単な引数のセットとなります。
引数の順序には、意味はありません。
The Content-Type header field specifies the nature of the data in the
body of an entity by giving media type and subtype identifiers, and
by providing auxiliary information that may be required for certain
media types. After the media type and subtype names, the remainder
of the header field is simply a set of parameters, specified in an
attribute=value notation. The ordering of parameters is not
significant.
概して最上位媒体種別は、副種別がその種別のデータの具体的な形式を指定するのに対し、データの一般的な種別を宣言するために使用されます。
従って『 image/xyz 』の媒体種別は、ユーザエージェントに具体的な画像形式『 xyz 』についての情報が全くない場合でも、データが画像であることをユーザエージェントに示すのに十分です。
そのような情報はたとえば、認識できない副種別から生のデータをユーザに見せるかどうか決めるために使用することができます -- がそのような動作は、文章による認識できない副種別のためには合理的かもしれませんが、画像か音声による認識できない副種別ではそうではありません。
このような理由で、文章・画像・音声・動画の登録済み副種別に、実際と異なる種別の埋め込み情報を入れるべきではありません。
そのような合成形式は、『 multipart 』か『application』種別を使って表わされるべきです。
In general, the top-level media type is used to declare the general
type of data, while the subtype specifies a specific format for that
type of data. Thus, a media type of "image/xyz" is enough to tell a
user agent that the data is an image, even if the user agent has no
knowledge of the specific image format "xyz". Such information can
be used, for example, to decide whether or not to show a user the raw
data from an unrecognized subtype -- such an action might be
reasonable for unrecognized subtypes of text, but not for
unrecognized subtypes of image or audio. For this reason, registered
subtypes of text, image, audio, and video should not contain embedded
information that is really of a different type. Such compound
formats should be represented using the "multipart" or "application"
types.
引数は媒体副種別を修飾するものであり、基本的に内容の性質に影響を及ぼすものではありません。
意味をもつ引数のセットは、媒体種別と副種別によって変わります。
ほとんどの引数は、単一の具体的な副種別に結び付いています。
しかしながら与えられた最上位媒体種別は、その種別のどんな副種別にも適用できる引数を定めることができます。
引数はその内容-種別か副種別を定めるのに必要とされるかもしれないし、或いはそれを追加してもかまいません。
MIME 実装においては、識別されない名前の引数はどのようなものであれ無視しなければなりません。
Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content. The set of
meaningful parameters depends on the media type and subtype. Most
parameters are associated with a single specific subtype. However, a
given top-level media type may define parameters which are applicable
to any subtype of that type. Parameters may be required by their
defining content type or subtype or they may be optional. MIME
implementations must ignore any parameters whose names they do not
recognize.
例えば、『boundary』引数が『 multipart 』媒体種別のどんな副種別にも必要とされるのに対し、『 charset 』引数は『text』のどんな副種別にも適用可能です。
For example, the "charset" parameter is applicable to any subtype of
"text", while the "boundary" parameter is required for any subtype of
the "multipart" media type.
どこででも意味をもつ全ての媒体種別にあてはまる引数などというものはありません。
MIME モデルでの本当に包括的な機構は、追加的な Content-* ヘッダフィールドの定義によって最もよく言及されます。
There are NO globally-meaningful parameters that apply to all media
types. Truly global mechanisms are best addressed, in the MIME
model, by the definition of additional Content-* header fields.
７つの最上位媒体種別の当初のセットは、 RFC 2046 で定義されます。
このうち５つは、 MIME 処理に関する限り、内容が本質的に不透明な分離した種別です。
残りの２つは、その内容が MIME 処理装置によって追加的な取り扱いを必要とする合成種別です。
An initial set of seven top-level media types is defined in RFC 2046.
Five of these are discrete types whose content is essentially opaque
as far as MIME processing is concerned. The remaining two are
composite types whose contents require additional handling by MIME
processors.
最上位媒体種別のこのセットは、実質的には完全なはずです。
取り扱われる種別のより幅広いセットへの追加は、一般にこれら当初の種別に新しい副種別を設けることによって成されることが予定されています。
将来、さらなる最上位種別が、この標準への標準過程拡張によってのみ定義されることでしょう。
いかなる理由であれ、もしこれ以外の最上位種別が使用されたなら、その非標準地位を示したうえ、来るべき公式の名前との対立の可能性を避けるために、その種別は『 X- 』に始まる名前を与えられなくてはなりません。
This set of top-level media types is intended to be substantially
complete. It is expected that additions to the larger set of
supported types can generally be accomplished by the creation of new
subtypes of these initial types. In the future, more top-level types
may be defined only by a standards-track extension to this standard.
If another top-level type is to be used for any reason, it must be
given a name starting with "X-" to indicate its non-standard status
and to avoid a potential conflict with a future official name.
RFC 822 の拡張 BNF 表記法では、 Content-Type ヘッダフィールド値は以下のように定義されます：
In the Augmented BNF notation of RFC 822, a Content-Type header field
value is defined as follows:
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
『 tspecials 』の定義が、 RFC 822 の定義になる『specials』へ"/""?""="の３文字を追加し"."を除いたものと同じであることに注意してください。
Note that the definition of "tspecials" is the same as the RFC 822
definition of "specials" with the addition of the three characters
"/", "?", and "=", and the removal of ".".
副種別指定が必須であること、 Content-Type ヘッダフィールドから省略してはいけないことにも注意してください。
つまり、既定の副種別などというものはないことになります。
Note also that a subtype specification is MANDATORY -- it may not be
omitted from a Content-Type header field. As such, there are no
default subtypes.
種別と副種別と引数名は、大文字・小文字を区別しません。
例えば、 TEXT と Text と TeXt は全て等しい最上位媒体種別となります。
引数値は通常は大文字・小文字を区別しませんが、予定された使い方によっては、しばしば大文字・小文字を区別するように解釈されることがあります。
（例えば、多元境界線は大文字・小文字を区別するが、 message/External-bodyの 『access-type』引数は大文字・小文字を区別しない。）
The type, subtype, and parameter names are not case sensitive. For
example, TEXT, Text, and TeXt are all equivalent top-level media
types. Parameter values are normally case sensitive, but sometimes
are interpreted in a case-insensitive fashion, depending on the
intended use. (For example, multipart boundaries are case-sensitive,
but the "access-type" parameter for message/External-body is not
case-sensitive.)
引用された文字列引数の値が引用文を含まないことに気をつけてください。
つまり、引用された文字列中の引用符は引数の値の一部ではなく、その引数値を区切るために使用されるだけです。
それに加えて、構成されたヘッダフィールドに対する RFC 822 規則に従って、コメントが許されています。こうして、以下の二つの形は
Note that the value of a quoted string parameter does not include the
quotes. That is, the quotation marks in a quoted-string are not a
part of the value of the parameter, but are merely used to delimit
that parameter value. In addition, comments are allowed in
accordance with RFC 822 rules for structured header fields. Thus the
following two forms
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
全く同等のものとなります。
are completely equivalent.
この語法に先立つ、副種別名の定義に関する唯一の語法上の制約は、その用法が衝突してはならないという要請です。
つまり、2つの異なったものを意味するのに"Content-Type: application/foobar" を使って、2つの異なるコミュニティにいるようにすることは望ましくありません。
新しい媒体副種別の定義過程は、だから、制約を押し付ける機構であるように意図されている訳ではなく、ただその定義と用法を広告するための機構です。
それゆえに新しい媒体副種別を定義するための許された機構は２つあります：
Beyond this syntax, the only syntactic constraint on the definition
of subtype names is the desire that their uses must not conflict.
That is, it would be undesirable to have two different communities
using "Content-Type: application/foobar" to mean two different
things. The process of defining new media subtypes, then, is not
intended to be a mechanism for imposing restrictions, but simply a
mechanism for publicizing their definition and usage. There are,
therefore, two acceptable mechanisms for defining new media subtypes:
このセットの中の２番目の文書（ RFC 2046 ）で、 MIME のための媒体種別の当初のセットを定義します。
The second document in this set, RFC 2046, defines the initial set of
media types for MIME.
既定値として、MIME Content-Type ヘッダのない RFC 822 通信文はこの作法によって、次のように指定されるUS-ASCII文字セットによる通常文として受け取られます：
Default RFC 822 messages without a MIME Content-Type header are taken
by this protocol to be plain text in the US-ASCII character set,
which can be explicitly specified as:
Content-type: text/plain; charset=us-ascii
この既定値は Content-Type ヘッダフィールドが一切指定されない場合を想定しています。
また、この既定値は、語法上無効な Content-Type ヘッダフィールドに出くわしたときのことも想定しておくことが勧められます。
MIME-Version ヘッダフィールドがあって Content-Type ヘッダフィールドがなければ、それを受けとる User Agent は同様に、送り手の意図したものが普通のUS-ASCII文章であったと想定することができます。
MIME-Version がないか語法上無効な Content-Type ヘッダフィールドがある場合にも、普通のUS-ASCII文章が想定されていいでしょう。しかしこの場合、送り手の意図は異なっていたかもしれません。
This default is assumed if no Content-Type header field is specified.
It is also recommend that this default be assumed when a
syntactically invalid Content-Type header field is encountered. In
the presence of a MIME-Version header field and the absence of any
Content-Type header field, a receiving User Agent can also assume
that plain US-ASCII text was the sender's intent. Plain US-ASCII
text may still be assumed in the absence of a MIME-Version or the
presence of an syntactically invalid Content-Type header field, but
the sender's intent might have been otherwise.
これは、 8bit 文字かバイナリデータのそれぞれ『ふさわしい』形式で、 email によってまともに送ることのできる数多くの媒体種別を表すものです。
転送作法によっては、そのようなデータを伝送できないことがあります。
例えば RFC 821 （ SMTP ）は、郵便通信文を、 7bit US-ASCIIデータにして一行当たりCRLF 行区切り子込みで 1000 字以下に制限しています。
Many media types which could be usefully transported via email are
represented, in their "natural" format, as 8bit character or binary
data. Such data cannot be transmitted over some transfer protocols.
For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
data with lines no longer than 1000 characters including any trailing
CRLF line separator.
そういうわけで、そのようなデータを7bitの短い行の形式に符号化する標準機構を定義する必要があります。
It is necessary, therefore, to define a standard mechanism for
encoding such data into a 7bit short line format. Proper labelling
of unencoded material in less restrictive formats for direct use over
less restrictive transports is also desireable. This document
specifies that such encodings will be indicated by a new "Content-
Transfer-Encoding" header field. This field has not been defined by
any previous standard.
Content-Transfer-Encoding項目の値は単一のトークンで、以下に示すように符号化種別を指定するものです。正式には
The Content-Transfer-Encoding field's value is a single token
specifying the type of encoding, as enumerated below. Formally:
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
値は大文字・小文字を区別しません。つまり、Base64 と BASE64 と bAsE64はすべて同等です。7ビットの符号化種別には、本体が既に7ビットのメール用表現になっていることが必要とされます。これは既定値です、つまりContent-Transfer-Encodingヘッダ項目が見当たらないときには"Content-Transfer-Encoding: 7BIT"と看做されます。
These values are not case sensitive -- Base64 and BASE64 and bAsE64
are all equivalent. An encoding type of 7BIT requires that the body
is already in a 7bit mail-ready representation. This is the default
value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
この単一のContent-Transfer-Encodingトークンは、実際には二つの部分に分かれます。これは本体の符号化転送についてどの種類のものが受け入れられるかを指定するもので、そのため復号過程はそれを元の形に戻すものでなければならず、また結果のドメインを指定するものでもあります。
This single Content-Transfer-Encoding token actually provides two
pieces of information. It specifies what sort of encoding
transformation the body was subjected to and hence what decoding
operation must be used to restore it to its original form, and it
specifies what the domain of the result is.
Content-Transfer-Encodings の変換部は、明示的にあるいは暗示的に、単一で明確な復号アルゴリズムを指定します。ここで復号アルゴリズムは、符号化されたオクテットのシークエンスを符号化される前の元のシークエンスに変換するか、それが符号化シークエンスとしては不正であるということを示すものです。
Content-Transfer- Encodings 変換が適切な操作を追加的な外部プロフィール情報に依存することはありません。
正当な符号化について、デコーダが単一の、明確な出力を生成しなければならないのに対して、そのような制限がエンコーダには存在しないことに注意してください。与えられたオクテットのシークエンスを、異なってはいるが同等の符号化シークエンスへ符号化するのは、全く正当です。
The transformation part of any Content-Transfer-Encodings specifies,
either explicitly or implicitly, a single, well-defined decoding
algorithm, which for any sequence of encoded octets either transforms
it to the original sequence of octets which was encoded, or shows
that it is illegal as an encoded sequence. Content-Transfer-
Encodings transformations never depend on any additional external
profile information for proper operation. Note that while decoders
must produce a single, well-defined output for a valid encoding no
such restrictions exist for encoders: Encoding a given sequence of
octets to different, equivalent encoded sequences is perfectly legal.
今のところ、素通しと、"quoted-printable"符号化と、"base64"符号化の3つの変換法が定義されています。その領分は"binary"、"8bit"、 "7bit"です。
Three transformations are currently defined: identity, the "quoted-
printable" encoding, and the "base64" encoding. The domains are
"binary", "8bit" and "7bit".
Content-Transfer-Encodingの値は"7bit"・"8bit"・"binary"で、すべて施された符号化変換を区別するためのものです。
それ自体は、単に本文データの領域の指標となるだけですが、与えられた輸送システムで伝達のために必要とされるかもしれない符号化の種類に関する有用な情報を与えます。用語"7bit data"・"8bit data"・"binary data"は全て第2項で定義済みです。
The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
mean that the identity (i.e. NO) encoding transformation has been
performed. As such, they serve simply as indicators of the domain of
the body data, and provide useful information about the sort of
encoding that might be needed for transmission in a given transport
system. The terms "7bit data", "8bit data", and "binary data" are
all defined in Section 2.
quoted-printableとbase64符号化は、その入力を任意の領域から"7bit"幅のデータに変換しますので、限定された輸送手段で安全に運ぶことができます。変換法の仕様定義は、以下で与えられます。
The quoted-printable and base64 encodings transform their input from
an arbitrary domain into material in the "7bit" range, thus making it
safe to carry over restricted transports. The specific definition of
the transformations are given below.
The proper Content-Transfer-Encoding label must always be used. Labelling unencoded data containing 8bit characters as "7bit" is not allowed, nor is labelling unencoded non-line-oriented data as anything other than "binary" allowed.
Unlike media subtypes, a proliferation of Content-Transfer-Encoding values is both undesirable and unnecessary. However, establishing only a single transformation into the "7bit" domain does not seem possible. There is a tradeoff between the desire for a compact and efficient encoding of largely- binary data and the desire for a somewhat readable encoding of data that is mostly, but not entirely, 7bit. For this reason, at least two encoding mechanisms are necessary: a more or less readable encoding (quoted-printable) and a "dense" or "uniform" encoding (base64).
Mail transport for unencoded 8bit data is defined in RFC 1652. As of
the initial publication of this document, there are no standardized
Internet mail transports for which it is legitimate to include
unencoded binary data in mail bodies. Thus there are no
circumstances in which the "binary" Content-Transfer-Encoding is
actually valid in Internet mail. However, in the event that binary
mail transport becomes a reality in Internet mail, or when MIME is
used in conjunction with any other binary-capable mail transport
mechanism, binary bodies must be labelled as such using this
mechanism.
NOTE: The five values defined for the Content-Transfer-Encoding field
imply nothing about the media type other than the algorithm by which
it was encoded or the transport system requirements if unencoded.
6.3. New Content-Transfer-Encodings
Implementors may, if necessary, define private Content-Transfer-
Encoding values, but must use an x-token, which is a name prefixed by
"X-", to indicate its non-standard status, e.g., "Content-Transfer-
Encoding: x-my-new-encoding". Additional standardized Content-
Transfer-Encoding values must be specified by a standards-track RFC.
The requirements such specifications must meet are given in RFC 2048.
As such, all content-transfer-encoding namespace except that
beginning with "X-" is explicitly reserved to the IETF for future
use.
Unlike media types and subtypes, the creation of new Content-
Transfer-Encoding values is STRONGLY discouraged, as it seems likely
to hinder interoperability with little potential benefit
6.4. Interpretation and Use
If a Content-Transfer-Encoding header field appears as part of a
message header, it applies to the entire body of that message. If a
Content-Transfer-Encoding header field appears as part of an entity's
headers, it applies only to the body of that entity. If an entity is
of type "multipart" the Content-Transfer-Encoding is not permitted to
have any value other than "7bit", "8bit" or "binary". Even more
severe restrictions apply to some subtypes of the "message" type.
Freed & Borenstein Standards Track [Page 16]
RFC 2045 Internet Message Bodies November 1996
It should be noted that most media types are defined in terms of
octets rather than bits, so that the mechanisms described here are
mechanisms for encoding arbitrary octet streams, not bit streams. If
a bit stream is to be encoded via one of these mechanisms, it must
first be converted to an 8bit byte stream using the network standard
bit order ("big-endian"), in which the earlier bits in a stream
become the higher-order bits in a 8bit byte. A bit stream not ending
at an 8bit boundary must be padded with zeroes. RFC 2046 provides a
mechanism for noting the addition of such padding in the case of the
application/octet-stream media type, which has a "padding" parameter.
The encoding mechanisms defined here explicitly encode all data in
US-ASCII. Thus, for example, suppose an entity has header fields
such as:
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
This must be interpreted to mean that the body is a base64 US-ASCII
encoding of data that was originally in ISO-8859-1, and will be in
that character set again after decoding.
Certain Content-Transfer-Encoding values may only be used on certain
media types. In particular, it is EXPRESSLY FORBIDDEN to use any
encodings other than "7bit", "8bit", or "binary" with any composite
media type, i.e. one that recursively includes other Content-Type
fields. Currently the only composite media types are "multipart" and
"message". All encodings that are desired for bodies of type
multipart or message must be done at the innermost level, by encoding
the actual body that needs to be encoded.
It should also be noted that, by definition, if a composite entity
has a transfer-encoding value such as "7bit", but one of the enclosed
entities has a less restrictive value such as "8bit", then either the
outer "7bit" labelling is in error, because 8bit data are included,
or the inner "8bit" labelling placed an unnecessarily high demand on
the transport system because the actual included data were actually
7bit-safe.
NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using
content-transfer-encodings on composite body data may seem overly
restrictive, it is necessary to prevent nested encodings, in which
data are passed through an encoding algorithm multiple times, and
must be decoded multiple times in order to be properly viewed.
Nested encodings add considerable complexity to user agents: Aside
from the obvious efficiency problems with such multiple encodings,
they can obscure the basic structure of a message. In particular,
they can imply that several decoding operations are necessary simply
Freed & Borenstein Standards Track [Page 17]
RFC 2045 Internet Message Bodies November 1996
to find out what types of bodies a message contains. Banning nested
encodings may complicate the job of certain mail gateways, but this
seems less of a problem than the effect of nested encodings on user
agents.
Any entity with an unrecognized Content-Transfer-Encoding must be
treated as if it has a Content-Type of "application/octet-stream",
regardless of what the Content-Type header field actually says.
NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER-
ENCODING: It may seem that the Content-Transfer-Encoding could be
inferred from the characteristics of the media that is to be encoded,
or, at the very least, that certain Content-Transfer-Encodings could
be mandated for use with specific media types. There are several
reasons why this is not the case. First, given the varying types of
transports used for mail, some encodings may be appropriate for some
combinations of media types and transports but not for others. (For
example, in an 8bit transport, no encoding would be required for text
in certain character sets, while such encodings are clearly required
for 7bit SMTP.)
Second, certain media types may require different types of transfer
encoding under different circumstances. For example, many PostScript
bodies might consist entirely of short lines of 7bit data and hence
require no encoding at all. Other PostScript bodies (especially
those using Level 2 PostScript's binary encoding mechanism) may only
be reasonably represented using a binary transport encoding.
Finally, since the Content-Type field is intended to be an open-ended
specification mechanism, strict specification of an association
between media types and encodings effectively couples the
specification of an application protocol with a specific lower-level
transport. This is not desirable since the developers of a media
type should not have to be aware of all the transports in use and
what their limitations are.
6.5. Translating Encodings
The quoted-printable and base64 encodings are designed so that
conversion between them is possible. The only issue that arises in
such a conversion is the handling of hard line breaks in quoted-
printable encoding output. When converting from quoted-printable to
base64 a hard line break in the quoted-printable form represents a
CRLF sequence in the canonical form of the data. It must therefore be
converted to a corresponding encoded CRLF in the base64 form of the
data. Similarly, a CRLF sequence in the canonical form of the data
obtained after base64 decoding must be converted to a quoted-
printable hard line break, but ONLY when converting text data.
Freed & Borenstein Standards Track [Page 18]
RFC 2045 Internet Message Bodies November 1996
6.6. Canonical Encoding Model
There was some confusion, in the previous versions of this RFC,
regarding the model for when email data was to be converted to
canonical form and encoded, and in particular how this process would
affect the treatment of CRLFs, given that the representation of
newlines varies greatly from system to system, and the relationship
between content-transfer-encodings and character sets. A canonical
model for encoding is presented in RFC 2049 for this reason.
6.7. Quoted-Printable Content-Transfer-Encoding
The Quoted-Printable encoding is intended to represent data that
largely consists of octets that correspond to printable characters in
the US-ASCII character set. It encodes the data in such a way that
the resulting octets are unlikely to be modified by mail transport.
If the data being encoded are mostly US-ASCII text, the encoded form
of the data remains largely recognizable by humans. A body which is
entirely US-ASCII may also be encoded in Quoted-Printable to ensure
the integrity of the data should the message pass through a
character-translating, and/or line-wrapping gateway.
In this encoding, octets are to be represented as determined by the
following rules:
(1) (General 8bit representation) Any octet, except a CR or
LF that is part of a CRLF line break of the canonical
(standard) form of the data being encoded, may be
represented by an "=" followed by a two digit
hexadecimal representation of the octet's value. The
digits of the hexadecimal alphabet, for this purpose,
are "0123456789ABCDEF". Uppercase letters must be
used; lowercase letters are not allowed. Thus, for
example, the decimal value 12 (US-ASCII form feed) can
be represented by "=0C", and the decimal value 61 (US-
ASCII EQUAL SIGN) can be represented by "=3D". This
rule must be followed except when the following rules
allow an alternative encoding.
(2) (Literal representation) Octets with decimal values of
33 through 60 inclusive, and 62 through 126, inclusive,
MAY be represented as the US-ASCII characters which
correspond to those octets (EXCLAMATION POINT through
LESS THAN, and GREATER THAN through TILDE,
respectively).
(3) (White Space) Octets with values of 9 and 32 MAY be
represented as US-ASCII TAB (HT) and SPACE characters,
Freed & Borenstein Standards Track [Page 19]
RFC 2045 Internet Message Bodies November 1996
respectively, but MUST NOT be so represented at the end
of an encoded line. Any TAB (HT) or SPACE characters
on an encoded line MUST thus be followed on that line
by a printable character. In particular, an "=" at the
end of an encoded line, indicating a soft line break
(see rule #5) may follow one or more TAB (HT) or SPACE
characters. It follows that an octet with decimal
value 9 or 32 appearing at the end of an encoded line
must be represented according to Rule #1. This rule is
necessary because some MTAs (Message Transport Agents,
programs which transport messages from one user to
another, or perform a portion of such transfers) are
known to pad lines of text with SPACEs, and others are
known to remove "white space" characters from the end
of a line. Therefore, when decoding a Quoted-Printable
body, any trailing white space on a line must be
deleted, as it will necessarily have been added by
intermediate transport agents.
(4) (Line Breaks) A line break in a text body, represented
as a CRLF sequence in the text canonical form, must be
represented by a (RFC 822) line break, which is also a
CRLF sequence, in the Quoted-Printable encoding. Since
the canonical representation of media types other than
text do not generally include the representation of
line breaks as CRLF sequences, no hard line breaks
(i.e. line breaks that are intended to be meaningful
and to be displayed to the user) can occur in the
quoted-printable encoding of such types. Sequences
like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely
appear in non-text data represented in quoted-
printable, of course.
Note that many implementations may elect to encode the
local representation of various content types directly
rather than converting to canonical form first,
encoding, and then converting back to local
representation. In particular, this may apply to plain
text material on systems that use newline conventions
other than a CRLF terminator sequence. Such an
implementation optimization is permissible, but only
when the combined canonicalization-encoding step is
equivalent to performing the three steps separately.
(5) (Soft Line Breaks) The Quoted-Printable encoding
REQUIRES that encoded lines be no more than 76
characters long. If longer lines are to be encoded
with the Quoted-Printable encoding, "soft" line breaks
Freed & Borenstein Standards Track [Page 20]
RFC 2045 Internet Message Bodies November 1996
must be used. An equal sign as the last character on a
encoded line indicates such a non-significant ("soft")
line break in the encoded text.
Thus if the "raw" form of the line is a single unencoded line that
says:
Now's the time for all folk to come to the aid of their country.
This can be represented, in the Quoted-Printable encoding, as:
Now's the time =
for all folk to come=
to the aid of their country.
This provides a mechanism with which long lines are encoded in such a
way as to be restored by the user agent. The 76 character limit does
not count the trailing CRLF, but counts all other characters,
including any equal signs.
Since the hyphen character ("-") may be represented as itself in the
Quoted-Printable encoding, care must be taken, when encapsulating a
quoted-printable encoded body inside one or more multipart entities,
to ensure that the boundary delimiter does not appear anywhere in the
encoded body. (A good strategy is to choose a boundary that includes
a character sequence such as "=_" which can never appear in a
quoted-printable body. See the definition of multipart messages in
RFC 2046.)
NOTE: The quoted-printable encoding represents something of a
compromise between readability and reliability in transport. Bodies
encoded with the quoted-printable encoding will work reliably over
most mail gateways, but may not work perfectly over a few gateways,
notably those involving translation into EBCDIC. A higher level of
confidence is offered by the base64 Content-Transfer-Encoding. A way
to get reasonably reliable transport through EBCDIC gateways is to
also quote the US-ASCII characters
!"#$@[¥]^`{|}‾
according to rule #1.
Because quoted-printable data is generally assumed to be line-
oriented, it is to be expected that the representation of the breaks
between the lines of quoted-printable data may be altered in
transport, in the same manner that plain text mail has always been
altered in Internet mail when passing between systems with differing
newline conventions. If such alterations are likely to constitute a
Freed & Borenstein Standards Track [Page 21]
RFC 2045 Internet Message Bodies November 1996
corruption of the data, it is probably more sensible to use the
base64 encoding rather than the quoted-printable encoding.
NOTE: Several kinds of substrings cannot be generated according to
the encoding rules for the quoted-printable content-transfer-
encoding, and hence are formally illegal if they appear in the output
of a quoted-printable encoder. This note enumerates these cases and
suggests ways to handle such illegal substrings if any are
encountered in quoted-printable data that is to be decoded.
(1) An "=" followed by two hexadecimal digits, one or both
of which are lowercase letters in "abcdef", is formally
illegal. A robust implementation might choose to
recognize them as the corresponding uppercase letters.
(2) An "=" followed by a character that is neither a
hexadecimal digit (including "abcdef") nor the CR
character of a CRLF pair is illegal. This case can be
the result of US-ASCII text having been included in a
quoted-printable part of a message without itself
having been subjected to quoted-printable encoding. A
reasonable approach by a robust implementation might be
to include the "=" character and the following
character in the decoded data without any
transformation and, if possible, indicate to the user
that proper decoding was not possible at this point in
the data.
(3) An "=" cannot be the ultimate or penultimate character
in an encoded object. This could be handled as in case
(2) above.
(4) Control characters other than TAB, or CR and LF as
parts of CRLF pairs, must not appear. The same is true
for octets with decimal values greater than 126. If
found in incoming quoted-printable data by a decoder, a
robust implementation might exclude them from the
decoded data and warn the user that illegal characters
were discovered.
(5) Encoded lines must not be longer than 76 characters,
not counting the trailing CRLF. If longer lines are
found in incoming, encoded data, a robust
implementation might nevertheless decode the lines, and
might report the erroneous encoding to the user.
Freed & Borenstein Standards Track [Page 22]
RFC 2045 Internet Message Bodies November 1996
WARNING TO IMPLEMENTORS: If binary data is encoded in quoted-
printable, care must be taken to encode CR and LF characters as "=0D"
and "=0A", respectively. In particular, a CRLF sequence in binary
data should be encoded as "=0D=0A". Otherwise, if CRLF were
represented as a hard line break, it might be incorrectly decoded on
platforms with different line break conventions.
For formalists, the syntax of quoted-printable data is described by
the following grammar:
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 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be humanly
readable. The encoding and decoding algorithms are simple, but the
encoded data are consistently only about 33 percent larger than the
unencoded data. This encoding is virtually identical to the one used
in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.)
NOTE: This subset has the important property that it is represented
identically in all versions of ISO 646, including US-ASCII, and all
characters in the subset are also represented identically in all
versions of EBCDIC. Other popular encodings, such as the encoding
used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741], and
the base85 encoding specified as part of Level 2 PostScript, do not
share these properties, and thus do not fulfill the portability
requirements a binary transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right, a
24-bit input group is formed by concatenating 3 8bit input groups.
These 24 bits are then treated as 4 concatenated 6-bit groups, each
of which is translated into a single digit in the base64 alphabet.
When encoding a bit stream via the base64 encoding, the bit stream
must be presumed to be ordered with the most-significant-bit first.
That is, the first bit in the stream will be the high-order bit in
the first 8bit byte, and the eighth bit will be the low-order bit in
the first 8bit byte, and so on.
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the
output string. These characters, identified in Table 1, below, are
selected so as to be universally representable, and the set excludes
characters with particular significance to SMTP (e.g., ".", CR, LF)
and to the multipart boundary delimiters defined in RFC 2046 (e.g.,
"-").
Freed & Borenstein Standards Track [Page 24]
RFC 2045 Internet Message Bodies November 1996
Table 1: The Base64 Alphabet
Value Encoding 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
The encoded output stream must be represented in lines of no more
than 76 characters each. All line breaks or other characters not
found in Table 1 must be ignored by decoding software. In base64
data, characters other than those in Table 1, line breaks, and other
white space probably indicate a transmission error, about which a
warning message or even a message rejection might be appropriate
under some circumstances.
Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a body. When fewer than 24 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 6-bit groups. Padding at the end of
the data is performed using the "=" character. Since all base64
input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Because it is used only for padding at the end of the data, the
occurrence of any "=" characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No
Freed & Borenstein Standards Track [Page 25]
RFC 2045 Internet Message Bodies November 1996
such assurance is possible, however, when the number of octets
transmitted was a multiple of three and no "=" characters are
present.
Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data.
Care must be taken to use the proper octets for line breaks if base64
encoding is applied directly to text material that has not been
converted to canonical form. In particular, text line breaks must be
converted into CRLF sequences prior to base64 encoding. The
important thing to note is that this may be done directly by the
encoder rather than in a prior canonicalization step in some
implementations.
NOTE: There is no need to worry about quoting potential boundary
delimiters within base64-encoded bodies within multipart entities
because no hyphen characters are used in the base64 encoding.
7. Content-ID Header Field
In constructing a high-level user agent, it may be desirable to allow
one body to make reference to another. Accordingly, bodies may be
labelled using the "Content-ID" header field, which is syntactically
identical to the "Message-ID" header field:
id := "Content-ID" ":" msg-id
Like the Message-ID values, Content-ID values must be generated to be
world-unique.
The Content-ID value may be used for uniquely identifying MIME
entities in several contexts, particularly for caching data
referenced by the message/external-body mechanism. Although the
Content-ID header is generally optional, its use is MANDATORY in
implementations which generate data of the optional MIME media type
"message/external-body". That is, each message/external-body entity
must have a Content-ID field to permit caching of such data.
It is also worth noting that the Content-ID value has special
semantics in the case of the multipart/alternative media type. This
is explained in the section of RFC 2046 dealing with
multipart/alternative.
Freed & Borenstein Standards Track [Page 26]
RFC 2045 Internet Message Bodies November 1996
8. Content-Description Header Field
The ability to associate some descriptive information with a given
body is often desirable. For example, it may be useful to mark an
"image" body as "a picture of the Space Shuttle Endeavor." Such text
may be placed in the Content-Description header field. This header
field is always optional.
description := "Content-Description" ":" *text
The description is presumed to be given in the US-ASCII character
set, although the mechanism specified in RFC 2047 may be used for
non-US-ASCII Content-Description values.
9. Additional MIME Header Fields
Future documents may elect to define additional MIME header fields
for various purposes. Any new header field that further describes
the content of a message should begin with the string "Content-" to
allow such fields which appear in a message header to be
distinguished from ordinary RFC 822 message header fields.
MIME-extension-field := <Any RFC 822 header field which
begins with the string
"Content-">
10. Summary
Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
header fields, it is possible to include, in a standardized way,
arbitrary types of data with RFC 822 conformant mail messages. No
restrictions imposed by either RFC 821 or RFC 822 are violated, and
care has been taken to avoid problems caused by additional
restrictions imposed by the characteristics of some Internet mail
transport mechanisms (see RFC 2049).
The next document in this set, RFC 2046, specifies the initial set of
media types that can be labelled and transported using these headers.
11. Security Considerations
Security issues are discussed in the second document in this set, RFC
2046.
Freed & Borenstein Standards Track [Page 27]
RFC 2045 Internet Message Bodies November 1996
12. Authors' Addresses
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
Appendix A -- Collected Grammar
This appendix contains the complete BNF grammar for all the syntax
specified by this document.
By itself, however, this grammar is incomplete. It refers by name to
several syntax rules that are defined by RFC 822. Rather than
reproduce those definitions here, and risk unintentional differences
between the two, this document simply refers the reader to RFC 822
for the remaining definitions. Wherever a term is undefined, it
refers to the RFC 822 definition.
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]