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]
一覧
スポンサーリンク