RFC1341 日本語訳
1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms forSpecifying and Describing the Format of Internet Message Bodies. N.Borenstein, N. Freed. June 1992. (Format: TXT=211117, PS=347082, PDF=192244 bytes) (Obsoleted by RFC1521) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Borenstein, Bellcore
Request for Comments: 1341 N. Freed, Innosoft
June 1992
ワーキンググループN.Borenstein、コメントを求めるBellcore要求をネットワークでつないでください: 1341 Innosoft1992年6月に解放されたN.
MIME (Multipurpose Internet Mail Extensions):
まねてください(マルチパーパスインターネットメールエクステンション):
Mechanisms for Specifying and Describing
the Format of Internet Message Bodies
インターネットメッセージ本体の形式を指定して、説明するためのメカニズム
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the
Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of
the "IAB Official Protocol Standards" for the
standardization state and status of this protocol.
Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
RFC 822 defines a message representation protocol which
specifies considerable detail about message headers, but
which leaves the message content, or message body, as flat
ASCII text. This document redefines the format of message
bodies to allow multi-part textual and non-textual message
bodies to be represented and exchanged without loss of
information. This is based on earlier work documented in
RFC 934 and RFC 1049, but extends and revises that work.
Because RFC 822 said so little about message bodies, this
document is largely orthogonal to (rather than a revision
of) RFC 822.
RFC822はメッセージヘッダーに関するかなりの詳細を指定しますが、メッセージ内容、またはメッセージ本体を残すメッセージ表現プロトコルを定義します、平坦なASCIIテキストとして。 このドキュメントは、複合原文の、そして、非原文のメッセージ本体が情報の損失なしで表されて、交換されるのを許容するためにメッセージ本体の書式を再定義します。 これは、その仕事をRFC934とRFC1049に記録された以前の仕事に基づいていますが、広げていて、改訂します。 RFC822が、メッセージ本体に関してこのドキュメントが主にそうであると直交していた状態でそれほど少ししか言わなかった、(改正よりむしろ、)、RFC822
In particular, this document is designed to provide
facilities to include multiple objects in a single message,
to represent body text in character sets other than US-
ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio
fragments, and generally to facilitate later extensions
defining new types of Internet mail for use by cooperating
mail agents.
特に、このドキュメントは、米国ASCIIを除いた文字集合における本文を表して、フォーマットされたマルチフォントテキスト・メッセージを表して、イメージやオーディオ断片などの非原文の材料を表すただ一つのメッセージに一般に、協力関係を持っているメールエージェントによる使用のために新しいタイプに関するインターネット・メールを定義する後の拡大を容易にするために複数のオブジェクトを含むように便宜を与えるように設計されています。
This document does NOT extend Internet mail header fields to
permit anything other than US-ASCII text data. It is
recognized that such extensions are necessary, and they are
the subject of a companion document [RFC -1342].
このドキュメントは、米国-ASCIIテキストデータ以外の何も可能にするためにインターネット・メールヘッダーフィールドを広げていません。 そのような拡大が必要であると認められて、それらは仲間ドキュメント[RFC-1342]の対象です。
A table of contents appears at the end of this document.
目次はこのドキュメントの端に現れます。
Borenstein & Freed [Page i]
Borensteinであって解放されています。[ページi]
1 Introduction
1つの序論
Since its publication in 1982, RFC 822 [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 [RFC-821]. As the format has seen wider
use, a number of limitations have proven increasingly
restrictive for the user community.
1982年の公表以来、RFC822[RFC-822]はインターネットに関する原文のメール・メッセージの標準書式を定義しています。 成功はRFC822形式が採用されたように完全かかなりRFC821[RFC-821]でSMTP輸送が定義したインターネットとインターネットの境界を超えたものです。 形式が、より広い使用を見たとき、多くの制限がますますユーザーコミュニティにおいて制限していると判明しました。
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 [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
RFC822がテキスト・メッセージに形式を指定することを意図しました。 そういうものとして、オーディオかイメージを含むかもしれないマルチメディアメッセージなどの非テキスト・メッセージは絶対に言及されません。 しかしながら、テキストの場合ではさえ、RFC822は言語が米国ASCII[米国-ASCII]より豊かな文字集合の使用を必要とするメールユーザの必要性に不十分です。 RFC822がオーディオ、ビデオ、アジアの言語テキスト、またはほとんどのヨーロッパの言語のテキストさえ含むメールにメカニズムを指定しないので、追加仕様が必要です。
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 of
seven-bit ASCII. This forces users to convert any non-
textual data that they may wish to send into seven-bit bytes
representable as printable 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 1113,
the Andrew Toolkit Representation [ATK], and many others.
RFC821/822に基づいているメールシステムの注目に値する限界の1つは彼らが電子メールメッセージのコンテンツを7ビットのASCIIの比較的短い系列に制限するという事実です。 これによって、ユーザはやむを得ず、地方のメールUA(ユーザエージェント、人間のユーザがメールを送って、受け取るプログラム)を呼び出す前にそれらが印刷可能であるとして「表-可能」な7ビットのバイトにASCII文字を送りたがっているどんな非原文のデータも変換します。 現在インターネットで使用されているそのようなencodingsに関する例は純粋な16進、uuencode、RFC1113で指定された4における3ベース64体系、アンドリューToolkit Representation[ATK]、および多くの他のものを含んでいます。
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 body
parts within electronic mail messages. The current
standards for the mapping of X.400 messages to RFC 822
messages specify that either X.400 non-textual body parts
should be converted to (not encoded in) an ASCII format, or
that they should 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's UA may not have the capability of
dealing with the non-textual body part, the user might have
some mechanism external to the UA that can extract useful
information from the body part. 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.
ゲートウェイがRFC822ホストとX.400ホストの間のメール・メッセージの交換を考慮するように設計されているとき、RFC822メールの制限はさらに明らかになります。 X.400[X400]は電子メールメッセージの中で非原文の身体の部分の包含にメカニズムを指定します。 X.400に関するマッピングが822のメッセージをRFCへ通信させるので、現在の規格は、X.400の非原文の身体の部分が(中では、コード化されません)ASCII書式に変換されるべきであるか、またはそれらが捨てられるべきであると指定します、捨てることが起こったことをRFC822ユーザに通知して。 ユーザが受信したがっているかもしれないという情報が無くなるようにこれは明確に望ましくありません。 ユーザのUAには、非原文の身体の部分に対処する能力がないかもしれませんが、ユーザは何らかのメカニズムを身体の部分から役に立つ情報を抜粋できるUAに外部にするかもしれません。 そのうえ、それはメッセージが結局X.400メッセージハンドリングシステムにgatewayedして戻されるかもしれないという(インターネット・メールですなわち、X.400メッセージは「トンネルを堀られる」)事実を考慮しません。そこでは、非文字情報が確実に再び役に立つようになるでしょう。
Borenstein & Freed [Page 1]
Borensteinであって解放されています。[1ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
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:
このドキュメントは結合する、世界的で存在があるどんな重大な非互換性も導入しないでこれらの問題の大部分を解決するRFC822メールの数個のメカニズムについて説明します。 特に、それは以下について説明します。
1. A MIME-Version header field, which uses a version number
to declare a message to be conformant with this
specification and allows mail processing agents to
distinguish between such messages and those generated
by older or non-conformant software, which is presumed
to lack such a field.
1. MIMEバージョンヘッダーフィールドとそのような分野があえて欠かれているより古いか非conformantのソフトウェアによって生成されたもの。(それは、メッセージがこの仕様があるconformantであると宣言するのにバージョン番号を使用して、メール処理エージェントがそのようなメッセージを見分けるのを許容します)。
2. A Content-Type header field, generalized from RFC 1049
[RFC-1049], which can be used to specify the type and
subtype of data in the body of a message and to fully
specify the native representation (encoding) of such
data.
2. メッセージのボディーでデータのタイプと「副-タイプ」を指定して、そのようなデータの固有の表現(コード化する)を完全に指定するのに使用できるRFC1049[RFC-1049]から一般化されたコンテントタイプヘッダーフィールド。
2.a. A "text" Content-Type value, which can be used to
represent textual information in a number of
character sets and formatted text description
languages in a standardized manner.
2. a。 「テキスト」コンテントタイプ価値。(標準化された方法で多くの文字集合とフォーマット済みのテキスト記述言語による文字情報を表すのにその価値を使用できます)。
2.b. A "multipart" Content-Type value, which can be
used to combine several body parts, possibly of
differing types of data, into a single message.
2. b。 「複合」のコンテントタイプ値。(ことによると異なったタイプに関するデータのいくつかの身体の部分をただ一つのメッセージに結合するのにその値を使用できます)。
2.c. An "application" Content-Type value, which can be
used to transmit application data or binary data,
and hence, among other uses, to implement an
electronic mail file transfer service.
2. c。 「アプリケーション」コンテントタイプ価値。(電子メールファイル転送サービスを実装するために、したがって、アプリケーションデータかバイナリ・データを伝えるのに使用される、および他の用途の中にその価値はあることができます)。
2.d. A "message" Content-Type value, for encapsulating
a mail message.
2. d。 メール・メッセージをカプセル化するための「メッセージ」コンテントタイプ価値。
2.e An "image" Content-Type value, for transmitting
still image (picture) data.
2. 静止画像(画像)データを送るためのe「イメージ」コンテントタイプ価値。
2.f. An "audio" Content-Type value, for transmitting
audio or voice data.
2. f。 オーディオか声のデータを送るための「オーディオ」コンテントタイプ価値。
2.g. A "video" Content-Type value, for transmitting
video or moving image data, possibly with audio as
part of the composite video data format.
2. g。 合成ビデオデータの形式の一部としてことによるとオーディオでビデオか動画データを送るための「ビデオ」コンテントタイプ価値。
3. A Content-Transfer-Encoding header field, which can be
used to specify an auxiliary encoding that was applied
to the data in order to allow it to pass through mail
transport mechanisms which may have data or character
set limitations.
3. Content転送コード化ヘッダーフィールドであり、それをコード化する補助物を指定するのにどれを使用できるかは、データか文字集合制限を持っているかもしれないメール移送機構を通り抜けるのを許容するためにデータに適用されました。
4. Two optional header fields that can be used to further
describe the data in a message body, the Content-ID and
Content-Description header fields.
4. メッセージ本体(コンテントIDとContent-記述ヘッダーフィールド)でさらにデータについて説明するのに使用できる2つの任意のヘッダーフィールド。
Borenstein & Freed [Page 2]
Borensteinであって解放されています。[2ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
MIME has been carefully designed as an extensible mechanism,
and it is expected that the set of content-type/subtype
pairs and their associated parameters will grow
significantly with time. Several other MIME fields, notably
including character set names, are likely to have new values
defined over time. In order to ensure that the set of such
values is developed in an orderly, well-specified, and
public manner, MIME defines a registration process which
uses the Internet Assigned Numbers Authority (IANA) as a
central registry for such values. Appendix F provides
details about how IANA registration is accomplished.
MIMEは広げることができるメカニズムとして入念に設計されています、そして、時間に応じてcontent type/「副-タイプ」組と彼らの関連パラメタのセットがかなり成長すると予想されます。 文字集合名を著しく含む他のいくつかのMIME分野が時間がたつにつれて定義された新しい値を持っていそうです。 そのような値のセットが規則的で、よく指定されて、公共の方法で発展するのを確実にするために、MIMEはそのような値に、中央の登録としてインターネットAssigned民数記Authority(IANA)を使用する登録手続を定義します。 付録FはIANA登録がどう優れるかに関する詳細を明らかにします。
Finally, to specify and promote interoperability, Appendix A
of this document provides a basic applicability statement
for a subset of the above mechanisms that defines a minimal
level of "conformance" with this document.
最終的に、相互運用性を指定して、促進するために、このドキュメントのAppendix Aはこのドキュメントによる最小量のレベルの「順応」を定義する上のメカニズムの部分集合に基本的な適用性証明を提供します。
HISTORICAL NOTE: Several of the mechanisms described in
this document may seem somewhat strange or even baroque at
first reading. It is important to note that compatibility
with existing standards AND robustness across existing
practice were two of the highest priorities of the working
group that developed this document. In particular,
compatibility was always favored over elegance.
歴史的な注意: 本書では説明されたメカニズムの数個が、初めに読みながら、いくらか奇妙であるかバロック様式になりさえするのに見えるかもしれません。 既存の規格との互換性と既存の習慣の向こう側の丈夫さがこのドキュメントを開発したワーキンググループの2つの最優先であったことに注意するのは重要です。 特に、互換性は優雅よりいつも好まれました。
2 Notations, Conventions, and Generic BNF Grammar
2つの記法、コンベンション、およびジェネリックBNF文法
This document is being published in two versions, one as
plain ASCII text and one as PostScript. The latter is
recommended, though the textual contents are identical. An
Andrew-format copy of this document is also available from
the first author (Borenstein).
このドキュメントは、2つのバージョンで発行されて、明瞭なASCIIテキストとしての1とポストスクリプトとして1です。 原文の内容は同じですが、後者はお勧めです。 また、このドキュメントのアンドリュー-形式コピーも最初の作者(Borenstein)から利用可能です。
Although the mechanisms specified in this document are all
described in prose, most are also described formally in the
modified BNF notation of RFC 822. Implementors will need to
be familiar with this notation in order to understand this
specification, and are referred to RFC 822 for a complete
explanation of the modified BNF notation.
本書では指定されたメカニズムは散文ですべて説明されますが、また、大部分はRFC822の変更されたBNF記法で正式に説明されます。 作成者はこの仕様を理解するためにこの記法によく知られるのが必要であり、変更されたBNF記法に関する完璧な説明についてRFC822を参照されます。
Some of the modified BNF in this document makes reference to
syntactic entities that are defined in RFC 822 and not in
this document. A complete formal grammar, then, is obtained
by combining the collected grammar appendix of this document
with that of RFC 822.
いくらかの変更されたBNFが本書ではで定義されるのではなく、RFC822で定義される構文の実体について本書では言及します。 そして、このドキュメントの集まっている文法付録をRFC822のものに結合することによって、完全な形式文法を得ます。
The term CRLF, in this document, refers to the sequence of
the two ASCII characters CR (13) and LF (10) which, taken
together, in this order, denote a line break in RFC 822
mail.
CRLFという用語は本書では一緒に、この順で取って、RFC822メールでラインブレイクを指示する2人のASCII文字CR(13)とLF(10)の系列を示します。
The term "character set", wherever it is used in this
document, refers to a coded character set, in the sense of
ISO character set standardization work, and must not be
「文字集合」という用語は、それがどこで本書では使用されてもISO文字集合標準化仕事の意味におけるコード化文字集合について言及して、あるはずがありません。
Borenstein & Freed [Page 3]
Borensteinであって解放されています。[3ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
misinterpreted as meaning "a set of characters."
「キャラクタのセット」を意味するとして、誤解されます。
The term "message", when not further qualified, means either
the (complete or "top-level") message being transferred on a
network, or a message encapsulated in a body of type
"message".
さらに資格がないと、「メッセージ」という用語はネットワークで移される(完全であるか「トップレベル」)のメッセージかタイプ「メッセージ」のボディーでカプセル化されたメッセージのどちらかを意味します。
The term "body part", in this document, means one of the
parts of the body of a multipart entity. A body part has a
header and a body, so it makes sense to speak about the body
of a body part.
「身体の部分」という用語は本書では複合実体の身体の部分の1つを意味します。 身体の部分にはヘッダーとボディーがあるので、それが身体の部分のボディーについて話す意味になります。
The term "entity", in this document, means either a message
or a body part. All kinds of entities share the property
that they have a header and a body.
「実体」という用語は本書ではメッセージか身体の部分のどちらかを意味します。 すべての種類の実体はそれらがヘッダーとaに具体化させる特性を共有します。
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.
さらに資格がないと、「ボディー」という用語は実体のボディー、すなわち、メッセージか身体の部分のボディーを意味します。
Note : the previous four definitions are clearly circular.
This is unavoidable, since the overal structure of a MIME
message is indeed recursive.
以下に注意してください。 前の4つの定義が明確に円形です。 MIMEメッセージのoveral構造が本当に再帰的であるので、これは避けられません。
In this document, all numeric and octet values are given in
decimal notation.
本書では、10進法ですべての数値と八重奏値を与えます。
It must be noted that Content-Type values, subtypes, and
parameter names as defined in this document are case-
insensitive. However, parameter values are case-sensitive
unless otherwise specified for the specific parameter.
本書では定義されるコンテントタイプ値、血液型亜型、およびパラメタ名がケース神経が鈍いことに注意しなければなりません。 しかしながら、別の方法で特定のパラメタに指定されない場合、パラメタ値は大文字と小文字を区別しています。
FORMATTING NOTE: This document has been carefully formatted
for ease of reading. The PostScript version of this
document, in particular, places notes like this one, which
may be skipped by the reader, in a smaller, italicized,
font, and indents it as well. In the text version, only the
indentation is preserved, so if you are reading the text
version of this you might consider using the PostScript
version instead. However, all such notes will be indented
and preceded by "NOTE:" or some similar introduction, even
in the text version.
形式注意: このドキュメントは読書する容易さのために慎重にフォーマットされました。 このドキュメントのポストスクリプトバージョンは、より小さくて、イタリック体で印刷されたフォントで読者によってスキップされるかもしれないこのもののような注意を特に置いて、また、それにギザギザを付けさせます。 テキストバージョンでは、刻み目だけが保持されるので、このテキストバージョンを読んでいるなら、あなたは、代わりにポストスクリプトバージョンを使用すると考えるかもしれません。 しかしながら、そのような注意を字下がりにされて、先行するすべてが「以下に注意します」。 または、テキストバージョンさえにおける何らかの同様の序論。
The primary purpose of these non-essential notes is to
convey information about the rationale of this document, or
to place this document in the proper historical or
evolutionary context. Such information may be skipped by
those who are focused entirely on building a compliant
implementation, but may be of use to those who wish to
understand why this document is written as it is.
これらの不要不急な注意のプライマリ目的は、このドキュメントの原理に関して情報を伝達するか、または適切な歴史的であるか進化論の関係のこのドキュメントを置くことです。 そのような情報は、完全に対応する実装を築き上げるのに焦点を合わせられる人によってスキップされるかもしれませんが、それのようにこのドキュメントがなぜ書かれているかを理解したがっている人の役に立つかもしれません。
For ease of recognition, all BNF definitions have been
placed in a fixed-width font in the PostScript version of
this document.
認識の容易さにおいて、すべてのBNF定義がこのドキュメントのポストスクリプトバージョンに固定ピッチフォントに置かれました。
Borenstein & Freed [Page 4]
Borensteinであって解放されています。[4ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
3 The MIME-Version Header Field
3 MIMEバージョンヘッダーフィールド
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 document
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.
RFC822が1982年に発行されたので、インターネットメッセージの1つの形式規格しか本当にありませんでした、そして、形式が使用中であり標準であると宣言する必要性は少ししか知覚されていません。 このドキュメントはRFC822の補足となる独立しているドキュメントです。 拡大はRFC822と互換性があるほど本書ではそのような方法で定義されましたが、メール処理エージェントが、メッセージが念頭で新しい規格で構成されたかどうかを知るのが、望ましいかもしれない事情がまだあります。
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.
したがって、このドキュメントは新しいヘッダーフィールド、インターネットメッセージボディー形式のバージョンが使用中であり標準であると宣言するのに使用されることである「MIMEバージョン」を定義します。
Messages composed in accordance with this document MUST
include such a header field, with the following verbatim
text:
このドキュメントによると、構成されたメッセージは以下の逐語的なテキストがあるそのようなヘッダーフィールドを含まなければなりません:
MIME-Version: 1.0
MIMEバージョン: 1.0
The presence of this header field is an assertion that the
message has been composed in compliance with this document.
このヘッダーフィールドの存在はメッセージがこのドキュメントに従って構成されたという主張です。
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:
将来のドキュメントが再びメッセージ・フォーマット規格を広げるのが、可能であるので、MIMEバージョン分野の内容のために正式なBNFを与えます:
MIME-Version := text
MIMEバージョン:=テキスト
Thus, future format specifiers, which might replace or
extend "1.0", are (minimally) constrained by the definition
of "text", which appears in RFC 822.
その結果、将来の形式特許説明書の作成書。(「1インチは「テキスト」の定義で(最少量で)強制的であり、どれがRFC822に現れること」を取り替えるか、またはその特許説明書の作成書は広げるかもしれません)。
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" if and only if the
embedded message is itself claimed to be MIME-compliant.
MIMEバージョンヘッダーフィールドがメッセージのトップレベルで必要であることに注意してください。 それは複合実体のそれぞれの身体の部分に必要ではありません。 そして、それがタイプ「メッセージ」のボディーの埋め込まれたヘッダーに必要である、埋め込まれたメッセージがMIME対応であると主張される場合にだけ。
Borenstein & Freed [Page 5]
Borensteinであって解放されています。[5ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
4 The Content-Type Header Field
4 コンテントタイプヘッダーフィールド
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.
コンテントタイプ分野の目的がボディーに含まれたデータについて十分完全に説明することであるので、受信ユーザエージェントはユーザにデータを提示するか、またはそうでなければ、適切な方法でデータに対処するために適切なエージェントかメカニズムを選ぶことができます。
HISTORICAL NOTE: The Content-Type header field was first
defined in RFC 1049. RFC 1049 Content-types used a simpler
and less powerful syntax, but one that is largely compatible
with the mechanism given here.
歴史的な注意: コンテントタイプヘッダーフィールドは最初に、RFC1049で定義されました。 RFC1049文書内容は、より簡単でそれほど強力でない構文、しかし、主に与えられていた状態でここのメカニズム互換性があるものを使用しました。
The Content-Type header field is used to specify the nature
of the data in the body of an entity, by giving type and
subtype identifiers, and by providing auxiliary information
that may be required for certain types. After the type and
subtype names, the remainder of the header field is simply a
set of parameters, specified in an attribute/value notation.
The set of meaningful parameters differs for the different
types. The ordering of parameters is not significant.
Among the defined parameters is a "charset" parameter by
which the character set used in the body may be declared.
Comments are allowed in accordance with RFC 822 rules for
structured header fields.
コンテントタイプヘッダーフィールドは、実体のボディーでデータの本質を指定するのにタイプと「副-タイプ」に識別子を与えて、あるタイプに必要であるかもしれない補助の情報を供給することによって、使用されます。 タイプと「副-タイプ」名の後に、ヘッダーフィールドの残りは単に属性/値の記法で指定された1セットのパラメタです。 重要なパラメタのセットは異なったタイプのために異なります。 パラメタの注文は重要ではありません。 定義されたパラメタの中に、ボディーで使用される文字集合が宣言されるかもしれない"charset"パラメタがあります。 構造化されたヘッダーフィールドのためのRFC822規則に従って、コメントは許容されています。
In general, the top-level Content-Type is used to declare
the general type of data, while the subtype specifies a
specific format for that type of data. Thus, a Content-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 audio, image, text, and video, should
not contain embedded information that is really of a
different type. Such compound types should be represented
using the "multipart" or "application" types.
一般に、トップレベルコンテントタイプはデータの一般型を宣言するのに使用されます、「副-タイプ」がそのタイプに関するデータのための特定の形式を指定しますが。 したがって、「イメージ/xyz」のコンテントタイプはデータがイメージであるとユーザエージェントに言うために十分です、ユーザエージェントに特定の画像形式"xyz"に関する知識が全くなくても。 例えば、認識されていない「副-タイプ」から生データをユーザに示すかどうか決めるのにそのような情報を使用できます--そのような動作は、テキストの認識されていない血液型亜型に妥当ですが、イメージかオーディオの認識されていない血液型亜型のために妥当でないかもしれません。 この理由で、オーディオの登録された血液型亜型(イメージ、テキスト、およびビデオ)は、本当な異なったタイプにはある埋め込まれた情報を含むべきではありません。 そのような合成タイプは、「複合」か「アプリケーション」タイプを使用することで代理をされるべきです。
Parameters are modifiers of the content-subtype, and do not
fundamentally affect the requirements of the host system.
Although most parameters make sense only with certain
content-types, others are "global" in the sense that they
might apply to any subtype. For example, the "boundary"
parameter makes sense only for the "multipart" content-type,
but the "charset" parameter might make sense with several
content-types.
パラメタは、満足している「副-タイプ」の修飾語であり、基本的にホストシステムの要件に影響しません。 ほとんどのパラメタが単にあるcontent typeで理解できますが、他のものは彼らがどんな「副-タイプ」にも適用するかもしれないという意味で「グローバルです」。 例えば、「境界」パラメタは「複合」のcontent typeのためだけに理解できますが、"charset"パラメタはいくつかのcontent typeで理解できるかもしれません。
An initial set of seven Content-Types is defined by this
document. This set of top-level names is intended to be
substantially complete. It is expected that additions to
the larger set of supported types can generally be
7つのコンテントタイプの始発はこのドキュメントによって定義されます。 このセットのトップレベル名が実質的に完全であることを意図します。 一般に、より大きいサポートしているタイプへの追加があることができると予想されます。
Borenstein & Freed [Page 6]
Borensteinであって解放されています。[6ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
accomplished by the creation of new subtypes of these
initial types. In the future, more top-level types may be
defined only by an extension to this standard. If another
primary 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.
これらの初期のタイプの新しい血液型亜型の作成で、達成されます。 将来、トップより多くのレベルのタイプは単にこの規格への拡大で定義されるかもしれません。 どんな理由にも別のプライマリタイプを使用するつもりであるなら、標準的でない状態を示して、「X」から将来の正式名称との潜在的闘争を避け始めて、名前をそれに与えなければなりません。
In the Extended BNF notation of RFC 822, a Content-Type
header field value is defined as follows:
RFC822のExtended BNF記法では、コンテントタイプヘッダーフィールド価値は以下の通り定義されます:
Content-Type := type "/" subtype *[";" parameter]
「コンテントタイプ:=は」 /をタイプする」「副-タイプ」*[「」、;、パラメタ]
type := "application" / "audio"
/ "image" / "message"
/ "multipart" / "text"
/ "video" / x-token
x:=「アプリケーション」/「オーディオ」/「イメージ」/「メッセージ」/「複合」/「テキスト」/「ビデオ」/トークンをタイプしてください。
x-token := <The two characters "X-" followed, with no
intervening white space, by any token>
2つのキャラクタ「X」がどんなトークン>も介入している余白なしで続けたx-トークン:=<。
subtype := token
「副-タイプ」:=トークン
parameter := attribute "=" value
パラメタ:=属性「=」価値
attribute := token
属性:=トークン
value := token / quoted-string
値の:=トークン/引用文字列
token := 1*<any CHAR except SPACE, CTLs, or tspecials>
トークン:=1*<はSPACE、CTLs、またはtspecials>以外のあらゆるCHARです。
tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
/ "," / ";" / ":" / "\" / <"> ; quoted-string,
/ "/" / "[" / "]" / "?" / "." ; to use within
/ "=" ; parameter values
tspecials:=「(「/」)」/"<"/">"/"@"。 」 「必須は/のそうです」、/、」、;、」 / ":" /「\」/<">"。 「」 引用文字列、/」 //「[「/」]」/“?" / "." ; /「=」の中で使用するために。 パラメタ値
Note that the definition of "tspecials" is the same as the
RFC 822 definition of "specials" with the addition of the
three characters "/", "?", and "=".
「"tspecials"の定義が3つのキャラクタの追加がある「特別番組」のRFC822定義と同じであるというメモ」/、」、“?"、および「=。」
Note also that a subtype specification is MANDATORY. There
are no default subtypes.
また、「副-タイプ」仕様がMANDATORYであることに注意してください。 デフォルト血液型亜型が全くありません。
The type, subtype, and parameter names are not case
sensitive. For example, TEXT, Text, and TeXt are all
equivalent. Parameter values are normally case sensitive,
but certain parameters are interpreted to be case-
insensitive, depending on the intended use. (For example,
multipart boundaries are case-sensitive, but the "access-
type" for message/External-body is not case-sensitive.)
タイプ、「副-タイプ」、およびパラメタ名は大文字と小文字を区別していません。 例えば、TEXT、Text、およびTeXtはすべて同等です。 パラメタ値は、意図している使用によって、パラメタがケース神経が鈍くなるように解釈されるのを通常大文字と小文字を区別していますが、確信しています。 (例えば、複合境界は大文字と小文字を区別していますが、外部のメッセージ/ボディーのための「アクセスタイプ」は大文字と小文字を区別していません。)
Beyond this syntax, the only 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
この構文を超えて、「副-タイプ」名の定義の唯一の規制は彼らの用途が闘争してはいけないという願望です。 すなわち、2を持っているのは望ましくないでしょう。
Borenstein & Freed [Page 7]
Borensteinであって解放されています。[7ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
different communities using "Content-Type:
application/foobar" to mean two different things. The
process of defining new content-subtypes, then, is not
intended to be a mechanism for imposing restrictions, but
simply a mechanism for publicizing the usages. There are,
therefore, two acceptable mechanisms for defining new
Content-Type subtypes:
異なった共同体が使用される、「コンテントタイプ:」 2つの別物を意味する「アプリケーション/foobar。」 次に、新しい満足している血液型亜型を定義するプロセスはしかし、制限を課すためのメカニズム、用法をピーアールするための単にメカニズムであることを意図しません。 したがって、新しいコンテントタイプ血液型亜型を定義するための2つの許容できるメカニズムがあります:
1. Private values (starting with "X-") may be
defined bilaterally between two cooperating
agents without outside registration or
standardization.
1. 個人的な値(「X」から始める)は2人の協力関係を持っているエージェントの間で外の登録も標準化なしで相互的に定義されるかもしれません。
2. New standard values must be documented,
registered with, and approved by IANA, as
described in Appendix F. Where intended for
public use, the formats they refer to must
also be defined by a published specification,
and possibly offered for standardization.
2. IANAが新しい基準値と記録されて、ともに記名されて、承認しなければならなくて、公共の使用のために意図するAppendix F.Whereで説明されるように、また、彼らが言及する書式を広められた仕様で定義して、標準化のためにことによると提供しなければなりません。
The seven standard initial predefined Content-Types are
detailed in the bulk of this document. They are:
7規格初期の事前に定義されたコンテントタイプはこのドキュメントの大半で詳細です。 それらは以下の通りです。
text -- textual information. The primary subtype,
"plain", indicates plain (unformatted) text. No
special software is required to get the full
meaning of the text, aside from support for the
indicated character set. Subtypes are to be used
for enriched text in forms where application
software may enhance the appearance of the text,
but such software must not be required in order to
get the general idea of the content. Possible
subtypes thus include any readable word processor
format. A very simple and portable subtype,
richtext, is defined in this document.
multipart -- data consisting of multiple parts of
independent data types. Four initial subtypes
are defined, including the primary "mixed"
subtype, "alternative" for representing the same
data in multiple formats, "parallel" for parts
intended to be viewed simultaneously, and "digest"
for multipart entities in which each part is of
type "message".
message -- an encapsulated message. A body of
Content-Type "message" is itself a fully formatted
RFC 822 conformant message which may contain its
own different Content-Type header field. The
primary subtype is "rfc822". The "partial"
subtype is defined for partial messages, to permit
the fragmented transmission of bodies that are
thought to be too large to be passed through mail
transport facilities. Another subtype,
"External-body", is defined for specifying large
bodies by reference to an external data source.
テキスト--文字情報。 プライマリ「明瞭な」「副-タイプ」は明瞭な(非フォーマットされる)テキストを示します。 どんな特別なソフトウェアもテキストの完全な意味を得るのに必要ではありません、示された文字集合のサポートは別として。 血液型亜型がフォームのアプリケーション・ソフトがテキストの外観を高めるかもしれない豊かにされたテキストに使用されることですが、内容の概念を得るためにそのようなソフトウェアを必要としてはいけません。 その結果、可能な血液型亜型はどんな読み込み可能なワードプロセッサ形式も含んでいます。 非常に簡単で携帯用の「副-タイプ」(richtext)が本書では定義される、複合、--独立しているデータ型の複数の部分から成るデータ。 4の初期の血液型亜型は定義されます、プライマリ「混ぜられた」「副-タイプ」を含んでいて、複数の形式における同じデータを表すのにおいて「代替です」、各部分がタイプ「メッセージ」 メッセージのものである複合実体のために同時に見られて、「読みこなすこと」を意図する部品に「平行です」--カプセル化されたメッセージ。 コンテントタイプ「メッセージ」のボディーはそれ自体でそれ自身の異なったコンテントタイプヘッダーフィールドを含むかもしれない完全にフォーマットされたRFC822conformantメッセージです。 プライマリ「副-タイプ」は"rfc822"です。 「部分的な」「副-タイプ」は部分的なメッセージのために定義されて、であることができない大きいと考えられるボディーの断片化しているトランスミッションを可能にするのはメール運送設備を通り抜けました。 別の「外部のボディー」である「副-タイプ」は、外部のデータ送信端末の参照で大きいボディーを指定するために定義されます。
Borenstein & Freed [Page 8]
Borensteinであって解放されています。[8ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
image -- image data. Image requires a display device
(such as a graphical display, a printer, or a FAX
machine) to view the information. Initial
subtypes are defined for two widely-used image
formats, jpeg and gif.
audio -- audio data, with initial subtype "basic".
Audio requires an audio output device (such as a
speaker or a telephone) to "display" the contents.
video -- video data. Video requires the capability to
display moving images, typically including
specialized hardware and software. The initial
subtype is "mpeg".
application -- some other kind of data, typically
either uninterpreted binary data or information to
be processed by a mail-based application. The
primary subtype, "octet-stream", is to be used in
the case of uninterpreted binary data, in which
case the simplest recommended action is to offer
to write the information into a file for the user.
Two additional subtypes, "ODA" and "PostScript",
are defined for transporting ODA and PostScript
documents in bodies. Other expected uses for
"application" include spreadsheets, data for
mail-based scheduling systems, and languages for
"active" (computational) email. (Note that active
email entails several securityconsiderations,
which are discussed later in this memo,
particularly in the context of
application/PostScript.)
イメージ--イメージデータ。 イメージは、情報を見るために、ディスプレイ装置(グラフィカルなディスプレイ、プリンタ、またはFAXマシンなどの)を必要とします。 初期の血液型亜型は2つの広く使用された画像形式、jpeg、およびgifオーディオのために定義されます--初期の「副-タイプ」が「基本的」のオーディオデータ。 オーディオは、オーディオ出力装置(スピーカーか電話などの)がコンテンツを「表示すること」を必要とします。. ビデオ--ビデオ・データ。 ビデオは専門化しているハードウェアとソフトウェアを通常含む動画を表示する能力を必要とします。 初期の「副-タイプ」は. アプリケーションの"mpegする"であることです--ある他の種類に関するデータ、通常非解釈されたバイナリ・データまたはメールベースのアプリケーションで処理されるべき情報。 「八重奏ストリーム」というプライマリ「副-タイプ」は非解釈されたバイナリ・データの場合に使用されることになっています、その場合、最も簡単なお勧めの動きがユーザのためにファイルの中に情報を書くと申し出ることです。 2追加血液型亜型、「ODA」、および「ポストスクリプト」が、ボディーでODAとポストスクリプトドキュメントを輸送するために定義されます。 「アプリケーション」への他の予想された用途はスプレッドシート、メールベースのスケジューリングシステムのためのデータ、および「アクティブな」(コンピュータの)メールのための言語を含んでいます。 (アクティブなメールが後でこのメモと、特にアプリケーション/ポストスクリプトの文脈で議論する数個のsecurityconsiderationsを伴うことに注意してください。)
Default RFC 822 messages are typed by this protocol as plain
text in the US-ASCII character set, which can be explicitly
specified as "Content-type: text/plain; charset=us-ascii".
If no Content-Type is specified, either by error or by an
older user agent, this default is assumed. In the presence
of a MIME-Version header field, a receiving User Agent can
also assume that plain US-ASCII text was the sender's
intent. In the absence of a MIME-Version specification,
plain US-ASCII text must still be assumed, but the sender's
intent might have been otherwise.
デフォルトRFC822メッセージがプレーンテキストとしてこのプロトコルによって米国-ASCII文字の組でタイプされる、「文書内容:。」(明らかに、ASCII文字の組を指定できます)。 テキスト/平野。 「charsetが私たちと等しい、-、ASCII、」 コンテントタイプが全く誤りか、より年取ったユーザエージェントによって指定されないなら、このデフォルトは想定されます。 また、MIMEバージョンヘッダーフィールドがあるとき、受信Userエージェントは、明瞭な米国-ASCIIテキストが送付者の意図であったと仮定できます。 MIMEバージョン仕様がないとき、まだ明瞭な米国-ASCIIテキストを想定しなければなりませんが、送付者の意図はそうでなかったかもしれません。
RATIONALE: In the absence of any Content-Type header field
or MIME-Version header field, it is impossible to be certain
that a message is actually text in the US-ASCII character
set, since it might well be a message that, using the
conventions that predate this document, includes text in
another character set or non-textual data in a manner that
cannot be automatically recognized (e.g., a uuencoded
compressed UNIX tar file). Although there is no fully
acceptable alternative to treating such untyped messages as
"text/plain; charset=us-ascii", implementors should remain
aware that if a message lacks both the MIME-Version and the
Content-Type header fields, it may in practice contain
almost anything.
原理: どんなコンテントタイプヘッダーフィールドやMIMEバージョンヘッダーフィールドがないとき、メッセージが実際に米国-ASCII文字の組のテキストであることを確信しているのは不可能です、自動的に認識できないのが(例えば、uuencoded圧縮されたUNIXタールファイル)、たぶんこのドキュメントより前に起こるコンベンションを使用して、別の文字集合か非原文のデータに方法でテキストを含んでいるメッセージでしょう、したがって。 扱いへのどんな完全に許容できる代替手段もありませんでしたが、そのようなものは「テキスト/平野」としてメッセージを非タイプしました。 「charsetが私たちと等しい、-、ASCII、」、メッセージがMIMEバージョンとコンテントタイプヘッダーフィールドの両方を欠いているなら、実際にはほとんど何でも含むかもしれないのを意識していたままで、作成者は残るべきです。
Borenstein & Freed [Page 9]
Borensteinであって解放されています。[9ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
It should be noted that the list of Content-Type values
given here may be augmented in time, via the mechanisms
described above, and that the set of subtypes is expected to
grow substantially.
ここに与えられたコンテントタイプ値のリストが上でメカニズムで説明された時間で増大するかもしれなくて、血液型亜型のセットが実質的に成長すると予想されることに注意されるべきです。
When a mail reader encounters mail with an unknown Content-
type value, it should generally treat it as equivalent to
"application/octet-stream", as described later in this
document.
メール読者が未知のContentタイプ価値でメールに遭遇すると、一般に、それは「八重奏アプリケーション/ストリーム」に同等で、後述のようであるとして本書ではそれを扱うべきです。
5 The Content-Transfer-Encoding Header Field
5 満足している転送コード化ヘッダーフィールド
Many Content-Types which could usefully be transported via
email are represented, in their "natural" format, as 8-bit
character or binary data. Such data cannot be transmitted
over some transport protocols. For example, RFC 821
restricts mail messages to 7-bit US-ASCII data with 1000
character lines.
メールで有効に輸送できるだろう多くのコンテントタイプが表されます、それらの「自然な」形式で、8ビットのキャラクタかバイナリ・データとして。 いくつかのトランスポート・プロトコルの上にそのようなデータを送ることができません。 例えば、RFC821は1000個のハイライト線でメール・メッセージを7ビットの米国-ASCIIデータに制限します。
It is necessary, therefore, to define a standard mechanism
for re-encoding such data into a 7-bit short-line format.
This document specifies that such encodings will be
indicated by a new "Content-Transfer-Encoding" header field.
The Content-Transfer-Encoding field is used to indicate the
type of transformation that has been used in order to
represent the body in an acceptable manner for transport.
したがって、7ビットの短い線形式にそのようなデータを再コード化するために標準のメカニズムを定義するのが必要です。 このドキュメントは、そのようなencodingsが新しい「満足している転送コード化」ヘッダーフィールドによって示されると指定します。 Content転送コード化分野は、輸送のための許容できる方法でボディーを表すのに使用された変換のタイプを示すのに使用されます。
Unlike Content-Types, a proliferation of Content-Transfer-
Encoding values is undesirable and unnecessary. However,
establishing only a single Content-Transfer-Encoding
mechanism 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 readable encoding
of data that is mostly, but not entirely, 7-bit data. For
this reason, at least two encoding mechanisms are necessary:
a "readable" encoding and a "dense" encoding.
コンテントタイプと異なって、Contentコード化を移している値の増殖は、望ましくなくて、不要です。 しかしながら、ただ一つのContent転送コード化メカニズムだけを確立するのは可能に思えません。 すなわち、主にバイナリ・データのコンパクトで効率的なコード化に関する願望と読み込み可能なデータの記号化に関する願望の間には、見返りがほとんどありますが、完全にあるというわけではありません、7ビットのデータ。 この理由に、少なくともメカニズムをコード化する2が必要です: 「読み込み可能な」コード化と「濃い」コード化。
The Content-Transfer-Encoding field is designed to specify
an invertible mapping between the "native" representation of
a type of data and a representation that can be readily
exchanged using 7 bit mail transport protocols, such as
those defined by RFC 821 (SMTP). This field has not been
defined by any previous standard. The field's value is a
single token specifying the type of encoding, as enumerated
below. Formally:
Content転送コード化分野は一種のデータの「ネイティブ」の表現と7ビットのメールトランスポート・プロトコルを使用することで容易に交換できる表現の間のinvertibleマッピングを指定するように設計されています、RFC821(SMTP)によって定義されたものなどのように。 この分野はどんな前の規格によっても定義されていません。 フィールドの値は以下に列挙されるようにコード化のタイプを指定するただ一つのトークンです。 正式に:
Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
満足している転送コード化:=「x「引用されて印刷可能な」/「8ビット」/「7ビット」/BASE64"/「バイナリー」/トークン」
These values are not case sensitive. That is, Base64 and
BASE64 and bAsE64 are all equivalent. An encoding type of
7BIT requires that the body is already in a seven-bit mail-
ready representation. This is the default value -- that is,
これらの値は大文字と小文字を区別していません。 すなわち、Base64、BASE64、およびbAsE64はすべて同等です。 7BITのコード化しているタイプは、ボディーが既に7ビットのメール持ち合わせの表現であるのを必要とします。 これはデフォルト値()です。
Borenstein & Freed [Page 10]
Borensteinであって解放されています。[10ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
"Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
「満足している転送コード化:」 Content転送コード化ヘッダーフィールドが存在していないなら、"7BIT"は想定されます。
The values "8bit", "7bit", and "binary" all imply that NO
encoding has been performed. However, they are potentially
useful as indications of the kind of data contained in the
object, and therefore of the kind of encoding that might
need to be performed for transmission in a given transport
system. "7bit" means that the data is all represented as
short lines of US-ASCII data. "8bit" means that the lines
are short, but there may be non-ASCII characters (octets
with the high-order bit set). "Binary" means that not only
may non-ASCII characters be present, but also that the lines
are not necessarily short enough for SMTP transport.
値「8ビット」、「7ビット」、および「バイナリー」はすべて、コード化でないのが実行されたのを含意します。 しかしながら、それらはオブジェクトに含まれたデータの種類、およびしたがって、与えられた輸送システムにおけるトランスミッションのために実行される必要があるかもしれないコード化の種類のしるしとして潜在的に役に立ちます。 「7ビット」は、データが米国-ASCIIデータの短い線としてすべて表されることを意味します。 「8ビット」は、系列が短いことを意味しますが、非ASCII文字がいるかもしれません(高位のビットによる八重奏はセットしました)。 「バイナリー」は、SMTP輸送には、非ASCII文字に出席していますように、なだけではなく、系列が必ず十分短くしもするというわけではないことを意味します。
The difference between "8bit" (or any other conceivable
bit-width token) and the "binary" token is that "binary"
does not require adherence to any limits on line length or
to the SMTP CRLF semantics, while the bit-width tokens do
require such adherence. If the body contains data in any
bit-width other than 7-bit, the appropriate bit-width
Content-Transfer-Encoding token must be used (e.g., "8bit"
for unencoded 8 bit wide data). If the body contains binary
data, the "binary" Content-Transfer-Encoding token must be
used.
「8ビット」(または、想像できるいかなる他のビット-幅のトークンも)と「2進」のトークンの違いは「バイナリー」が行長におけるどんな限界、または、SMTP CRLF意味論に固守を必要としないということです、ビット-幅のトークンはそのような固守を必要としますが。 ボディーが7ビット以外のどんなビット-幅でもデータを含むなら、適切なビット-幅のContent転送コード化トークンを使用しなければなりません(例えば、暗号化されていない幅8ビットのデータのための「8ビット」)。 ボディーがバイナリ・データを含むなら、「2進」のContent転送コード化トークンを使用しなければなりません。
NOTE: The distinction between the Content-Transfer-Encoding
values of "binary," "8bit," etc. may seem unimportant, in
that all of them really mean "none" -- that is, there has
been no encoding of the data for transport. However, clear
labeling will be of enormous value to gateways between
future mail transport systems with differing capabilities in
transporting data that do not meet the restrictions of RFC
821 transport.
以下に注意してください。 「バイナリー」、「8ビット」などのContent転送コード化値の区別は重要でなく見えるかもしれません、彼らが皆、本当に「なにも」を意味するので--すなわち、輸送のためのデータのコード化がありませんでした。 しかしながら、明確なラベリングには、RFC821輸送の制限を満たさないデータを輸送することにおける異なった能力がある将来のメール輸送システムの間には、ゲートウェイには莫大な価値があるでしょう。
As of the publication of this document, there are no
standardized Internet transports for which it is legitimate
to include unencoded 8-bit or binary data in mail bodies.
Thus there are no circumstances in which the "8bit" or
"binary" Content-Transfer-Encoding is actually legal on the
Internet. However, in the event that 8-bit or binary mail
transport becomes a reality in Internet mail, or when this
document is used in conjunction with any other 8-bit or
binary-capable transport mechanism, 8-bit or binary bodies
should be labeled as such using this mechanism.
このドキュメントの公表現在、メール本文に暗号化されていない8ビットかバイナリ・データを含んでいるのが正統であるインターネット輸送は標準化されません。 したがって、「8ビット」か「2進」のContent転送コード化が実際にインターネットで法的である事情が全くありません。 しかしながら、8ビットかバイナリメール輸送がインターネット・メールで現実のものになるか、またはこのドキュメントがいかなる他の8ビットの、または、2進にできる移送機構に関連して使用されるとき、8ビットの、または、2進のボディーは、そういうものとしてこのメカニズムを使用することでラベルされるべきです。
NOTE: The five values defined for the Content-Transfer-
Encoding field imply nothing about the Content-Type other
than the algorithm by which it was encoded or the transport
system requirements if unencoded.
以下に注意してください。 暗号化されていないなら、Contentコード化を移している分野と定義された5つの値はそれがコード化されたアルゴリズムか輸送システム要求以外のコンテントタイプに関して何も含意しません。
Implementors may, if necessary, define new Content-
Transfer-Encoding values, but must use an x-token, which is
a name prefixed by "X-" to indicate its non-standard status,
必要なら、x-トークン(「X」によって前に置かれた、標準的でない状態を示した名前である)を使用しなければならないのを除いて、作成者は転送をコード化する新しいContent値を定義するかもしれません。
Borenstein & Freed [Page 11]
Borensteinであって解放されています。[11ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
e.g., "Content-Transfer-Encoding: x-my-new-encoding".
However, unlike Content-Types and subtypes, the creation of
new Content-Transfer-Encoding values is explicitly and
strongly discouraged, as it seems likely to hinder
interoperability with little potential benefit. Their use
is allowed only as the result of an agreement between
cooperating user agents.
例えば、「内容はコード化を移します」。 「x、私の新しいコード化、」 しかしながら、コンテントタイプと血液型亜型と異なって、新しいContent転送コード化値の作成は明らかに強くがっかりしています、少ない潜在的利益で相互運用性を妨げるのがありそうに思えるように。 彼らの使用は単に協力関係を持っているユーザエージェントの間の協定の結果として許されています。
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 a body part's headers, it applies only to
the body of that body part. If an entity is of type
"multipart" or "message", the Content-Transfer-Encoding is
not permitted to have any value other than a bit width
(e.g., "7bit", "8bit", etc.) or "binary".
Content転送コード化ヘッダーフィールドがメッセージヘッダーの一部として現れるなら、それはそのメッセージの全身に適用されます。 Content転送コード化ヘッダーフィールドが身体の部分のヘッダーの一部として現れるなら、それはその身体の部分のボディーだけに適用されます。 実体が「複合タイプ」のものであるか「メッセージ」、Content転送コード化にはしばらく幅(例えば、「7ビット」、「8ビット」など)か「バイナリー」を除いたどんな値もあることが許可されないなら。
It should be noted that email is character-oriented, so that
the mechanisms described here are mechanisms for encoding
arbitrary byte streams, not bit streams. If a bit stream is
to be encoded via one of these mechanisms, it must first be
converted to an 8-bit 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 byte. A bit stream
not ending at an 8-bit boundary must be padded with zeroes.
This document provides a mechanism for noting the addition
of such padding in the case of the application Content-Type,
which has a "padding" parameter.
メールがキャラクタ指向であることに注意されるべきです、ストリームが少し、ネットワーク規格を使用する8ビットのバイト・ストリームがこれらのメカニズムの1つを通してコード化されています、最初にそれを変えなければならないということになるように、ストリームにおける以前のビットが高次なビット1バイトでなるオーダー(「ビッグエンディアン」)に噛み付いたということであるならここで説明されたメカニズムが任意のバイト・ストリーム(ビットストリームでない)をコード化するためのメカニズムであるように。 少し、ゼロで8ビットの境界で終わらないストリームを水増ししなければなりません。 このドキュメントは「詰め物」パラメタを持っているアプリケーションコンテントタイプの場合でそのような詰め物の追加に注意するのにメカニズムを提供します。
The encoding mechanisms defined here explicitly encode all
data in ASCII. Thus, for example, suppose an entity has
header fields such as:
ここで明らかに定義されたコード化メカニズムはASCIIにおけるすべてのデータをコード化します。 このようにして、例えば、実体には以下などのヘッダーフィールドがあると仮定してください。
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
コンテントタイプ: テキスト/平野。 charset=ISO-8859-1の満足している転送コード化: base64
This should be interpreted to mean that the body is a base64
ASCII encoding of data that was originally in ISO-8859-1,
and will be in that character set again after decoding.
これは、ボディーが元々ISO-8859-1にあって、解読した後に、その文字集合には再びあるbase64ASCIIデータの記号化であることを意味するために解釈されるべきです。
The following sections will define the two standard encoding
mechanisms. The definition of new content-transfer-
encodings is explicitly discouraged and should only occur
when absolutely necessary. All content-transfer-encoding
namespace except that beginning with "X-" is explicitly
reserved to the IANA for future use. Private agreements
about content-transfer-encodings are also explicitly
discouraged.
以下のセクションはメカニズムをコード化する2規格を定義するでしょう。新しい満足している転送-encodingsの定義は、明らかにがっかりしていて、絶対に必要であるときにだけ、起こるべきです。 それを除いた「X」と共に始まるすべての満足している転送コード化名前空間が今後の使用のために明らかにIANAに予約されます。 また、満足している転送encodingsに関する個人的な協定も明らかにお勧めできないです。
Certain Content-Transfer-Encoding values may only be used on
certain Content-Types. In particular, it is expressly
forbidden to use any encodings other than "7bit", "8bit", or
"binary" with any Content-Type that recursively includes
other Content-Type fields, notably the "multipart" and
あるContent転送コード化値はあるコンテントタイプで使用されるだけであるかもしれません。 そして特に、他のコンテントタイプ分野、著しく「複合」を再帰的に含んでいるどんなコンテントタイプがある「7ビット」、「8ビット」、または「バイナリー」を除いたどんなencodingsも使用するのが明白に禁じられる。
Borenstein & Freed [Page 12]
Borensteinであって解放されています。[12ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
"message" Content-Types. 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.
「メッセージ」コンテントタイプ。 最も奥深いレベルでタイプ複合のボディーのために望まれているすべてのencodingsかメッセージをしなければなりません、コード化される必要がある実際のボディーをコード化することによって。
NOTE ON ENCODING RESTRICTIONS: Though the prohibition
against using content-transfer-encodings on data of type
multipart or message 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 to find out
what types of objects 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.
制限をコード化するとき、以下に注意してください。 タイプに関するデータの満足している転送encodingsを使用するに対して複合の禁止かメッセージがひどく制限しているように見えるかもしれませんが、入れ子にされたencodingsを防ぐのが必要です。(そこでは、データはコード化アルゴリズム複数の回通り抜けて、適切に見られるために複数の回解読しなければなりません)。 入れ子にされたencodingsはユーザエージェントにかなりの複雑さを加えます: そのような複数のencodingsに関する明白な効率問題は別として、それらはメッセージの基本構造を見えなくすることができます。 特に、彼らは、いくつかの解読操作が単にメッセージがどんなタイプの物を含むかを見つけるのに必要であることを含意できます。 入れ子にされたencodingsを禁止すると、あるメール・ゲートウェイの仕事は複雑にされるかもしれませんが、これは問題よりユーザエージェントへの入れ子にされたencodingsの効果見えます。
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
Content-Type that is to be encoded, or, at the very least,
that certain Content-Transfer-Encodings could be mandated
for use with specific Content-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 Content-Type/transport combinations and
not for others. (For example, in an 8-bit transport, no
encoding would be required for text in certain character
sets, while such encodings are clearly required for 7-bit
SMTP.) Second, certain Content-Types may require different
types of transfer encoding under different circumstances.
For example, many PostScript bodies might consist entirely
of short lines of 7-bit data and hence require little or no
encoding. 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 Content-Type is intended to be an open-ended
specification mechanism, strict specification of an
association between Content-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 Content-Type should not have to be aware
of all the transports in use and what their limitations are.
満足しているタイプと内容転送コード化との関係で以下に注意してください。 または少なくともコード化されることになっているコンテントタイプの特性からContent-転送コード化を推論できて、特定のコンテントタイプとの使用のためにあるContent転送Encodingsを強制できたように思えるかもしれません。 これがそうでないいくつかの理由があります。 まず最初に、メールに使用される異なったタイプの輸送を考えて、いくつかのコンテントタイプ/輸送組み合わせに、いくらかのencodingsが他のものにとって適切であるのではなく、適切であるかもしれません。 (例えば、8ビットの輸送では、コード化でないのが、ある文字の組のテキストに必要でしょう、そのようなencodingsが7ビットのSMTPに明確に必要ですが。) 2番目に、あるコンテントタイプは異なった状況の下での転送コード化を異なったタイプに要求するかもしれません。 例えば、多くのポストスクリプト本体は、7ビットのデータの短い線から完全に成って、したがって、まずコード化を必要としないかもしれません。 他のポストスクリプト本体、(特にLevelを使用するもの、2つのポストスクリプトの2進のコード化メカニズム) 2進の輸送コード化を使用することで合理的に表されるだけであるかもしれません。 最終的に、コンテントタイプが制限のない仕様メカニズムであることを意図するので、事実上、コンテントタイプとencodingsとの協会の厳しい仕様は特定の低レベル輸送にアプリケーション・プロトコルの仕様を結びつけます。 コンテントタイプの開発者が使用中のすべての輸送と彼らの制限が何であるかということであることを意識している必要はないはずであるので、これは望ましくはありません。
NOTE ON 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 line breaks. When converting
from quoted-printable to base64 a line break must be
converted into a CRLF sequence. Similarly, a CRLF sequence
ENCODINGSを翻訳するとき、以下に注意してください。 引用されて印刷可能とbase64 encodingsは、それらの間の変換が可能であるように、設計されています。 そのような変換で起こる唯一の問題はラインブレイクの取り扱いです。 引用されて印刷可能であるのからbase64まで変換するとき、CRLF系列にラインブレイクを変換しなければなりません。 同様に、a CRLFは配列します。
Borenstein & Freed [Page 13]
Borensteinであって解放されています。[13ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
in base64 data should be converted to a quoted-printable
line break, but ONLY when converting text data.
テキストデータを変換するだけであるとき、base64では、データは引用されて印刷可能なラインブレイクに変換されるべきです。
NOTE ON CANONICAL ENCODING MODEL: There was some
confusion, in earlier drafts of this memo, 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. For this
reason, a canonical model for encoding is presented as
Appendix H.
正準なコード化のときに、モデル化するように注意してください: 何らかの混乱がありました、このメモの以前の草稿で、メールデータがいつ標準形に変換されて、コード化されるかことであり、特に、この過程がどのようにCRLFsの処理に影響するかモデルに関して、システムによってニューラインの表現が大いに異なるなら。 この理由で、コード化のための規範的モデルはAppendix Hとして提示されます。
5.1 Quoted-Printable Content-Transfer-Encoding
5.1 引用されて印刷可能な満足している転送コード化
The Quoted-Printable encoding is intended to represent data
that largely consists of octets that correspond to printable
characters in the 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 ASCII text, the encoded form of the data remains
largely recognizable by humans. A body which is entirely
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.
Quoted印刷可能なコード化が主にASCII文字の組で印刷可能なキャラクタに文通される八重奏から成るデータを表すことを意図します。 それはメール輸送で結果として起こる八重奏が変更されそうにないような方法でデータをコード化します。 コード化されるデータがほとんどASCIIテキストであるなら、データのコード化されたフォームは人間で主に認識可能なままで残っています。 また、完全にASCIIであるボディーはQuotedメッセージがキャラクタ翻訳、そして/または、線ラッピングを通り抜けるならデータの保全を確実にするのにおいて印刷可能なゲートウェイでコード化されるかもしれません。
In this encoding, octets are to be represented as determined
by the following rules:
このコード化では、八重奏は以下の規則で決定するように表されることです:
Rule #1: (General 8-bit representation) Any octet,
except those indicating a line break according to the
newline convention of the canonical 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 when sending hexadecimal data, though a robust
implementation may choose to recognize lowercase
letters on receipt. Thus, for example, the value 12
(ASCII form feed) can be represented by "=0C", and the
value 61 (ASCII EQUAL SIGN) can be represented by
"=3D". Except when the following rules allow an
alternative encoding, this rule is mandatory.
#1、を統治してください: (一般8ビットの表現) コード化されるデータの標準形のニューラインコンベンションに従ってラインブレイクを示すもの以外のどんな八重奏も八重奏の価値の2ケタ16進表現があとに続いた「=」によって表されるかもしれません。 16進アルファベットのケタはこのために"0123456789ABCDEF"です。 16進データを送るとき、大文字を使用しなければなりません、体力を要している実現は、領収書の上の小文字を認識するのを選ぶかもしれませんが。 このようにして、例えば、値12(ASCII改ページ)を「=0C」表すことができます、そして、「=3D」は値61(ASCII等号)を表すことができます。 以下の規則が代替のコード化を許す時を除いて、この規則は義務的です。
Rule #2: (Literal representation) Octets with decimal
values of 33 through 60 inclusive, and 62 through 126,
inclusive, MAY be represented as the ASCII characters
which correspond to those octets (EXCLAMATION POINT
through LESS THAN, and GREATER THAN through TILDE,
respectively).
#2、を統治してください: (文字通りの表現) 包括的な33〜60のデシマル値が包括的の八重奏、および62〜126はそれらの八重奏(それぞれLESS THANを通したEXCLAMATION POINT、およびTILDEを通したGREATER THAN)に文通するASCII文字として表されるかもしれません。
Rule #3: (White Space): Octets with values of 9 and 32
MAY be represented as ASCII TAB (HT) and SPACE
characters, respectively, but MUST NOT be so
#3、を統治してください: (余白): したがって、表されてはいけないのを除いて、9と32の値がある八重奏はASCII TAB(HT)とSPACEキャラクタとしてそれぞれ表されるかもしれません。
Borenstein & Freed [Page 14]
Borensteinであって解放されています。[14ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
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 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 part 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.
コード化された行の終わりでは、表されます。 その結果、印刷可能なキャラクタはその線の上でコード化された線の上のどんなTAB(HT)やSPACEキャラクタにもついて来なければなりません。 特にコード化された行の終わりの「=」、柔らかいラインブレイク(規則#5を見る)を示すと、1つ以上のタブ(HT)か間隔文字が従われるかもしれません。 Rule#1に従ってコード化された行の終わりに現れる値9か32がある八重奏を表さなければならないということになります。 いくつかのMTAs(メッセージTransportエージェント、1人のユーザから別のユーザまでメッセージを輸送するか、またはそのような転送の一部を実行するプログラム)がSPACEsと共にテキストの線を水増しするのが知られていて、他のものが線の端から「余白」キャラクタを外すのが知られるので、この規則が必要です。 したがって、Quoted印刷可能なボディーを解読するとき、線の上のどんな引きずっている余白も削除しなければなりません、それが必ず中間的輸送エージェントによって加えられてしまうだろうというとき。
Rule #4 (Line Breaks): A line break in a text body
part, independent of what its representation is
following the canonical representation of the data
being encoded, must be represented by a (RFC 822) line
break, which is a CRLF sequence, in the Quoted-
Printable encoding. If isolated CRs and LFs, or LF CR
and CR LF sequences are allowed to appear in binary
data according to the canonical form, they must be
represented using the "=0D", "=0A", "=0A=0D" and
"=0D=0A" notations respectively.
#4(ラインブレイク)を統治してください: (RFC822)ラインブレイクでテキスト身体の部分のラインブレイク(コード化されるデータの正準な表現に続く表現が何であるかに関する独立者)を表さなければなりません、Quotedの印刷可能なコード化で。(ラインブレイクはCRLF系列です)。 標準形に従って系列が2進のデータで見えることができるCRsとLFsか、LF CRとCR LF、隔離されるなら、それぞれ「=0D」、「=0A」、「=0A=0D」、および「=0D=0A」記法を使用することでそれらを表さなければなりません。
Note that many implementation may elect to encode the
local representation of various content types directly.
In particular, this may apply to plain text material on
systems that use newline conventions other than CRLF
delimiters. Such an implementation is permissible, but
the generation of line breaks must be generalized to
account for the case where alternate representations of
newline sequences are used.
多くの実現が、直接様々な満足しているタイプのローカルの表現をコード化するのを選ぶかもしれないことに注意してください。 特に、これはCRLFデリミタ以外のニューラインコンベンションを使用するシステムの上のプレーンテキストの材料に適用されるかもしれません。 そのような実現は許されていますが、ニューライン系列の交互の表現が使用されているケースの原因になるようにラインブレイクの世代を一般化しなければなりません。
Rule #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 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:
#5(柔らかいラインブレイク)を統治してください: 76未満のキャラクタが長かったなら、それがコード化したQuoted印刷可能なコード化REQUIRESは立ち並んでいます。 より長い線がQuoted印刷可能なコード化でコード化されることであるなら、'柔らかい'ラインブレイクを使用しなければなりません。 コード化された線の上の最後のキャラクタとしての等号はコード化されたテキストのそのような非重要な('柔らかい')ラインブレイクを示します。 したがって、線の「生」のフォームがただ一つの暗号化されていない線であるなら、それは言います:
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
Quoted印刷可能なコード化でこれを表すことができます。
Borenstein & Freed [Page 15]
Borensteinであって解放されています。[15ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
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.
これはユーザエージェントによって回復されるほど長い線がそのような方法でコード化されるメカニズムを提供します。 76キャラクタ限界は、引きずっているCRLFを数えませんが、どんな等号も含む他のすべてのキャラクタを数えます。
Since the hyphen character ("-") is represented as itself in
the Quoted-Printable encoding, care must be taken, when
encapsulating a quoted-printable encoded body in a multipart
entity, to ensure that the encapsulation boundary 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 later in this
document.)
ハイフンキャラクタ(「-」)がそれ自体として引用されて印刷可能なコード化で代理をされるので、カプセル化境界がコード化されたボディーで何処にも現れないのを保証するために複合実体で引用されて印刷可能なコード化されたボディーを要約するとき、注意しなければなりません。 (優れた戦略は引用されて印刷可能なボディーに決して現れることができない「=_」などのキャラクタシーケンスを含んでいる境界を選ぶことです。 後で本書では複合メッセージの定義を見てください。)
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. (In theory, an EBCDIC
gateway could decode a quoted-printable body and re-encode
it using base64, but such gateways do not yet exist.) 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 ASCII
characters
以下に注意してください。 引用されて印刷可能なコード化は読み易さと信頼性の間の輸送におけるある種の妥協を表します。 数ゲートウェイ(著しくEBCDICへの翻訳にかかわるもの)の上で完全に働かないかもしれないのを除いて、引用されて印刷可能なコード化でコード化されたボディーはほとんどのメール・ゲートウェイより確かにやり直すでしょう。 (EBCDICゲートウェイは、base64を使用することで理論上、引用されて印刷可能なボディーを解読して、それを再コード化するかもしれませんが、そのようなゲートウェイはまだ存在していません。) base64 Content転送コード化で、より高いレベルの信用を提供します。 合理的に信頼できる輸送をEBCDICゲートウェイに通す方法はまた、ASCII文字を引用することです。
!"#$@[\]^`{|}~
!"#$@[\]^`{|}~
according to rule #1. See Appendix B for more information.
規則#1に従って。 詳しい情報に関してAppendix Bを見てください。
Because quoted-printable data is generally assumed to be
line-oriented, it is to be expected that 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 corruption of the
data, it is probably more sensible to use the base64
encoding rather than the quoted-printable encoding.
引用されて印刷可能なデータが線指向であると一般に思われるので、引用された印刷可能なデータの線の間の中断が輸送で変更されるかもしれないと予想されることになっていて、異なったニューラインコンベンションと共にシステムの間を通るとき、同じ方法で、そのプレーンテキストメールはインターネット・メールでいつも変更されていました。 そのような変更がデータの不正を構成しそうであるなら、引用されて印刷可能なコード化よりむしろbase64コード化を使用するのはたぶんさらに分別があります。
Borenstein & Freed [Page 16]
Borensteinであって解放されています。[16ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
5.2 Base64 Content-Transfer-Encoding
5.2 Base64の満足している転送コード化
The Base64 Content-Transfer-Encoding is designed to
represent arbitrary sequences of octets in a form that is
not 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
based on the one used in Privacy Enhanced Mail applications,
as defined in RFC 1113. The base64 encoding is adapted
from RFC 1113, with one change: base64 eliminates the "*"
mechanism for embedded clear text.
Base64 Content転送コード化は、人間的に読み込み可能でないフォームでの八重奏の気紛れな順番を表すように設計されています。 コード化とアルゴリズムを解読するのが簡単ですが、コード化されたデータは暗号化されていないデータより一貫しておよそ33パーセント大きいだけです。 このコード化はRFC1113で定義されるようにPrivacy Enhancedメールアプリケーションで使用されるものに基づいています。 base64コード化は1回の変化でRFC1113から適合させられます: base64は埋め込まれたクリアテキストのために「*」メカニズムを排除します。
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.)
6ビットが印刷可能なキャラクタ単位で表されるのを可能にして、米国-ASCIIの65文字サブセットが使用されています。 (「=」という65番目の余分なキャラクタは特別な処理機能を意味するのに使用されます。)
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 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.
以下に注意してください。 この部分集合には、同様にISO646のすべてのバージョンに表されて、米国ASCIIを含んでいて、重要な特性があります、そして、また、部分集合のすべてのキャラクタが同様にEBCDICのすべてのバージョンで代理をされます。 UUENCODEユーティリティとbase85コード化で使用されるコード化などの他のポピュラーなencodingsはLevelの一部として2つのポストスクリプトを指定して、これらの特性を共有しないで、またその結果、メールのためにコード化される2進の輸送に満たされなければならないという携帯性要件を実現させません。
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 8-bit 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 byte, and the eighth
bit will be the low-order bit in the first byte, and so on.
4の出力ストリングがキャラクタをコード化したので、コード化の過程は入力ビットの24ビットのグループを代表します。 左から右まで続いて、24ビットの入力グループは、3の8ビットの入力グループを連結することによって、結成されます。 そして、4が6ビットのグループ(それのそれぞれがbase64アルファベットの一桁に翻訳される)を連結したので、これらの24ビットは扱われます。 base64コード化を通して流れを少しコード化するとき、ビットストリームはあえて最も多くの重要なビット1番目で命令されなければなりません。 すなわち、流れにおける最初のビットは最初のバイトで高位のビットになるでしょう、そして、8番目のビットは最初のバイト、などに下位のビットになるでしょう。
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 encapsulation boundaries defined in this document
(e.g., "-").
それぞれの6ビットのグループはインデックスとして64の印刷可能なキャラクタのアレイに使用されます。 インデックスによって参照をつけられるキャラクタは出力ストリングに置かれます。 「これらの以下のTable1で特定されたキャラクタが一般に「表-可能」になるように選ばれて、セットが特定の意味でSMTPまでキャラクタを除く、(例えば」、」、"CR"、"LF") そして、本書では(例えば、「-」)カプセル化境界と定義されています。
Borenstein & Freed [Page 17]
Borensteinであって解放されています。[17ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Table 1: The Base64 Alphabet
テーブル1: Base64アルファベット
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
評価..18秒間..C..44秒間..パッド..33時間
The output stream (encoded bytes) 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.
それぞれ76未満のキャラクタの線で出力ストリーム(バイトをコード化する)を表さなければなりません。 ソフトウェアを解読することによって、Table1で見つけられなかったすべてのラインブレイクか他のキャラクタを無視しなければなりません。 base64データでは、Table1のそれら以外のキャラクタ、ラインブレイク、および他の余白はたぶん伝送エラーを示します。(警告メッセージかメッセージ拒絶さえそれに関していくつかの状況で適切であるかもしれません)。
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. Output character positions
which are not required to represent actual input data are
set to 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.
24ビット未満がコード化されるデータの終わりで有効であるなら、特別な処理は実行されます。 完全なコード化量子はいつもボディーの先に完成します。 24入力ビット未満が入力グループで有効であるときに、ゼロ・ビットは、整数の6ビットのグループを結成するために加えられます(右で)。 実際の入力データを表すのに必要でない出力欄はキャラクタ「=」に設定されます。 すべてのbase64入力が整数の八重奏であるので、以下のケースしか起こることができません: (1) 入力をコード化する最終的な量子は24ビットの不可欠の倍数です。 (2) ここで、コード化された出力の最終的なユニットが「=」が全くそっと歩いていない4つのキャラクタの不可欠の倍数になる、入力をコード化する最終的な量子はちょうど8ビットです。 (3) ここで、コード化された出力の最終的なユニットは2人の「=」暫定記号によっていうことになられた2つのキャラクタになるだろうか、入力をコード化する最終的な量子はまさに16ビットです。 ここで、コード化された出力の最終的なユニットは1人の「=」暫定記号によっていうことになられた3つのキャラクタになるでしょう。
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 should be converted into CRLF sequences
base64コード化が直接テキストの材料に適用されて、それが標準形に変換されていないということであるなら、ラインブレイクに適切な八重奏を使用するために注意しなければなりません。 特に、テキストラインブレイクはCRLF系列に変換されるべきです。
Borenstein & Freed [Page 18]
Borensteinであって解放されています。[18ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
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.
base64コード化の前に。 注意する重要なことは直接先のcanonicalizationステップでというよりむしろエンコーダでいくつかの実現でこれをするかもしれないということです。
NOTE: There is no need to worry about quoting apparent
encapsulation boundaries within base64-encoded parts of
multipart entities because no hyphen characters are used in
the base64 encoding.
以下に注意してください。 ハイフンキャラクタが全くbase64コード化に使用されないので複合実体のbase64によってコード化された部品の中で見かけのカプセル化境界を引用するのを心配する必要は全くありません。
6 Additional Optional Content- Header Fields
6 追加任意の内容ヘッダーフィールド
6.1 Optional Content-ID Header Field
6.1 任意のコンテントIDヘッダーフィールド
In constructing a high-level user agent, it may be desirable
to allow one body to make reference to another.
Accordingly, bodies may be labeled using the "Content-ID"
header field, which is syntactically identical to the
"Message-ID" header field:
ハイレベルのユーザエージェントを組み立てるのにおいて、1つのボディーが別のものについて言及するのを許容するのは望ましいかもしれません。 それに従って、ボディーはシンタクス上「Message ID」ヘッダーフィールドと同じ「コンテントID」ヘッダーフィールドを使用することでラベルされるかもしれません:
Content-ID := msg-id
コンテントID:=msg-イド
Like the Message-ID values, Content-ID values must be
generated to be as unique as possible.
Message-ID値のように、コンテントID値は、できるだけ特有になるように発生しなければなりません。
6.2 Optional Content-Description Header Field
6.2 任意の満足している記述ヘッダーフィールド
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.
何らかの記述的な情報を与えられたボディーに関連づける能力はしばしば望ましいです。 例えば、「スペースシャトルEndeavorの絵」として「イメージ」ボディーをマークするのは役に立つかもしれません。 そのようなテキストはContent記述ヘッダーフィールドに置かれるかもしれません。
Content-Description := *text
満足している記述:=*テキスト
The description is presumed to be given in the US-ASCII
character set, although the mechanism specified in [RFC-
1342] may be used for non-US-ASCII Content-Description
values.
あえて米国-ASCII文字の組で記述を与えます、[RFC1342]で指定されたメカニズムは非米国のASCII Content-記述値に使用されるかもしれませんが。
Borenstein & Freed [Page 19]
Borensteinであって解放されています。[19ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
7 The Predefined Content-Type Values
7 事前に定義されたコンテントタイプ値
This document defines seven initial Content-Type values and
an extension mechanism for private or experimental types.
Further standard types must be defined by new published
specifications. It is expected that most innovation in new
types of mail will take place as subtypes of the seven types
defined here. The most essential characteristics of the
seven content-types are summarized in Appendix G.
このドキュメントは個人的であるか実験しているタイプのために7つの初期のコンテントタイプ値と拡大メカニズムを定義します。 新しい広められた仕様でさらなる標準体型を定義しなければなりません。 新しいタイプのメールにおけるほとんどの革新がここで定義された7つのタイプの血液型亜型として起こると予想されます。 7つの満足しているタイプの最も不可欠の特性はAppendix Gにまとめられます。
7.1 The Text Content-Type
7.1 テキストコンテントタイプ
The text Content-Type is intended for sending material which
is principally textual in form. It is the default Content-
Type. A "charset" parameter may be used to indicate the
character set of the body text. The primary subtype of text
is "plain". This indicates plain (unformatted) text. The
default Content-Type for Internet mail is "text/plain;
charset=us-ascii".
テキストコンテントタイプはフォームで主に原文であることの送付の材料のために意図します。 それはContentがタイプするデフォルトです。 "charset"パラメタは、本文の文字の組を示すのに使用されるかもしれません。 テキストの第一の「副-タイプ」は「明瞭です」。 これは明瞭な(非フォーマットされる)テキストを示します。 インターネット・メールのためのデフォルトコンテントタイプは「テキスト/明瞭です」。 「charsetが私たちと等しい、-、ASCII、」
Beyond plain text, there are many formats for representing
what might be known as "extended text" -- text with embedded
formatting and presentation information. An interesting
characteristic of many such representations is that they are
to some extent readable even without the software that
interprets them. It is useful, then, to distinguish them,
at the highest level, from such unreadable data as images,
audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, it is
reasonable to show subtypes of text to the user, while it is
not reasonable to do so with most nontextual data.
プレーンテキストを超えて、「拡張テキスト」として知られているかもしれないことを表すための多くの形式がいます--埋め込まれた形式とプレゼンテーション情報があるテキスト。 そのような多くの表現のおもしろい特性はそれらがそれらを解釈するソフトウェアがなくてもある程度読み込み可能であるということです。 次に、それらを区別するのは役に立ちます、上層部によって、イメージ、オーディオ、またはテキストが読みにくいフォームに表したような読みにくいデータから。 適切な解釈ソフトウェアがないとき、テキストの血液型亜型をユーザに示しているのは妥当です、したがって、ほとんどのnontextualデータを処理するのが妥当ではありませんが。
Such formatted textual data should be represented using
subtypes of text. Plausible subtypes of text are typically
given by the common name of the representation format, e.g.,
"text/richtext".
そのようなフォーマットされた原文のデータは、テキストの血液型亜型を使用することで表されるべきです。 テキストのもっともらしい血液型亜型は表現形式の一般名、例えば、「テキスト/richtext」によって通常与えられています。
7.1.1 The charset parameter
7.1.1 charsetパラメタ
A critical parameter that may be specified in the Content-
Type field for text data is the character set. This is
specified with a "charset" parameter, as in:
Contentタイプ分野でテキストデータに指定されるかもしれない臨界パラメータは文字の組です。 これは以下のように"charset"パラメタで指定されます。
Content-type: text/plain; charset=us-ascii
文書内容: テキスト/平野。 charsetが私たちと等しい、-、ASCII
Unlike some other parameter values, the values of the
charset parameter are NOT case sensitive. The default
character set, which must be assumed in the absence of a
charset parameter, is US-ASCII.
ある他のパラメタ値と異なって、charsetパラメタの値は大文字と小文字を区別していません。 デフォルト文字の組(charsetパラメタがないとき想定しなければならない)は米国-ASCIIです。
An initial list of predefined character set names can be
found at the end of this section. Additional character sets
may be registered with IANA as described in Appendix F,
although the standardization of their use requires the usual
このセクションの端で事前に定義された文字の組名の初期のリストを見つけることができます。 追加文字セットはAppendix Fで説明されるようにIANAに登録されるかもしれません、彼らの使用の標準化が普通を必要としますが
Borenstein & Freed [Page 20]
Borensteinであって解放されています。[20ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
IAB review and approval. Note that if the specified
character set includes 8-bit data, a Content-Transfer-
Encoding header field and a corresponding encoding on the
data are required in order to transmit the body via some
mail transfer protocols, such as SMTP.
IABレビューと承認。 SMTPなどのいくつかのメール転送プロトコルでボディーを伝えるために指定された文字の組が8ビットのデータを含むなら、Contentコード化を移しているヘッダーフィールドとデータでの対応するコード化が必要であることに注意してください。
The default character set, US-ASCII, has been the subject of
some confusion and ambiguity in the past. Not only were
there some ambiguities in the definition, there have been
wide variations in practice. In order to eliminate such
ambiguity and variations in the future, it is strongly
recommended that new user agents explicitly specify a
character set via the Content-Type header field. "US-ASCII"
does not indicate an arbitrary seven-bit character code, but
specifies that the body uses character coding that uses the
exact correspondence of codes to characters specified in
ASCII. National use variations of ISO 646 [ISO-646] are NOT
ASCII and their use in Internet mail is explicitly
discouraged. The omission of the ISO 646 character set is
deliberate in this regard. The character set name of "US-
ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
The character set name "ASCII" is reserved and must not be
used for any purpose.
デフォルト文字の組(米国-ASCII)は過去の何らかの混乱とあいまいさの対象です。 いくつかのあいまいさが定義中だけであったのではなく、広い変化が実際にはありました。 将来そのようなあいまいさと変化を取り除くために、新しいユーザエージェントがコンテントタイプヘッダーフィールドで明らかに文字の組を指定することが強く勧められます。 「米国-ASCII」は、任意の7ビットのキャラクタコードを示しませんが、ボディーがASCIIで指定されたキャラクタにコードの正確な通信を使用するキャラクタコード化を使用すると指定します。 国立はISO646の変化を使用します。[ISO-646]はASCIIではありません、そして、インターネット・メールにおける彼らの使用は明らかにお勧めできないです。 ISO646文字の組の省略はこの点で慎重です。 「米国ASCII」の文字の組名は明らかに、ANSI X3.4-1986[米国-ASCII]だけについて言及します。 「ASCII」という文字の組名は、予約されていて、どんな目的にも使用されてはいけません。
NOTE: RFC 821 explicitly specifies "ASCII", and references
an earlier version of the American Standard. Insofar as one
of the purposes of specifying a Content-Type and character
set is to permit the receiver to unambiguously determine how
the sender intended the coded message to be interpreted,
assuming anything other than "strict ASCII" as the default
would risk unintentional and incompatible changes to the
semantics of messages now being transmitted. This also
implies that messages containing characters coded according
to national variations on ISO 646, or using code-switching
procedures (e.g., those of ISO 2022), as well as 8-bit or
multiple octet character encodings MUST use an appropriate
character set specification to be consistent with this
specification.
以下に注意してください。 RFC821は明らかに「ASCII」を指定します、そして、参照はアメリカン・スタンダードの以前のバージョンを指定します。 受信機が、送付者がどのように解釈されるべきコード化されたメッセージを意図したかを明白に決定することを許可するコンテントタイプと文字の組を指定する目的の1つがことである限り、デフォルトとしての「厳しいASCII」を除いた何かを仮定すると、現在送られるメッセージの意味論への意図的でなくて非互換な変化は危険にさらされるでしょう。 また、これは、ISO646の国家の変化に従ってコード化されるか、またはコードを切り換える手順(例えば、ISO2022のもの)、および8ビットか複数の八重奏キャラクタencodingsを用いることでキャラクタを含むメッセージがこの仕様と一致しているのに適切な文字の組仕様を使用しなければならないのを含意します。
The complete US-ASCII character set is listed in [US-ASCII].
Note that the control characters including DEL (0-31, 127)
have no defined meaning apart from the combination CRLF
(ASCII values 13 and 10) indicating a new line. Two of the
characters have de facto meanings in wide use: FF (12) often
means "start subsequent text on the beginning of a new
page"; and TAB or HT (9) often (though not always) means
"move the cursor to the next available column after the
current position where the column number is a multiple of 8
(counting the first column as column 0)." Apart from this,
any use of the control characters or DEL in a body must be
part of a private agreement between the sender and
recipient. Such private agreements are discouraged and
should be replaced by the other capabilities of this
document.
完全な米国-ASCII文字の組は[米国-ASCII]で記載されています。 DEL(0-31、127)を含む制御文字が組み合わせCRLF(ASCII値13と10)は別として復帰改行を示しながら定義された意味を全く持っていないことに注意してください。 2つのキャラクタには、広い使用での事実上の意味があります: FF(12)は、しばしば「新しいページの始まりに関するその後のテキストを始めます」と意味します。 そして、TABかHT(9)が、しばしば「カーソルを現在の位置の後の次の有効なコラムに桁位置が8の倍数(コラム0に最初のコラムをみなして)であるところに動かします。」と意味します(いつもがではありませんが)。 これは別として、ボディーにおける制御文字かDELのどんな使用も送付者と受取人との個人的な協定の一部であるに違いありません。 そのような個人的な協定をがっかりして、このドキュメントの他の能力に取り替えるべきです。
Borenstein & Freed [Page 21]
Borensteinであって解放されています。[21ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
NOTE: Beyond US-ASCII, an enormous proliferation of
character sets is possible. It is the opinion of the IETF
working group that a large number of character sets is NOT a
good thing. We would prefer to specify a single character
set that can be used universally for representing all of the
world's languages in electronic mail. Unfortunately,
existing practice in several communities seems to point to
the continued use of multiple character sets in the near
future. For this reason, we define names for a small number
of character sets for which a strong constituent base
exists. It is our hope that ISO 10646 or some other
effort will eventually define a single world character set
which can then be specified for use in Internet mail, but in
the advance of that definition we cannot specify the use of
ISO 10646, Unicode, or any other character set whose
definition is, as of this writing, incomplete.
以下に注意してください。 米国-ASCIIを超えて、文字の組の莫大な増殖は可能です。 それは良いものではなく、多くの文字の組があるIETFワーキンググループに関する意見です。 私たちは、電子メールに世界の言語のすべてを表すのに一般に使用できるただ一つの文字の組を指定するのを好むでしょう。 残念ながら、いくつかの共同体の既存の習慣は近い将来の複数の文字の組の継続的な使用を示すように思えます。 この理由で、私たちは強い構成しているベースが存在する少ない数の文字の組のために名前を定義します。 それはISO10646かある他の努力が結局次にインターネット・メールにおける使用に指定できるただ一つの世界文字の組を定義するという私たちの望みですが、その定義の進歩では、私たちは不完全な状態でISO10646、ユニコード、またはいかなる他の文字の組のこの書くこと現在、定義がある使用も指定できません。
The defined charset values are:
定義されたcharset値は以下の通りです。
US-ASCII -- as defined in [US-ASCII].
米国-ASCII--[米国-ASCII]で定義されるように。
ISO-8859-X -- where "X" is to be replaced, as
necessary, for the parts of ISO-8859 [ISO-
8859]. Note that the ISO 646 character sets
have deliberately been omitted in favor of
their 8859 replacements, which are the
designated character sets for Internet mail.
As of the publication of this document, the
legitimate values for "X" are the digits 1
through 9.
ISO-8859-X--「X」が必要に応じてISO-8859[ISO8859]の部分に取り替えられることになっているところ。 ISO646文字の組が彼らの8859の交換を支持して故意に省略されたことに注意してください。交換はインターネット・メールのための指定された文字の組です。 このドキュメントの公表現在、「X」のための正統の値は1〜9にケタです。
Note that the character set used, if anything other than
US-ASCII, must always be explicitly specified in the
Content-Type field.
コンテントタイプ分野でいつも明らかにどちらかと言えば、米国-ASCIIを除いて、使用される文字の組を指定しなければならないことに注意してください。
No other character set name may be used in Internet mail
without the publication of a formal specification and its
registration with IANA as described in Appendix F, or by
private agreement, in which case the character set name must
begin with "X-".
他の文字の組名は全くAppendix F、または個人的な協定で説明されるようにインターネット・メールで形式仕様の公表とIANAとのその登録なしで使用されないかもしれません、その場合、文字の組名は「X」と共に始まらなければなりません。
Implementors are discouraged from defining new character
sets for mail use unless absolutely necessary.
作成者は、絶対に必要でない場合メール使用のために新しい文字の組を定義して、がっかりしています。
The "charset" parameter has been defined primarily for the
purpose of textual data, and is described in this section
for that reason. However, it is conceivable that non-
textual data might also wish to specify a charset value for
some purpose, in which case the same syntax and values
should be used.
"charset"パラメタは、主として原文のデータの目的のために定義されて、その理由でこのセクションで説明されます。 しかしながら、また、非原文のデータが何らかの目的にcharset値を指定したがっているのが想像できる、その場合、同じ構文と値は使用されるべきです。
In general, mail-sending software should always use the
"lowest common denominator" character set possible. For
example, if a body contains only US-ASCII characters, it
一般に、メールを送るソフトウェアはいつも可能な「最小公分母」文字の組を使用するはずです。 ボディーが例えば米国-ASCII文字だけを含むならそれ
Borenstein & Freed [Page 22]
Borensteinであって解放されています。[22ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
should be marked as being in the US-ASCII character set, not
ISO-8859-1, which, like all the ISO-8859 family of character
sets, is a superset of US-ASCII. More generally, if a
widely-used character set is a subset of another character
set, and a body contains only characters in the widely-used
subset, it should be labeled as being in that subset. This
will increase the chances that the recipient will be able to
view the mail correctly.
文字の組のすべてのISO-8859家のように米国-ASCIIのスーパーセットであるISO-8859-1ではなく、米国-ASCII文字の組にはあるとしてマークされるべきです。 より一般に、広く使用された文字の組が別の文字の組の部分集合であり、ボディーが広く使用された部分集合にキャラクタだけを含むなら、それはその部分集合にはあるとしてラベルされるべきです。 これは受取人が正しくメールを見ることができるという可能性を高めるでしょう。
7.1.2 The Text/plain subtype
7.1.2 Text/明瞭な「副-タイプ」
The primary subtype of text is "plain". This indicates
plain (unformatted) text. The default Content-Type for
Internet mail, "text/plain; charset=us-ascii", describes
existing Internet practice, that is, it is the type of body
defined by RFC 822.
テキストの第一の「副-タイプ」は「明瞭です」。 これは明瞭な(非フォーマットされる)テキストを示します。 インターネット・メールのためのデフォルトコンテントタイプ、「テキスト/平野」。 「charsetが私たちと等しい、-、ASCII、」、説明、すなわち、既存のインターネット習慣、それはRFC822によって定義されたボディーのタイプです。
7.1.3 The Text/richtext subtype
7.1.3 Text/richtext subtype
In order to promote the wider interoperability of simple
formatted text, this document defines an extremely simple
subtype of "text", the "richtext" subtype. This subtype was
designed to meet the following criteria:
簡単なフォーマット済みのテキストの、より広い相互運用性を促進するために、このドキュメントは「テキスト」("richtext"「副-タイプ」)の非常に簡単な「副-タイプ」を定義します。 この「副-タイプ」は以下の評価基準を満たすように設計されました:
1. The syntax must be extremely simple to parse,
so that even teletype-oriented mail systems can
easily strip away the formatting information and
leave only the readable text.
1. 構文は分析するのが非常に簡単でなければなりません、テレタイプ指向のメールシステムさえ容易に形式情報をはいで、読み込み可能なテキストだけを残すことができるように。
2. The syntax must be extensible to allow for new
formatting commands that are deemed essential.
2. 構文は不可欠であると考えられる新しい書式付けコマンドを考慮するのにおいて広げることができるに違いありません。
3. The capabilities must be extremely limited, to
ensure that it can represent no more than is
likely to be representable by the user's primary
word processor. While this limits what can be
sent, it increases the likelihood that what is
sent can be properly displayed.
3. 能力は、ユーザの第一のワードプロセッサで「表-可能」であることがありそうであるというよりもいいえともう少し表すことができるのを保証するために非常に限らなければなりません。 これは送ることができるものを制限しますが、それは適切に送られるものを表示できる可能性を広げます。
4. The syntax must be compatible with SGML, so
that, with an appropriate DTD (Document Type
Definition, the standard mechanism for defining a
document type using SGML), a general SGML parser
could be made to parse richtext. However, despite
this compatibility, the syntax should be far
simpler than full SGML, so that no SGML knowledge
is required in order to implement it.
4. 構文はSGMLと互換性があるに違いありません、一般的なSGMLパーサに適切なDTD(Type Definitionを記録してください、SGMLを使用することでドキュメントタイプを定義するための標準のメカニズム)でrichtextを分析させることができるように。 しかしながら、この互換性にもかかわらず、構文は完全なSGMLよりはるかに簡単であるべきです、SGML知識が全くそれを実行するのに必要でないように。
The syntax of "richtext" is very simple. It is assumed, at
the top-level, to be in the US-ASCII character set, unless
of course a different charset parameter was specified in the
Content-type field. All characters represent themselves,
with the exception of the "<" character (ASCII 60), which is
used to mark the beginning of a formatting command.
"richtext"の構文は非常に簡単です。 トップレベルで米国-ASCII文字の組にはそれがあると思われます、異なったcharsetパラメタがもちろん文書内容分野で指定されなかったなら。 すべてのキャラクタが自分たちの代理をします、"<"キャラクタ(ASCII60)を除いて。(キャラクタは、書式付けコマンドの始まりを示すのに使用されます)。
Borenstein & Freed [Page 23]
Borensteinであって解放されています。[23ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Formatting instructions consist of formatting commands
surrounded by angle brackets ("<>", ASCII 60 and 62). Each
formatting command may be no more than 40 characters in
length, all in US-ASCII, restricted to the alphanumeric and
hyphen ("-") characters. Formatting commands may be preceded
by a forward slash or solidus ("/", ASCII 47), making them
negations, and such negations must always exist to balance
the initial opening commands, except as noted below. Thus,
if the formatting command "<bold>" appears at some point,
there must later be a "</bold>" to balance it. There are
only three exceptions to this "balancing" rule: First, the
command "<lt>" is used to represent a literal "<" character.
Second, the command "<nl>" is used to represent a required
line break. (Otherwise, CRLFs in the data are treated as
equivalent to a single SPACE character.) Finally, the
command "<np>" is used to represent a page break. (NOTE:
The 40 character limit on formatting commands does not
include the "<", ">", or "/" characters that might be
attached to such commands.)
書式設定命令は角ブラケット(「<>」、ASCII60と62)によって囲まれた書式付けコマンドから成ります。 各書式付けコマンドは長さが40未満のキャラクタであるかもしれません、英数字とハイフン(「-」)キャラクタに制限された米国-ASCIIで。 前進のスラッシュかソリドゥス(「/」、ASCII47)が書式付けコマンドに先行するかもしれなくて、作っているそれらは否定です、そして、そのような否定が初期の初めのコマンドのバランスをとるためにいつも存在しなければなりません、以下に述べられるのを除いて。 したがって、書式付けコマンド「<の大胆な>」が何らかのポイントに現れるなら、後で、それのバランスをとる「</大胆な>」があるに違いありません。 この「バランスをとること」の規則への3つの例外しかありません: まず最初に、コマンド「<lt>」は、文字通りの"<"キャラクタの代理をするのに使用されます。 2番目に、コマンド「<nl>」は、必要なラインブレイクを表すのに使用されます。 (さもなければ、データのCRLFsは単独のSPACEキャラクタと同等物として扱われます。) 最終的に、コマンド「<Np>」は、ページブレークを表すのに使用されます。 「(注意: 書式付けコマンドにおける40キャラクタ限界は、"<"、">"をどんなインクルードにもしないか、または」 そのようなコマンドに付けられるかもしれないキャラクタを」 /にします。)
Initially defined formatting commands, not all of which will
be implemented by all richtext implementations, include:
初めは定義された書式付けコマンド(それのすべてがすべてのrichtext実現で実行されるというわけではない)は:
Bold -- causes the subsequent text to be in a bold
font.
Italic -- causes the subsequent text to be in an italic
font.
Fixed -- causes the subsequent text to be in a fixed
width font.
Smaller -- causes the subsequent text to be in a
smaller font.
Bigger -- causes the subsequent text to be in a bigger
font.
Underline -- causes the subsequent text to be
underlined.
Center -- causes the subsequent text to be centered.
FlushLeft -- causes the subsequent text to be left
justified.
FlushRight -- causes the subsequent text to be right
justified.
Indent -- causes the subsequent text to be indented at
the left margin.
IndentRight -- causes the subsequent text to be
indented at the right margin.
Outdent -- causes the subsequent text to be outdented
at the left margin.
OutdentRight -- causes the subsequent text to be
outdented at the right margin.
SamePage -- causes the subsequent text to be grouped,
if possible, on one page.
Subscript -- causes the subsequent text to be
interpreted as a subscript.
ボールド--太字フォントにはその後のテキストがあることを引き起こします。 イタリック体、--イタリック体の字体にはその後のテキストがあることを引き起こします。 修理されました--固定幅の字体にはその後のテキストがあることを引き起こします。 小ささ、--より小さい字体にはその後のテキストがあることを引き起こします。 大きさ、--より大きい字体にはその後のテキストがあることを引き起こします。 アンダーライン--その後のテキストがアンダーラインを引かれることを引き起こします。 センター--その後のテキストが中心に置かれることを引き起こします。 FlushLeft--その後のテキストが正当化されるように残されることを引き起こします。 FlushRight--その後のテキストがまさしく正当であることを引き起こします。 インデント--その後のテキストが左のマージンで字下がりにされることを引き起こします。 IndentRight--その後のテキストがライト・マージンで字下がりにされることを引き起こします。 Outdent--その後のテキストが左のマージンで「外-へこ」むことを引き起こします。 OutdentRight--その後のテキストがライト・マージンで「外-へこ」むことを引き起こします。 SamePage--できれば、その後のテキストが1ページで分類されることを引き起こします。 添字--その後のテキストが添字として解釈されることを引き起こします。
Borenstein & Freed [Page 24]
Borensteinであって解放されています。[24ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Superscript -- causes the subsequent text to be
interpreted as a superscript.
Heading -- causes the subsequent text to be interpreted
as a page heading.
Footing -- causes the subsequent text to be interpreted
as a page footing.
ISO-8859-X (for any value of X that is legal as a
"charset" parameter) -- causes the subsequent text
to be interpreted as text in the appropriate
character set.
US-ASCII -- causes the subsequent text to be
interpreted as text in the US-ASCII character set.
Excerpt -- causes the subsequent text to be interpreted
as a textual excerpt from another source.
Typically this will be displayed using indentation
and an alternate font, but such decisions are up
to the viewer.
Paragraph -- causes the subsequent text to be
interpreted as a single paragraph, with
appropriate paragraph breaks (typically blank
space) before and after.
Signature -- causes the subsequent text to be
interpreted as a "signature". Some systems may
wish to display signatures in a smaller font or
otherwise set them apart from the main text of the
message.
Comment -- causes the subsequent text to be interpreted
as a comment, and hence not shown to the reader.
No-op -- has no effect on the subsequent text.
lt -- <lt> is replaced by a literal "<" character. No
balancing </lt> is allowed.
nl -- <nl> causes a line break. No balancing </nl> is
allowed.
np -- <np> causes a page break. No balancing </np> is
allowed.
上付き文字--その後のテキストが上付き文字として解釈されることを引き起こします。 見出し--その後のテキストがページ見出しとして解釈されることを引き起こします。 立脚地--その後のテキストがページ立脚地として解釈されることを引き起こします。 ISO-8859-X("charset"パラメタとして法的なXのどんな値のためのも)--その後のテキストが適切な文字の組のテキストとして解釈されることを引き起こします。 米国-ASCII--その後のテキストが米国-ASCII文字の組のテキストとして解釈されることを引き起こします。 抜粋--その後のテキストが原文の抜粋として別のソースから解釈されることを引き起こします。 通常、刻み目と交互の字体を使用することでこれを表示するでしょうが、そのような決定はビューアー次第です。 パラグラフ--適切なパラグラフで1つのパラグラフとして解釈されることを中断(通常空白のスペース)以前、後にその後のテキストを引き起こします。 署名--その後のテキストが「署名」として解釈されることを引き起こします。 いくつかのシステムが、より小さい字体で署名を表示したいか、またはそうでなければ、メッセージの主なテキストとそれらを区別して目立たせたがっているかもしれません。 コメント--その後のテキストがコメントとして解釈されて、したがって、読者に示されないことを引き起こします。 オプアートがありません--. その後のテキストltへの効果がありません--<lt>を文字通りの"<"キャラクタに取り替えます。 . nlはどんなバランスをとることの</lt>にも許容されていません--<nl>はラインブレイクを引き起こします。 . Npはどんなバランスをとることの</nl>にも許容されていません--<Np>はページブレークを引き起こします。 バランスをとることの</Np>は全く許容されていません。
Each positive formatting command affects all subsequent text
until the matching negative formatting command. Such pairs
of formatting commands must be properly balanced and nested.
Thus, a proper way to describe text in bold italics is:
それぞれの積極的な書式付けコマンドは合っている否定的書式付けコマンドまですべてのその後のテキストに影響します。 そのような組の書式付けコマンドは適切にバランスをとっていて、入れ子にしなければなりません。 したがって、太字のイタリックでテキストについて説明する適切な方法は以下の通りです。
<bold><italic>the-text</italic></bold>
<の大胆な><イタリック体の>、-、テキストの</イタリック体の></大胆な>。
or, alternately,
または、交互に。
<italic><bold>the-text</bold></italic>
<のイタリック体の><大胆な>、-、テキストの</大胆な></イタリック体の>。
but, in particular, the following is illegal
richtext:
しかし、↓これは特に、不法なrichtextです:
<bold><italic>the-text</bold></italic>
<の大胆な><イタリック体の>、-、テキストの</大胆な></イタリック体の>。
NOTE: The nesting requirement for formatting commands
imposes a slightly higher burden upon the composers of
以下に注意してください。 コマンドが作曲家でのわずかに高い負担を課す形式のための巣篭もり要件
Borenstein & Freed [Page 25]
Borensteinであって解放されています。[25ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
richtext bodies, but potentially simplifies richtext
displayers by allowing them to be stack-based. The main
goal of richtext is to be simple enough to make multifont,
formatted email widely readable, so that those with the
capability of sending it will be able to do so with
confidence. Thus slightly increased complexity in the
composing software was deemed a reasonable tradeoff for
simplified reading software. Nonetheless, implementors of
richtext readers are encouraged to follow the general
Internet guidelines of being conservative in what you send
and liberal in what you accept. Those implementations that
can do so are encouraged to deal reasonably with improperly
nested richtext.
具体化しますが、それらがスタックベースであることを許容することによって、richtextは潜在的にrichtext displayersを簡素化します。 richtextの第一目的はマルチフォント、フォーマットされたメールを広く読み込み可能にするほど簡単であることになっています、したがって、それを送る能力があるそれらが信用を処理できるように。 構成ソフトウェアにおけるこのようにしてわずかに増加する複雑さは簡易型の読書ソフトウェアのための手頃な見返りであると考えられました。 それにもかかわらず、richtext読者の作成者があなたが送るもので保守的であって、あなたが受け入れるもので寛容であることの一般的なインターネットガイドラインに従うよう奨励されます。 そうできるそれらの実現が合理的に不適切に入れ子にされたrichtextに対処するよう奨励されます。
Implementations must regard any unrecognized formatting
command as equivalent to "No-op", thus facilitating future
extensions to "richtext". Private extensions may be defined
using formatting commands that begin with "X-", by analogy
to Internet mail header field names.
実現は、どんな認識されていない書式付けコマンドも「オプアートがありません」に同等であるとみなして、その結果、"richtext"に今後の拡大を容易にしなければなりません。 個人的な拡大は、「X」と共にインターネット・メールヘッダーフィールドへの類推で始まる書式付けコマンドを使用することで定義されるかもしれません。
It is worth noting that no special behavior is required for
the TAB (HT) character. It is recommended, however, that, at
least when fixed-width fonts are in use, the common
semantics of the TAB (HT) character should be observed,
namely that it moves to the next column position that is a
multiple of 8. (In other words, if a TAB (HT) occurs in
column n, where the leftmost column is column 0, then that
TAB (HT) should be replaced by 8-(n mod 8) SPACE
characters.)
どんな特別な振舞いもTAB(HT)キャラクタに必要でないことに注意する価値があります。 しかしながら、それがお勧めである、それ、少なくともいつ固定ピッチフォントは使用中に、TAB(HT)キャラクタの一般的な意味論が観測されるべきであり、すなわち、8の倍数である次期コラム位置に動くということであるか。 (言い換えれば、TAB(HT)が一番左コラムがコラム0である桁nに起こるなら、そのTAB(HT)を8(nモッズ風の8)SPACEキャラクタに取り替えるべきです。)
Richtext also differentiates between "hard" and "soft" line
breaks. A line break (CRLF) in the richtext data stream is
interpreted as a "soft" line break, one that is included
only for purposes of mail transport, and is to be treated as
white space by richtext interpreters. To include a "hard"
line break (one that must be displayed as such), the "<nl>"
or "<paragraph> formatting constructs should be used. In
general, a soft line break should be treated as white space,
but when soft line breaks immediately follow a <nl> or a
</paragraph> tag they should be ignored rather than treated
as white space.
また、Richtextは「困難で」「柔らかい」ラインブレイクを区別します。 richtextデータ・ストリームにおけるラインブレイク(CRLF)は、「柔らかい」ラインブレイク、メール輸送の目的のためだけに含まれているものとして解釈されて、richtextインタプリタによって余白として扱われることです。 インクルードa「困難」ラインブレイク(そういうものとして表示しなければならないもの)、「<nl>」または「構造物をフォーマットする<パラグラフ>が使用されるべきであること」に。 一般に、柔らかいラインブレイクが余白として扱われるべきですが、柔らかいラインブレイクがすぐに<nl>か</パラグラフ>タグに続くとき、それらは余白として扱われるよりむしろ無視されるべきです。
Putting all this together, the following "text/richtext"
body fragment:
このすべてをまとめる以下の「テキスト/richtext」ボディー断片:
<bold>Now</bold> is the time for
<italic>all</italic> good men
<smaller>(and <lt>women>)</smaller> to
<ignoreme></ignoreme> come
<の大胆な>は、</大胆な>が<ignoreme></ignoreme>への<のイタリック体の>よりすべて</イタリック体の>良い男性<の、より小さい>(そして、<lt>女性>)</小さい>のための時間であるので、来ます。
to the aid of their
<nl>
それらの<nl>の援助に
Borenstein & Freed [Page 26]
Borensteinであって解放されています。[26ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
beloved <nl><nl>country. <comment> Stupid
quote! </comment> -- the end
いとしい<のnl><nl>国。 コメント>Stupidが引用する<! </コメント>--終わり
represents the following formatted text (which will, no
doubt, look cryptic in the text-only version of this
document):
以下のフォーマット済みのテキスト(間違いなくこのドキュメントのテキストのみバージョンで不可解に見える)を表します:
Now is the time for all good men (and <women>) to
come to the aid of their
beloved
現在、すべての良い男性(そして、<女性>)が意識を取り戻す時間は彼女らの恋人の援助ですか?
country. -- the end
国。 -- 終わり
Richtext conformance: A minimal richtext implementation is
one that simply converts "<lt>" to "<", converts CRLFs to
SPACE, converts <nl> to a newline according to local newline
convention, removes everything between a <comment> command
and the next balancing </comment> command, and removes all
other formatting commands (all text enclosed in angle
brackets).
Richtext順応: 最小量のrichtext実現は単に「<lt>」を"<"に変換して、CRLFsをスペースに変換して、地方のニューラインコンベンションに従って<nl>をニューラインに変換して、<コメント>命令と次のバランスをとることの</コメント>命令の間にすべてを移して、他のすべての書式付けコマンド(角ブラケットに同封されたすべてのテキスト)を移すものです。
NOTE ON THE RELATIONSHIP OF RICHTEXT TO SGML: Richtext is
decidedly not SGML, and must not be used to transport
arbitrary SGML documents. Those who wish to use SGML
document types as a mail transport format must define a new
text or application subtype, e.g., "text/sgml-dtd-whatever"
or "application/sgml-dtd-whatever", depending on the
perceived readability of the DTD in use. Richtext is
designed to be compatible with SGML, and specifically so
that it will be possible to define a richtext DTD if one is
needed. However, this does not imply that arbitrary SGML
can be called richtext, nor that richtext implementors have
any need to understand SGML; the description in this
document is a complete definition of richtext, which is far
simpler than complete SGML.
SGMLへのRICHTEXTの関係で以下に注意してください。 Richtextは、明らかにそうしていないSGMLであり、任意のSGMLドキュメントを輸送するのに使用されてはいけません。 メール輸送形式としてSGMLドキュメントタイプを使用したがっている人は新しいテキストかアプリケーション「副-タイプ」か例えば、「すべてのテキスト/sgml-dtd」か使用中のDTDの知覚された読み易さによる「すべてのアプリケーション/sgml-dtd」を定義しなければなりません。 Richtextは、互換性があるようにSGMLで設計されていて、1が必要であるならrichtext DTDを定義するのが可能であるように、明確に設計されています。 しかしながら、これは任意のSGMLをrichtextと呼ぶことができて、richtext作成者にはSGMLを理解するどんな必要もあるのを含意しません。 記述は本書ではrichtextの完全な定義です。(richtextは完全なSGMLよりはるかに簡単です)。
NOTE ON THE INTENDED USE OF RICHTEXT: It is recognized that
implementors of future mail systems will want rich text
functionality far beyond that currently defined for
richtext. The intent of richtext is to provide a common
format for expressing that functionality in a form in which
much of it, at least, will be understood by interoperating
software. Thus, in particular, software with a richer
notion of formatted text than richtext can still use
richtext as its basic representation, but can extend it with
new formatting commands and by hiding information specific
to that software system in richtext comments. As such
systems evolve, it is expected that the definition of
richtext will be further refined by future published
specifications, but richtext as defined here provides a
platform on which evolutionary refinements can be based.
RICHTEXTの意図している使用のときに以下に注意してください。 将来のメールシステムの作成者が遠くに現在richtextのために定義されているそれを超えてリッチテキストの機能性が欲しくなると認められます。 richtextの意図はそれの多くがソフトウェアを共同利用するのに少なくとも解釈されるフォームでその機能性を言い表すための一般的な形式を提供することです。 その結果、特にフォーマット済みのテキストの、より豊かな概念があるソフトウェア、基本的な表現としてrichtextにまだrichtextを使用できますが、新しい書式付けコマンドとrichtextコメントでそのソフトウェア・システムに特定の情報を隠すことによってそれを広げることができるより。 そういうものとして、システムは発展しますが、richtextの定義が将来の広められた仕様でさらに洗練されると予想されますが、ここで定義されるrichtextは進化論の気品が基づくことができるプラットホームを提供します。
IMPLEMENTATION NOTE: In some environments, it might be
impossible to combine certain richtext formatting commands,
実現注意: いくつかの環境で、あるrichtext書式付けコマンドを結合するのは不可能であるかもしれません。
Borenstein & Freed [Page 27]
Borensteinであって解放されています。[27ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
whereas in others they might be combined easily. For
example, the combination of <bold> and <italic> might
produce bold italics on systems that support such fonts, but
there exist systems that can make text bold or italicized,
but not both. In such cases, the most recently issued
recognized formatting command should be preferred.
彼らは他のもので容易に結合されるかもしれませんが。 例えば、<の大胆な>と<のイタリック体の>の組み合わせはそのような字体を支持するシステムに太字のイタリックを作成するかもしれませんが、テキストを大胆さかイタリック体で印刷されるようにすることができるシステムが存在していますが、ともに存在するというわけではありません。 そのような場合、最も最近発行された認識された書式付けコマンドは好まれるべきです。
One of the major goals in the design of richtext was to make
it so simple that even text-only mailers will implement
richtext-to-plain-text translators, thus increasing the
likelihood that multifont text will become "safe" to use
very widely. To demonstrate this simplicity, an extremely
simple 35-line C program that converts richtext input into
plain text output is included in Appendix D.
richtextのデザインにおける主要な目標の1つはそれをテキストのみ郵送者さえrichtextからプレーンテキストへの翻訳者を実行するほど簡単にすることでした、その結果、マルチフォントテキストが非常に広く使用するために「安全に」なる可能性を広げます。 この簡単さを示すために、richtext入力をプレーンテキスト出力に変換する非常に簡単な35線のCプログラムはAppendix Dに含まれています。
Borenstein & Freed [Page 28]
Borensteinであって解放されています。[28ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
7.2 The Multipart Content-Type
7.2 複合コンテントタイプ
In the case of multiple part messages, in which one or more
different sets of data are combined in a single body, a
"multipart" Content-Type field must appear in the entity's
header. The body must then contain one or more "body parts,"
each preceded by an encapsulation boundary, and the last one
followed by a closing boundary. Each part starts with an
encapsulation boundary, and then contains a body part
consisting of header area, a blank line, and a body area.
Thus a body part is similar to an RFC 822 message in syntax,
but different in meaning.
複数の部分メッセージの場合では、「複合」のコンテントタイプ野原は実体のヘッダーに現れなければなりません。(そこでは、1つ以上の異なったデータが単一のボディーで結合されます)。 次に、ボディーは1「身体の部分」を含まなければなりません、そして、それぞれがカプセル化境界のそばで先行しました、そして、最後のものは終わりの境界のそばで続きました。 各部分は、カプセル化境界から始まって、次に、ヘッダー領域、空白行、およびボディー領域から成る身体の部分を含んでいます。 したがって、身体の部分は、構文においてRFC822メッセージと同様ですが、意味において異なっています。
A body part is NOT to be interpreted as actually being an
RFC 822 message. To begin with, NO header fields are
actually required in body parts. A body part that starts
with a blank line, therefore, is allowed and is a body part
for which all default values are to be assumed. In such a
case, the absence of a Content-Type header field implies
that the encapsulation is plain US-ASCII text. The only
header fields that have defined meaning for body parts are
those the names of which begin with "Content-". All other
header fields are generally to be ignored in body parts.
Although they should generally be retained in mail
processing, they may be discarded by gateways if necessary.
Such other fields are permitted to appear in body parts but
should not be depended on. "X-" fields may be created for
experimental or private purposes, with the recognition that
the information they contain may be lost at some gateways.
実際にRFC822メッセージであるので解釈されるために、身体の部分はありません。 初めに、ヘッダーフィールドは全く実際に身体の部分で必要ではありません。 したがって空白行から始まる身体の部分は、許容されていて、想定されるすべてのデフォルト値がことである身体の部分です。 このような場合には、コンテントタイプヘッダーフィールドの欠如は、カプセル化が明瞭な米国-ASCIIテキストであることを含意します。 身体の部分と意味を定義した唯一のヘッダーフィールドがそれの名前が「内容」で始まるそれらです。 他のすべてのヘッダーフィールドは一般に、身体の部分で無視されることです。 メール処理で一般に保有されるべきですが、必要なら、それらはゲートウェイによって捨てられるかもしれません。 よるべきでないのを除いて、身体の部分で見える他の分野が許可されているそのようなもの。 「X」分野は実験的であるか個人的な目的のために作成されるかもしれません、それらが含む情報が数門で失われるかもしれないという認識で。
The distinction between an RFC 822 message and a body part
is subtle, but important. A gateway between Internet and
X.400 mail, for example, must be able to tell the difference
between a body part that contains an image and a body part
that contains an encapsulated message, the body of which is
an image. In order to represent the latter, the body part
must have "Content-Type: message", and its body (after the
blank line) must be the encapsulated message, with its own
"Content-Type: image" header field. The use of similar
syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which
all parts actually are messages, a "digest" subtype is also
defined.)
RFC822メッセージと身体の部分での区別は、微妙ですが、重要です。 例えば、インターネットとX.400メールの間のゲートウェイはイメージを含む身体の部分と要約のメッセージを含む身体の部分の違いを言うことができなければなりません。そのボディーはイメージです。 後者、部分が持たなければならないボディーを表す、「コンテントタイプ:」 「通信してください」、ボディー(空白行の後の)がそれ自身のものがある要約のメッセージであるに違いない、「コンテントタイプ:」 「イメージ」ヘッダーフィールド。 同様の構文の使用は逆もまた同様にメッセージの変換を身体の部分に容易にしますが、2の区別を作成者に解釈しなければなりません。 (また、すべての部品が実際にメッセージである特別な場合において、「ダイジェスト」「副-タイプ」は定義されます。)
As stated previously, each body part is preceded by an
encapsulation boundary. The encapsulation boundary MUST NOT
appear inside any of the encapsulated parts. Thus, it is
crucial that the composing agent be able to choose and
specify the unique boundary that will separate the parts.
先に述べたとおり、それぞれの身体の部分はカプセル化境界のそばで先行されています。 カプセル化境界は要約の部品のいずれにも現れてはいけません。 したがって、構成しているエージェントが部品を切り離すユニークな境界を選んで、指定できるのは、重要です。
All present and future subtypes of the "multipart" type must
use an identical syntax. Subtypes may differ in their
semantics, and may impose additional restrictions on syntax,
「複合」のタイプのすべての現在の、そして、将来の血液型亜型が同じ構文を使用しなければなりません。 血液型亜型は、それらの意味論において異なって、追加制限を構文に課すかもしれません。
Borenstein & Freed [Page 29]
Borensteinであって解放されています。[29ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
but must conform to the required syntax for the multipart
type. This requirement ensures that all conformant user
agents will at least be able to recognize and separate the
parts of any multipart entity, even of an unrecognized
subtype.
しかし、必須は複合タイプに、必要な構文に従います。 この要件は、すべてのconformantユーザエージェントがどんな複合実体と、認識されていない「副-タイプ」さえの部分も認識して、少なくとも切り離すことができるのを確実にします。
As stated in the definition of the Content-Transfer-Encoding
field, no encoding other than "7bit", "8bit", or "binary" is
permitted for entities of type "multipart". The multipart
delimiters and header fields are always 7-bit ASCII in any
case, and data within the body parts can be encoded on a
part-by-part basis, with Content-Transfer-Encoding fields
for each appropriate body part.
Content転送コード化分野の定義で述べられているように、「7ビット」、「8ビット」、または「バイナリー」以外のコード化は「複合タイプ」の実体のために受入れられません。 どのような場合でも、複合デリミタとヘッダーフィールドはいつも7ビットのASCIIです、そして、部分に従った部分ベースで身体の部分の中のデータはコード化できます、それぞれの適切な身体の部分へのContent転送コード化分野で。
Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly
forbidden for the body part headers embedded in the bodies
of messages of type "multipart."
メール・ゲートウェイ、リレー、および他のメール取り扱いエージェントがRFC822メッセージのトップレベルヘッダーを変更するのが一般的に知られています。 彼らが、頻繁に特に取り外すように言い足す、または、追加注文ヘッダーフィールド。 そのような変更は「複合タイプ」に関するメッセージのボディーを埋め込まれたボディー部分ヘッダーのために明らかに禁じられます。
7.2.1 Multipart: The common syntax
7.2.1 複合: 一般的な構文
All subtypes of "multipart" share a common syntax, defined
in this section. A simple example of a multipart message
also appears in this section. An example of a more complex
multipart message is given in Appendix C.
一般的な構文であって、このセクションで定義された「複合」のシェアのすべての血液型亜型。 また、複合メッセージの簡単な例はこのセクションに現れます。 より複雑な複合メッセージに関する例はAppendix Cで出されます。
The Content-Type field for multipart entities requires one
parameter, "boundary", which is used to specify the
encapsulation boundary. The encapsulation boundary is
defined as a line consisting entirely of two hyphen
characters ("-", decimal code 45) followed by the boundary
parameter value from the Content-Type header field.
複合実体のためのコンテントタイプ分野は1つのパラメタ、カプセル化境界を指定するのに使用される「境界」を必要とします。 カプセル化境界は境界パラメタ価値がコンテントタイプヘッダーフィールドからあとに続いた2つのハイフンキャラクタ(「-」、10進コード45)から完全に成る線と定義されます。
NOTE: The hyphens are for rough compatibility with the
earlier RFC 934 method of message encapsulation, and for
ease of searching for the boundaries in some
implementations. However, it should be noted that multipart
messages are NOT completely compatible with RFC 934
encapsulations; in particular, they do not obey RFC 934
quoting conventions for embedded lines that begin with
hyphens. This mechanism was chosen over the RFC 934
mechanism because the latter causes lines to grow with each
level of quoting. The combination of this growth with the
fact that SMTP implementations sometimes wrap long lines
made the RFC 934 mechanism unsuitable for use in the event
that deeply-nested multipart structuring is ever desired.
以下に注意してください。 ハイフンはメッセージカプセル化の以前のRFC934方法との荒い互換性、およびいくつかの実現における境界を捜し求める容易さのためのものです。 しかしながら、複合メッセージは完全にRFC934カプセル化と互換性があるというわけではないことに注意されるべきです。 特に、彼らはハイフンで始まる埋め込まれた線にRFC934引用コンベンションに従いません。 それぞれのレベルの引用に従って線が後者で発展するので、このメカニズムはRFC934メカニズムに関して選ばれました。 SMTP実現が時々長い線を包装するという事実があるこの成長の組み合わせは深く入れ子にされた複合構造が今までに望まれている場合RFCを使用に、不適当な934メカニズムにしました。
Thus, a typical multipart Content-Type header field might
look like this:
したがって、典型的な複合コンテントタイプヘッダーフィールドはこれに似るかもしれません:
Content-Type: multipart/mixed;
コンテントタイプ: 複合か混ぜられる。
Borenstein & Freed [Page 30]
Borensteinであって解放されています。[30ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
boundary=gc0p4Jq0M2Yt08jU534c0p
境界=gc0p4Jq0M2Yt08jU534c0p
This indicates that the entity consists of several parts,
each itself with a structure that is syntactically identical
to an RFC 822 message, except that the header area might be
completely empty, and that the parts are each preceded by
the line
これは、実体が数個の部品から成るのを示して、ヘッダー領域が完全に人影がないかもしれないのを除いて、シンタクス上RFC822メッセージと同じであり、部品がそれぞれそうである構造があるそれぞれ自体が線のそばで先行しました。
--gc0p4Jq0M2Yt08jU534c0p
--gc0p4Jq0M2Yt08jU534c0p
Note that the encapsulation boundary must occur at the
beginning of a line, i.e., following a CRLF, and that that
initial CRLF is considered to be part of the encapsulation
boundary rather than part of the preceding part. The
boundary must be followed immediately either by another CRLF
and the header fields for the next part, or by two CRLFs, in
which case there are no header fields for the next part (and
it is therefore assumed to be of Content-Type text/plain).
すなわち、CRLFに続いて、カプセル化境界が線の始めに起こらなければならなくて、その初期のCRLFが前の部分の一部よりむしろカプセル化境界の一部であると考えられることに注意してください。 すぐ次の部分への別のCRLFとヘッダーフィールド、または2CRLFsが境界に従わなければなりません、次の部分へのヘッダーフィールドが全くどのケースにないかで(したがって、それがコンテントタイプテキスト/直さいであると思われます)。
NOTE: The CRLF preceding the encapsulation line is
considered part of the boundary so that it is possible to
have a part that does not end with a CRLF (line break).
Body parts that must be considered to end with line breaks,
therefore, should have two CRLFs preceding the encapsulation
line, the first of which is part of the preceding body part,
and the second of which is part of the encapsulation
boundary.
以下に注意してください。 カプセル化線に先行するCRLFが境界の一部であると考えられるので、CRLF(ラインブレイク)と共に終わらない部分を持っているのは可能です。 (2CRLFsをカプセル化線に先行させるはずです)したがって、ラインブレイクで終わると考えなければならない身体の部分。それの1番目は前の身体の部分の一部です。その2番目はそれによるカプセル化境界の一部です。
The requirement that the encapsulation boundary begins with
a CRLF implies that the body of a multipart entity must
itself begin with a CRLF before the first encapsulation line
-- that is, if the "preamble" area is not used, the entity
headers must be followed by TWO CRLFs. This is indeed how
such entities should be composed. A tolerant mail reading
program, however, may interpret a body of type multipart
that begins with an encapsulation line NOT initiated by a
CRLF as also being an encapsulation boundary, but a
compliant mail sending program must not generate such
entities.
境界がCRLFと共に始めるカプセル化自体が、複合実体のボディーがそうしなければならないのを含意するという要件は最初のカプセル化線の前のCRLFと共に始まります--すなわち、「序文」領域が使用されていないなら、TWO CRLFsは実体ヘッダーに続かなければなりません。 本当に、これはそのような実体がどう構成されるべきであるかということです。 しかしながら、許容性があるメール読み込みプログラムはまた、カプセル化台詞があるとしてCRLFが開始されていなくカプセル化境界を始めるタイプ複合のボディーを解釈するかもしれませんが、言いなりになっているメール送付プログラムはそのような実体を発生させてはいけません。
Encapsulation boundaries must not appear within the
encapsulations, and must be no longer than 70 characters,
not counting the two leading hyphens.
カプセル化境界は、70のキャラクタよりカプセル化の中に現れてはいけなくて、もうであるに違いありません、2つの主なハイフンを数えないで。
The encapsulation boundary following the last body part is a
distinguished delimiter that indicates that no further body
parts will follow. Such a delimiter is identical to the
previous delimiters, with the addition of two more hyphens
at the end of the line:
最後の身体の部分に続くカプセル化境界はどんな一層の身体の部分も続かないのを示す顕著なデリミタです。 そのようなデリミタは前のデリミタと同じです、行の終わりのもう2つのハイフンの添加で:
--gc0p4Jq0M2Yt08jU534c0p--
--gc0p4Jq0M2Yt08jU534c0p--
There appears to be room for additional information prior to
the first encapsulation boundary and following the final
最初のカプセル化境界の前の追加情報の余地であり、決勝に続いているのに現れます。
Borenstein & Freed [Page 31]
Borensteinであって解放されています。[31ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
boundary. These areas should generally be left blank, and
implementations should ignore anything that appears before
the first boundary or after the last one.
境界。 一般に、これらの領域は空白のままにされるべきです、そして、実現は最初の境界の前か最後のものの後に現れるものは何でも無視するべきです。
NOTE: These "preamble" and "epilogue" areas are not used
because of the lack of proper typing of these parts and the
lack of clear semantics for handling these areas at
gateways, particularly X.400 gateways.
以下に注意してください。 これらの「序文」と「エピローグ」領域はこれらの部品の適切なタイプの不足とゲートウェイ(特にX.400ゲートウェイ)でこれらの領域を扱うための明確な意味論の不足のために使用されません。
NOTE: Because encapsulation boundaries must not appear in
the body parts being encapsulated, a user agent must
exercise care to choose a unique boundary. The boundary in
the example above could have been the result of an algorithm
designed to produce boundaries with a very low probability
of already existing in the data to be encapsulated without
having to prescan the data. Alternate algorithms might
result in more 'readable' boundaries for a recipient with an
old user agent, but would require more attention to the
possibility that the boundary might appear in the
encapsulated part. The simplest boundary possible is
something like "---", with a closing boundary of "-----".
以下に注意してください。 カプセル化境界を身体の数回に分けて要約される掲載してはいけないので、ユーザエージェントはユニークな境界を選ぶために注意しなければなりません。 上記の例における境界は前スキャンにデータを持っていなくて要約されるためにデータに既に存在するという非常に低い確率で境界を作成するように設計されたアルゴリズムの結果であったかもしれません。 交互のアルゴリズムは、年取ったユーザエージェントと共に受取人のための、より'読み込み可能な'境界をもたらすかもしれませんが、境界が要約の部分に現れるかもしれない可能性に関する、より多くの注意を必要とするでしょう。 「可能な境界がある中で最も簡単なもの」---「終わりの境界、」-----".
As a very simple example, the following multipart message
has two parts, both of them plain text, one of them
explicitly typed and one of them implicitly typed:
非常に簡単な例として、以下の複合メッセージには、2つの部品があって、それらの両方がプレーンテキストです、と明らかにタイプされたそれらの1つと彼らのひとりはそれとなくタイプしました:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple
boundary"
From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッド Freed <ned@innosoft.com 、gt;、Subject: メッセージMIMEバージョンを抽出してください: 1.0文書内容: 複合か混ぜられる。 境界は「簡単な境界」と等しいです。
This is the preamble. It is to be ignored, though it
is a handy place for mail composers to include an
explanatory note to non-MIME compliant readers.
--simple boundary
これは序文です。 それは無視されることになっています、それがメール作曲家が非MIMEの言いなりになっている読者に注記を含む便利な場所ですが。 --簡単な境界
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
これはそれとなくタイプされた明瞭なASCIIテキストです。 それはlinebreakで終わりません。 --簡単な境界文書内容: テキスト/平野。 charsetが私たちと等しい、-、ASCII
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
これは明らかにタイプされた明瞭なASCIIテキストです。 それ、DOESはlinebreakで終わります。
--simple boundary--
This is the epilogue. It is also to be ignored.
--簡単な境界--これはエピローグです。 また、それは無視されることになっています。
The use of a Content-Type of multipart in a body part within
another multipart entity is explicitly allowed. In such
cases, for obvious reasons, care must be taken to ensure
that each nested multipart entity must use a different
boundary delimiter. See Appendix C for an example of nested
別の複合実体の中の身体の部分の複合のコンテントタイプの使用は明らかに許されています。 そのような場合、明白な理由によって、それぞれの入れ子にされた複合実体が異なった境界デリミタを使用しなければならないのを保証するために注意しなければなりません。 入れ子にされることの例に関してAppendix Cを見てください。
Borenstein & Freed [Page 32]
Borensteinであって解放されています。[32ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
multipart entities.
複合実体。
The use of the multipart Content-Type with only a single
body part may be useful in certain contexts, and is
explicitly permitted.
ただ一つの身体の部分だけがある複合コンテントタイプの使用は、ある文脈で役に立つかもしれなくて、明らかに受入れられます。
The only mandatory parameter for the multipart Content-Type
is the boundary parameter, which consists of 1 to 70
characters from a set of characters known to be very robust
through email gateways, and NOT ending with white space.
(If a boundary appears to end with white space, the white
space must be presumed to have been added by a gateway, and
should be deleted.) It is formally specified by the
following BNF:
複合コンテントタイプのための唯一の義務的なパラメタが境界パラメタです。(そのパラメタはメールゲートウェイを通して非常に強健であることが知られて、余白で終わらない1セットのキャラクタからの1〜70のキャラクタから成ります)。 (境界が余白で終わるように見えるなら、余白は、あえてゲートウェイによって加えられたに違いなくて、削除されるべきです。) それは以下のBNFによって正式に指定されます:
boundary := 0*69<bchars> bcharsnospace
境界:=0*69<bchars>bcharsnospace
bchars := bcharsnospace / " "
bchars:=bcharsnospace/、「」
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
「bcharsnospace:=DIGIT/アルファー/、「'「」 /「」 (「/」)/「+」/"_"/」、/「-」/」。」' / "/" / ":" / "=" / "?"
Overall, the body of a multipart entity may be specified as
follows:
全体的に見て、複合実体のボディーは以下の通り指定されるかもしれません:
multipart-body := preamble 1*encapsulation
close-delimiter epilogue
複合ボディー:=序文1*カプセル化近いデリミタエピローグ
encapsulation := delimiter CRLF body-part
カプセル化:=デリミタCRLF身体部分
delimiter := CRLF "--" boundary ; taken from Content-Type
field.
; when content-type is
multipart
; There must be no space
; between "--" and boundary.
デリミタ:=CRLF「--」境界。 コンテントタイプ分野から、取ります。 ; 満足しているタイプが複合であるときに。 スペースが全くあるはずがありません。 「--」と境界の間で。
close-delimiter := delimiter "--" ; Again, no space before
"--"
近いデリミタ:=デリミタ「--」。 再び「--」の前のスペースがありません。
preamble := *text ; to be ignored upon
receipt.
序文:=*テキスト。 領収書で無視されるために。
epilogue := *text ; to be ignored upon
receipt.
エピローグ:=*テキスト。 領収書で無視されるために。
body-part = <"message" as defined in RFC 822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere. Note that the
身体部分はどこでもそれ自体で線かサブストリングメッセージ本体で何処にも現れない指定されたデリミタ、または、として任意のすべてのヘッダーフィールドでRFC822で定義されるように<「メッセージ」と等しいです。 それに注意してください。
Borenstein & Freed [Page 33]
Borensteinであって解放されています。[33ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
semantics of a part differ from the semantics
of a message, as described in the text.>
部分の意味論は. テキスト>で説明されるようにメッセージの意味論と異なっています。
NOTE: Conspicuously missing from the multipart type is a
notion of structured, related body parts. In general, it
seems premature to try to standardize interpart structure
yet. It is recommended that those wishing to provide a more
structured or integrated multipart messaging facility should
define a subtype of multipart that is syntactically
identical, but that always expects the inclusion of a
distinguished part that can be used to specify the structure
and integration of the other parts, probably referring to
them by their Content-ID field. If this approach is used,
other implementations will not recognize the new subtype,
but will treat it as the primary subtype (multipart/mixed)
and will thus be able to show the user the parts that are
recognized.
以下に注意してください。 複合タイプから著しく消えるのは、構造化されて、関連する身体の部分の概念です。 一般に、まだinterpart構造を標準化しようとするのは時期尚早に思えます。 さらに構造化されたか、統合している複合メッセージング施設を提供したがっている人がシンタクス上同じですが、いつも使用できる顕著な部分の包含が他の部品の構造と統合を指定すると予想する複合の「副-タイプ」を定義するのは、お勧めです、たぶんそれらのコンテントID分野のそばでそれらについて言及して。 このアプローチが使用されていると、他の実現は新しい「副-タイプ」を認識しないでしょう、第一の「副-タイプ」としてそれを扱って(複合の、または、混ぜられた)、その結果、認識される部品はユーザに見せることができるでしょう。
7.2.2 The Multipart/mixed (primary) subtype
7.2.2 Multipart/混ぜられた(第一の)「副-タイプ」
The primary subtype for multipart, "mixed", is intended for
use when the body parts are independent and intended to be
displayed serially. Any multipart subtypes that an
implementation does not recognize should be treated as being
of subtype "mixed".
予備選挙が副タイプする、複合です、「混入」は、身体の部分が独立しているとき、使用のために意図して、順次表示されることを意図します。 「副-タイプ」の存在が「混入した」ので、実現が認識しないどんな複合血液型亜型も扱われるべきです。
7.2.3 The Multipart/alternative subtype
7.2.3 Multipart/代替手段「副-タイプ」
The multipart/alternative type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, each of the parts is an "alternative" version of
the same information. User agents should recognize that the
content of the various parts are interchangeable. The user
agent should either choose the "best" type based on the
user's environment and preferences, or offer the user the
available alternatives. In general, choosing the best type
means displaying only the LAST part that can be displayed.
This may be used, for example, to send mail in a fancy text
format in such a way that it can easily be displayed
anywhere:
複合の、または、代替のタイプはシンタクス上複合か混ぜられるのと同じですが、意味論は異なっています。 それぞれの部品は特に、同じ情報の「代替」のバージョンです。 ユーザエージェントは、様々な部分の内容が交換可能であると認めるべきです。 ユーザエージェントは、ユーザの環境と好みに基づく「最も良い」タイプを選ぶべきであるか、または利用可能な代替手段をユーザに提供するべきです。 一般に、最も良いタイプを選ぶのは、表示できるLAST部分だけを表示することを意味します。 例えば、これは容易にどこでもそれを表示できるような方法でメールを高級テキスト形式で送るのに使用されるかもしれません:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッド Freed <ned@innosoft.com 、gt;、Subject: フォーマット済みのテキストメールMIMEバージョン: 1.0コンテントタイプ: 複合/代替手段。 境界=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
--boundary42コンテントタイプ: テキスト/平野。 charsetが私たちと等しい、-、ASCII
...plain text version of message goes here....
...メッセージのプレーンテキストバージョンはここに行きます…
Borenstein & Freed [Page 34]
Borensteinであって解放されています。[34ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
--boundary42
Content-Type: text/richtext
--boundary42コンテントタイプ: テキスト/richtext
.... richtext version of same message goes here ...
--boundary42
Content-Type: text/x-whatever
… . 同じメッセージのrichtextバージョンはここに行きます… --boundary42コンテントタイプ: すべてのテキスト/x
.... fanciest formatted version of same message goes here
...
--boundary42--
…、同じメッセージの最も高級なフォーマットされたバージョンはここに行きます… --boundary42--
In this example, users whose mail system understood the
"text/x-whatever" format would see only the fancy version,
while other users would see only the richtext or plain text
version, depending on the capabilities of their system.
この例では、メールシステムが「すべてのテキスト/x」形式を理解していたユーザは高級バージョンだけを見るでしょう、他のユーザがrichtextかプレーンテキストバージョンだけを見るでしょうが、それらのシステムの能力によって。
In general, user agents that compose multipart/alternative
entities should place the body parts in increasing order of
preference, that is, with the preferred format last. For
fancy text, the sending user agent should put the plainest
format first and the richest format last. Receiving user
agents should pick and display the last format they are
capable of displaying. In the case where one of the
alternatives is itself of type "multipart" and contains
unrecognized sub-parts, the user agent may choose either to
show that alternative, an earlier alternative, or both.
一般に、複合の、または、代替の実体を構成するユーザエージェントは身体の部分を増加するよく使われる順に置くべきです、すなわち、都合のよい形式最終で。 高級テキストのために、送付ユーザエージェントは1番目の、そして、最も豊かな形式が持続する中で最も明瞭な書式を置くべきです。 ユーザエージェントを受けるのは、彼らが表示できる最後の書式を選んで、表示するべきです。 代替手段の1つがタイプ「複合」がそれ自体であって、認識されていないサブの部品を含む場合では、ユーザエージェントは、その代替手段、以前の代替手段、または両方を示すのを選ぶかもしれません。
NOTE: From an implementor's perspective, it might seem more
sensible to reverse this ordering, and have the plainest
alternative last. However, placing the plainest alternative
first is the friendliest possible option when
mutlipart/alternative entities are viewed using a non-MIME-
compliant mail reader. While this approach does impose some
burden on compliant mail readers, interoperability with
older mail readers was deemed to be more important in this
case.
以下に注意してください。 作成者の見解から、この注文を逆にして、最後に最も明瞭な代替手段を持っているのは、より分別があるように思えるかもしれません。 しかしながら、mutlipart/代替手段実体がaを使用することで見られるとき、最初に最も明瞭な代替手段を置くのが、可能な限り好意的なオプションである、非、-、MIME対応することのメール読者。 このアプローチが言いなりになっているメール読者に何らかの負担を課している間、より年取ったメール読者がいる相互運用性がこの場合より重要であると考えられました。
It may be the case that some user agents, if they can
recognize more than one of the formats, will prefer to offer
the user the choice of which format to view. This makes
sense, for example, if mail includes both a nicely-formatted
image version and an easily-edited text version. What is
most critical, however, is that the user not automatically
be shown multiple versions of the same data. Either the
user should be shown the last recognized version or should
explicitly be given the choice.
彼らが形式の1つ以上を認識できると何人かのユーザエージェントが、選択をどの形式を見るかをユーザに提供するのを好むのは、事実であるかもしれません。 例えば、メールがうまくフォーマットされたイメージバージョンと容易に編集されたテキストバージョンの両方を含んでいるなら、これは理解できます。 しかしながら、最も批判的なことは同じデータの複数のバージョンが自動的にユーザに示されないということです。 ユーザに最後に認識されたバージョンを示すべきであるか、または明らかに選択を与えるべきです。
Borenstein & Freed [Page 35]
Borensteinであって解放されています。[35ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
7.2.4 The Multipart/digest subtype
7.2.4 Multipart/ダイジェスト「副-タイプ」
This document defines a "digest" subtype of the multipart
Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, in a digest, the default Content-Type value for
a body part is changed from "text/plain" to
"message/rfc822". This is done to allow a more readable
digest format that is largely compatible (except for the
quoting convention) with RFC 934.
このドキュメントは複合コンテントタイプの「ダイジェスト」「副-タイプ」を定義します。 このタイプはシンタクス上複合か混ぜられるのと同じですが、意味論は異なっています。 ダイジェストでは、特に、身体の部分へのデフォルトコンテントタイプ価値は「テキスト/平野」から「メッセージ/rfc822」に変わります。 RFC934と主に互換性がある(引用コンベンションを除いた)より読み込み可能なダイジェスト形式を許容するためにこれをします。
A digest in this format might, then, look something like
this:
次に、この形式のダイジェストはこのように見えるかもしれません:
From: Moderator-Address
MIME-Version: 1.0
Subject: Internet Digest, volume 42
Content-Type: multipart/digest;
boundary="---- next message ----"
From: 議長アドレスMIMEバージョン: 1.0 Subject: インターネットDigest、第42巻のコンテントタイプ: 複合/ダイジェスト。 「境界=」---- 次のメッセージ----"
------ next message ----
------ 次のメッセージ----
From: someone-else
Subject: my opinion
From: 他の誰か、Subject: 私の意見
...body goes here ...
...ボディーはここに行きます…
------ next message ----
------ 次のメッセージ----
From: someone-else-again
Subject: my different opinion
From: だれか、ほか、再び、Subject: 私の異なった意見
... another body goes here...
… 別のボディーはここに行きます…
------ next message ------
------ 次のメッセージ------
7.2.5 The Multipart/parallel subtype
7.2.5 Multipart/平行な「副-タイプ」
This document defines a "parallel" subtype of the multipart
Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, in a parallel entity, all of the parts are
intended to be presented in parallel, i.e., simultaneously,
on hardware and software that are capable of doing so.
Composing agents should be aware that many mail readers will
lack this capability and will show the parts serially in any
event.
このドキュメントは複合コンテントタイプの「平行な」「副-タイプ」を定義します。 このタイプはシンタクス上複合か混ぜられるのと同じですが、意味論は異なっています。 平行な実体では、特に、すなわち、同時に平行に部品のすべてが提示されることを意図します、そうすることができるハードウェアとソフトウェアの上で。 エージェントを構成するのは多くのメール読者がこの能力を欠いて、順次とにかく部品を見せるのを意識しているべきです。
Borenstein & Freed [Page 36]
Borensteinであって解放されています。[36ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
7.3 The Message Content-Type
7.3 メッセージコンテントタイプ
It is frequently desirable, in sending mail, to encapsulate
another mail message. For this common operation, a special
Content-Type, "message", is defined. The primary subtype,
message/rfc822, has no required parameters in the Content-
Type field. Additional subtypes, "partial" and "External-
body", do have required parameters. These subtypes are
explained below.
それは、別のメール・メッセージを要約するために送付メールで頻繁に望ましいです。 この一般的な操作において、「メッセージ」という特別なコンテントタイプは定義されます。 第一の「副-タイプ」(メッセージ/rfc822)はContentタイプ分野にどんな必要なパラメタも持っていません。 追加血液型亜型、「部分的」、そして、および「外部のボディー」には、必要なパラメタがあります。 これらの血液型亜型は以下で説明されます。
NOTE: It has been suggested that subtypes of message might
be defined for forwarded or rejected messages. However,
forwarded and rejected messages can be handled as multipart
messages in which the first part contains any control or
descriptive information, and a second part, of type
message/rfc822, is the forwarded or rejected message.
Composing rejection and forwarding messages in this manner
will preserve the type information on the original message
and allow it to be correctly presented to the recipient, and
hence is strongly encouraged.
以下に注意してください。 メッセージの血液型亜型が進められたか拒絶されたメッセージのために定義されるかもしれないことが提案されました。 しかしながら、最初の部分がどんなコントロールや記述的な情報も含む複合メッセージ、およびタイプメッセージ/rfc822の第二部が進められたか拒絶されたメッセージであるので、進められて拒絶されたメッセージを扱うことができます。 拒絶を構成して、メッセージを転送するのは、この様にオリジナルのメッセージのタイプ情報を保存して、それが正しく受取人に提示されるのを許容して、したがって、強く奨励されます。
As stated in the definition of the Content-Transfer-Encoding
field, no encoding other than "7bit", "8bit", or "binary" is
permitted for messages or parts of type "message". The
message header fields are always US-ASCII in any case, and
data within the body can still be encoded, in which case the
Content-Transfer-Encoding header field in the encapsulated
message will reflect this. Non-ASCII text in the headers of
an encapsulated message can be specified using the
mechanisms described in [RFC-1342].
Content転送コード化分野の定義で述べられているように、「7ビット」、「8ビット」、または「バイナリー」以外のコード化はメッセージかタイプ「メッセージ」の部品に受入れられません。 どのような場合でも、いつもメッセージヘッダーフィールドは米国-ASCIIです、そして、まだボディーの中のデータをコード化できます、そして、その場合、要約のメッセージのContent転送コード化ヘッダーフィールドはこれを反映するでしょう。 [RFC-1342]で説明されたメカニズムを使用することで要約のメッセージのヘッダーの非ASCIIテキストを指定できます。
Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly
forbidden for the encapsulated headers embedded in the
bodies of messages of type "message."
メール・ゲートウェイ、リレー、および他のメール取り扱いエージェントがRFC822メッセージのトップレベルヘッダーを変更するのが一般的に知られています。 彼らが、頻繁に特に取り外すように言い足す、または、追加注文ヘッダーフィールド。 そのような変更はタイプ「メッセージ」に関するメッセージのボディーを埋め込まれた要約のヘッダーのために明らかに禁じられます。
7.3.1 The Message/rfc822 (primary) subtype
7.3.1 Message/rfc822の(第一)の「副-タイプ」
A Content-Type of "message/rfc822" indicates that the body
contains an encapsulated message, with the syntax of an RFC
822 message.
「メッセージ/rfc822」のコンテントタイプは、ボディーが要約のメッセージを含むのをRFC822メッセージの構文で示します。
7.3.2 The Message/Partial subtype
7.3.2 Message/部分的な「副-タイプ」
A subtype of message, "partial", is defined in order to
allow large objects to be delivered as several separate
pieces of mail and automatically reassembled by the
receiving user agent. (The concept is similar to IP
fragmentation/reassembly in the basic Internet Protocols.)
This mechanism can be used when intermediate transport
agents limit the size of individual messages that can be
sent. Content-Type "message/partial" thus indicates that
メッセージの「部分的な」「副-タイプ」は、大きい物が数個の別々のメールとして届けられて、受信ユーザエージェントによって自動的に組み立て直されるのを許容するために定義されます。 (概念は基本的なインターネットプロトコルにおいてIP断片化/再アセンブリと同様です。) 中間的輸送エージェントが送ることができる個々のメッセージのサイズを制限するとき、このメカニズムを使用できます。 コンテントタイプ、「メッセージ/部分的である」、その結果、それを示します。
Borenstein & Freed [Page 37]
Borensteinであって解放されています。[37ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
the body contains a fragment of a larger message.
ボディーは、より大きいメッセージの断片を含みます。
Three parameters must be specified in the Content-Type field
of type message/partial: The first, "id", is a unique
identifier, as close to a world-unique identifier as
possible, to be used to match the parts together. (In
general, the identifier is essentially a message-id; if
placed in double quotes, it can be any message-id, in
accordance with the BNF for "parameter" given earlier in
this specification.) The second, "number", an integer, is
the part number, which indicates where this part fits into
the sequence of fragments. The third, "total", another
integer, is the total number of parts. This third subfield
is required on the final part, and is optional on the
earlier parts. Note also that these parameters may be given
in any order.
タイプメッセージ/部分的のコンテントタイプ分野で3つのパラメタを指定しなければなりません: 「イド」という1番目は、可能であるとしての世界ユニークな識別子の近くように部品を一緒に合わせるのに使用されるためにはユニークな識別子です。 (一般に、識別子は本質的にはメッセージイドです; 二重引用符に置かれるなら、それはどんなメッセージイドであるかもしれません、より早くこの仕様で与えられた「パラメタ」のためのBNFによると。) 2番目(「数」、整数)は部品番号です。(その部品番号は、この部分がどこに断片の系列に収まるかを示します)。 3(「合計」、別の整数)番目は部品の総数です。 この3番目の部分体は、最終部分の上で必要であり、以前の部分で任意です。 また、これらのパラメタが順不同に与えられるかもしれないことに注意してください。
Thus, part 2 of a 3-part message may have either of the
following header fields:
したがって、3部分のメッセージの第2部には、以下のヘッダーフィールドのどちらかがあるかもしれません:
Content-Type: Message/Partial;
number=2; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
コンテントタイプ: メッセージ/部分的。 数=2。 =3を合計してください。 イドは「ocは jpbe0M2Yt4s@thumper.bellcore.com と等しいこと」と等しいです。
Content-Type: Message/Partial;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2
コンテントタイプ: メッセージ/部分的。 イドは「ocは jpbe0M2Yt4s@thumper.bellcore.com と等しいこと」と等しいです。 数=2
But part 3 MUST specify the total number of parts:
しかし、パート3は部品の総数を指定しなければなりません:
Content-Type: Message/Partial;
number=3; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
コンテントタイプ: メッセージ/部分的。 数=3。 =3を合計してください。 イドは「ocは jpbe0M2Yt4s@thumper.bellcore.com と等しいこと」と等しいです。
Note that part numbering begins with 1, not 0.
0ではなく付番が1で始めるその部分に注意してください。
When the parts of a message broken up in this manner are put
together, the result is a complete RFC 822 format message,
which may have its own Content-Type header field, and thus
may contain any other data type.
終えられたメッセージの部分がこの様にまとめられるとき、結果は完全なRFC822形式メッセージです。(そのメッセージは、それ自身のコンテントタイプヘッダーフィールドを持って、その結果、いかなる他のデータ型も含むかもしれません)。
Message fragmentation and reassembly: The semantics of a
reassembled partial message must be those of the "inner"
message, rather than of a message containing the inner
message. This makes it possible, for example, to send a
large audio message as several partial messages, and still
have it appear to the recipient as a simple audio message
rather than as an encapsulated message containing an audio
message. That is, the encapsulation of the message is
considered to be "transparent".
メッセージ断片化と再アセンブリ: 組み立て直された部分的なメッセージの意味論はメッセージが内側のメッセージを含むのについてというよりむしろ「内側」のメッセージのものであるに違いありません。 これで、いくつかの部分的なメッセージとして大きいオーディオメッセージを送って、受取人にとってまだ現れさせているのはオーディオメッセージを含む要約のメッセージとしてというよりむしろ簡単なオーディオメッセージとして例えば、可能になります。 すなわち、メッセージのカプセル化が「透明である」と考えられます。
When generating and reassembling the parts of a
message/partial message, the headers of the encapsulated
message must be merged with the headers of the enclosing
メッセージ/部分的なメッセージの部分を発生して、組み立て直すとき、要約のメッセージのヘッダーを同封のヘッダーに合併しなければなりません。
Borenstein & Freed [Page 38]
Borensteinであって解放されています。[38ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
entities. In this process the following rules must be
observed:
実体。 この過程で、以下の規則を守らなければなりません:
(1) All of the headers from the initial enclosing
entity (part one), except those that start with
"Content-" and "Message-ID", must be copied, in
order, to the new message.
(1) 「内容」と「Message ID」から始めるもの以外の初期の同封実体(パート1)からのヘッダーのすべてをコピーしなければなりません、オーダーで、新しいメッセージに。
(2) Only those headers in the enclosed message
which start with "Content-" and "Message-ID" must
be appended, in order, to the headers of the new
message. Any headers in the enclosed message
which do not start with "Content-" (except for
"Message-ID") will be ignored.
(2) オーダーでどれが「内容」と「Message ID」から始めるか新しいメッセージのヘッダーに追加しなければならないという同封のメッセージのそれらのヘッダーだけ。 どれが「内容」(「Message ID」を除いた)から始めないかが無視されるという同封のメッセージのどんなヘッダー。
(3) All of the headers from the second and any
subsequent messages will be ignored.
(3) 2番目からのヘッダーとどんなその後のメッセージのすべても無視されるでしょう。
For example, if an audio message is broken into two parts,
the first part might look something like this:
例えば、2つの部品がオーディオメッセージに細かく分けられるなら、最初の部分はこのように見えるかもしれません:
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
Message-ID: id1@host.com
MIME-Version: 1.0
Content-type: message/partial;
id="ABC@host.com";
number=1; total=2
X奇妙なヘッダー1: Foo From: Bill@host.com To: joe@otherhost.com Subject: オーディオメールMessage-ID: id1@host.com MIMEバージョン: 1.0文書内容: メッセージ/部分的。 イドは" ABC@host.com "と等しいです。 数=1。 =2を合計してください。
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID: anotherid@foo.com
Content-type: audio/basic
Content-transfer-encoding: base64
X奇妙なヘッダー1: X奇妙なヘッダー2を禁じてください: こんにちは、Message ID: anotherid@foo.com 文書内容: 基本的なContent転送オーディオ/コード化: base64
... first half of encoded audio data goes here...
… コード化されたオーディオデータの前半はここへ去ります…
and the second half might look something like this:
そして、後半は何かこのようなものに見えるかもしれません:
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
MIME-Version: 1.0
Message-ID: id2@host.com
Content-type: message/partial;
id="ABC@host.com"; number=2; total=2
From: Bill@host.com To: joe@otherhost.com Subject: オーディオメールMIMEバージョン: 1.0Message ID: id2@host.com 文書内容: メッセージ/部分的。 イドは" ABC@host.com "と等しいです。 数=2。 =2を合計してください。
... second half of encoded audio data goes here...
… コード化されたオーディオデータの後半はここへ去ります…
Then, when the fragmented message is reassembled, the
resulting message to be displayed to the user should look
something like this:
次に、断片化しているメッセージが組み立て直されるとき、ユーザに表示されるべき結果として起こるメッセージはこのように見えるべきです:
Borenstein & Freed [Page 39]
Borensteinであって解放されています。[39ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
Message-ID: anotherid@foo.com
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
X奇妙なヘッダー1: Foo From: Bill@host.com To: joe@otherhost.com Subject: オーディオメールMessage-ID: anotherid@foo.com MIMEバージョン: 1.0文書内容: 基本的なContent転送オーディオ/コード化: base64
... first half of encoded audio data goes here...
... second half of encoded audio data goes here...
… コード化されたオーディオデータの前半はここへ去ります… … コード化されたオーディオデータの後半はここへ去ります…
It should be noted that, because some message transfer
agents may choose to automatically fragment large messages,
and because such agents may use different fragmentation
thresholds, it is possible that the pieces of a partial
message, upon reassembly, may prove themselves to comprise a
partial message. This is explicitly permitted.
いくつかのメッセージ転送エージェントが、自動的に大きいメッセージを断片化するのを選ぶかもしれなくて、そのようなエージェントが異なった断片化敷居を使用するかもしれないので部分的なメッセージの断片が、再アセンブリで自分たちが部分的なメッセージを包括すると立証するのが、可能であることに注意されるべきです。 これは明らかに受入れられます。
It should also be noted that the inclusion of a "References"
field in the headers of the second and subsequent pieces of
a fragmented message that references the Message-Id on the
previous piece may be of benefit to mail readers that
understand and track references. However, the generation of
such "References" fields is entirely optional.
また、2番目のヘッダーでの「参照」分野の包含と前の断片のMessage-イドがそうする参照がそれを読者に郵送するのに有益であるという断片化しているメッセージのその後の断片が参照を理解して、追跡することに注意されるべきです。 しかしながら、そのような「参照」分野の世代は完全に任意です。
7.3.3 The Message/External-Body subtype
7.3.3 外部のMessage/ボディー「副-タイプ」
The external-body subtype indicates that the actual body
data are not included, but merely referenced. In this case,
the parameters describe a mechanism for accessing the
external data.
外部のボディー「副-タイプ」は、実際のボディーデータが含まれていませんが、単に参照をつけられるのを示します。 この場合、パラメタは、外部のデータにアクセスするためにメカニズムについて説明します。
When a message body or body part is of type
"message/external-body", it consists of a header, two
consecutive CRLFs, and the message header for the
encapsulated message. If another pair of consecutive CRLFs
appears, this of course ends the message header for the
encapsulated message. However, since the encapsulated
message's body is itself external, it does NOT appear in the
area that follows. For example, consider the following
message:
タイプにはメッセージ本体か身体の部分があるとき、「外部のメッセージ/ボディー」であり、それは要約のメッセージのためのヘッダー、2連続したCRLFs、およびメッセージヘッダーから成ります。 連続したCRLFsのもう1組が現れるなら、これはもちろん要約のメッセージのためのメッセージヘッダーを終わらせます。 しかしながら、要約のメッセージのボディーがそれ自体で外部であるので、その領域では、それが続くように見えません。 例えば、以下のメッセージを考えてください:
Content-type: message/external-body; access-
type=local-file;
name=/u/nsb/Me.gif
文書内容: 外部のメッセージ/ボディー。 アクセス=ローカルファイルをタイプしてください。 名前=/u/nsb/Me.gif
Content-type: image/gif
文書内容: イメージ/gif
THIS IS NOT REALLY THE BODY!
これが本当にそうでない、ボディー!
The area at the end, which might be called the "phantom
body", is ignored for most external-body messages. However,
it may be used to contain auxilliary information for some
終わりの領域はほとんどの外部のボディーメッセージのために無視されます。(終わりは「幻影のボディー」と呼ばれるかもしれません)。 しかしながら、それは、いくつかのためのauxilliary情報を含むのに使用されるかもしれません。
Borenstein & Freed [Page 40]
Borensteinであって解放されています。[40ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
such messages, as indeed it is when the access-type is
"mail-server". Of the access-types defined by this
document, the phantom body is used only when the access-type
is "mail-server". In all other cases, the phantom body is
ignored.
本当にアクセス型が「メールサーバ」である時であるときにそのようなメッセージ。 このドキュメントによって定義されたアクセス型では、アクセス型が「メールサーバ」であるときにだけ、幻影のボディーは使用されています。 他のすべての場合では、幻影のボディーは無視されます。
The only always-mandatory parameter for message/external-
body is "access-type"; all of the other parameters may be
mandatory or optional depending on the value of access-type.
メッセージ/外部のボディーのための唯一のいつも義務的なパラメタが「アクセス型」です。 他のパラメタのすべてはアクセス型の値への義務的であるか任意の依存であるかもしれません。
ACCESS-TYPE -- One or more case-insensitive words,
comma-separated, indicating supported access
mechanisms by which the file or data may be
obtained. Values include, but are not limited to,
"FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE",
and "MAIL-SERVER". Future values, except for
experimental values beginning with "X-", must be
registered with IANA, as described in Appendix F .
ACCESS-TYPE--1つ以上の大文字と小文字を区別しない単語、コンマによって切り離されます、表示はファイルかデータが入手されるかもしれないアクセス機構をサポートしました。 含んでいますが、値が制限されない、「FTP」、「やがて、-、FTP、」、"TFTP"、「AFS」、「ローカルファイル」、および「メールサーバ。」 「X」と共に始まる実験値を除いて、付録Fで説明されるようにIANAに将来価値を登録しなければなりません。
In addition, the following two parameters are optional for
ALL access-types:
さらに、すべてのアクセス型には、以下の2つのパラメタが任意です:
EXPIRATION -- The date (in the RFC 822 "date-time"
syntax, as extended by RFC 1123 to permit 4 digits
in the date field) after which the existence of
the external data is not guaranteed.
EXPIRATION--外部のデータの存在が保証されない日付(RFC822「日付-時間」構文年月日欄の4ケタを可能にするためにRFC1123によって広げられるように)。
SIZE -- The size (in octets) of the data. The
intent of this parameter is to help the recipient
decide whether or not to expend the necessary
resources to retrieve the external data.
SIZE--データのサイズ(八重奏における)。 このパラメタの意図は受取人が、外部のデータを検索するために必要なリソースを費やすかどうか決めるのを助けることです。
PERMISSION -- A field that indicates whether or
not it is expected that clients might also attempt
to overwrite the data. By default, or if
permission is "read", the assumption is that they
are not, and that if the data is retrieved once,
it is never needed again. If PERMISSION is "read-
write", this assumption is invalid, and any local
copy must be considered no more than a cache.
"Read" and "Read-write" are the only defined
values of permission.
PERMISSION--また、クライアントが、データを上書きするのを試みるかもしれないと予想されるかどうかを示す分野。 デフォルトでか許可が「読んでください」であるなら、仮定はそれらがそうでなく、またデータが一度検索されるなら、それは二度と必要でないということです。 PERMISSIONが「読まれて、書いてください」であるなら、この仮定は無効です、そして、キャッシュだけであるとどんな地方のコピーも考えなければなりません。 「読んでください」と「-読まれて、書いてください」は許可の唯一の定義された値です。
The precise semantics of the access-types defined here are
described in the sections that follow.
ここで定義されたアクセス型の正確な意味論は従うセクションで説明されます。
7.3.3.1 The "ftp" and "tftp" access-types
7.3.3.1 "ftp"と"tftp"アクセス型
An access-type of FTP or TFTP indicates that the message
body is accessible as a file using the FTP [RFC-959] or TFTP
[RFC-783] protocols, respectively. For these access-types,
the following additional parameters are mandatory:
FTPかTFTPのアクセス型は、メッセージ本体がファイルとしてそれぞれFTP[RFC-959]かTFTP[RFC-783]プロトコルを使用するのにおいてアクセスしやすいのを示します。 これらのアクセス型にとって、以下の追加パラメタは義務的です:
Borenstein & Freed [Page 41]
Borensteinであって解放されています。[41ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
NAME -- The name of the file that contains the
actual body data.
NAME--実際のボディーデータを含むファイルの名前。
SITE -- A machine from which the file may be
obtained, using the given protocol
SITE--与えられたプロトコルを使用して、ファイルが入手されるかもしれないマシン
Before the data is retrieved, using these protocols, the
user will generally need to be asked to provide a login id
and a password for the machine named by the site parameter.
これらのプロトコルを使用して、データが検索される前に、一般に、ユーザは、サイトパラメタによって指定されたマシンのためのログインイドとパスワードを提供するように頼まれる必要があるでしょう。
In addition, the following optional parameters may also
appear when the access-type is FTP or ANON-FTP:
また、さらに、アクセス型がFTPかANON-FTPであるときに、以下の任意のパラメタは現れるかもしれません:
DIRECTORY -- A directory from which the data named
by NAME should be retrieved.
ディレクトリ--NAMEによって指定されたデータが検索されるべきであるディレクトリ。
MODE -- A transfer mode for retrieving the
information, e.g. "image".
MODE--情報を検索するための転送モード、例えば、「イメージ。」
7.3.3.2 The "anon-ftp" access-type
7.3.3.2 「やがて、ftpな」アクセス型
The "anon-ftp" access-type is identical to the "ftp" access
type, except that the user need not be asked to provide a
name and password for the specified site. Instead, the ftp
protocol will be used with login "anonymous" and a password
that corresponds to the user's email address.
"ftp"アクセス型にとって、「やがて、ftpな」アクセス型は同じです、ユーザが指定されたサイトのための名前とパスワードを提供するように頼まれる必要はないのを除いて。 代わりに、ftpプロトコルは、ログインが「匿名」で使用されていてユーザのEメールアドレスに対応するパスワードになるでしょう。
7.3.3.3 The "local-file" and "afs" access-types
7.3.3.3 「ローカルファイル」と"afs"アクセス型
An access-type of "local-file" indicates that the actual
body is accessible as a file on the local machine. An
access-type of "afs" indicates that the file is accessible
via the global AFS file system. In both cases, only a
single parameter is required:
「ローカルファイル」のアクセス型は、実際のボディーが地方のマシンのファイルとしてアクセスしやすいのを示します。 "afs"のアクセス型は、ファイルがグローバルなAFSファイルシステムでアクセス可能であることを示します。 ただ一つのパラメタだけが必要です:
NAME -- The name of the file that contains the
actual body data.
NAME--実際のボディーデータを含むファイルの名前。
The following optional parameter may be used to describe the
locality of reference for the data, that is, the site or
sites at which the file is expected to be visible:
以下の任意のパラメタはすなわち、ファイルが目に見えると予想されるデータの参照の場所、サイトまたはサイトについて説明するのに使用されるかもしれません:
SITE -- A domain specifier for a machine or set of
machines that are known to have access to the data
file. Asterisks may be used for wildcard matching
to a part of a domain name, such as
"*.bellcore.com", to indicate a set of machines on
which the data should be directly visible, while a
single asterisk may be used to indicate a file
that is expected to be universally available,
e.g., via a global file system.
SITE--データファイルに近づく手段を持っているのが知られているマシンのマシンかセットのためのドメイン特許説明書の作成書。 ただ一つのアスタリスクをゆったり過ごします。「アスタリスクはワイルドカードマッチングにドメイン名の一部まで使用されるかもしれません、」 *.bellcore.comなどのように」一般に利用可能であると予想されるファイルを示すのに使用されるかもしれません、データが直接目に見えるべきである1セットのマシンを示してください、そして、例えば、グローバルなファイルシステムで。
7.3.3.4 The "mail-server" access-type
7.3.3.4 「メールサーバ」アクセス型
Borenstein & Freed [Page 42]
Borensteinであって解放されています。[42ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
The "mail-server" access-type indicates that the actual body
is available from a mail server. The mandatory parameter
for this access-type is:
「メールサーバ」アクセス型は、実際のボディーがメールサーバから利用可能であることを示します。このアクセス型にとって、義務的なパラメタは以下の通りです。
SERVER -- The email address of the mail server
from which the actual body data can be obtained.
SERVER--実際のボディーデータを得ることができるメールサーバのEメールアドレス。
Because mail servers accept a variety of syntax, some of
which is multiline, the full command to be sent to a mail
server is not included as a parameter on the content-type
line. Instead, it may be provided as the "phantom body"
when the content-type is message/external-body and the
access-type is mail-server.
メールサーバがさまざまな構文(それのいくつかがマルチラインである)を受け入れるので、メールサーバに送られるべき完全なコマンドはcontent type系列に関するパラメタとして含まれていません。 content typeが外部のメッセージ/ボディーであり、アクセス型がメールサーバであるときに、代わりに、「幻影のボディー」としてそれを提供するかもしれません。
Note that MIME does not define a mail server syntax.
Rather, it allows the inclusion of arbitrary mail server
commands in the phantom body. Implementations should
include the phantom body in the body of the message it sends
to the mail server address to retrieve the relevant data.
MIMEがメールサーバ構文を定義しないことに注意してください。 むしろ、それは幻影のボディーでの任意のメールサーバコマンドの包含を許容します。 実装はそれが関連データを検索するためにメールサーバアドレスに送るメッセージ欄に幻影のボディーを含むべきです。
Borenstein & Freed [Page 43]
Borensteinであって解放されています。[43ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
7.3.3.5 Examples and Further Explanations
7.3.3.5 例とさらなる説明
With the emerging possibility of very wide-area file
systems, it becomes very hard to know in advance the set of
machines where a file will and will not be accessible
directly from the file system. Therefore it may make sense
to provide both a file name, to be tried directly, and the
name of one or more sites from which the file is known to be
accessible. An implementation can try to retrieve remote
files using FTP or any other protocol, using anonymous file
retrieval or prompting the user for the necessary name and
password. If an external body is accessible via multiple
mechanisms, the sender may include multiple parts of type
message/external-body within an entity of type
multipart/alternative.
非常に広い領域のファイルシステムの現れている可能性によると、あらかじめファイルがアクセス可能であり、直接ファイルシステムからアクセス可能にならないマシンのセットを知るのは非常に困難になります。 したがって、それはファイル名を両方に提供している、直接試みられるべき意味、およびファイルがアクセスしやすいのが知られている1つ以上のサイトの名前になるかもしれません。 実装はFTPかいかなる他のプロトコルも使用することでリモートファイルを取ろうとすることができます、必要な名前とパスワードのために匿名のファイル検索を使用するか、またはユーザをうながして。 外部のボディーが複数のメカニズムでアクセスしやすいなら、送付者は複合である、または代替でタイプの実体の中の外部のメッセージ/ボディーのタイプの複数の部分を入れるかもしれません。
However, the external-body mechanism is not intended to be
limited to file retrieval, as shown by the mail-server
access-type. Beyond this, one can imagine, for example,
using a video server for external references to video clips.
しかしながら、メールサーバアクセス型によって示されるように検索をファイルするために外部のボディーメカニズムが制限されることを意図しません。 これを超えて、人は、例えば、外部参照にビデオクリップにビデオ・サーバを使用すると想像できます。
If an entity is of type "message/external-body", then the
body of the entity will contain the header fields of the
encapsulated message. The body itself is to be found in the
external location. This means that if the body of the
"message/external-body" message contains two consecutive
CRLFs, everything after those pairs is NOT part of the
message itself. For most message/external-body messages,
this trailing area must simply be ignored. However, it is a
convenient place for additional data that cannot be included
in the content-type header field. In particular, if the
"access-type" value is "mail-server", then the trailing area
must contain commands to be sent to the mail server at the
address given by NAME@SITE, where NAME and SITE are the
values of the NAME and SITE parameters, respectively.
実体が次に、「外部のメッセージ/ボディー」であり、タイプに、実体のボディーがカプセル化されたメッセージのヘッダーフィールドを含むということであるなら。 ボディー自体は外部の位置で見つけられることになっています。 これは、「外部のメッセージ/ボディー」メッセージのボディーが2連続したCRLFsを含むなら、それらの組後のすべてがメッセージ自体の一部でないことを意味します。 ほとんどの外部のメッセージ/ボディーメッセージに関しては、単にこの引きずっている領域を無視しなければなりません。 しかしながら、それはcontent typeヘッダーフィールドに含むことができない追加データのための便利な場所です。 特に、引きずっている領域は「アクセス型」値が「メールサーバ」であるならそれぞれNAMEとSITEがNAMEとSITEパラメタの値であるところで NAME@SITE によって与えられたアドレスのメールサーバに送られるべきコマンドを含まなければなりません。
The embedded message header fields which appear in the body
of the message/external-body data can be used to declare the
Content-type of the external body. Thus a complete
message/external-body message, referring to a document in
PostScript format, might look like this:
外部のボディーに関する文書内容を宣言するのに外部のメッセージ欄/ボディーデータに現れる埋め込まれたメッセージヘッダーフィールドは使用できます。 したがって、ポストスクリプト形式でドキュメントを参照する場合、完全な外部のメッセージ/ボディーメッセージはこれに似るかもしれません:
From: Whomever
Subject: whatever
MIME-Version: 1.0
Message-ID: id1@host.com
Content-Type: multipart/alternative; boundary=42
From: 誰でも、Subject: いかなるMIMEバージョンも: 1.0Message ID: id1@host.com コンテントタイプ: 複合/代替手段。 境界=42
--42
Content-Type: message/external-body;
name="BodyFormats.ps";
--42コンテントタイプ: 外部のメッセージ/ボディー。 「BodyFormats.ps」と=を命名してください。
Borenstein & Freed [Page 44]
Borensteinであって解放されています。[44ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
サイトは"thumper.bellcore.com"と等しいです。 = やがてFTPをアクセスしてタイプする、。 ディレクトリは「パブ」と等しいです。 モードは「イメージ」と等しいです。 満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
文書内容: アプリケーション/追伸
--42
Content-Type: message/external-body;
name="/u/nsb/writing/rfcs/RFC-XXXX.ps";
site="thumper.bellcore.com";
access-type=AFS
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
--42コンテントタイプ: 外部のメッセージ/ボディー。 「/u/nsb/writing/rfcs/RFC-XXXX.ps」と=を命名してください。 サイトは"thumper.bellcore.com"と等しいです。 アクセス型=AFS満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
文書内容: アプリケーション/追伸
--42
Content-Type: message/external-body;
access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
--42コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型はメールサーバサーバ=" listserv@bogus.bitnet "と等しいです。 満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
文書内容: アプリケーション/追伸
get rfc-xxxx doc
rfc-xxxx docを手に入れてください。
--42--
--42--
Like the message/partial type, the message/external-body
type is intended to be transparent, that is, to convey the
data type in the external body rather than to convey a
message with a body of that type. Thus the headers on the
outer and inner parts must be merged using the same rules as
for message/partial. In particular, this means that the
Content-type header is overridden, but the From and Subject
headers are preserved.
メッセージ/部分的なタイプのように、外部のメッセージ/ボディータイプが透明であることを意図して、そのタイプのボディーでメッセージを伝えるというよりむしろ外部のボディーでデータ型を伝えるために、それはいます。 したがって、メッセージ/部分的なように同じ規則を使用することで外側の、そして、内側の部品の上のヘッダーを合併しなければなりません。 特に、これは、文書内容ヘッダーがくつがえされますが、FromとSubjectヘッダーが保存されることを意味します。
Note that since the external bodies are not transported as
mail, they need not conform to the 7-bit and line length
requirements, but might in fact be binary files. Thus a
Content-Transfer-Encoding is not generally necessary, though
it is permitted.
外部のボディーがメールとして輸送されないので、それらが7ビットと行長要件に従う必要はありませんが、事実上、バイナリーファイルであるかもしれないことに注意してください。 したがって、それは受入れられますが、一般に、Content転送コード化は必要ではありません。
Note that the body of a message of type "message/external-
body" is governed by the basic syntax for an RFC 822
message. In particular, anything before the first
consecutive pair of CRLFs is header information, while
anything after it is body information, which is ignored for
most access-types.
「メッセージ/外部のボディー」というタイプに関するメッセージのボディーがRFC822メッセージのために基本的な構文で治められることに注意してください。 CRLFsの最初の連続した組の前の何は特に、ヘッダー情報ですでも、それの後の何がボディー情報ですがも。(それは、ほとんどのアクセス型のために無視されます)。
Borenstein & Freed [Page 45]
Borensteinであって解放されています。[45ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
7.4 The Application Content-Type
7.4 アプリケーションコンテントタイプ
The "application" Content-Type is to be used for data which
do not fit in any of the other categories, and particularly
for data to be processed by mail-based uses of application
programs. This is information which must be processed by an
application before it is viewable or usable to a user.
Expected uses for Content-Type application include mail-
based file transfer, spreadsheets, data for mail-based
scheduling systems, and languages for "active"
(computational) email. (The latter, in particular, can pose
security problems which should be understood by
implementors, and are considered in detail in the discussion
of the application/PostScript content-type.)
「アプリケーション」コンテントタイプはデータがアプリケーション・プログラムのメールベースの用途で処理されるために他のカテゴリのどれかに、特に合わないデータに使用されることです。これはユーザにとって見えているか、または使用可能になる前にアプリケーションで処理しなければならない情報です。 コンテントタイプアプリケーションへの予想された用途はメールのベースのファイル転送、スプレッドシート、メールベースのスケジューリングシステムのためのデータ、および「アクティブな」(コンピュータの)メールのための言語を含んでいます。 (後者は作成者に解釈されるべきであり、アプリケーション/ポストスクリプトcontent typeの議論で詳細に考えられる警備上の問題を特に引き起こすことができます。)
For example, a meeting scheduler might define a standard
representation for information about proposed meeting dates.
An intelligent user agent would use this information to
conduct a dialog with the user, and might then send further
mail based on that dialog. More generally, there have been
several "active" messaging languages developed in which
programs in a suitably specialized language are sent through
the mail and automatically run in the recipient's
environment.
例えば、ミーティングスケジューラは提案されたミーティング期日頃の情報の標準の表現を定義するかもしれません。 知的なユーザエージェントはユーザと共に対話を行うのにこの情報を使用するでしょう、そして、その時はその対話に基づくさらなるメールを送るかもしれませんか? より一般に、適当に専門の言語におけるどのプログラムがメールで送られて、自動的に受取人の環境に立候補するかで開発されたいくつかの「アクティブな」メッセージング言語がありました。
Such applications may be defined as subtypes of the
"application" Content-Type. This document defines three
subtypes: octet-stream, ODA, and PostScript.
そのようなアプリケーションは「アプリケーション」コンテントタイプの血液型亜型と定義されるかもしれません。 このドキュメントは3血液型亜型を定義します: 八重奏ストリーム、ODA、およびポストスクリプト。
In general, the subtype of application will often be the
name of the application for which the data are intended.
This does not mean, however, that any application program
name may be used freely as a subtype of application. Such
usages must be registered with IANA, as described in
Appendix F.
一般に、アプリケーションの「副-タイプ」はしばしばデータが意図するアプリケーションの名前になるでしょう。 しかしながら、これは、どんな応用プログラム名もアプリケーションの「副-タイプ」として自由に使用されるかもしれないことを意味しません。 Appendix Fで説明されるようにそのような用法をIANAに登録しなければなりません。
7.4.1 The Application/Octet-Stream (primary) subtype
7.4.1 八重奏Application/ストリームの(プライマリ)の「副-タイプ」
The primary subtype of application, "octet-stream", may be
used to indicate that a body contains binary data. The set
of possible parameters includes, but is not limited to:
「八重奏ストリーム」というアプリケーションのプライマリ「副-タイプ」は、ボディーがバイナリ・データを含むのを示すのに使用されるかもしれません。 含んでいますが、可能なパラメタのセットは制限されません:
NAME -- a suggested name for the binary data if
stored as a file.
NAME--ファイルとして保存されるなら、aはバイナリ・データのために名前を示しました。
TYPE -- the general type or category of binary
data. This is intended as information for the
human recipient rather than for any automatic
processing.
TYPE--バイナリ・データの一般型かカテゴリ。 これはどんな自動処理のためにもというよりむしろ人間の受取人への情報として意図します。
CONVERSIONS -- the set of operations that have
been performed on the data before putting it in
the mail (and before any Content-Transfer-Encoding
that might have been applied). If multiple
CONVERSIONS--メール(そして適用されたどんなContent転送コード化の前にも)にそれを入れる前にデータに実行された操作のセット。 複数
Borenstein & Freed [Page 46]
Borensteinであって解放されています。[46ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
conversions have occurred, they must be separated
by commas and specified in the order they were
applied -- that is, the leftmost conversion must
have occurred first, and conversions are undone
from right to left. Note that NO conversion
values are defined by this document. Any
conversion values that that do not begin with "X-"
must be preceded by a published specification and
by registration with IANA, as described in
Appendix F.
オーダーで指定されて、それらは適用されました--変換は起こりました、そして、コンマでそれらを切り離さなければなりません、そして、すなわち、一番左変換は最初に起こったに違いありません、そして、変換は左への権利から元に戻されます。 転換価値が全くこのドキュメントによって定義されないことに注意してください。 広められた仕様とIANAとの登録でそれが「X」と共に始めない少しの転換価値にも先行しなければなりません、付録Fで説明されるように。
PADDING -- the number of bits of padding that were
appended to the bitstream comprising the actual
contents to produce the enclosed byte-oriented
data. This is useful for enclosing a bitstream in
a body when the total number of bits is not a
multiple of the byte size.
PADDING--同封のバイト指向のデータを作り出すために実際のコンテンツを包括するbitstreamにそれを水増しするビットの数を追加しました。 これはビットの総数がバイトサイズの倍数でないときにbitstreamを一団となって同封することの役に立ちます。
The values for these attributes are left undefined at
present, but may require specification in the future. An
example of a common (though UNIX-specific) usage might be:
これらの属性のための値は、現在のところ未定義の状態で出られますが、将来、仕様を必要とするかもしれません。 一般的な(UNIX特有ですが)用法に関する例は以下の通りです。
Content-Type: application/octet-stream;
name=foo.tar.Z; type=tar;
conversions="x-encrypt,x-compress"
コンテントタイプ: 八重奏アプリケーション/ストリーム。 =をfoo.tar.Zと命名してください。 =タールをタイプしてください。 変換が等しい、「x暗号化、x-湿布、」
However, it should be noted that the use of such conversions
is explicitly discouraged due to a lack of portability and
standardization. The use of uuencode is particularly
discouraged, in favor of the Content-Transfer-Encoding
mechanism, which is both more standardized and more portable
across mail boundaries.
しかしながら、そのような変換の使用が移植性と標準化の不足のために明らかにお勧めできないことに注意されるべきです。 uuencodeの使用は特にお勧めできないです、Content転送コード化メカニズムを支持して。メカニズムは、さらに標準化されていて、かつメール限界の向こう側に、より携帯用です。
The recommended action for an implementation that receives
application/octet-stream mail is to simply offer to put the
data in a file, with any Content-Transfer-Encoding undone,
or perhaps to use it as input to a user-specified process.
八重奏アプリケーション/ストリームメールを受け取る実装のためのお勧めの動作はユーザによって指定されたプロセスに入力されるようにどんなContent転送コード化も元に戻されている状態でファイルにデータを入れるか、または恐らくそれを使用すると単に申し出ることです。
To reduce the danger of transmitting rogue programs through
the mail, it is strongly recommended that implementations
NOT implement a path-search mechanism whereby an arbitrary
program named in the Content-Type parameter (e.g., an
"interpreter=" parameter) is found and executed using the
mail body as input.
メールで凶暴なプログラムを放送するという危険を減少させるために、実装がコンテントタイプパラメタ(例えば、「インタプリタ=」パラメタ)で指定された任意のプログラムが入力されるようにメール本文を使用することで見つけられて、実行される経路検索メカニズムを実装しないことが強く勧められます。
7.4.2 The Application/PostScript subtype
7.4.2 Application/ポストスクリプト「副-タイプ」
A Content-Type of "application/postscript" indicates a
PostScript program. The language is defined in
[POSTSCRIPT]. It is recommended that Postscript as sent
through email should use Postscript document structuring
conventions if at all possible, and correctly.
「アプリケーション/追伸」のコンテントタイプはポストスクリプトプログラムについて簡単に述べます。 言語は[POSTSCRIPT]で定義されます。 メールで送られるPostscriptができれば、正しくコンベンションを構造化するPostscriptドキュメントを使用するはずであるのは、お勧めです。
Borenstein & Freed [Page 47]
Borensteinであって解放されています。[47ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
The execution of general-purpose PostScript interpreters
entails serious security risks, and implementors are
discouraged from simply sending PostScript email bodies to
"off-the-shelf" interpreters. While it is usually safe to
send PostScript to a printer, where the potential for harm
is greatly constrained, implementors should consider all of
the following before they add interactive display of
PostScript bodies to their mail readers.
汎用ポストスクリプトインタプリタの実行は重大なセキュリティ危険を伴います、そして、作成者は単に送付ポストスクリプトメール本文から「すぐ入手できる」インタプリタまでがっかりしています。 通常、害の可能性が大いに抑制されるプリンタにポストスクリプトを送るのが安全である間、彼らがポストスクリプト本体の対話的なディスプレイをメール読者に加える前に作成者は以下のすべてを考えるべきです。
The remainder of this section outlines some, though probably
not all, of the possible problems with sending PostScript
through the mail.
このセクションの残りはいくつかについて概説します、たぶんメールでポストスクリプトを送る起こりうる問題のすべてではありませんが。
Dangerous operations in the PostScript language include, but
may not be limited to, the PostScript operators deletefile,
renamefile, filenameforall, and file. File is only
dangerous when applied to something other than standard
input or output. Implementations may also define additional
nonstandard file operators; these may also pose a threat to
security. Filenameforall, the wildcard file search
operator, may appear at first glance to be harmless. Note,
however, that this operator has the potential to reveal
information about what files the recipient has access to,
and this information may itself be sensitive. Message
senders should avoid the use of potentially dangerous file
operators, since these operators are quite likely to be
unavailable in secure PostScript implementations. Message-
receiving and -displaying software should either completely
disable all potentially dangerous file operators or take
special care not to delegate any special authority to their
operation. These operators should be viewed as being done by
an outside agency when interpreting PostScript documents.
Such disabling and/or checking should be done completely
outside of the reach of the PostScript language itself; care
should be taken to insure that no method exists for
reenabling full-function versions of these operators.
含んでいますが、言語が制限されないかもしれないポストスクリプト、ポストスクリプトオペレータdeletefile、renamefile、filenameforall、およびファイルにおける危険な操作。 標準の入力か出力以外の何かに適用されると、ファイルは危険であるだけです。 また、実装は追加標準的でないファイルのオペレータを定義するかもしれません。 また、これらはセキュリティへの脅威を引き起こすかもしれません。 Filenameforall(ワイルドカードファイル検索オペレータ)は、無害であるように一見したところでは見えるかもしれません。 しかしながら、このオペレータが受取人がどんなファイルに近づく手段を持つかの情報を明らかにする可能性を持っていて、この情報が持っているかもしれないことにそれ自体で注意してください。敏感であってください。 メッセージ送付者は潜在的に危険なファイルのオペレータの使用を避けるべきです、これらのオペレータがかなり安全なポストスクリプト実装で入手できない傾向があるので。 メッセージソフトウェアを受け取って、表示するのは、すべての潜在的に危険なファイルのオペレータを完全に無効にするべきであるか、または少しの特別な権威も彼らの操作へ代表として派遣しないように特別に注意を払うべきです。 ポストスクリプトドキュメントを解釈するとき外の政府機関によって行われるとこれらのオペレータは見なされるべきです。 そのような無効にする、そして/または、ポストスクリプト言語自体の範囲の外で完全に照合するべきです。 メソッドが全くこれらのオペレータの完全な機能バージョンを再可能にするために存在しないのを保障するために注意するべきです。
The PostScript language provides facilities for exiting the
normal interpreter, or server, loop. Changes made in this
"outer" environment are customarily retained across
documents, and may in some cases be retained semipermanently
in nonvolatile memory. The operators associated with exiting
the interpreter loop have the potential to interfere with
subsequent document processing. As such, their unrestrained
use constitutes a threat of service denial. PostScript
operators that exit the interpreter loop include, but may
not be limited to, the exitserver and startjob operators.
Message-sending software should not generate PostScript that
depends on exiting the interpreter loop to operate. The
ability to exit will probably be unavailable in secure
PostScript implementations. Message-receiving and
-displaying software should, if possible, disable the
ability to make retained changes to the PostScript
environment. Eliminate the startjob and exitserver commands.
ポストスクリプト言語は普通のインタプリタ、またはサーバを出るために便宜を与えて、輪にしてください。 この「外側」の環境で行われた変更は、ドキュメントの向こう側に通例に保有されて、いくつかの場合、不揮発性メモリで半永久保有されるかもしれません。 インタプリタ輪を出ると関連しているオペレータには、その後の文書処理を妨げる可能性があります。 そういうものとして、彼らの気ままな使用はサービス否定の脅威を構成します。 含んでいますが、輪が制限されないかもしれないインタプリタ、exitserver、およびstartjobオペレータを出るポストスクリプトオペレータ。 メッセージ送信ソフトウェアは作動するためにインタプリタ輪を出るのによるポストスクリプトを生成するはずがありません。 出る能力はたぶん安全なポストスクリプト実装で入手できなくなるでしょう。 できれば、メッセージ受信と表示ソフトウェアはポストスクリプト環境への保有された変更を行う能力を無効にするはずです。 startjobとexitserverコマンドを排除してください。
Borenstein & Freed [Page 48]
Borensteinであって解放されています。[48ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
If these commands cannot be eliminated, at least set the
password associated with them to a hard-to-guess value.
これらのコマンドを排除できないなら、推測しにくい値にそれらに関連しているパスワードを少なくとも設定してください。
PostScript provides operators for setting system-wide and
device-specific parameters. These parameter settings may be
retained across jobs and may potentially pose a threat to
the correct operation of the interpreter. The PostScript
operators that set system and device parameters include, but
may not be limited to, the setsystemparams and setdevparams
operators. Message-sending software should not generate
PostScript that depends on the setting of system or device
parameters to operate correctly. The ability to set these
parameters will probably be unavailable in secure PostScript
implementations. Message-receiving and -displaying software
should, if possible, disable the ability to change system
and device parameters. If these operators cannot be
disabled, at least set the password associated with them to
a hard-to-guess value.
ポストスクリプトはシステム全体の、そして、デバイス特有のパラメタを設定するのにオペレータを提供します。 これらのパラメタ設定は、仕事の向こう側に保有されて、潜在的にインタプリタの正しい操作への脅威を引き起こすかもしれません。 含んでいますが、セットシステムとデバイス・パラメータが制限されないかもしれないポストスクリプトオペレータ、setsystemparams、およびsetdevparamsオペレータ。 メッセージ送信ソフトウェアは正しく作動するためにシステムかデバイス・パラメータの設定に依存するポストスクリプトを生成するはずがありません。 これらのパラメタを設定する能力はたぶん安全なポストスクリプト実装で入手できなくなるでしょう。 できれば、メッセージ受信と表示ソフトウェアはシステムとデバイス・パラメータを変える能力を無効にするはずです。 これらのオペレータを無効にすることができないなら、推測しにくい値に彼らに関連しているパスワードを少なくとも設定してください。
Some PostScript implementations provide nonstandard
facilities for the direct loading and execution of machine
code. Such facilities are quite obviously open to
substantial abuse. Message-sending software should not
make use of such features. Besides being totally hardware-
specific, they are also likely to be unavailable in secure
implementations of PostScript. Message-receiving and
-displaying software should not allow such operators to be
used if they exist.
いくつかのポストスクリプト実装が機械コードのダイレクトローディングと実行に標準的でない施設を提供します。 そのような施設は全く明らかにかなりの乱用に開かれています。 メッセージ送信ソフトウェアはそのような特徴を利用するはずがありません。 また、ハードウェア完全に特有であること以外に、それらもポストスクリプトの安全な実装で入手できない傾向があります。 彼らが存在するなら、メッセージ受信と表示ソフトウェアは、そのようなオペレータが使用されるのを許容するはずがありません。
PostScript is an extensible language, and many, if not most,
implementations of it provide a number of their own
extensions. This document does not deal with such extensions
explicitly since they constitute an unknown factor.
Message-sending software should not make use of nonstandard
extensions; they are likely to be missing from some
implementations. Message-receiving and -displaying software
should make sure that any nonstandard PostScript operators
are secure and don't present any kind of threat.
ポストスクリプトは、広げることができる言語と、多くかそれの実装はそれら自身の多くの拡大を最も提供します。 未知の要素を構成するので、このドキュメントは明らかにそのような拡大に対処しません。 メッセージ送信ソフトウェアは標準的でない拡大を利用するはずがありません。 それらはいくつかの実装からなくなる傾向があります。 メッセージ受信と表示ソフトウェアは、どんな標準的でないポストスクリプトオペレータも確実に安全になるようにして、どんな種類の脅威も提示するはずがありません。
It is possible to write PostScript that consumes huge
amounts of various system resources. It is also possible to
write PostScript programs that loop infinitely. Both types
of programs have the potential to cause damage if sent to
unsuspecting recipients. Message-sending software should
avoid the construction and dissemination of such programs,
which is antisocial. Message-receiving and -displaying
software should provide appropriate mechanisms to abort
processing of a document after a reasonable amount of time
has elapsed. In addition, PostScript interpreters should be
limited to the consumption of only a reasonable amount of
any given system resource.
多量の様々なシステム資源を消費するポストスクリプトを書くのは可能です。 また、ポストスクリプトプログラムにその輪を無限に書くのも可能です。 両方のタイプに関するプログラムには、疑わない受取人に送るなら、損害を与える可能性があります。 メッセージ送信ソフトウェアはそのようなプログラムの工事と普及を避けるはずです(非社交的です)。 妥当な時間が経過した後にメッセージ受信と表示ソフトウェアはドキュメントのアボート処理に適切な手段を提供するはずです。 さらに、ポストスクリプトインタプリタはどんな与えられたシステム資源の十分な量だけの消費にも制限されるべきです。
Finally, bugs may exist in some PostScript interpreters
which could possibly be exploited to gain unauthorized
最終的に、バグは何人かのポストスクリプトインタプリタに存在するかもしれません(利得権限のなく利用できました)。
Borenstein & Freed [Page 49]
Borensteinであって解放されています。[49ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
access to a recipient's system. Apart from noting this
possibility, there is no specific action to take to prevent
this, apart from the timely correction of such bugs if any
are found.
受取人のシステムへのアクセス。 この可能性に注意することは別として、いずれか見つけられるなら、そのようなバグのタイムリーな修正は別としてこれを防ぐために取るどんな特定の行動もありません。
7.4.3 The Application/ODA subtype
7.4.3 Application/ODA「副-タイプ」
The "ODA" subtype of application is used to indicate that a
body contains information encoded according to the Office
Document Architecture [ODA] standards, using the ODIF
representation format. For application/oda, the Content-
Type line should also specify an attribute/value pair that
indicates the document application profile (DAP), using the
key word "profile". Thus an appropriate header field might
look like this:
アプリケーションの「小田」「副-タイプ」はボディーが事務文書体系[ODA]規格に従ってコード化された情報を含むのを示すのに使用されます、ODIF表現形式を使用して。 また、アプリケーション/odaとして、Contentタイプ系列はドキュメントアプリケーションプロフィール(DAP)を示す属性/値の組を指定するべきです、「プロフィール」というキーワードを使用して。 したがって、適切なヘッダーフィールドはこれに似るかもしれません:
Content-Type: application/oda; profile=Q112
コンテントタイプ: アプリケーション/oda。 プロフィール=Q112
Consult the ODA standard [ODA] for further information.
詳細のODA規格[ODA]に相談してください。
Borenstein & Freed [Page 50]
Borensteinであって解放されています。[50ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
7.5 The Image Content-Type
7.5 イメージコンテントタイプ
A Content-Type of "image" indicates that the bodycontains an
image. The subtype names the specific image format. These
names are case insensitive. Two initial subtypes are "jpeg"
for the JPEG format, JFIF encoding, and "gif" for GIF format
[GIF].
「イメージ」のコンテントタイプがそれを示す、イメージをbodycontainsします。 「副-タイプ」は特定の画像形式を命名します。 これらの名前は大文字と小文字を区別しないです。 JPEG形式のための"jpeg"、JFIFがGIFのためのコード化と、"gif"であるという2の初期の血液型亜型形式[GIF。]
The list of image subtypes given here is neither exclusive
nor exhaustive, and is expected to grow as more types are
registered with IANA, as described in Appendix F.
ここに与えられたイメージ血液型亜型のリストは、排他的でなくて、また徹底的でなく、より多くのタイプがIANAに示されるとき成長すると予想されます、Appendix Fで説明されるように。
7.6 The Audio Content-Type
7.6 オーディオコンテントタイプ
A Content-Type of "audio" indicates that the body contains
audio data. Although there is not yet a consensus on an
"ideal" audio format for use with computers, there is a
pressing need for a format capable of providing
interoperable behavior.
「オーディオ」のコンテントタイプは、ボディーがオーディオデータを含むのを示します。 コンピュータによる使用のための「理想的な」オーディオ形式に関するコンセンサスがまだありませんが、共同利用できる振舞いを提供できる形式のための差し迫った必要性があります。
The initial subtype of "basic" is specified to meet this
requirement by providing an absolutely minimal lowest common
denominator audio format. It is expected that richer
formats for higher quality and/or lower bandwidth audio will
be defined by a later document.
「基本的」の初期の「副-タイプ」は、絶対に最小量の最小公分母オーディオ形式を提供することによってこの必要条件を満たすために指定されます。 より高い品質、そして/または、下側の帯域幅オーディオのための、より豊かな書式が後のドキュメントによって定義されると予想されます。
The content of the "audio/basic" subtype is audio encoded
using 8-bit ISDN u-law [PCM]. When this subtype is present,
a sample rate of 8000 Hz and a single channel is assumed.
「オーディオ的か基本的な」「副-タイプ」の内容は8ビットのISDN u-法[PCM]を使用することでコード化されたオーディオです。 この「副-タイプ」が存在しているとき、8000Hzと単独のチャンネルの見本郵送料率は想定されます。
7.7 The Video Content-Type
7.7 ビデオコンテントタイプ
A Content-Type of "video" indicates that the body contains a
time-varying-picture image, possibly with color and
coordinated sound. The term "video" is used extremely
generically, rather than with reference to any particular
technology or format, and is not meant to preclude subtypes
such as animated drawings encoded compactly. The subtype
"mpeg" refers to video coded according to the MPEG standard
[MPEG].
「ビデオ」のコンテントタイプは、ボディーがことによると色の時変画像を含んで、音を調整したのを示します。 そして、「ビデオ」という用語が非常に一般的にむしろどんな特定の技術や形式に関して使用される、動く図面がコンパクトにコード化した血液型亜型を排除することは意味されません。 「副-タイプ」"mpeg"はMPEG規格[MPEG]に従ってコード化されたビデオを示します。
Note that although in general this document strongly
discourages the mixing of multiple media in a single body,
it is recognized that many so-called "video" formats include
a representation for synchronized audio, and this is
explicitly permitted for subtypes of "video".
このドキュメントが単一のボディーでのマルチメディアの混合を一般に強くがっかりさせますが、多くのいわゆる「ビデオ」形式が連動しているオーディオの表現を含んでいると認められて、これが「ビデオ」の血液型亜型のために明らかに許可されていることに注意してください。
7.8 Experimental Content-Type Values
7.8 実験コンテントタイプ値
A Content-Type value beginning with the characters "X-" is a
private value, to be used by consenting mail systems by
mutual agreement. Any format without a rigorous and public
definition must be named with an "X-" prefix, and publicly
specified values shall never begin with "X-". (Older
キャラクタ「X」と共に始まるコンテントタイプ値は、相談ずくの同意しているメールシステムによって使用されるためには個人的な値です。 「X」接頭語で厳しくて公共の定義のないどんな形式も命名しなければなりません、そして、公的に指定された値は「X」と共に決して始まらないものとします。 (旧
Borenstein & Freed [Page 51]
Borensteinであって解放されています。[51ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
versions of the widely-used Andrew system use the "X-BE2"
name, so new systems should probably choose a different
name.)
広く使用されたアンドリューシステムのバージョンが使用する、「システムがたぶん異なった名前を選ぶはずであるように、名前であって、とても新しいX-BE2")。」
In general, the use of "X-" top-level types is strongly
discouraged. Implementors should invent subtypes of the
existing types whenever possible. The invention of new
types is intended to be restricted primarily to the
development of new media types for email, such as digital
odors or holography, and not for new data formats in
general. In many cases, a subtype of application will be
more appropriate than a new top-level type.
一般に、「X」トップレベルタイプの使用は強くお勧めできないです。 可能であるときはいつも、作成者は既存のタイプの血液型亜型を発明するべきです。 新しいタイプの発明は主としてメールのためのデジタルにおいかホログラフィなどのニューメディアタイプの進化に制限されることを意図する、および一般に、どんな新しいデータ形式のためのものではありません。 多くの場合、アプリケーションの「副-タイプ」は新しいトップレベルタイプよりさらに適切になるでしょう。
Borenstein & Freed [Page 52]
Borensteinであって解放されています。[52ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
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 objects 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 Appendix B). The "multipart" and
"message" Content-Types allow mixing and hierarchical
structuring of objects of different types in a single
message. Further Content-Types provide a standardized
mechanism for tagging messages or body parts as audio,
image, or several other kinds of data. A distinguished
parameter syntax allows further specification of data format
details, particularly the specification of alternate
character sets. Additional optional header fields provide
mechanisms for certain extensions deemed desirable by many
implementors. Finally, a number of useful Content-Types are
defined for general use by consenting user agents, notably
text/richtext, message/partial, and message/external-body.
MIMEバージョンを使用して、コンテントタイプ、およびContent-転送コード化ヘッダーフィールドでありそれは含むのにおいて可能です、標準化された方法で、RFC822conformantメール・メッセージがある任意のタイプのデータ・オブジェクト。 RFC821かRFC822のどちらかによって課されなかった制限は全く違反されます、そして、いくつかのインターネット・メール移送機構の特性によって課された追加制限で引き起こされた問題を避けるために、注意しました(Appendix Bを見てください)。 「複合」と「メッセージ」コンテントタイプはただ一つのメッセージに異なったタイプの物の混合と階層構造形成を許容します。 さらなるコンテントタイプはオーディオ、イメージ、または他の数種類のデータとしてメッセージか身体の部分にタグ付けをするのに標準化されたメカニズムを提供します。 顕著なパラメタ構文はさらにデータの形式の詳細の仕様、特に交互の文字の組の仕様を許容します。 追加任意のヘッダーフィールドは望ましいと多くの作成者によって考えられたある拡大にメカニズムを提供します。 最終的に、多くの役に立つコンテントタイプが、一般的使用のために同意しているユーザエージェント、著しくテキスト/richtextによって定義されるのと、メッセージ/部分と、外部のメッセージ/ボディーです。
Borenstein & Freed [Page 53]
Borensteinであって解放されています。[53ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Acknowledgements
承認
This document is the result of the collective effort of a
large number of people, at several IETF meetings, on the
IETF-SMTP and IETF-822 mailing lists, and elsewhere.
Although any enumeration seems doomed to suffer from
egregious omissions, the following are among the many
contributors to this effort:
このドキュメントはIETF-SMTPとIETF-822メーリングリストの上とほかの場所でのいくつかのIETFミーティングにおける多くの人々の結集した力の結果です。 どんな列挙もとてもひどい省略に苦しむのが運命づけられるように思えますが、以下はこの努力への多くの貢献者の中のひとりです:
Harald Tveit Alvestrand Timo Lehtinen
Randall Atkinson John R. MacMillan
Philippe Brandon Rick McGowan
Kevin Carosso Leo Mclaughlin
Uhhyung Choi Goli Montaser-Kohsari
Cristian Constantinof Keith Moore
Mark Crispin Tom Moore
Dave Crocker Erik Naggum
Terry Crowley Mark Needleman
Walt Daniels John Noerenberg
Frank Dawson Mats Ohrman
Hitoshi Doi Julian Onions
Kevin Donnelly Michael Patton
Keith Edwards David J. Pepper
Chris Eich Blake C. Ramsdell
Johnny Eriksson Luc Rooijakkers
Craig Everhart Marshall T. Rose
Patrik Faeltstroem Jonathan Rosenberg
Erik E. Fair Jan Rynning
Roger Fajman Harri Salminen
Alain Fontaine Michael Sanderson
James M. Galvin Masahiro Sekiguchi
Philip Gladstone Mark Sherman
Thomas Gordon Keld Simonsen
Phill Gross Bob Smart
James Hamilton Peter Speck
Steve Hardcastle-Kille Henry Spencer
David Herron Einar Stefferud
Bruce Howard Michael Stein
Bill Janssen Klaus Steinberger
Olle Jaernefors Peter Svanberg
Risto Kankkunen James Thompson
Phil Karn Steve Uhler
Alan Katz Stuart Vance
Tim Kehres Erik van der Poel
Neil Katin Guido van Rossum
Kyuho Kim Peter Vanderbilt
Anders Klemets Greg Vaudreuil
John Klensin Ed Vielmetti
Valdis Kletniek Ryan Waldron
Jim Knowles Wally Wedel
Stev Knowles Sven-Ove Westberg
Bob Kummerfeld Brian Wideen
ハラルド・Tveit Alvestrandティモ・レーティネン・ランドル・アトキンソン・ジョン・R.マクミランのフィリップ・ブランドン・リック・マガウアン・ケビン・Carosso Leo Mclaughlin Uhhyungチェ・Goli Montaser-Kohsariクリスチャン・Constantinofキース・ムーア・マーククリスピン・トム・ムーア・デーヴ・Crockerエリック・Naggumテリー・クローリー・マークニードルマン・ウォルト・ダニエル・ジョン・Noerenbergフランク・ドーソンはOhrman等土井ジュリアンたまねぎケビンドネリーマイケルパットンキースエドワーズデヴィッドJ.コショウクリスアイヒブレークC.RamsdellジョニーエリクソンリュックRooijakkersクレイグエバーハートマーシャルTをもつれさせます; バラパトリクFaeltstroemジョナサンローゼンバーグエリックE.Fair Jan Rynningロジャー・Fajmanハリー・サルミネン・アラン・フォンテーヌ・マイケル・サンダーソン・ジェームスM; ガルビン・正裕・Sekiguchiフィリップ・Gladstone Mark Sherman・トーマス・ゴードン・Keldシモンセン・フィルGrossのボブSmartのジェームス・ハワード・マイケル・シタイン・ビル・ジャンセン・ハミルトンピーター細粒スティーブHardcastle-KilleヘンリースペンサーデヴィッドハーロンEinar Stefferudブルースクラウスシュタインバーガー・オッレ・Jaerneforsピーター・スバンベルク・Ristoカンクネン・ジェームス・トンプソンフィル・Karnスティーブ・Uhlerアラン・キャッツ・スチュアート・ヴァンス・ティム・Kehres恵里kバンderポールニールケーティングイドバンロスムKyuhoキムピーターバンダービルトアンダースKlemetsグレッグボードルイジョンKlensinエドVielmettiヴァルディスKletniekライアンウォルドロンジムノウルズウォリーウェデルStevノウルズスベン-OveウェストバーグボブKummerfeldブライアンWideen
Borenstein & Freed [Page 54]
Borensteinであって解放されています。[54ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Pekka Kytolaakso John Wobus
Stellan Lagerstr.m Glenn Wright
Vincent Lau Rayan Zachariassen
Donald Lindsay David Zimmerman
The authors apologize for any omissions from this list,
which are certainly unintentional.
作者のペッカ・Kytolaaksoジョン・Wobusステラン・Lagerstr.mグレン・ライト・ヴィンセント・ラウ・ライアン・Zachariassenドナルド・リンゼー・デヴィッド・ジンマーマンはこのリストからのどんな省略も謝ります。(確かに、省略は意図的ではありません)。
Borenstein & Freed [Page 55]
Borensteinであって解放されています。[55ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Appendix A -- Minimal MIME-Conformance
付録A--最小量のMIME順応
The mechanisms described in this document are open-ended.
It is definitely not expected that all implementations will
support all of the Content-Types described, nor that they
will all share the same extensions. In order to promote
interoperability, however, it is useful to define the
concept of "MIME-conformance" to define a certain level of
implementation that allows the useful interworking of
messages with content that differs from US ASCII text. In
this section, we specify the requirements for such
conformance.
本書では説明されたメカニズムは制限のないです。 すべての実現が説明されたコンテントタイプのすべてを支持して、同じ拡大を共有しないと確実に予想されます。 しかしながら、相互運用性を促進するために、米国ASCIIテキストと異なっている内容があるメッセージを役に立つ織り込むことを許すあるレベルの実現を定義するために「MIME順応」の概念を定義するのは役に立ちます。 このセクションでは、私たちはそのような順応のための要件を指定します。
A mail user agent that is MIME-conformant MUST:
MIME-conformantであるメールユーザエージェントはそうしなければなりません:
1. Always generate a "MIME-Version: 1.0" header
field.
1. aをいつも発生させてください、「MIMEバージョン:」 1インチのヘッダーフィールド。
2. Recognize the Content-Transfer-Encoding header
field, and decode all received data encoded with
either the quoted-printable or base64
implementations. Encode any data sent that is
not in seven-bit mail-ready representation using
one of these transformations and include the
appropriate Content-Transfer-Encoding header
field, unless the underlying transport mechanism
supports non-seven-bit data, as SMTP does not.
2. Content転送コード化ヘッダーフィールドを認識してください、そして、引用されて印刷可能であるかbase64実現でコード化されたすべての受信データを解読してください。 送られた7ビットのメール持ち合わせの表現これらの変化の1つを使用することで中でないデータを少しのコード化してください、そして、適切なContent転送コード化ヘッダーフィールドを含めてください、非7がデータに噛み付いた状態で基本的さがメカニズムサポートを輸送しないなら、SMTPがそうしないように。
3. Recognize and interpret the Content-Type
header field, and avoid showing users raw data
with a Content-Type field other than text. Be
able to send at least text/plain messages, with
the character set specified as a parameter if it
is not US-ASCII.
3. コンテントタイプヘッダーフィールドを認識して、解釈してください、そして、テキスト以外のコンテントタイプ分野で生データをユーザに示すのを避けてください。 少なくともテキスト/明瞭なメッセージを送ることができてください、それが米国-ASCIIでないならパラメタとして指定された文字の組で。
4. Explicitly handle the following Content-Type
values, to at least the following extents:
4. 明らかに少なくとも以下の範囲に以下のコンテントタイプ値を扱ってください:
Text:
-- Recognize and display "text" mail
with the character set "US-ASCII."
-- Recognize other character sets at
least to the extent of being able
to inform the user about what
character set the message uses.
-- Recognize the "ISO-8859-*" character
sets to the extent of being able to
display those characters that are
common to ISO-8859-* and US-ASCII,
namely all characters represented
by octet values 0-127.
-- For unrecognized subtypes, show or
offer to show the user the "raw"
version of the data. An ability at
テキスト: -- 「米国-ASCII」という文字の組がある「テキスト」メールを認識して、表示してください。 -- 他の文字の組を少なくともメッセージが周囲でどんな文字の組を使用するかをユーザに知らせることができる範囲まで認識してください。 -- 「ISO8859*」文字の組をISO8859*と米国-ASCIIに共通のそれらのキャラクタは見せることができる範囲まで認識してください、すなわち、八重奏値0-127によって代理をされたすべてのキャラクタ。 -- 認識されていない血液型亜型には、目立つか、またはデータの「生」のバージョンをユーザに示すと申し出てください。 能力
Borenstein & Freed [Page 56]
Borensteinであって解放されています。[56ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
least to convert "text/richtext" to
plain text, as shown in Appendix D,
is encouraged, but not required for
conformance.
Message:
--Recognize and display at least the
primary (822) encapsulation.
Multipart:
-- Recognize the primary (mixed)
subtype. Display all relevant
information on the message level
and the body part header level and
then display or offer to display
each of the body parts
individually.
-- Recognize the "alternative" subtype,
and avoid showing the user
redundant parts of
multipart/alternative mail.
-- Treat any unrecognized subtypes as if
they were "mixed".
Application:
-- Offer the ability to remove either of
the two types of Content-Transfer-
Encoding defined in this document
and put the resulting information
in a user file.
「テキスト/richtext」をプレーンテキストに変換するAppendix Dに示される最少は、奨励されますが、順応に必要ではありません。 メッセージ: --少なくとも第一の(822)カプセル化を認識して、表示してください。 複合: -- 第一(混ぜられた)の「副-タイプ」を認識してください。 メッセージレベルとボディー部分ヘッダーレベルのすべての関連情報を表示して、次に、表示を表示するか、または個別にそれぞれの身体の部分を表示すると申し出てください。 -- 「代替」の「副-タイプ」を認めてください、そして、複合の、または、代替のメールのユーザの余分な部分を見せるのを避けてください。 -- まるでそれらが「混ぜられるかの」ようにあらゆる認識されていない血液型亜型を扱ってください。 アプリケーション: -- 本書では定義された2つのタイプのContent-転送コード化のどちらかを移して、結果として起こる情報をユーザ・ファイルに入れる能力を提供してください。
5. Upon encountering any unrecognized Content-
Type, an implementation must treat it as if it had
a Content-Type of "application/octet-stream" with
no parameter sub-arguments. How such data are
handled is up to an implementation, but likely
options for handling such unrecognized data
include offering the user to write it into a file
(decoded from its mail transport format) or
offering the user to name a program to which the
decoded data should be passed as input.
Unrecognized predefined types, which in a MIME-
conformant mailer might still include audio,
image, or video, should also be treated in this
way.
5. どんな認識されていないContentタイプにも遭遇すると、まるでそれには「八重奏アプリケーション/流れ」のコンテントタイプがパラメタサブ議論なしであるかのように実現はそれを扱わなければなりません。 そのようなデータがどう扱われるかが実現まで達していますが、そのような認識されていないデータを扱うためのありそうなオプションは、ファイル(メール輸送形式から、解読される)の中にそれを書くためにユーザを提供するか、または解読されたデータが入力されるように通過されるべきであるプログラムを命名するためにユーザを提供するのを含んでいます。 また、認識されていない事前に定義されたタイプ(MIME conformant郵送者ではまだオーディオを含んでいるかもしれません)(イメージ、またはビデオ)は、このように扱われるべきです。
A user agent that meets the above conditions is said to be
MIME-conformant. The meaning of this phrase is that it is
assumed to be "safe" to send virtually any kind of
properly-marked data to users of such mail systems, because
such systems will at least be able to treat the data as
undifferentiated binary, and will not simply splash it onto
the screen of unsuspecting users. There is another sense
in which it is always "safe" to send data in a format that
is MIME-conformant, which is that such data will not break
or be broken by any known systems that are conformant with
RFC 821 and RFC 822. User agents that are MIME-conformant
上記の条件を満たすユーザエージェントはMIME-conformantであると言われています。 この句の意味は実際にはどんな種類の適切に著しいデータもそのようなメールシステムのユーザに送るために「安全である」と思われるということです、そのようなシステムが非分化しているバイナリーとしてデータを少なくとも扱うことができて、疑いを持たないユーザーのスクリーンにそれを絶対にはねかけないので。 壊れているというそのようなデータがRFC821とRFC822とconformantであるどんな知られているシステムでも壊さないで、またならないことであるMIME-conformantである形式でデータを送るのがいつも「安全である」別の感覚があります。 MIME-conformantであるユーザエージェント
Borenstein & Freed [Page 57]
Borensteinであって解放されています。[57ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
have the additional guarantee that the user will not be
shown data that were never intended to be viewed as text.
テキストとして見なされることを決して意図しなかったデータがユーザに示されないという追加保証を持ってください。
Borenstein & Freed [Page 58]
Borensteinであって解放されています。[58ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Appendix B -- General Guidelines For Sending Email Data
付録B--送付メールデータのための一般的ガイドライン
Internet email is not a perfect, homogeneous system. Mail
may become corrupted at several stages in its travel to a
final destination. Specifically, email sent throughout the
Internet may travel across many networking technologies.
Many networking and mail technologies do not support the
full functionality possible in the SMTP transport
environment. Mail traversing these systems is likely to be
modified in such a way that it can be transported.
インターネットメールは完全で、同次のシステムではありません。 メールはいくつかの段階で最終的な目的地への旅行で崩壊するようになるかもしれません。 明確に、インターネット中で送られたメールは多くのネットワーク・テクノロジーの向こう側に移動するかもしれません。 多くのネットワークとメール技術はSMTP輸送環境で可能な完全な機能性を支持しません。 これらのシステムを横断する郵便配達人はそれを輸送できるような方法で変更されそうです。
There exist many widely-deployed non-conformant MTAs in the
Internet. These MTAs, speaking the SMTP protocol, alter
messages on the fly to take advantage of the internal data
structure of the hosts they are implemented on, or are just
plain broken.
多くの広く配備された非conformant MTAsがインターネットに存在しています。 これらのMTAsはSMTPプロトコルを話して、彼らが実行されるホストの内部のデータ構造を利用するために飛行中のメッセージを変更するか、またはただ単に壊されます。
The following guidelines may be useful to anyone devising a
data format (Content-Type) that will survive the widest
range of networking technologies and known broken MTAs
unscathed. Note that anything encoded in the base64
encoding will satisfy these rules, but that some well-known
mechanisms, notably the UNIX uuencode facility, will not.
Note also that anything encoded in the Quoted-Printable
encoding will survive most gateways intact, but possibly not
some gateways to systems that use the EBCDIC character set.
以下のガイドラインは、最も広い範囲のネットワーク・テクノロジーを乗り切るデータの形式(コンテントタイプ)について工夫するだれのも役に立って知られている壊れているMTAs無事であるかもしれません。 base64コード化でコード化されたものは何もこれらの規則を満たしますが、いくつかの周知のメカニズム、著しくUNIX uuencode施設が満たさないことに注意してください。 また、Quoted印刷可能なコード化でコード化されたものは何も完全な状態でほとんどのゲートウェイを乗り切りますが、ことによるとEBCDlC文字を使用するシステムへの数門がセットしないことに注意してください。
(1) Under some circumstances the encoding used for
data may change as part of normal gateway or user
agent operation. In particular, conversion from
base64 to quoted-printable and vice versa may be
necessary. This may result in the confusion of
CRLF sequences with line breaks in text body
parts. As such, the persistence of CRLF as
something other than a line break should not be
relied on.
(1) いくつかの状況で、データに使用されるコード化は正常なゲートウェイかユーザエージェント操作の一部として変化するかもしれません。 base64から引用されて印刷可能になるまでの変換が逆もまた同様に特に、必要であるかもしれません。 これはテキスト身体の部分のラインブレイクへのCRLF系列の混乱をもたらすかもしれません。 そういうものとして、ラインブレイク以外の何かとしてのCRLFの固執に依存するべきではありません。
(2) Many systems may elect to represent and store
text data using local newline conventions. Local
newline conventions may not match the RFC822 CRLF
convention -- systems are known that use plain CR,
plain LF, CRLF, or counted records. The result is
that isolated CR and LF characters are not well
tolerated in general; they may be lost or
converted to delimiters on some systems, and hence
should not be relied on.
(2) 多くのシステムが、地方のニューラインコンベンションを使用することでテキストデータを表して、格納するのを選ぶかもしれません。 地方のニューラインコンベンションはRFC822 CRLFコンベンションに合わないかもしれません--明瞭なCR、明瞭なLF、CRLF、または数えられた記録を使用するシステムが知られています。 結果は孤立しているCRとLFキャラクタがよく一般に許容されないということです。 それらを失うべきでないかもしれませんし、いくつかのシステムの上でデリミタに変えて、またしたがって、当てにするべきではありません。
(3) TAB (HT) characters may be misinterpreted or
may be automatically converted to variable numbers
of spaces. This is unavoidable in some
environments, notably those not based on the ASCII
character set. Such conversion is STRONGLY
DISCOURAGED, but it may occur, and mail formats
should not rely on the persistence of TAB (HT)
(3) TAB(HT)キャラクタは、誤解されるか、または自動的に可変数の空間に変換されるかもしれません。 これはいくつかの環境、著しくASCII文字の組に基づかないもので避けられません。 起こるかもしれません、そして、そのような変換はSTRONGLY DISCOURAGEDですが、メール書式はTABの固執に依存するべきではありません。(HT)
Borenstein & Freed [Page 59]
Borensteinであって解放されています。[59ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
characters.
キャラクタ。
(4) Lines longer than 76 characters may be wrapped
or truncated in some environments. Line wrapping
and line truncation are STRONGLY DISCOURAGED, but
unavoidable in some cases. Applications which
require long lines should somehow differentiate
between soft and hard line breaks. (A simple way
to do this is to use the quoted-printable
encoding.)
(4) 76のキャラクタより長い線は、いくつかの環境で包装されるか、または先端を切られるかもしれません。 いくつかの場合、線ラッピングと線トランケーションは、STRONGLY DISCOURAGEDにもかかわらず、避けられません。 長い線を必要とするアプリケーションはどうにか柔らかくて困難なラインブレイクを区別するべきです。 (これをする簡単な方法は引用されて印刷可能なコード化を使用することです。)
(5) Trailing "white space" characters (SPACE, TAB
(HT)) on a line may be discarded by some transport
agents, while other transport agents may pad lines
with these characters so that all lines in a mail
file are of equal length. The persistence of
trailing white space, therefore, should not be
relied on.
(5) 線の上の引きずっている「余白」キャラクタ(SPACE、TAB(HT))は何人かの輸送エージェントによって捨てられるかもしれません、他の輸送エージェントがこれらのキャラクタと共に線を水増しするかもしれないので、メールファイルのすべての線が等しい長さのものですが。 したがって、引きずっている余白の固執に依存するべきではありません。
(6) Many mail domains use variations on the ASCII
character set, or use character sets such as
EBCDIC which contain most but not all of the US-
ASCII characters. The correct translation of
characters not in the "invariant" set cannot be
depended on across character converting gateways.
For example, this situation is a problem when
sending uuencoded information across BITNET, an
EBCDIC system. Similar problems can occur without
crossing a gateway, since many Internet hosts use
character sets other than ASCII internally. The
definition of Printable Strings in X.400 adds
further restrictions in certain special cases. In
particular, the only characters that are known to
be consistent across all gateways are the 73
characters that correspond to the upper and lower
case letters A-Z and a-z, the 10 digits 0-9, and
the following eleven special characters:
(6) 多くのメール・ドメインが、ASCII文字の組の変化を使用するか、または米国のASCII文字の大部分にもかかわらず、すべてを含むというわけではないEBCDICなどの文字の組を使用します。 ゲートウェイを変換するキャラクタの向こう側に「不変式」セットでキャラクタに関する正しい訳に依存できます。 送付がBitnet、EBCDICシステムの向こう側に情報をuuencodedしたとき、例えば、この状況は問題です。 多くのインターネット・ホストが内部的にASCIIを除いた文字の組を使用するのでゲートウェイを越えないで、同様の問題は起こることができます。 X.400とのPrintable Stringsの定義はある特別な場合におけるさらなる制限を加えます。 すべてのゲートウェイの向こう側に一貫しているのが知られている唯一のキャラクタが、特に、上側と小文字A-Zと1zに文通する73のキャラクタと、10ケタ0-9と、以下の11の特殊文字です:
"'" (ASCII code 39)
"(" (ASCII code 40)
")" (ASCII code 41)
"+" (ASCII code 43)
"," (ASCII code 44)
"-" (ASCII code 45)
"." (ASCII code 46)
"/" (ASCII code 47)
":" (ASCII code 58)
"=" (ASCII code 61)
"?" (ASCII code 63)
「「'」 「「+」 (ASCIIコード39)「(「(ASCIIコード40)」)」(ASCIIコード41)(ASCIIコード43)」、(ASCIIコード44)「-」(ASCIIコード45)」。」' (ASCIIコード46) 「「/」(ASCIIコード47)」:、」 (ASCIIコード58) “?"と「等しい」(ASCIIコード61)。 (ASCIIコード63)
A maximally portable mail representation, such as
the base64 encoding, will confine itself to
relatively short lines of text in which the only
meaningful characters are taken from this set of
base64コード化などの最高に携帯用のメール表現はどれについてこのセットから唯一の重要なキャラクタを取るかでそれ自体をテキストの比較的短い線に制限するでしょう。
Borenstein & Freed [Page 60]
Borensteinであって解放されています。[60ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
73 characters.
73のキャラクタ。
Please note that the above list is NOT a list of recommended
practices for MTAs. RFC 821 MTAs are prohibited from
altering the character of white space or wrapping long
lines. These BAD and illegal practices are known to occur
on established networks, and implementions should be robust
in dealing with the bad effects they can cause.
上記のリストはMTAsのための推奨案のリストではありません。 RFC821MTAsは余白のキャラクタを変更するか、または長い線を包装するのが禁止されています。 これらのBADと不法な習慣が既存のネットワークに起こるのが知られて、implementionsはそれらが引き起こす場合がある悪い効果に対処するのにおいて強健であるべきです。
Borenstein & Freed [Page 61]
Borensteinであって解放されています。[61ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Appendix C -- A Complex Multipart Example
付録C--複雑な複合例
What follows is the outline of a complex multipart message.
This message has five parts to be displayed serially: two
introductory plain text parts, an embedded multipart
message, a richtext part, and a closing encapsulated text
message in a non-ASCII character set. The embedded
multipart message has two parts to be displayed in parallel,
a picture and an audio fragment.
続くことは複雑な複合メッセージのアウトラインです。 このメッセージには、順次表示するために、5つの部品があります: 2つの紹介しているプレーンテキスト部分、埋め込まれた複合メッセージ、richtext部分、および閉鎖は非ASCII文字の組のテキストメッセージを要約しました。 埋め込まれた複合メッセージには、平行に表示されるべき2つの部品、絵、およびオーディオ断片があります。
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@bellcore.com>
Subject: A multipart example
Content-Type: multipart/mixed;
boundary=unique-boundary-1
MIMEバージョン: 1.0 From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、Subject: 複合例のコンテントタイプ: 複合か混ぜられる。 ユニークな境界-1の境界=
This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.
If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.
--unique-boundary-1
これは複合メッセージの序文部門です。 複合形式がこの序文を無視するべきであるのを理解している読者に郵送してください。 本稿を読んでいるなら、あなたは、適切に複合メッセージを表示する方法を理解しているメール読者に変化すると考えたがっているかもしれません。 --ユニークな境界1
...Some text appears here...
[Note that the preceding blank line means
no header fields were given and this is text,
with charset US ASCII. It could have been
done with explicit typing as in the next part.]
...何らかのテキストがここに現れます… [charset米国ASCIIと共に前の空白行がヘッダーフィールドを全く与えないで、これがテキストであることを意味することに注意してください。 次の部分のように明白なタイプでそれをしたかもしれません。]
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
--ユニークな境界1文書内容: テキスト/平野。 charsetは米国-ASCIIと等しいです。
This could have been part of the previous part,
but illustrates explicit versus implicit
typing of body parts.
これは、前の部分の一部であったかもしれませんが、身体の部分の暗黙の型宣言に対して明白な状態で例証します。
--unique-boundary-1
Content-Type: multipart/parallel;
boundary=unique-boundary-2
--ユニークな境界1コンテントタイプ: 複合/平行線。 ユニークな境界-2の境界=
--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
--ユニークな境界2コンテントタイプ: 基本的なContent転送オーディオ/コード化: base64
... base64-encoded 8000 Hz single-channel
u-law-format audio data goes here....
… 8000Hzのbase64によってコード化された単独のチャンネルu法の形式オーディオデータはここに行きます…
--unique-boundary-2
Content-Type: image/gif
Content-Transfer-Encoding: Base64
--ユニークな境界2コンテントタイプ: gif Content転送イメージ/コード化: Base64
Borenstein & Freed [Page 62]
Borensteinであって解放されています。[62ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
... base64-encoded image data goes here....
… base64によってコード化されたイメージデータはここに行きます…
--unique-boundary-2--
--ユニークな境界2--
--unique-boundary-1
Content-type: text/richtext
--ユニークな境界1文書内容: テキスト/richtext
This is <bold><italic>richtext.</italic></bold>
<nl><nl>Isn't it
<bigger><bigger>cool?</bigger></bigger>
これ、<の、より大きい><より大きい>冷静?<の大胆な><イタリック体の>richtextそれではなく、</イタリック体の></大胆な>のnl><nl><Isnが、よりより</大きい></大きい>です。
--unique-boundary-1
Content-Type: message/rfc822
--ユニークな境界1コンテントタイプ: メッセージ/rfc822
From: (name in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
From: (米国-ASCIIにおける名前) Subject: (米国-ASCIIにおける対象) コンテントタイプ: テキスト/平野。 charset=ISO-8859-1の満足している転送コード化: 引用されて印刷可能です。
... Additional text in ISO-8859-1 goes here ...
... ISO-8859-1の追加テキストはここに続きます…
--unique-boundary-1--
--ユニークな境界1--
Borenstein & Freed [Page 63]
Borensteinであって解放されています。[63ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Appendix D -- A Simple Richtext-to-Text Translator in C
付録D--CのRichtextからテキストへの純真な翻訳者
One of the major goals in the design of the richtext subtype
of the text Content-Type is to make formatted text so simple
that even text-only mailers will implement richtext-to-
plain-text translators, thus increasing the likelihood that
multifont text will become "safe" to use very widely. To
demonstrate this simplicity, what follows is an extremely
simple 44-line C program that converts richtext input into
plain text output:
テキストコンテントタイプのrichtext subtypeのデザインにおける主要な目標の1つはフォーマット済みのテキストをテキストのみ郵送者さえrichtextからプレーンテキストへの翻訳者を実行するほど簡単にすることです、その結果、マルチフォントテキストが非常に広く使用するために「安全に」なる可能性を広げます。 この簡単さを示すために、続くことはrichtext入力をプレーンテキスト出力に変換する非常に簡単な44線のCプログラムです:
#include <stdio.h>
#include <ctype.h>
main() {
int c, i;
char token[50];
#<stdio.h>#インクルード<ctype.h>メイン()を含めてください、int c、i; 象徴[50]を炭にしてください。
while((c = getc(stdin)) != EOF) {
if (c == '<') {
for (i=0; (i<49 && (c = getc(stdin)) != '>'
&& c != EOF); ++i) {
token[i] = isupper(c) ? tolower(c) : c;
}
if (c == EOF) break;
if (c != '>') while ((c = getc(stdin)) !=
'>'
&& c != EOF) {;}
if (c == EOF) break;
token[i] = '%%BODY%%';
if (!strcmp(token, "lt")) {
putc('<', stdout);
} else if (!strcmp(token, "nl")) {
putc('\n', stdout);
} else if (!strcmp(token, "/paragraph")) {
fputs("\n\n", stdout);
} else if (!strcmp(token, "comment")) {
int commct=1;
while (commct > 0) {
while ((c = getc(stdin)) != '<'
&& c != EOF) ;
if (c == EOF) break;
for (i=0; (c = getc(stdin)) != '>'
&& c != EOF; ++i) {
token[i] = isupper(c) ?
tolower(c) : c;
}
if (c== EOF) break;
token[i] = NULL;
if (!strcmp(token, "/comment")) --
commct;
if (!strcmp(token, "comment"))
++commct;
(c=EOF)が壊れるなら、+ + i)は=isupper(c)tolower(c): (c)をtokeniします; (c!='>')であるなら='>をゆったり過ごしてください(c=getc(stdin))。(c=getc(stdin!)=EOF)である、(c='<')である、(i=0;、(i<49、(cはgetc(stdin)と等しいです)='>'、c!=EOF、)、;、'c!=EOF) (c=EOF)が壊れるなら; 「tokeniはNULLと等しいです;、(strcmp、(象徴、」、/コメント、」、)、--commct; + + (strcmp(象徴、「コメント」))commctであるなら。
Borenstein & Freed [Page 64]
Borensteinであって解放されています。[64ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
}
} /* Ignore all other tokens */
} else if (c != '\n') putc(c, stdout);
}
putc('\n', stdout); /* for good measure */
}
It should be noted that one can do considerably better than
this in displaying richtext data on a dumb terminal. In
particular, one can replace font information such as "bold"
with textual emphasis (like *this* or _T_H_I_S_). One can
also properly handle the richtext formatting commands
regarding indentation, justification, and others. However,
the above program is all that is necessary in order to
present richtext on a dumb terminal.
} } '/*がすべてのもう一方象徴*/を無視する、ほか、(c!='\n')putc(c、stdout)であるなら。 putc('\n'、stdout)。 良い測定*/のための/* 1つがダム端末で表示におけるこれよりかなり良いrichtextデータができることに注意されるべきです。 特に、1つは原文の強調(_*この*や_T_H I_S_のような)に「ボールド」などの字体情報を置き換えることができます。 また、1つは適切に刻み目、正当化、および他のものに関するrichtext書式付けコマンドを扱うことができます。 しかしながら、上記のプログラムはダム端末の上のrichtextを寄贈するのに必要なすべてです。
Borenstein & Freed [Page 65]
Borensteinであって解放されています。[65ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Appendix E -- Collected Grammar
付録E--集まっている文法
This appendix contains the complete BNF grammar for all the
syntax specified by this document.
この付録はこのドキュメントによって指定されたすべての構文のための完全なBNF文法を含んでいます。
By itself, however, this grammar is incomplete. It refers
to several entities 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.
しかしながら、それ自体で、この文法は不完全です。 それはRFC822によって定義されるいくつかの実体について言及します。 むしろ、このドキュメントはここでそれらの定義を再生させて、2の意図的でない違いを危険にさらすより残っている定義について単にRFC822の読者を参照します。 用語が未定義である、それがRFC822定義を呼ぶどこ。
attribute := token
属性:=象徴
body-part = <"message" as defined in RFC 822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere.>
RFC822(それ自体かサブストリングとしたどこでも指定されたデリミタがすべてのヘッダーフィールドが任意であってメッセージ本体で何処にも起こらないで、オンの線)で>を定義するので、=<「メッセージ」をボディーで分けてください。
boundary := 0*69<bchars> bcharsnospace
境界:=0*69<bchars>bcharsnospace
bchars := bcharsnospace / " "
bchars:=bcharsnospace/、「」
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
「bcharsnospace:=DIGIT/アルファー/、「'「」 /「」 (「/」)/「+」/"_"/」、/「-」/」。」' / "/" / ":" / "=" / "?"
close-delimiter := delimiter "--"
近いデリミタ:=デリミタ「--」
Content-Description := *text
満足している記述:=*テキスト
Content-ID := msg-id
コンテントID:=msg-イド
Content-Transfer-Encoding := "BASE64" / "QUOTED-
PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
満足している転送コード化:=、「BASE64"/、「引用される、印刷可能である、」 x/「8ビット」/「7ビット」/「バイナリー」/トークン、」
Content-Type := type "/" subtype *[";" parameter]
「コンテントタイプ:=は」 /をタイプする」「副-タイプ」*[「」、;、パラメタ]
delimiter := CRLF "--" boundary ; taken from Content-Type
field.
; when content-type is
multipart
; There should be no space
; between "--" and boundary.
デリミタ:=CRLF「--」境界。 コンテントタイプ分野から、取ります。 ; content typeが複合であるときに。 スペースが全くあるべきではありません。 「--」と境界の間で。
encapsulation := delimiter CRLF body-part
カプセル化:=デリミタCRLF身体部分
epilogue := *text ; to be ignored upon
receipt.
エピローグ:=*テキスト。 領収書で無視されるために。
Borenstein & Freed [Page 66]
Borensteinであって解放されています。[66ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
MIME-Version := 1*text
MIMEバージョン:=1*テキスト
multipart-body := preamble 1*encapsulation close-delimiter
epilogue
複合ボディー:=序文1*カプセル化近いデリミタエピローグ
parameter := attribute "=" value
パラメタ:=属性「=」価値
preamble := *text ; to be ignored upon
receipt.
序文:=*テキスト。 領収書で無視されるために。
subtype := token
「副-タイプ」:=トークン
token := 1*<any CHAR except SPACE, CTLs, or tspecials>
トークン:=1*<はSPACE、CTLs、またはtspecials>以外のあらゆるCHARです。
tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
/ "," / ";" / ":" / "\" / <"> ; quoted-string,
/ "/" / "[" / "]" / "?" / "." ; to use within
/ "=" ; parameter values
tspecials:=「(「/」)」/"<"/">"/"@"。 」 「必須は/のそうです」、/、」、;、」 / ":" /「\」/<">"。 「」 引用文字列、/」 //「[「/」]」/“?" / "." ; /「=」の中で使用するために。 パラメタ値
type := "application" / "audio" ; case-
insensitive
/ "image" / "message"
/ "multipart" / "text"
/ "video" / x-token
:=「アプリケーション」/「オーディオ」をタイプしてください。 xケース神経の鈍い/「イメージ」/「メッセージ」/「複合」/「テキスト」/「ビデオ」/トークン
value := token / quoted-string
値の:=トークン/引用文字列
x-token := <The two characters "X-" followed, with no
intervening white space, by any token>
2つのキャラクタ「X」がどんなトークン>も介入している余白なしで続けたx-トークン:=<。
Borenstein & Freed [Page 67]
Borensteinであって解放されています。[67ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Appendix F -- IANA Registration Procedures
付録F--IANA登録手順
MIME has been carefully designed to have extensible
mechanisms, and it is expected that the set of content-
type/subtype pairs and their associated parameters will grow
significantly with time. Several other MIME fields, notably
character set names, access-type parameters for the
message/external-body type, conversions parameters for the
application type, and possibly even Content-Transfer-
Encoding values, are likely to have new values defined over
time. In order to ensure that the set of such values is
developed in an orderly, well-specified, and public manner,
MIME defines a registration process which uses the Internet
Assigned Numbers Authority (IANA) as a central registry for
such values.
MIMEは広げることができるメカニズムを持つように入念に設計されています、そして、時間に応じて内容タイプ/「副-タイプ」組のセットと彼らの関連パラメタがかなり成長すると予想されます。 他のいくつかのMIME分野、著しく文字集合名、外部のメッセージ/ボディータイプへのアクセス型パラメタ(アプリケーションタイプ、およびことによると同等のContent-転送コード化値のための変換パラメタ)は時間がたつにつれて定義された新しい値を持っていそうです。 そのような値のセットが規則的で、よく指定されて、公共の方法で発展するのを確実にするために、MIMEはそのような値に、中央の登録としてインターネットAssigned民数記Authority(IANA)を使用する登録手続を定義します。
In general, parameters in the content-type header field are
used to convey supplemental information for various content
types, and their use is defined when the content-type and
subtype are defined. New parameters should not be defined
as a way to introduce new functionality.
一般に、content typeヘッダーフィールドにおけるパラメタは様々なcontent typeのための補足的情報を伝えるのに使用されます、そして、content typeと「副-タイプ」が定義されるとき、彼らの使用は定義されます。 新しい機能性を紹介する方法と新しいパラメタを定義するべきではありません。
In order to simplify and standardize the registration
process, this appendix gives templates for the registration
of new values with IANA. Each of these is given in the form
of an email message template, to be filled in by the
registering party.
登録手続を簡素化して、標準化するために、この付録はIANAとの新しい値の登録のためのテンプレートを与えます。 登録パーティーによって記入されるように、メールメッセージテンプレートの形でそれぞれのこれらを与えます。
F.1 Registration of New Content-type/subtype Values
新しい文書内容/「副-タイプ」値のF.1登録
Note that MIME is generally expected to be extended by
subtypes. If a new fundamental top-level type is needed,
its specification should be published as an RFC or
submitted in a form suitable to become an RFC, and be
subject to the Internet standards process.
一般に、血液型亜型によってMIMEが広げられると予想されることに注意してください。 新しい基本的なトップレベルタイプを必要とするなら、仕様をRFCとして発表するべきであるか、またはRFCになって、インターネット標準化過程を受けることがあるのにおいて適当なフォームで提出するべきです。
To: IANA@isi.edu
Subject: Registration of new MIME content-type/subtype
To: IANA@isi.edu Subject: 新しいMIME content type/「副-タイプ」の登録
MIME type name:
MIMEの種類名:
(If the above is not an existing top-level MIME type,
please explain why an existing type cannot be used.)
(上記が既存のトップレベルMIMEの種類でないなら、なぜ既存のタイプを使用できないか説明してください。)
MIME subtype name:
MIME「副-タイプ」は以下を命名します。
Required parameters:
必要なパラメタ:
Optional parameters:
任意のパラメタ:
Encoding considerations:
問題をコード化します:
Security considerations:
セキュリティ問題:
Borenstein & Freed [Page 68]
Borensteinであって解放されています。[68ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Published specification:
広められた仕様:
(The published specification must be an Internet RFC or
RFC-to-be if a new top-level type is being defined, and
must be a publicly available specification in any
case.)
(広められた仕様は、新しいトップレベルタイプが定義されているなら、インターネットRFCか未来のRFCでなければならなく、どのような場合でも、公的に利用可能な仕様であるに違いありません。)
Person & email address to contact for further
information:
F.2 Registration of New Character Set Values
詳細のために連絡する人とEメールアドレス: 新しい文字コード値のF.2登録
To: IANA@isi.edu
Subject: Registration of new MIME character set value
To: IANA@isi.edu Subject: 新しいMIME文字集合価値の登録
MIME character set name:
MIME文字集合名:
Published specification:
広められた仕様:
(The published specification must be an Internet RFC or
RFC-to-be or an international standard.)
(広められた仕様は、インターネットRFC、未来のRFCまたは世界規格であるに違いありません。)
Person & email address to contact for further
information:
詳細のために連絡する人とEメールアドレス:
F.3 Registration of New Access-type Values for
Message/external-body
外部のメッセージ/ボディーのための新しいアクセス型値のF.3登録
To: IANA@isi.edu
Subject: Registration of new MIME Access-type for
Message/external-body content-type
To: IANA@isi.edu Subject: 外部のMessage/ボディーcontent typeのための新しいMIME Access-タイプの登録
MIME access-type name:
MIMEアクセス型は以下を命名します。
Required parameters:
必要なパラメタ:
Optional parameters:
任意のパラメタ:
Published specification:
広められた仕様:
(The published specification must be an Internet RFC or
RFC-to-be.)
(広められた仕様は、インターネットRFCか未来のRFCであるに違いありません。)
Person & email address to contact for further
information:
詳細のために連絡する人とEメールアドレス:
F.4 Registration of New Conversions Values for Application
アプリケーションのための新しい変換値のF.4登録
To: IANA@isi.edu
Subject: Registration of new MIME Conversions value
for Application content-type
To: IANA@isi.edu Subject: Application content typeのための新しいMIME Conversions価値の登録
MIME Conversions name:
MIME Conversionsは以下を命名します。
Borenstein & Freed [Page 69]
Borensteinであって解放されています。[69ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Published specification:
広められた仕様:
(The published specification must be an Internet RFC or
RFC-to-be.)
(広められた仕様は、インターネットRFCか未来のRFCであるに違いありません。)
Person & email address to contact for further
information:
詳細のために連絡する人とEメールアドレス:
Borenstein & Freed [Page 70]
Borensteinであって解放されています。[70ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Appendix G -- Summary of the Seven Content-types
付録G--7つの文書内容の概要
Content-type: text
文書内容: テキスト
Subtypes defined by this document: plain, richtext
血液型亜型はこのドキュメントで定義しました: 単にrichtext
Important Parameters: charset
重要なパラメタ: charset
Encoding notes: quoted-printable generally preferred if an
encoding is needed and the character set is mostly an
ASCII superset.
コード化は以下に注意します。 引用されて印刷可能である、一般に、コード化が必要であり、文字集合がほとんどASCIIスーパーセットであるなら好まれます。
Security considerations: Rich text formats such as TeX and
Troff often contain mechanisms for executing arbitrary
commands or file system operations, and should not be
used automatically unless these security problems have
been addressed. Even plain text may contain control
characters that can be used to exploit the capabilities
of "intelligent" terminals and cause security
violations. User interfaces designed to run on such
terminals should be aware of and try to prevent such
problems.
________________________________________________________________
セキュリティ問題: TeXやTroffなどのリッチテキストフォーマットをしばしば任意のコマンドかファイルシステム・オペレーションを実行するためのメカニズムを含んでいて、これらの警備上の問題を扱っていないなら、自動的に使用するべきではありません。 プレーンテキストさえ「知的な」端末と原因安全の侵害の能力を開発するのに使用できる制御文字を含むかもしれません。 端末が意識しているべきであるそのようなもので走って、そのような問題を防ごうとするように設計されたユーザインタフェース。________________________________________________________________
Content-type: multipart
文書内容: 複合
Subtypes defined by this document: mixed, alternative,
digest, parallel.
血液型亜型はこのドキュメントで定義しました: 混ぜられて、代替であり、平行に読みこなしてください。
Important Parameters: boundary
重要なパラメタ: 境界
Encoding notes: No content-transfer-encoding is permitted.
コード化は以下に注意します。 満足している転送コード化は受入れられません。
________________________________________________________________
________________________________________________________________
Content-type: message
文書内容: メッセージ
Subtypes defined by this document: rfc822, partial,
external-body
血液型亜型はこのドキュメントで定義しました: 部分の、そして、外部のボディーのrfc822
Important Parameters: id, number, total
重要なパラメタ: イド、数、合計
Encoding notes: No content-transfer-encoding is permitted.
コード化は以下に注意します。 満足している転送コード化は受入れられません。
________________________________________________________________
________________________________________________________________
Content-type: application
文書内容: アプリケーション
Subtypes defined by this document: octet-stream,
postscript, oda
血液型亜型はこのドキュメントで定義しました: 八重奏ストリーム、追伸、oda
Important Parameters: profile
重要なパラメタ: プロフィール
Borenstein & Freed [Page 71]
Borensteinであって解放されています。[71ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Encoding notes: base64 generally preferred for octet-stream
or other unreadable subtypes.
コード化は以下に注意します。 一般に、base64は何らかの八重奏ストリームのために読みにくい血液型亜型を好みました。
Security considerations: This type is intended for the
transmission of data to be interpreted by locally-installed
programs. If used, for example, to transmit executable
binary programs or programs in general-purpose interpreted
languages, such as LISP programs or shell scripts, severe
security problems could result. In general, authors of
mail-reading agents are cautioned against giving their
systems the power to execute mail-based application data
without carefully considering the security implications.
While it is certainly possible to define safe application
formats and even safe interpreters for unsafe formats, each
interpreter should be evaluated separately for possible
security problems.
________________________________________________________________
セキュリティ問題: データの伝達は局所的にインストールされたプログラムでこのタイプは解釈されるつもりでした。例えば、伝わるのに使用されるなら、一般に、実行可能な2進のプログラムかプログラムがインタープリタ型言語を目標とします、LISPプログラムやシェルスクリプトのように厳しい警備上の問題は結果として生じることができました。 一般に、メールを閲読するエージェントの作者は、セキュリティが含意であると慎重に考えないメールベースのアプリケーションデータを実行する権限を彼らのシステムに与えないように警告されます。 確かに、危険な形式のために安全な依頼書と安全なインタプリタさえ定義するのが可能である間、各インタプリタは可能な警備上の問題によって別々に評価されるべきです。________________________________________________________________
Content-type: image
文書内容: イメージ
Subtypes defined by this document: jpeg, gif
血液型亜型はこのドキュメントで定義しました: jpeg、gif
Important Parameters: none
重要なパラメタ: なし
Encoding notes: base64 generally preferred
コード化は以下に注意します。 一般に、好まれたbase64
________________________________________________________________
________________________________________________________________
Content-type: audio
文書内容: オーディオ
Subtypes defined by this document: basic
血液型亜型はこのドキュメントで定義しました: 基本的
Important Parameters: none
重要なパラメタ: なし
Encoding notes: base64 generally preferred
コード化は以下に注意します。 一般に、好まれたbase64
________________________________________________________________
________________________________________________________________
Content-type: video
文書内容: ビデオ
Subtypes defined by this document: mpeg
血液型亜型はこのドキュメントで定義しました: mpeg
Important Parameters: none
重要なパラメタ: なし
Encoding notes: base64 generally preferred
コード化は以下に注意します。 一般に、好まれたbase64
Borenstein & Freed [Page 72]
Borensteinであって解放されています。[72ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Appendix H -- Canonical Encoding Model
付録H--正準なコード化はモデル化されます。
There was some confusion, in earlier drafts of this memo,
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. For this reason, a canonical model for encoding is
presented below.
何らかの混乱がありました、このメモの以前の草稿で、メールデータがいつ標準形に変換されて、コード化されるかことであり、特に、このプロセスがどのようにCRLFsの処理に影響するかモデルに関して、システムによってニューラインの表現が大いに異なるなら。 この理由で、コード化のための規範的モデルは以下に提示されます。
The process of composing a MIME message part can be modelled
as being done in a number of steps. Note that these steps
are roughly similar to those steps used in RFC1113:
多くのステップでするとしてMIMEメッセージ部分を構成するプロセスをモデル化できます。 これらのステップがおよそRFC1113で使用されるそれらのステップと同様であることに注意してください:
Step 1. Creation of local form.
1を踏んでください。 地方のフォームの作成。
The body part to be transmitted is created in the system's
native format. The native character set is used, and where
appropriate local end of line conventions are used as well.
The may be a UNIX-style text file, or a Sun raster image, or
a VMS indexed file, or audio data in a system-dependent
format stored only in memory, or anything else that
corresponds to the local model for the representation of
some form of information.
伝えられるべき身体の部分はシステムのネイティブの形式で作成されます。 ネイティブの文字集合はまた、適切な地方の行末コンベンションが使用されるところで使用されます。 UNIX-スタイルテキストファイルか、Sunラスター・イメージであるかもしれないVMSはファイルに索引をつけたか、またはシステム依存する形式のオーディオデータが何らかのフォームの情報の表現のためのローカルのモデルに文通されるメモリ、または他の何かだけを蓄えました。
Step 2. Conversion to canonical form.
2を踏んでください。 標準形への変換。
The entire body part, including "out-of-band" information
such as record lengths and possibly file attribute
information, is converted to a universal canonical form.
The specific content type of the body part as well as its
associated attributes dictate the nature of the canonical
form that is used. Conversion to the proper canonical form
may involve character set conversion, transformation of
audio data, compression, or various other operations
specific to the various content types.
「バンドの外に」レコード長やことによるとファイル属性情報の情報を含む全身部分は普遍的な標準形に変換されます。 関連属性と同様に身体の部分の特定のcontent typeは使用された標準形の本質を決めます。 適切な標準形への変換は文字集合変換、オーディオデータ、圧縮、または様々なcontent typeに特定の他の様々な操作の変換にかかわるかもしれません。
For example, in the case of text/plain data, the text must
be converted to a supported character set and lines must be
delimited with CRLF delimiters in accordance with RFC822.
Note that the restriction on line lengths implied by RFC822
is eliminated if the next step employs either quoted-
printable or base64 encoding.
例えば、テキスト/明瞭なデータの場合では、サポートしている文字集合にテキストを変換しなければなりません、そして、RFC822によると、CRLFデリミタで系列を区切らなければなりません。 次のステップ雇用が印刷可能であるかbase64コード化を引用したならRFC822によって含意された行長における制限が排除されることに注意してください。
Step 3. Apply transfer encoding.
3を踏んでください。 転送コード化を適用してください。
A Content-Transfer-Encoding appropriate for this body part
is applied. Note that there is no fixed relationship
between the content type and the transfer encoding. In
particular, it may be appropriate to base the choice of
base64 or quoted-printable on character frequency counts
which are specific to a given instance of body part.
このボディーに、適切なContent転送コード化部分は適用されています。 content typeと転送コード化との固定関係が全くないことに注意してください。 base64か身体の部分の与えられたインスタンスに特定のキャラクタで印刷可能な頻度数の選択を基礎づけるのは特に、適切であるかもしれません。
Borenstein & Freed [Page 73]
Borensteinであって解放されています。[73ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Step 4. Insertion into message.
4を踏んでください。 メッセージへの挿入。
The encoded object is inserted into a MIME message with
appropriate body part headers and boundary markers.
コード化された物は適切なボディー部分ヘッダーと境界マーカーでMIMEメッセージに挿入されます。
It is vital to note that these steps are only a model; they
are specifically NOT a blueprint for how an actual system
would be built. In particular, the model fails to account
for two common designs:
これらのステップがモデルにすぎないことに注意するのは重大です。 それらは、明確に実際のシステムがどう構築されるか青写真ではありません。 特に、モデルは2つの一般的なデザインを説明しません:
1. In many cases the conversion to a canonical
form prior to encoding will be subsumed into the
encoder itself, which understands local formats
directly. For example, the local newline
convention for text bodyparts might be carried
through to the encoder itself along with knowledge
of what that format is.
1. 多くの場合、コード化の前の標準形への変換はエンコーダ自体に包括されるでしょう。(それは、直接地方の形式を理解しています)。 例えば、テキストbodypartsのための地方のニューラインコンベンションはその形式が何であるかに関する知識に伴うエンコーダ自体に突き抜けた状態で運ばれるかもしれません。
2. The output of the encoders may have to pass
through one or more additional steps prior to
being transmitted as a message. As such, the
output of the encoder may not be compliant with
the formats specified by RFC822. In particular,
once again it may be appropriate for the
converter's output to be expressed using local
newline conventions rather than using the standard
RFC822 CRLF delimiters.
2. エンコーダの出力はメッセージとして伝えられる前に、1個以上の追加階段を通り抜けなければならないかもしれません。 そういうものとして、形式がRFC822によって指定されている状態で、エンコーダの出力は対応しないかもしれません。 もう一度、コンバータの出力が急送されるのは、標準のRFC822 CRLFデリミタを使用するよりむしろ地方のニューラインコンベンションを使用するのにおいて特に、適切であるかもしれません。
Other implementation variations are conceivable as well.
The only important aspect of this discussion is that the
resulting messages are consistent with those produced by the
model described here.
また、他の実現変化は想像できます。 この議論の唯一の重要な一面は結果として起こるメッセージがここで説明されたモデルによって生産されるそれらと一致しているということです。
Borenstein & Freed [Page 74]
Borensteinであって解放されています。[74ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
References
参照
[US-ASCII] Coded Character Set--7-Bit American Standard Code
for Information Interchange, ANSI X3.4-1986.
[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
[ATK] Borenstein, Nathaniel S., Multimedia Applications
Development with the Andrew Toolkit, Prentice-Hall, 1990.
[ATK]Borenstein、ナザニエルS.、アンドリューツールキット、新米のホール、1990へのマルチメディア応用開発。
[GIF] Graphics Interchange Format (Version 89a), Compuserve,
Inc., Columbus, Ohio, 1990.
[GIF]グラフィックスは形式を交換します。(バージョン89a)、Compuserve Inc.、コロンブス、オハイオ、1990。
[ISO-2022] International Standard--Information Processing--
ISO 7-bit and 8-bit coded character sets--Code extension
techniques, ISO 2022:1986.
[ISO-2022] 国際規格--情報Processing--ISOの7ビットの、そして、8ビットのコード化文字集合--コード拡張のテクニック、ISO、2022:1986
[ISO-8859] Information Processing -- 8-bit Single-Byte Coded
Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO
8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2,
1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part
4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5:
Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7:
Latin/Greek alphabet, ISO 8859-7, 1987. Part 8:
Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin
alphabet No. 5, ISO 8859-9, 1990.
[ISO-8859]情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部: ローマ字No.1、ISO8859-1:1987。 第2部: ローマ字No.2、ISO8859-2、1987。 パート3: ローマ字No.3、ISO8859-3、1988。 パート4: ローマ字No.4、ISO8859-4、1988。 パート5: ラテン/キリル文字、ISO8859-5、1988。 パート6: ラテン/アラビア文字、ISO8859-6、1987。 パート7: ラテン/ギリシャ語アルファベット、ISO8859-7、1987。 パート8: ラテン語の、または、ヘブライのアルファベット、ISO8859-8、1988。 パート9: ローマ字No.5、ISO8859-9、1990。
[ISO-646] International Standard--Information Processing--
ISO 7-bit coded character set for information interchange,
ISO 646:1983.
[ISO-646]国際規格--情報Processing--情報交換、ISOのためのISOの7ビットのコード化文字集合、646:1983
[MPEG] Video Coding Draft Standard ISO 11172 CD, ISO
IEC/TJC1/SC2/WG11 (Motion Picture Experts Group), May, 1991.
[MPEG]ビデオ符号化の草稿の標準のISO11172CD、ISO IEC/TJC1/SC2/WG11(エムペグ)、1991年5月。
[ODA] ISO 8613; Information Processing: Text and Office
System; Office Document Architecture (ODA) and Interchange
Format (ODIF), Part 1-8, 1989.
[小田]ISO8613。 情報処理: テキストとオフィス・システム。 事務文書体系(ODA)と置き換えは(ODIF)、第1部-8、1989をフォーマットします。
[PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva,
1972, "Pulse Code Modulation (PCM) of Voice Frequencies".
推薦G.711、ジュネーブ[PCM]CCITT、分冊III.4--1972、「音声周波数のパルスコードの変調(PCM)。」
[POSTSCRIPT] Adobe Systems, Inc., PostScript Language
Reference Manual, Addison-Wesley, 1985.
[追伸]アドビ・システムズInc.、ポストスクリプト言語リファレンスマニュアル、アディソン-ウエスリー、1985。
[X400] Schicker, Pietro, "Message Handling Systems, X.400",
Message Handling Systems and Distributed Applications, E.
Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-
Holland, 1989, pp. 3-41.
ピエトロ、「メッセージハンドリングシステム、X.400」メッセージハンドリングの[X400]Schickerとシステムと分配されたアプリケーション、E.Stefferud、O-j。 ジェイコブセン、およびP.Schicker、eds、北部オランダ、1989、ページ 3-41.
[RFC-783] Sollins, K.R. TFTP Protocol (revision 2). June,
1981, MIT, RFC-783.
[RFC-783]Sollins、K.R.TFTPは(改正2)について議定書の中で述べます。 1981年6月、MIT、RFC-783。
[RFC-821] Postel, J.B. Simple Mail Transfer Protocol.
August, 1982, USC/Information Sciences Institute, RFC-821.
[RFC-821]ポステル、J.のB.の簡単なメール転送プロトコル。 1982年8月、科学が設けるUSC/情報、RFC-821。
Borenstein & Freed [Page 75]
Borensteinであって解放されています。[75ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
[RFC-822] Crocker, D. Standard for the format of ARPA
Internet text messages. August, 1982, UDEL, RFC-822.
[RFC-822]クロッカー、ARPAインターネット・テキスト・メッセージの形式のためのD.Standard。 1982年8月のUDEL、RFC-822。
[RFC-934] Rose, M.T.; Stefferud, E.A. Proposed standard
for message encapsulation. January, 1985, Delaware
and NMA, RFC-934.
[RFC-934]ローズ、M.T.。 Stefferud、メッセージカプセル化のE.A.Proposed規格。 1985年1月のデラウェアとNMA、RFC-934。
[RFC-959] Postel, J.B.; Reynolds, J.K. File Transfer
Protocol. October, 1985, USC/Information Sciences
Institute, RFC-959.
[RFC-959]ポステル、J.B.。 レイノルズ、J.K.ファイル転送プロトコル。 1985年10月、科学が設けるUSC/情報、RFC-959。
[RFC-1049] Sirbu, M.A. Content-Type header field for
Internet messages. March, 1988, CMU, RFC-1049.
[RFC-1049]シルブ、インターネットメッセージのためのM.A.コンテントタイプヘッダーフィールド。 1988年3月、米カーネギーメロン大学、RFC-1049。
[RFC-1113] Linn, J. Privacy enhancement for Internet
electronic mail: Part I - message encipherment and
authentication procedures. August, 1989, IAB Privacy Task
Force, RFC-1113.
[RFC-1113]リン、インターネット電子メールのためのJ.Privacy増進: Iを分けてください--メッセージ暗号文と認証手順。 1989年8月、IABプライバシー特別委員会、RFC-1113。
[RFC-1154] Robinson, D.; Ullmann, R. Encoding header field
for Internet messages. April, 1990, Prime Computer,
Inc., RFC-1154.
[RFC-1154] ロビンソン、D.。 ウルマン、インターネットメッセージのためのR.Encodingヘッダーフィールド。 1990年4月、プライムコンピュータInc.、RFC-1154。
[RFC-1342] Moore, Keith, Representation of Non-Ascii Text in
Internet Message Headers. June, 1992, University of
Tennessee, RFC-1342.
[RFC-1342] ムーア、キース、インターネットメッセージヘッダーの非アスキーテキストの表現。 1992年6月、テネシー大学、RFC-1342。
Security Considerations
セキュリティ問題
Security issues are discussed in Section 7.4.2 and in
Appendix G. Implementors should pay special attention to
the security implications of any mail content-types that can
cause the remote execution of any actions in the recipient's
environment. In such cases, the discussion of the
applicaton/postscript content-type in Section 7.4.2 may
serve as a model for considering other content-types with
remote execution capabilities.
セクション7.4.2で安全保障問題について議論します、そして、Appendixでは、G.Implementorsは受取人の環境でいずれのリモート実行を引き起こす場合がある満足しているタイプ動作をどんなメールのセキュリティ含意に関する特別な注意にも支払うはずです。 そのような場合、セクション7.4.2における、追伸の満足しているapplicaton/タイプの議論は、リモート実行能力がある他の満足しているタイプを考えるために手本になるかもしれません。
Borenstein & Freed [Page 76]
Borensteinであって解放されています。[76ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
Authors' Addresses
作者のアドレス
For more information, the authors of this document may be
contacted via Internet mail:
詳しくは、インターネット・メールでこのドキュメントの作者は連絡されるかもしれません:
Nathaniel S. Borenstein
MRE 2D-296, Bellcore
445 South St.
Morristown, NJ 07962-1910
ナザニエルS.Borenstein MRE2D-296、南聖モリスタウン、Bellcore445ニュージャージー07962-1910
Phone: +1 201 829 4270
Fax: +1 201 829 7019
Email: nsb@bellcore.com
以下に電話をしてください。 +1 201 829、4270Fax: +1 7019年の201 829メール: nsb@bellcore.com
Ned Freed
Innosoft International, Inc.
250 West First Street
Suite 240
Claremont, CA 91711
ネッドは最初に、通りSuite240クレアーモント、Innosoftの国際Inc.250の西カリフォルニア 91711を解放しました。
Phone: +1 714 624 7907
Fax: +1 714 621 5319
Email: ned@innosoft.com
以下に電話をしてください。 +1 714 624、7907Fax: +1 5319年の714 621メール: ned@innosoft.com
Borenstein & Freed [Page 77]
Borensteinであって解放されています。[77ページ]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
RFC 1341MIME: 多目的のインターネットメールExtensionsJune1992
THIS PAGE INTENTIONALLY LEFT BLANK.
このページは故意に空白を出ました。
Please discard this page and place the following table of
contents after the title page.
タイトル・ページの後にこのページを捨てて、以下の目次を置いてください。
Borenstein & Freed [Page i]
Borensteinであって解放されています。[ページi]
Table of Contents
目次
1 Introduction....................................... 1
2 Notations, Conventions, and Generic BNF Grammar.... 3
3 The MIME-Version Header Field...................... 5
4 The Content-Type Header Field...................... 6
5 The Content-Transfer-Encoding Header Field......... 10
5.1 Quoted-Printable Content-Transfer-Encoding......... 14
5.2 Base64 Content-Transfer-Encoding................... 17
6 Additional Optional Content- Header Fields......... 19
6.1 Optional Content-ID Header Field................... 19
6.2 Optional Content-Description Header Field.......... 19
7 The Predefined Content-Type Values................. 20
7.1 The Text Content-Type.............................. 20
7.1.1 The charset parameter.............................. 20
7.1.2 The Text/plain subtype............................. 23
7.1.3 The Text/richtext subtype.......................... 23
7.2 The Multipart Content-Type......................... 29
7.2.1 Multipart: The common syntax...................... 30
7.2.2 The Multipart/mixed (primary) subtype.............. 34
7.2.3 The Multipart/alternative subtype.................. 34
7.2.4 The Multipart/digest subtype....................... 36
7.2.5 The Multipart/parallel subtype..................... 36
7.3 The Message Content-Type........................... 37
7.3.1 The Message/rfc822 (primary) subtype............... 37
7.3.2 The Message/Partial subtype........................ 37
7.3.3 The Message/External-Body subtype.................. 40
7.4 The Application Content-Type....................... 46
7.4.1 The Application/Octet-Stream (primary) subtype..... 46
7.4.2 The Application/PostScript subtype................. 47
7.4.3 The Application/ODA subtype........................ 50
7.5 The Image Content-Type............................. 51
7.6 The Audio Content-Type............................. 51
7.7 The Video Content-Type............................. 51
7.8 Experimental Content-Type Values................... 51
Summary............................................ 53
Acknowledgements................................... 54
Appendix A -- Minimal MIME-Conformance............. 56
Appendix B -- General Guidelines For Sending Email Data59
Appendix C -- A Complex Multipart Example.......... 62
Appendix D -- A Simple Richtext-to-Text Translator in C64
Appendix E -- Collected Grammar.................... 66
Appendix F -- IANA Registration Procedures......... 68
F.1 Registration of New Content-type/subtype Values..68
F.2 Registration of New Character Set Values...... 69
F.3 Registration of New Access-type Values for Message/external-body69
F.4 Registration of New Conversions Values for Application69
Appendix G -- Summary of the Seven Content-types... 71
Appendix H -- Canonical Encoding Model............. 73
References......................................... 75
Security Considerations............................ 76
Authors' Addresses................................. 77
1つの序論… 1 2の記法、コンベンション、および一般的なBNF文法… MIMEバージョンヘッダーがさばく3 3… コンテントタイプヘッダーがさばく5 4… 内容がコード化を移しているヘッダーがさばく6 5… 10 5.1 引用されて印刷可能な満足している転送コード化… 14 5.2 Base64の満足している転送コード化… 17 6 追加任意の内容ヘッダーフィールド… 19 6.1 任意のコンテントIDヘッダーフィールド… 19 6.2 任意の満足している記述ヘッダーフィールド… 19 7 事前に定義されたコンテントタイプ値… 20 7.1 テキストコンテントタイプ… 20 7.1 .1 charsetパラメタ… 20 7.1 .2 Text/明瞭な「副-タイプ」… 23 7.1 .3 Text/richtext subtype… 23 7.2 複合コンテントタイプ… 29 7.2 .1 複合: 一般的な構文… 30 7.2 .2 Multipart/混ぜられた(第一の)「副-タイプ」… 34 7.2 .3 Multipart/代替手段「副-タイプ」… 34 7.2 .4 Multipart/ダイジェスト「副-タイプ」… 36 7.2 .5 Multipart/平行な「副-タイプ」… 36 7.3 メッセージコンテントタイプ… 37 7.3 .1 Message/rfc822の(第一)の「副-タイプ」… 37 7.3 .2 Message/部分的な「副-タイプ」… 37 7.3 .3 外部のMessage/ボディー「副-タイプ」… 40 7.4 アプリケーションコンテントタイプ… 46 7.4 .1 八重奏Application/流れの(第一)の「副-タイプ」… 46 7.4 .2 Application/ポストスクリプト「副-タイプ」… 47 7.4 .3 Application/ODA「副-タイプ」… 50 7.5 イメージコンテントタイプ… 51 7.6 オーディオコンテントタイプ… 51 7.7 ビデオコンテントタイプ… 51 7.8 実験コンテントタイプ値… 51概要… 53の承認… 54 付録A--最小量のMIME順応… 56 付録B--送付のための一般的ガイドラインは付録CをData59にメールします--複雑な複合例。 62 付録D(C64付録EのRichtextからテキストへの純真な翻訳者)は文法を集めました… 66 付録F--IANA登録手順… 68 新しい文書内容/「副-タイプ」値のF.1登録。68 新しい文字コード値のF.2登録… 69 新しいアクセス型のF.3登録は新しい変換の外部のメッセージ/body69 F.4登録のためにApplication69付録Gのための値を評価します--7つの文書内容の概要 71 付録H--正準なコード化はモデル化されます… 73の参照箇所… 75 セキュリティ問題… 76人の作者のアドレス… 77
Borenstein & Freed [Page ii]
Borensteinであって解放されています。[ページii]
Borenstein & Freed [Page iii]
Borensteinであって解放されています。[ページiii]
一覧
スポンサーリンク
