RFC1521 日本語訳
1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanismsfor Specifying and Describing the Format of Internet Message Bodies.N. Borenstein, N. Freed. September 1993. (Format: TXT=187424, PS=393670, PDF=205091 bytes) (Obsoletes RFC1341) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updated by RFC1590) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Borenstein
Request for Comments: 1521 Bellcore
Obsoletes: 1341 N. Freed
Category: Standards Track Innosoft
September 1993
Borensteinがコメントのために要求するワーキンググループN.をネットワークでつないでください: 1521 Bellcoreは以下を時代遅れにします。 1341年のN.の解放されたカテゴリ: 標準化過程Innosoft1993年9月
MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing
the Format of Internet Message Bodies
パート1をまねてください(マルチパーパスインターネットメールエクステンション): インターネットメッセージ本体の形式を指定して、説明するためのメカニズム
Status of this Memo
このMemoの状態
This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
STD 11, 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 STD 11, 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.
STD11、RFC822はメッセージヘッダーに関するかなりの詳細を指定しますが、メッセージ内容、またはメッセージ本体を残すメッセージ表現プロトコルを定義します、平坦なASCIIテキストとして。 このドキュメントは、複合原文の、そして、非原文のメッセージ本体が情報の損失なしで表されて、交換されるのを許容するためにメッセージ本体の書式を再定義します。 これは、その仕事をRFC934とSTD11に記録された、以前の仕事、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. Such extensions are the subject of a companion document [RFC-1522].
このドキュメントは、米国-ASCIIテキストデータ以外の何も可能にするためにインターネット・メールヘッダーフィールドを広げていません。 そのような拡大は仲間ドキュメント[RFC-1522]の対象です。
This document is a revision of RFC 1341. Significant differences from RFC 1341 are summarized in Appendix H.
このドキュメントはRFC1341の改正です。 RFC1341からの著しい違いはAppendix Hにまとめられます。
Borenstein & Freed [Page 1] RFC 1521 MIME September 1993
Borensteinと解放された[1ページ]RFC1521は1993年9月にまねます。
Table of Contents
目次
1. Introduction....................................... 3 2. Notations, Conventions, and Generic BNF Grammar.... 6 3. The MIME-Version Header Field...................... 7 4. The Content-Type Header Field...................... 9 5. The Content-Transfer-Encoding Header Field......... 13 5.1. Quoted-Printable Content-Transfer-Encoding......... 18 5.2. Base64 Content-Transfer-Encoding................... 21 6. Additional Content-Header Fields................... 23 6.1. Optional Content-ID Header Field................... 23 6.2. Optional Content-Description Header Field.......... 24 7. The Predefined Content-Type Values................. 24 7.1. The Text Content-Type.............................. 24 7.1.1. The charset parameter.............................. 25 7.1.2. The Text/plain subtype............................. 28 7.2. The Multipart Content-Type......................... 28 7.2.1. Multipart: The common syntax...................... 29 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..................... 37 7.2.6. Other Multipart subtypes........................... 37 7.3. The Message Content-Type........................... 38 7.3.1. The Message/rfc822 (primary) subtype............... 38 7.3.2. The Message/Partial subtype........................ 39 7.3.3. The Message/External-Body subtype.................. 42 7.3.3.1. The "ftp" and "tftp" access-types............... 44 7.3.3.2. The "anon-ftp" access-type...................... 45 7.3.3.3. The "local-file" and "afs" access-types......... 45 7.3.3.4. The "mail-server" access-type................... 45 7.3.3.5. Examples and Further Explanations............... 46 7.4. The Application Content-Type....................... 49 7.4.1. The Application/Octet-Stream (primary) subtype..... 50 7.4.2. The Application/PostScript subtype................. 50 7.4.3. Other Application subtypes......................... 53 7.5. The Image Content-Type............................. 53 7.6. The Audio Content-Type............................. 54 7.7. The Video Content-Type............................. 54 7.8. Experimental Content-Type Values................... 54 8. Summary............................................ 56 9. Security Considerations............................ 56 10. Authors' Addresses................................. 57 11. Acknowledgements................................... 58 Appendix A -- Minimal MIME-Conformance.................... 60 Appendix B -- General Guidelines For Sending Email Data... 63 Appendix C -- A Complex Multipart Example................. 66 Appendix D -- Collected Grammar........................... 68
1. 序論… 3 2. 記法、コンベンション、およびジェネリックBNF文法… 6 3. MIMEバージョンヘッダーフィールド… 7 4. コンテントタイプヘッダーフィールド… 9 5. 満足している転送コード化ヘッダーフィールド… 13 5.1. 引用されて印刷可能な満足している転送コード化… 18 5.2. Base64の満足している転送コード化… 21 6. 追加満足しているヘッダーフィールド… 23 6.1. 任意のコンテントIDヘッダーフィールド… 23 6.2. 任意の満足している記述ヘッダーフィールド… 24 7. 事前に定義されたコンテントタイプ値… 24 7.1. テキストコンテントタイプ… 24 7.1.1. charsetパラメタ… 25 7.1.2. Text/明瞭な「副-タイプ」… 28 7.2. 複合コンテントタイプ… 28 7.2.1. 複合: 一般的な構文… 29 7.2.2. Multipart/混ぜられた(プライマリ)「副-タイプ」… 34 7.2.3. Multipart/代替手段「副-タイプ」… 34 7.2.4. Multipart/ダイジェスト「副-タイプ」… 36 7.2.5. Multipart/平行な「副-タイプ」… 37 7.2.6. 他のMultipart血液型亜型… 37 7.3. メッセージコンテントタイプ… 38 7.3.1. Message/rfc822の(プライマリ)の「副-タイプ」… 38 7.3.2. Message/部分的な「副-タイプ」… 39 7.3.3. 外部のMessage/ボディー「副-タイプ」… 42 7.3.3.1. "ftp"と"tftp"はアクセスしてタイプされます… 44 7.3.3.2. 「やがて、ftpな」アクセスタイプ… 45 7.3.3.3. 「ローカルファイル」と"afs"はアクセスしてタイプされます… 45 7.3.3.4. 「メールサーバ」アクセスタイプ… 45 7.3.3.5. 例とさらなる説明… 46 7.4. アプリケーションコンテントタイプ… 49 7.4.1. 八重奏Application/ストリームの(プライマリ)の「副-タイプ」… 50 7.4.2. Application/ポストスクリプト「副-タイプ」… 50 7.4.3. 他のApplication血液型亜型… 53 7.5. イメージコンテントタイプ… 53 7.6. オーディオコンテントタイプ… 54 7.7. ビデオコンテントタイプ… 54 7.8. 実験コンテントタイプ値… 54 8. 概要… 56 9. セキュリティ問題… 56 10. 作者のアドレス… 57 11. 承認… 58 付録A--最小量のMIME順応… 60 付録B--送付のための一般的ガイドラインはデータをメールします… 63 付録C--複雑な複合例… 66 付録D--文法を集めます… 68
Borenstein & Freed [Page 2] RFC 1521 MIME September 1993
Borensteinと解放された[2ページ]RFC1521は1993年9月にまねます。
Appendix E -- IANA Registration Procedures................ 72
E.1 Registration of New Content-type/subtype Values...... 72
E.2 Registration of New Access-type Values
for Message/external-body............................ 73
Appendix F -- Summary of the Seven Content-types.......... 74
Appendix G -- Canonical Encoding Model.................... 76
Appendix H -- Changes from RFC 1341....................... 78
References................................................ 80
付録E--IANA登録手順… 72 新しい文書内容/「副-タイプ」値のE.1登録… 72 外部のメッセージ/ボディーのための新しいアクセス型値のE.2登録… 73 付録F--7つの文書内容の概要… 74 付録G--正準なコード化はモデル化されます… 76 付録H--RFC1341からの変化… 78の参照箇所… 80
1. Introduction
1. 序論
Since its publication in 1982, STD 11, 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 STD 10, RFC 821 [RFC-821]. As the format has seen wider use, a number of limitations have proven increasingly restrictive for the user community.
1982年の公表、STD11以来、RFC822[RFC-822]はインターネットに関する原文のメール・メッセージの標準書式を定義しています。 成功はRFC822形式が採用されたように完全かかなりSTD10RFC821[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 1421, the Andrew Toolkit Representation [ATK], and many others.
RFC821/822に基づいているメールシステムの注目に値する限界の1つは彼らが電子メールメッセージのコンテンツを7ビットのASCIIの比較的短い系列に制限するという事実です。 これによって、ユーザはやむを得ず、地方のメールUAを呼び出す印刷可能なASCII文字として「表-可能」なバイト前にそれらが7ビットに送りたがっているかもしれないどんな非原文のデータ(ユーザエージェント、人間のユーザがメールを送って、受け取るプログラム)も変換します。 現在インターネットで使用されているそのようなencodingsに関する例は純粋な16進、uuencode、RFC1421で指定された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 either that X.400 non-textual body parts must be converted to (not encoded in) an ASCII format, or that they must be discarded, notifying the RFC 822 user that discarding has occurred. This is clearly undesirable, as information that a user may wish to
ゲートウェイがRFC822ホストとX.400ホストの間のメール・メッセージの交換を考慮するように設計されているとき、RFC822メールの制限はさらに明らかになります。 X.400[X400]は電子メールメッセージの中で非原文の身体の部分の包含にメカニズムを指定します。 X.400に関するマッピングが822のメッセージをRFCへ通信させるので、現在の規格は、X.400の非原文の身体の部分を(中では、コード化されません)ASCII書式に変換しなければならないか、またはそれらを捨てなければならないと指定します、捨てることが起こったことをRFC822ユーザに通知して。 これはユーザがそうしたがっているかもしれないという情報として明確に望ましくありません。
Borenstein & Freed [Page 3] RFC 1521 MIME September 1993
Borensteinと解放された[3ページ]RFC1521は1993年9月にまねます。
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.
受信してください。失われています。 ユーザのUAには、非原文の身体の部分に対処する能力がないかもしれませんが、ユーザは何らかのメカニズムを身体の部分から役に立つ情報を抜粋できるUAに外部にするかもしれません。 そのうえ、それはメッセージが結局X.400メッセージハンドリングシステムにgatewayedして戻されるかもしれないという(インターネット・メールですなわち、X.400メッセージは「トンネルを堀られる」)事実を考慮しません。そこでは、非文字情報が確実に再び役に立つようになるでしょう。
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 another
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。 オーディオか声のデータを送るための「オーディオ」コンテントタイプ価値。
Borenstein & Freed [Page 4] RFC 1521 MIME September 1993
Borensteinと解放された[4ページ]RFC1521は1993年9月にまねます。
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 additional header fields that can be used to further describe
the data in a message body, the Content-ID and Content-
Description header fields.
4. メッセージ本体でさらにデータについて説明するのに使用できる2つの追加ヘッダーフィールド、コンテントID、およびContent記述ヘッダーフィールド。
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 E provides details about how IANA registration is accomplished.
MIMEは広げることができるメカニズムとして入念に設計されています、そして、時間に応じてcontent type/「副-タイプ」組と彼らの関連パラメタのセットがかなり成長すると予想されます。 文字集合名を著しく含む他のいくつかのMIME分野が時間がたつにつれて定義された新しい値を持っていそうです。 そのような値のセットが規則的で、よく指定されて、公共の方法で発展するのを確実にするために、MIMEはそのような値に、中央の登録としてインターネットAssigned民数記Authority(IANA)を使用する登録手続を定義します。 付録Eは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つの最優先であったことに注意するのは重要です。 特に、互換性は優雅よりいつも好まれました。
MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341] [RFC-1342]. This document is a relatively minor updating of RFC 1341, and is intended to supersede it. The differences between this document and RFC 1341 are summarized in Appendix H. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Several other RFC documents will be of interest to the MIME implementor, in particular [RFC 1343], [RFC-1344], and [RFC-1345].
MIMEは、RFCs1341と1342[RFC-1341][RFC-1342]として最初に、定義されて、発行されました。 このドキュメントは、RFC1341の比較的小さい方のアップデートであり、それに取って代わることを意図します。 このドキュメントとRFC1341の違いはAppendix H.にまとめられます。Pleaseはこのプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を示します。 他のいくつかのRFCドキュメントがMIME作成者特に[RFC1343][RFC-1344]、および[RFC-1345]に興味深くなるでしょう。
Borenstein & Freed [Page 5] RFC 1521 MIME September 1993
Borensteinと解放された[5ページ]RFC1521は1993年9月にまねます。
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 (PostScript is a trademark of Adobe Systems Incorporated.). While the text version is the official specification, some will find the PostScript version easier to read. 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 plus the modifications to RFC 822 defined in RFC 1123, which specifically changes the syntax for `return', `date' and `mailbox'.
いくらかの変更されたBNFが本書ではで定義されるのではなく、RFC822で定義される構文の実体について本書では言及します。 そして、RFC822へのRFC822と変更のものがRFC1123で定義されている'リターン'、'日付'、および'メールボックス'のために明確に構文を変えるこのドキュメントの集まっている文法付録を結合することによって、完全な形式文法を得ます。
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" is used in this document to refer to a method used with one or more tables to convert encoded text to a series of octets. This definition is intended to allow various kinds of text encodings, from simple single-table mappings such as ASCII to complex table switching methods such as those that use ISO 2022's techniques. However, a MIME character set name must fully specify the mapping to be performed.
「文字集合」という用語が1と共に使用されるメソッドを示すのに本書では使用されたか、または変換するより多くのテーブルが一連の八重奏にテキストをコード化しました。 この定義がテキストencodingsの様々な種類を許容することを意図します、ASCIIなどの簡単な単一のテーブルマッピングから複雑なISO2022のテクニックを使用するものなどのテーブル切り換えメソッドまで。 しかしながら、MIME文字集合名は、実行されるためにマッピングを完全に指定しなければなりません。
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.
さらに資格がないと、「ボディー」という用語は実体のボディー、すなわち、メッセージか身体の部分のボディーを意味します。
Borenstein & Freed [Page 6] RFC 1521 MIME September 1993
Borensteinと解放された[6ページ]RFC1521は1993年9月にまねます。
NOTE: The previous four definitions are clearly circular. This is
unavoidable, since the overall structure of a MIME message is
indeed recursive.
以下に注意してください。 前の4つの定義が明確に円形です。 MIMEメッセージの全体的な構造が本当に再帰的であるので、これは避けられません。
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 conformant implementation, but may be of use to those
who wish to understand why this document is written as it is.
これらの不要不急な注意のプライマリ目的は、このドキュメントの原理に関して情報を伝達するか、または適切な歴史的であるか進化論の関係のこのドキュメントを置くことです。 そのような情報は、完全にconformant実装を築き上げるのに焦点を合わせられる人によってスキップされるかもしれませんが、それのようにこのドキュメントがなぜ書かれているかを理解したがっている人の役に立つかもしれません。
For ease of recognition, all BNF definitions have been placed in a
fixed-width font in the PostScript version of this document.
認識の容易さにおいて、すべてのBNF定義がこのドキュメントのポストスクリプトバージョンに固定ピッチフォントに置かれました。
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
このドキュメントによると、構成されたメッセージはそのようなものを含まなければなりません。
Borenstein & Freed [Page 7] RFC 1521 MIME September 1993
Borensteinと解放された[7ページ]RFC1521は1993年9月にまねます。
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を与えます:
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
「「MIMEバージョン」というバージョン:=」:、」 「1*ケタ」、」 1*ケタ
Thus, future format specifiers, which might replace or extend "1.0", are constrained to be two integer fields, separated by a period. If a message is received with a MIME-version value other than "1.0", it cannot be assumed to conform with this specification.
その結果、将来の形式特許説明書の作成書。(「2つの整数分野であることが抑制されて、期間までに切り離された1インチ」を取り替えるか、またはその特許説明書の作成書は広げるかもしれません)。 「1インチ、この仕様に従うと思うことができないこと」を除いたMIMEバージョン値でメッセージを受け取るなら。
Note that the MIME-Version header field is required at the top level of a message. It is not required for each body part of a multipart entity. It is required for the embedded headers of a body of type "message" if and only if the embedded message is itself claimed to be MIME-conformant.
MIMEバージョンヘッダーフィールドがメッセージのトップレベルで必要であることに注意してください。 それは複合実体のそれぞれの身体の部分に必要ではありません。 そして、それがタイプ「メッセージ」のボディーの埋め込まれたヘッダーに必要である、埋め込まれたメッセージがMIME-conformantであると主張される場合にだけ。
It is not possible to fully specify how a mail reader that conforms with MIME as defined in this document should treat a message that might arrive in the future with some value of MIME-Version other than "1.0". However, conformant software is encouraged to check the version number and at least warn the user if an unrecognized MIME- version is encountered.
定義されるようにMIMEに従うメール読者がどう本書では将来「1インチ」以外のMIMEバージョンの何らかの値と共に到着するかもしれないメッセージを扱うべきであるかを完全に指定するのは可能ではありません。 しかしながら、認識されていないMIMEバージョンが遭遇するなら、conformantソフトウェアは、バージョン番号をチェックして、ユーザに少なくとも警告するよう奨励されます。
It is also worth noting that version control for specific content- types is not accomplished using the MIME-Version mechanism. In particular, some formats (such as application/postscript) have version numbering conventions that are internal to the document format. Where such conventions exist, MIME does nothing to supersede them. Where no such conventions exist, a MIME type might use a "version" parameter in the content-type field if necessary.
また、特定の内容タイプのためのバージョンコントロールがMIMEバージョンメカニズムを使用するのに優れていないことに注意する価値があります。 特に、いくつかの形式(アプリケーション/追伸などの)がドキュメント・フォーマットに内部であることのバージョン付番コンベンションを開きます。 そのようなコンベンションが存在するところでは、MIMEはそれらに取って代わるようなことを何もしません。 必要なら、どんなそのようなコンベンションも存在しないところでは、MIMEの種類はcontent type分野で「バージョン」パラメタを使用するかもしれません。
NOTE TO IMPLEMENTORS: All header fields defined in this document, including MIME-Version, Content-type, etc., are subject to the general syntactic rules for header fields specified in RFC 822. In particular, all can include comments, which means that the following two MIME-Version fields are equivalent:
作成者に以下に注意してください。 RFC822で指定されたヘッダーフィールドにおいて、MIMEバージョン、文書内容などを含んでいて、本書では定義されたすべてのヘッダーフィールドが一般的な構文の規則を受けることがあります。 特に、すべてがコメントを含むことができます:以下の2MIMEバージョンがさばくその手段は同等です。
MIME-Version: 1.0
MIME-Version: 1.0 (Generated by GBD-killer 3.7)
MIMEバージョン: 1.0MIMEバージョン: 1.0 (GBD-殺人者3.7で、生成されます)
Borenstein & Freed [Page 8] RFC 1521 MIME September 1993
Borensteinと解放された[8ページ]RFC1521は1993年9月にまねます。
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. In particular, there are NO globally-meaningful parameters that apply to all content-types. Global mechanisms are best addressed, in the MIME model, by the definition of additional Content-* header fields. 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セットのパラメタです。 重要なパラメタのセットは異なったタイプのために異なります。 特に、すべてのcontent typeに適用されるどんなグローバルに重要なパラメタもありません。 MIMEモデルで追加Content-*ヘッダーフィールドの定義でグローバルなメカニズムを扱うのは最も良いです。 パラメタの注文は重要ではありません。 定義されたパラメタの中に、ボディーで使用される文字集合が宣言されるかもしれない"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で理解できるかもしれません。
Borenstein & Freed [Page 9] RFC 1521 MIME September 1993
Borensteinと解放された[9ページ]RFC1521は1993年9月にまねます。
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 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.
7つのコンテントタイプの始発はこのドキュメントによって定義されます。 このセットのトップレベル名が実質的に完全であることを意図します。 一般に、これらの初期のタイプの新しい血液型亜型の作成で、より大きいサポートしているタイプへの追加を実行できると予想されます。 将来、トップより多くのレベルのタイプは単にこの規格への拡大で定義されるかもしれません。 どんな理由にも別のプライマリタイプを使用するつもりであるなら、標準的でない状態を示して、「X」から将来の正式名称との潜在的闘争を避け始めて、名前をそれに与えなければなりません。
In the Augmented BNF notation of RFC 822, a Content-Type header field value is defined as follows:
RFC822のAugmented BNF記法では、コンテントタイプヘッダーフィールド価値は以下の通り定義されます:
content := "Content-Type" ":" type "/" subtype *(";"
parameter)
; case-insensitive matching of type and subtype
「「コンテントタイプ」という内容:=」:、」 」 「タイプ」/「副-タイプ」*(「;」パラメタ)。 タイプと「副-タイプ」の大文字と小文字を区別しないマッチング
type := "application" / "audio"
/ "image" / "message"
/ "multipart" / "text"
/ "video" / extension-token
; All values case-insensitive
拡大:=「アプリケーション」/「オーディオ」/「イメージ」/「メッセージ」/「複合」/「テキスト」/「ビデオ」/トークンをタイプしてください。 すべてが評価する、大文字と小文字を区別しなさ
extension-token := x-token / iana-token
iana拡大トークン:=x-トークン/トークン
iana-token := <a publicly-defined extension token,
registered with IANA, as specified in
appendix E>
付録E>の指定されるとしてIANAに公的に定義された拡大トークンであって、登録されたiana-トークン:=<。
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
2つのキャラクタ「X」か「x」がどんなトークン>も介入している余白なしで続けたx-トークン:=<。
subtype := token ; case-insensitive
「副-タイプ」:=トークン。 大文字と小文字を区別しない
parameter := attribute "=" value
パラメタ:=属性「=」価値
attribute := token ; case-insensitive
:=トークンを結果と考えてください。 大文字と小文字を区別しない
value := token / quoted-string
値の:=トークン/引用文字列
token := 1*<any (ASCII) CHAR except SPACE, CTLs,
or tspecials>
トークン:=1*<はSPACE、CTLs、またはtspecials>以外のあらゆる(ASCII)CHARです。
tspecials := "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
「」 tspecials:=「(「/」)」/「<」 /">"/"@"/」、/」;、」 / ":" 「/「\」/<「>/」/」/「[「/」]」/“?" / "=" ; 引用文字列にあるに違いありません。 パラメタ値の中の使用に
Borenstein & Freed [Page 10] RFC 1521 MIME September 1993
Borensteinと解放された[10ページ]RFC1521は1993年9月にまねます。
Note that the definition of "tspecials" is the same as the RFC 822 definition of "specials" with the addition of the three characters "/", "?", and "=", and the removal of ".".
「"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 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つの異なった共同体には使用があるのが、望ましくないだろう、「コンテントタイプ:」 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 E. 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 E.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
テキスト--文字情報。 プライマリ「明瞭な」「副-タイプ」は明瞭な(非フォーマットされる)テキストを示します。 どんな特別なソフトウェアもテキストの完全な意味を得るのに必要ではありません、示された文字集合のサポートは別として。 血液型亜型がフォームのアプリケーション・ソフトがテキストの外観を高めるかもしれない豊かにされたテキストに使用されることですが、内容の概念を得るためにそのようなソフトウェアを必要としてはいけません。 その結果、可能な血液型亜型はどんな読み込み可能なワードプロセッサも含んでいます。
Borenstein & Freed [Page 11] RFC 1521 MIME September 1993
Borensteinと解放された[11ページ]RFC1521は1993年9月にまねます。
format. A very simple and portable subtype,
richtext, was defined in RFC 1341, with a future
revision expected.
形式。 今後の改正が予想されている状態で、非常に簡単で携帯用の「副-タイプ」(richtext)はRFC1341で定義されました。
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".
複合、--独立しているデータ型の複数の部分から成るデータ。 4の初期の血液型亜型は定義されます、プライマリ「混ぜられた」「副-タイプ」を含んでいて、複数の形式における同じデータを表すのにおいて「代替です」、各部分がタイプ「メッセージ」のものである複合実体のために同時に見られて、「読みこなすこと」を意図する部品に「平行です」。
message -- an encapsulated message. A body of
Content-Type "message" is itself all or part of 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.
メッセージ--カプセル化されたメッセージ。 コンテントタイプ「メッセージ」のボディーは、それ自体でそれ自身の異なったコンテントタイプヘッダーフィールドを含むかもしれない完全にフォーマットされたRFC822conformantメッセージのすべてか一部です。 プライマリ「副-タイプ」は"rfc822"です。 「部分的な」「副-タイプ」は部分的なメッセージのために定義されて、であることができない大きいと考えられるボディーの断片化しているトランスミッションを可能にするのはメール運送設備を通り抜けました。 別の「外部のボディー」である「副-タイプ」は、外部のデータ送信端末の参照で大きいボディーを指定するために定義されます。
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.
イメージ--イメージデータ。 イメージは、情報を見るために、ディスプレイ装置(グラフィカルなディスプレイ、プリンタ、またはFAXマシンなどの)を必要とします。 初期の血液型亜型は2つの広く使用された画像形式、jpeg、および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".
ビデオ--ビデオ・データ。 ビデオは専門化しているハードウェアとソフトウェアを通常含む動画を表示する能力を必要とします。 初期の「副-タイプ」は"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.
アプリケーション--ある他の種類に関するデータ、通常、どちらかが、メールベースのアプリケーションで処理されるためにバイナリ・データか情報を非解釈しました。 「八重奏ストリーム」というプライマリ「副-タイプ」は非解釈されたバイナリ・データの場合に使用されることになっています、その場合、最も簡単なお勧めの動きがユーザのためにファイルの中に情報を書くと申し出ることです。
Borenstein & Freed [Page 12] RFC 1521 MIME September 1993
Borensteinと解放された[12ページ]RFC1521は1993年9月にまねます。
An additional subtype, "PostScript", is defined
for transporting 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
and other application data may entail several
security considerations, which are discussed later
in this memo, particularly in the context of
application/PostScript.)
「ポストスクリプト」という追加「副-タイプ」は、ボディーでポストスクリプトドキュメントを輸送するために定義されます。 「アプリケーション」への他の予想された用途はスプレッドシート、メールベースのスケジューリングシステムのためのデータ、および「アクティブな」(コンピュータの)メールのための言語を含んでいます。 (このメモと、特にアプリケーション/ポストスクリプトの文脈でアクティブなメールと他のアプリケーションデータが後で議論するいくつかのセキュリティ問題を伴うかもしれないことに注意してください。)
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, 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バージョンとコンテントタイプヘッダーフィールドの両方を欠いているなら、実際にはほとんど何でも含むかもしれないのを意識していたままで、作成者は残るべきです。
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.
メール読者が未知の文書内容値でメールに遭遇すると、一般に、それは「八重奏アプリケーション/ストリーム」に同等で、後述のようであるとして本書ではそれを扱うべきです。
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 lines no longer than 1000 characters.
メールで有効に輸送できるだろう多くのコンテントタイプが表されます、それらの「自然な」形式で、8ビットのキャラクタかバイナリ・データとして。 いくつかのトランスポート・プロトコルの上にそのようなデータを送ることができません。 例えば、RFC821はもう1000のキャラクタより系列でメール・メッセージを7ビットの米国-ASCIIデータに制限しません。
Borenstein & Freed [Page 13] RFC 1521 MIME September 1993
Borensteinと解放された[13ページ]RFC1521は1993年9月にまねます。
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)によって定義されたものなどのように。 この分野はどんな前の規格によっても定義されていません。 フィールドの値は以下に列挙されるようにコード化のタイプを指定するただ一つのトークンです。 正式に:
encoding := "Content-Transfer-Encoding" ":" mechanism
「:=「満足している転送コード化」をコード化します」:、」 メカニズム
mechanism := "7bit" ; case-insensitive
/ "quoted-printable"
/ "base64"
/ "8bit"
/ "binary"
/ x-token
「7は噛み付いた」メカニズム:=。 大文字と小文字を区別しない/「引用されて印刷可能な」/「x「8ビット」/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, "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.
これらの値は大文字と小文字を区別していません。 すなわち、Base64、BASE64、およびbAsE64はすべて同等です。 7BITのコード化しているタイプは、ボディーが既に7ビットのメール持ち合わせの表現であるのを必要とします。 これはデフォルト値です--すなわち、「内容はコード化を移します」。 Content転送コード化ヘッダーフィールドが存在していないなら、"7BIT"は想定されます。
The values "8bit", "7bit", and "binary" all mean 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. In particular:
値「8ビット」、「7ビット」、および「バイナリー」はすべて、コード化でないのが実行されたことを意味します。 しかしながら、それらはオブジェクトに含まれたデータの種類、およびしたがって、与えられた輸送システムにおけるトランスミッションのために実行される必要があるかもしれないコード化の種類のしるしとして潜在的に役に立ちます。 特に:
"7bit" means that the data is all represented as short
lines of US-ASCII data.
「7ビット」は、データが米国-ASCIIデータの短い線としてすべて表されることを意味します。
Borenstein & Freed [Page 14] RFC 1521 MIME September 1993
Borensteinと解放された[14ページ]RFC1521は1993年9月にまねます。
"8bit" means that the lines are short, but there may be
non-ASCII characters (octets with the high-order
bit set).
「8ビット」は、系列が短いことを意味しますが、非ASCII文字がいるかもしれません(高位のビットによる八重奏はセットしました)。
"Binary" means that not only may non-ASCII characters
be present, but also that the lines are not
necessarily short enough for SMTP transport.
「バイナリー」は、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輸送の制限を満たさないデータを輸送することにおける異なった能力がある将来のメール輸送システムの間には、ゲートウェイには莫大な価値があるでしょう。
Mail transport for unencoded 8-bit data is defined in RFC-1426
[RFC-1426]. As of the publication of this document, there are no
standardized Internet mail transports for which it is legitimate
to include unencoded binary data in mail bodies. Thus there are
no circumstances in which the "binary" Content-Transfer-Encoding
is actually legal on the Internet. However, in the event that
binary mail transport becomes a reality in Internet mail, or when
this document is used in conjunction with any other binary-capable
transport mechanism, binary bodies should be labeled as such using
this mechanism.
暗号化されていない8ビットのデータのためのメール輸送はRFC-1426[RFC-1426]で定義されます。 このドキュメントの公表現在、メール本文に暗号化されていないバイナリ・データを含んでいるのが正統であるインターネット・メール輸送は標準化されません。 したがって、「2進」のContent転送コード化が実際にインターネットで法的である事情が全くありません。 しかしながら、バイナリメール輸送がインターネット・メールで現実のものになるか、またはこのドキュメントがいかなる他の2進にできる移送機構に関連して使用されるとき、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, 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
必要なら、「X」によって前に置かれた、標準的でない状態を示した名前であるx-トークンを使用しなければならないのを除いて、作成者は新しいContent転送コード化値を定義するかもしれません、例えば、「内容はコード化を移します」。 「x、私の新しいコード化、」 しかしながら、コンテントタイプと血液型亜型と異なって、新しいContent転送コード化値の作成は明らかに強くがっかりしています、少ない潜在的利益で相互運用性を妨げるのがありそうに思えるように。 彼らの使用が許されている、唯一
Borenstein & Freed [Page 15] RFC 1521 MIME September 1993
Borensteinと解放された[15ページ]RFC1521は1993年9月にまねます。
result of an agreement between cooperating user agents.
協力関係を持っているユーザエージェントの間の協定の結果。
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 octet
streams, not bit streams. If a bit stream is to be encoded via one
of these mechanisms, it must first be converted to an 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 must 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 "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.
あるContent転送コード化値はあるコンテントタイプで使用されるだけであるかもしれません。 特に、他のコンテントタイプ分野を再帰的に含んでいるどんなContentタイプ、著しく「複合」と「メッセージ」コンテントタイプがある「7ビット」、「8ビット」、または「バイナリー」を除いたどんなencodingsも使用するのが明白に禁じられます。 最も奥深いレベルでタイプ複合のボディーのために望まれているすべてのencodingsかメッセージをしなければなりません、コード化される必要がある実際のボディーをコード化することによって。
Borenstein & Freed [Page 16] RFC 1521 MIME September 1993
Borensteinと解放された[16ページ]RFC1521は1993年9月にまねます。
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 in base64 data must be converted to a
quoted-printable line break, but ONLY when converting text data.
ENCODINGSを翻訳するとき、以下に注意してください。 引用されて印刷可能とbase64 encodingsは、それらの間の変換が可能であるように、設計されています。 そのような変換で起こる唯一の問題はラインブレイクの取り扱いです。 引用されて印刷可能であるのからbase64まで変換するとき、CRLF系列にラインブレイクを変換しなければなりません。 テキストデータを変換するだけであるとき、同様に、base64データのCRLF系列を引用されて印刷可能なラインブレイクに変換しなければなりません。
Borenstein & Freed [Page 17] RFC 1521 MIME September 1993
Borensteinと解放された[17ページ]RFC1521は1993年9月にまねます。
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, and the relationship between content-transfer-
encodings and character sets. For this reason, a canonical model
for encoding is presented as Appendix G.
正準なコード化のときに、モデル化するように注意してください: 何らかの混乱がありました、このメモの以前の草稿で、メールデータがいつ標準形に変換されて、コード化されるかことであり、特に、この過程がどのようにCRLFsの処理に影響するかモデルに関して、ニューラインの表現がシステムとシステム、および満足している転送-encodingsと文字の組との関係に大いに異なるなら。 この理由で、コード化のための規範的モデルはAppendix Gとして提示されます。
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 (standard) form of the data being encoded, may be
represented by an "=" followed by a two digit hexadecimal
representation of the octet's value. The digits of the
hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".
Uppercase letters must be used 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 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
#3、を統治してください: (余白): 9と32の値がある八重奏はASCII TAB(HT)とSPACEキャラクタとしてそれぞれ表されるかもしれませんが、コード化された行の終わりに非常に表されてはいけません。 その結果、印刷可能なキャラクタはその線の上でコード化された線の上のどんなTAB(HT)やSPACEキャラクタにもついて来なければなりません。 特に
Borenstein & Freed [Page 18] RFC 1521 MIME September 1993
Borensteinと解放された[18ページ]RFC1521は1993年9月にまねます。
"=" 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.
コード化された行の終わりの「=」、柔らかいラインブレイク(規則#5を見る)を示すと、1つ以上のTAB(HT)かSPACEキャラクタが続くかもしれません。 Rule#1に従ってコード化された行の終わりに現れる値9か32がある八重奏を表さなければならないということになります。 いくつかのMTAs(メッセージTransportエージェント、1人のユーザから別のユーザまでメッセージを輸送するか、またはそのような転送の一部を実行するプログラム)がSPACEsと共にテキストの線を水増しするのが知られていて、他のものが線の端から「余白」キャラクタを外すのが知られるので、この規則が必要です。 したがって、Quoted印刷可能なボディーを解読するとき、線の上のどんな引きずっている余白も削除しなければなりません、それが必ず中間的輸送エージェントによって加えられてしまうだろうというとき。
Rule #4 (Line Breaks): A line break in a text body, 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.
Since the canonical representation of types other than text do not
generally include the representation of line breaks, no hard line
breaks (i.e. line breaks that are intended to be meaningful and
to be displayed to the user) should occur in the quoted-printable
encoding of such types. Of course, occurrences of "=0D", "=0A",
"0A=0D" and "=0D=0A" will eventually be encountered. In general,
however, base64 is preferred over quoted-printable for binary
data.
#4(ラインブレイク)を統治してください: (RFC822)ラインブレイクでテキスト本文のラインブレイク(コード化されるデータの正準な表現に続く表現が何であるかに関する独立者)を表さなければなりません、Quoted印刷可能なコード化で。(ラインブレイクはCRLF系列です)。 テキスト以外のタイプの正準な表現が一般にラインブレイクの表現を含んでいないので、どんな困難なラインブレイク(すなわち、重要であり、ユーザに表示されることを意図するラインブレイク)もそのようなタイプの引用されて印刷可能なコード化で起こるべきではありません。 もちろん、「=0D」、「=0A」、"0A=0D"、および「=0D=0A」の発生は結局、遭遇するでしょう。 一般に、しかしながら、base64はバイナリーには、引用されて印刷可能なデータより好まれます。
Note that many implementations may elect to encode the local
representation of various content types directly, as described in
Appendix G. 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.
多くの実現が、直接様々な満足しているタイプのローカルの表現をコード化するのを選ぶかもしれないというメモ、Appendix G.Inで特定の状態で説明されるように、これは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 19] RFC 1521 MIME September 1993
Borensteinと解放された[19ページ]RFC1521は1993年9月にまねます。
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 representation of the breaks between the lines of quoted printable data may be altered in transport, in the same manner that plain text mail has always been altered in Internet mail when passing between systems with differing newline conventions. If such alterations are likely to constitute a corruption of the data, it is probably more sensible to use the base64 encoding rather than the quoted-printable encoding.
引用されて印刷可能なデータが適応する線であると一般に思われるので、引用された印刷可能なデータの線の間の中断の表現が輸送で変更されるかもしれないと予想されることになっていて、異なったニューラインコンベンションと共にシステムの間を通るとき、同じ方法で、そのプレーンテキストメールはインターネット・メールでいつも変更されていました。 そのような変更がデータの不正を構成しそうであるなら、引用されて印刷可能なコード化よりむしろbase64コード化を使用するのはたぶんさらに分別があります。
WARNING TO IMPLEMENTORS: If binary data are encoded in quoted- printable, care must be taken to encode CR and LF characters as "=0D" and "=0A", respectively. In particular, a CRLF sequence in binary data should be encoded as "=0D=0A". Otherwise, if CRLF were represented as a hard line break, it might be incorrectly decoded on
作成者への警告: 2進のデータがコード化されたコネが、「=0D」としてCRとLFキャラクタをコード化して、「0Aと等しい」ように印刷可能であることで、注意しなければならないのをそれぞれ引用したということであるなら。 特に、2進のデータのCRLF系列は「=0D=0A」としてコード化されるべきです。 さもなければ、CRLFが困難なラインブレイクとして表されるなら、それでは、不当に解読されるでしょうに。
Borenstein & Freed [Page 20] RFC 1521 MIME September 1993
Borensteinと解放された[20ページ]RFC1521は1993年9月にまねます。
platforms with different line break conventions.
異なったラインブレイクコンベンションがあるプラットホーム。
For formalists, the syntax of quoted-printable data is described by the following grammar:
形式主義者に関しては、引用されて印刷可能なデータの構文は以下の文法によって説明されます:
quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
; Maximum line length of 76 characters excluding CRLF
引用されて印刷可能な:=([*(ptext/SPACE/TAB)ptext][「=」]CRLF)。 CRLFを除いた76のキャラクタの最大の行長
ptext := octet /<any ASCII character except "=", SPACE, or TAB>
; characters not listed as "mail-safe" in Appendix B
; are also not recommended.
ptext:=八重奏/<、「=」を除いたどんなASCII文字、スペース、またはタブ>も。 キャラクタはAppendixで「メール安全な」Bとして記載しませんでした。 また、推薦されません。
octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; octet must be used for characters > 127, =, SPACE, or TAB,
; and is recommended for any characters not listed in
; Appendix B as "mail-safe".
八重奏:=「=」2(/「B」/ケタ/「C」/「D」/「E」/「F」)。 キャラクタの>127、=、SPACE、またはTABに八重奏を使用しなければなりません。 そして、記載されなかった少しのキャラクタのためにも、推薦されます。 「メール金庫」としての付録B。
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 need not be humanly readable. The encoding and decoding algorithms are simple, but the encoded data are consistently only about 33 percent larger than the unencoded data. This encoding is virtually identical to the one used in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421. The base64 encoding is adapted from RFC 1421, with one change: base64 eliminates the "*" mechanism for embedded clear text.
Base64 Content転送コード化は、人間的に読み込み可能である必要はないフォームでの八重奏の気紛れな順番を表すように設計されています。 コード化とアルゴリズムを解読するのが簡単ですが、コード化されたデータは暗号化されていないデータより一貫しておよそ33パーセント大きいだけです。 このコード化は実際にはRFC1421で定義されるようにPrivacy Enhancedメール(PEM)アプリケーションで使用されるものと同じです。 base64コード化は1回の変化でRFC1421から適合させられます: 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.
4の出力ストリングがキャラクタをコード化したので、コード化の過程は入力ビットの24ビットのグループを代表します。 左から右まで続いて、24ビットの入力グループは、3の8ビットの入力グループを連結することによって、結成されます。 そして、4が6ビットのグループ(それのそれぞれがbase64アルファベットの一桁に翻訳される)を連結したので、これらの24ビットは扱われます。 base64コード化を通して流れを少しコード化するとき、ビットストリームは最初に、あえて最も重要なビットで命令されなければなりません。
Borenstein & Freed [Page 21] RFC 1521 MIME September 1993
Borensteinと解放された[21ページ]RFC1521は1993年9月にまねます。
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.
すなわち、流れにおける最初のビットは最初のバイトで高位のビットになるでしょう、そして、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) そして、本書では(例えば、「-」)カプセル化境界と定義されています。
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. Padding at the end of the data is performed using the '=' character. Since all base64 input is an integral number of octets, only the following cases can
24ビット未満がコード化されるデータの終わりで有効であるなら、特別な処理は実行されます。 完全なコード化量子はいつもボディーの先に完成します。 24入力ビット未満が入力グループで有効であるときに、ゼロ・ビットは、整数の6ビットのグループを結成するために加えられます(右で)。 データの終わりでそっと歩くのは、'='キャラクタを使用することで実行されます。 すべてのbase64入力が整数の八重奏であるので、以下のケースだけは八重奏であることができます。
Borenstein & Freed [Page 22] RFC 1521 MIME September 1993
Borensteinと解放された[22ページ]RFC1521は1993年9月にまねます。
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.
起こります: (1) 入力をコード化する最終的な量子は24ビットの不可欠の倍数です。 (2) ここで、コード化された出力の最終的なユニットが「=」が全くそっと歩いていない4つのキャラクタの不可欠の倍数になる、入力をコード化する最終的な量子はちょうど8ビットです。 (3) ここで、コード化された出力の最終的なユニットは2人の「=」暫定記号によっていうことになられた2つのキャラクタになるだろうか、入力をコード化する最終的な量子はまさに16ビットです。 ここで、コード化された出力の最終的なユニットは1人の「=」暫定記号によっていうことになられた3つのキャラクタになるでしょう。
Because it is used only for padding at the end of the data, the occurrence of any '=' characters may be taken as evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible, however, when the number of octets transmitted was a multiple of three.
それがデータの終わりでそっと歩くのにだけ使用されるので、どんな'='キャラクタの発生もデータの端に達したという(トランジットにおけるトランケーションなしで)証拠としてみなされるかもしれません。 そのようなどんな保証も可能でない、しかしながら、八重奏の数がいつ伝わったかは、3の倍数でした。
Any characters outside of the base64 alphabet are to be ignored in base64-encoded data. The same applies to any illegal sequence of characters in the base64 encoding, such as "====="
base64アルファベットにおける外部のどんなキャラクタもbase64によってコード化されたデータで無視されることになっています。 「同じくらいがbase64コード化における、キャラクタのどんな不法な系列にも適用される、」====="
Care must be taken to use the proper octets for line breaks if base64 encoding is applied directly to text material that has not been converted to canonical form. In particular, text line breaks must be converted into CRLF sequences prior to base64 encoding. The important thing to note is that this may be done directly by the encoder rather than in a prior canonicalization step in some implementations.
base64コード化が直接テキストの材料に適用されて、それが標準形に変換されていないということであるなら、ラインブレイクに適切な八重奏を使用するために注意しなければなりません。 特に、base64コード化の前にテキストラインブレイクをCRLF系列に変換しなければなりません。 注意する重要なことは直接先の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 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」ヘッダーフィールドを使用することでラベルされるかもしれません:
id := "Content-ID" ":" msg-id Like the Message-ID values, Content-ID values must be generated to be world-unique.
「イド:=「コンテントID」」:、」 msg-イドLike、Message-ID値であり、コンテントID値は、世界特有になるように発生しなければなりません。
The Content-ID value may be used for uniquely identifying MIME entities in several contexts, particularly for cacheing data referenced by the message/external-body mechanism. Although the Content-ID header is generally optional, its use is mandatory in
コンテントID値は唯一いくつかの文脈のMIME実体を特定するのに使用されるかもしれません、特に外部のメッセージ/ボディーメカニズムによって参照をつけられるデータをcacheingするように。 使用は中で一般に、コンテントIDヘッダーが任意であることが義務的ですが
Borenstein & Freed [Page 23] RFC 1521 MIME September 1993
Borensteinと解放された[23ページ]RFC1521は1993年9月にまねます。
implementations which generate data of the optional MIME Content-type "message/external-body". That is, each message/external-body entity must have a Content-ID field to permit cacheing of such data.
「外部のメッセージ/ボディー」という任意のMIME文書内容に関するデータを発生させる実現。 すなわちそれぞれの外部のメッセージ/ボディー実体には、そのようなデータをcacheingすることを許可するコンテントID分野がなければなりません。
It is also worth noting that the Content-ID value has special semantics in the case of the multipart/alternative content-type. This is explained in the section of this document dealing with multipart/alternative.
また、コンテント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-記述ヘッダーフィールドに置かれるかもしれません。
description := "Content-Description" ":" *text
「記述:=「満足している記述」」:、」 *テキスト
The description is presumed to be given in the US-ASCII character set, although the mechanism specified in [RFC-1522] may be used for non-US-ASCII Content-Description values.
あえて米国-ASCII文字の組で記述を与えます、[RFC-1522]で指定されたメカニズムは非米国のASCII Content-記述値に使用されるかもしれませんが。
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 F.
このドキュメントは個人的であるか実験しているタイプのために7つの初期のコンテントタイプ値と拡大メカニズムを定義します。 新しい広められた仕様でさらなる標準体型を定義しなければなりません。 新しいタイプのメールにおけるほとんどの革新がここで定義された7つのタイプの血液型亜型として起こると予想されます。 7つの満足しているタイプの最も不可欠の特性はAppendix Fにまとめられます。
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 for some text subtypes, notably including the primary subtype, "text/plain", which indicates plain (unformatted) text. The default Content-Type for Internet mail is "text/plain; charset=us- ascii".
テキストコンテントタイプはフォームで主に原文であることの送付の材料のために意図します。 それはデフォルトコンテントタイプです。 "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
プレーンテキストを超えて、「拡張テキスト」として知られているかもしれないことを表すための多くの形式がいます--埋め込まれた形式とプレゼンテーション情報があるテキスト。 そのような多くの表現のおもしろい特性はそれらがそれらを解釈するソフトウェアがなくてもある程度読み込み可能であるということです。 それは、その時、上層部によってそのような読みにくいデータからのそれらを区別するために役に立ちます。
Borenstein & Freed [Page 24] RFC 1521 MIME September 1993
Borensteinと解放された[24ページ]RFC1521は1993年9月にまねます。
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" [RFC-1341].
そのようなフォーマットされた原文のデータは、テキストの血液型亜型を使用することで表されるべきです。 テキストのもっともらしい血液型亜型は表現形式の一般名、例えば、「テキスト/richtext」[RFC-1341]によって通常与えられています。
7.1.1. The charset parameter
7.1.1. charsetパラメタ
A critical parameter that may be specified in the Content-Type field for text/plain data is the character set. This is specified with a "charset" parameter, as in:
コンテントタイプ分野でテキスト/明瞭なデータに指定されるかもしれない臨界パラメータは文字の組です。 これは以下のように"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です。
The specification for any future subtypes of "text" must specify whether or not they will also utilize a "charset" parameter, and may possibly restrict its values as well. When used with a particular body, the semantics of the "charset" parameter should be identical to those specified here for "text/plain", i.e., the body consists entirely of characters in the given charset. In particular, definers of future text subtypes should pay close attention the the implications of multibyte character sets for their subtype definitions.
何か「テキスト」の将来の血液型亜型のための仕様は、彼らがまた、"charset"パラメタを利用して、ことによるとまた、値を制限するかもしれないかどうか指定しなければなりません。 特定のボディーと共に使用されると、"charset"パラメタの意味論がここで「テキスト/平野」に指定されたものと同じであるべきである、すなわち、ボディーは与えられたcharsetでキャラクタから完全に成ります。 特に、将来のテキスト血液型亜型のdefinersは彼らの「副-タイプ」定義のために多バイト文字セットの含意を周到な注意に支払うはずです。
This RFC specifies the definition of the charset parameter for the purposes of MIME to be a unique mapping of a byte stream to glyphs, a mapping which does not require external profiling information.
このRFCは、MIMEの目的がglyphs(外部のプロフィール情報を必要としないマッピング)へのバイト・ストリームのユニークなマッピングであるためにcharsetパラメタの定義を指定します。
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, although the standardization of their use requires the usual IESG [RFC-1340] 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.
このセクションの端で事前に定義された文字の組名の初期のリストを見つけることができます。 追加文字セットはIANAに登録されるかもしれません、彼らの使用の標準化が普通のIESG[RFC-1340]レビューと承認を必要としますが。 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
デフォルト文字の組(米国-ASCII)は過去の何らかの混乱とあいまいさの対象です。 いくつかのあいまいさが定義中だけであったのではなく、広い変化が実際にはありました。 中でそのようなあいまいさと変化を取り除きます。
Borenstein & Freed [Page 25] RFC 1521 MIME September 1993
Borensteinと解放された[25ページ]RFC1521は1993年9月にまねます。
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」は、任意の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のどんな使用も送付者と受取人との個人的な協定の一部であるに違いありません。 そのような個人的な協定をがっかりして、このドキュメントの他の能力に取り替えるべきです。
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
以下に注意してください。 米国-ASCIIを超えて、文字の組の莫大な増殖は可能です。 それは良いものではなく、多くの文字の組があるIETFワーキンググループに関する意見です。 私たちは、電子メールに世界の言語のすべてを表すのに一般に使用できるただ一つの文字の組を指定するのを好むでしょう。 残念ながら、いくつかの共同体の既存の習慣は近い将来の複数の文字の組の継続的な使用を示すように思えます。 これに関しては、推論してください、私たちは定義します。
Borenstein & Freed [Page 26] RFC 1521 MIME September 1993
Borensteinと解放された[26ページ]RFC1521は1993年9月にまねます。
names for a small number of character sets for which a strong
constituent base exists.
強い構成しているベースが存在する少ない数の文字の組のための名前。
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[ISO-8859]の部分に取り替えられることになっているところ。 ISO646文字の組が彼らの8859の交換を支持して故意に省略されたことに注意してください。交換はインターネット・メールのための指定された文字の組です。 このドキュメントの公表現在、「X」のための正統の値は1〜9にケタです。
The character sets specified above are the ones that were relatively uncontroversial during the drafting of MIME. This document does not endorse the use of any particular character set other than US-ASCII, and recognizes that the future evolution of world character sets remains unclear. It is expected that in the future, additional character sets will be registered for use in MIME.
上で指定された文字の組はMIMEの草稿の間に比較的論議を呼んでいないものです。 このドキュメントは、米国-ASCIIを除いたどんな特定の文字の組の使用も是認しないで、世界文字の組の今後の発展が不明瞭なままで残っていると認めます。 将来追加文字セットがMIMEにおける使用のために登録されると予想されます。
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, or by private agreement, in which case the character set name must begin with "X-".
他の文字の組名は全くインターネット・メールで形式仕様の公表と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 must always use the "lowest common denominator" character set possible. For example, if a body contains only US-ASCII characters, it must 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 must be labeled as being in that subset. This will increase the chances that the recipient will be able to view the mail correctly.
一般に、メールを送るソフトウェアはいつも可能な「最小公分母」文字の組を使用しなければなりません。 例えば、ボディーが米国-ASCII文字だけを含むなら、文字の組のすべてのISO-8859家のように米国-ASCIIのスーパーセットであるISO-8859-1ではなく、米国-ASCII文字の組にはあるとしてそれをマークしなければなりません。 より一般に、広く使用された文字の組が別の文字の組の部分集合であり、ボディーが広く使用された部分集合にキャラクタだけを含むなら、その部分集合にはあるとしてそれをラベルしなければなりません。 これは受取人が正しくメールを見ることができるという可能性を高めるでしょう。
Borenstein & Freed [Page 27] RFC 1521 MIME September 1993
Borensteinと解放された[27ページ]RFC1521は1993年9月にまねます。
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によって定義されたボディーのタイプです。
No other text subtype is defined by this document.
他のテキストがない「副-タイプ」はこのドキュメントによって定義されます。
The formal grammar for the content-type header field for text is as follows:
テキストのための満足しているタイプヘッダーフィールドのための形式文法は以下の通りです:
text-type := "text" "/" text-subtype [";" "charset" "=" charset]
」 「テキストタイプ:=「テキスト」」/テキスト-「副-タイプ」[「」、;、"charset"「=」charset]
text-subtype := "plain" / extension-token
拡大テキスト-「副-タイプ」:=「平野」/象徴
charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"
/ "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"
/ "iso-8859-8" / "iso-8859-9" / extension-token
; case insensitive
ASCII..1インチ..2インチ..3インチ..4インチ..5インチ..6インチ..7インチ..8インチ..9インチ..拡大..象徴 大文字と小文字を区別しない
7.2. The Multipart Content-Type
7.2. 複合コンテントタイプ
In the case of multiple part entities, 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.
複数の部分実体の場合では、「複合」のContentタイプ野原は実体のヘッダーに現れなければなりません。(そこでは、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 corresponding body 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 must 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」分野は実験的であるか個人的な目的のために作成されるかもしれません、それらが含む情報が数門で失われるかもしれないという認識で。
Borenstein & Freed [Page 28] RFC 1521 MIME September 1993
Borensteinと解放された[28ページ]RFC1521は1993年9月にまねます。
NOTE: 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, 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 represented as 7-bit ASCII in any case (though the header fields may encode non-ASCII header text as per [RFC-1522]), 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としていつも複合デリミタとヘッダーフィールドを表します、そして、(ヘッダーフィールドは[RFC-1522]に従って非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
一般的な構文であって、このセクションで定義された「複合」のシェアのすべての血液型亜型。 また、複合メッセージの簡単な例はこのセクションに現れます。 より複雑な複合メッセージに関する例はそうです。
Borenstein & Freed [Page 29] RFC 1521 MIME September 1993
Borensteinと解放された[29ページ]RFC1521は1993年9月にまねます。
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メカニズムにしました。
WARNING TO IMPLEMENTORS: The grammar for parameters on the Content- type field is such that it is often necessary to enclose the boundaries in quotes on the Content-type line. This is not always necessary, but never hurts. Implementors should be sure to study the grammar carefully in order to avoid producing illegal Content-type fields. Thus, a typical multipart Content-Type header field might look like this:
作成者への警告: Contentタイプフィールドに関するパラメタのための文法がそのようなものであるので、文書内容線に関する引用文における境界を同封するのがしばしば必要です。 これは、いつも必要であるというわけではありませんが、決して痛みません。 作成者は、不法な文書内容分野を生産するのを避けるために確実に慎重に文法を研究するべきです。 したがって、典型的な複合コンテントタイプヘッダーフィールドはこれに似るかもしれません:
Content-Type: multipart/mixed;
boundary=gc0p4Jq0M2Yt08jU534c0p
コンテントタイプ: 複合か混ぜられる。 境界=gc0p4Jq0M2Yt08jU534c0p
But the following is illegal:
しかし、以下は不法です:
Content-Type: multipart/mixed;
boundary=gc0p4Jq0M:2Yt08jU534c0p
コンテントタイプ: 複合か混ぜられる。 境界=gc0p4Jq0M: 2Yt08jU534c0p
(because of the colon) and must instead be represented as
そして、(コロンによる)、代わりに、表さなければなりません。
Content-Type: multipart/mixed;
boundary="gc0p4Jq0M:2Yt08jU534c0p"
コンテントタイプ: 複合か混ぜられる。 境界=「gc0p4Jq0M: 2Yt08jU534c0p」
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メッセージと同じであり、部品がそれぞれそうである構造があるそれぞれ自体が線のそばで先行しました。
--gc0p4Jq0M:2Yt08jU534c0p
--gc0p4Jq0M: 2Yt08jU534c0p
Borenstein & Freed [Page 30] RFC 1521 MIME September 1993
Borensteinと解放された[30ページ]RFC1521は1993年9月にまねます。
Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that the initial CRLF is considered to be attached to 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 conceptually
attached to 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, must 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番目はそれによるカプセル化境界の一部です。
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 boundary. These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary or after the last one.
境界は最初のカプセル化境界の前の追加情報の余地であり、決勝に続いているように見えます。 一般に、これらの領域は空白のままにされるべきです、そして、実現は最初の境界の前か最後のものの後に現れるものは何でも無視しなければなりません。
NOTE: These "preamble" and "epilogue" areas are generally 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. However, rather than leaving the
preamble area blank, many MIME implementations have found this to
be a convenient place to insert an explanatory note for recipients
who read the message with pre-MIME software, since such notes will
be ignored by MIME-compliant software.
以下に注意してください。 一般に、これらの「序文」と「エピローグ」領域はこれらの部品の適切なタイプの不足とゲートウェイ(特にX.400ゲートウェイ)でこれらの領域を扱うための明確な意味論の不足のために使用されません。 しかしながら、序文部門を空白の状態でおくよりむしろ多くのMIME実現によって、これがプレMIMEソフトウェアでメッセージを読む受取人のために注記を挿入する便利な場所であることがわかりました、そのような注意がMIME対応することのソフトウェアによって無視されるので。
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
以下に注意してください。 カプセル化境界を身体の数回に分けて要約される掲載してはいけないので、ユーザエージェントはユニークな境界を選ぶために注意しなければなりません。 上記の例における境界は中に既に存在するという非常に低い確率がある状態で境界を作成するように設計されたアルゴリズムの結果であったかもしれません。
Borenstein & Freed [Page 31] RFC 1521 MIME September 1993
Borensteinと解放された[31ページ]RFC1521は1993年9月にまねます。
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 conformant readers.
--simple boundary
これは序文です。 それは無視されることになっています、それがメール作曲家が非MIME conformant読者に注記を含む便利な場所ですが。 --簡単な境界
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 multipart entities.
別の複合実体の中の身体の部分の複合のコンテントタイプの使用は明らかに許されています。 そのような場合、明白な理由によって、それぞれの入れ子にされた複合実体が異なった境界デリミタを使用しなければならないのを保証するために注意しなければなりません。 入れ子にされた複合実体の例に関してAppendix Cを見てください。
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
複合コンテントタイプのための唯一の義務的なパラメタが境界パラメタです。(そのパラメタはメールゲートウェイを通して非常に強健であることが知られて、余白で終わらない1セットのキャラクタからの1〜70のキャラクタから成ります)。 (境界が余白で終わるように見えるなら、余白はあえてaによって加えられたに違いありません。
Borenstein & Freed [Page 32] RFC 1521 MIME September 1993
Borensteinと解放された[32ページ]RFC1521は1993年9月にまねます。
gateway, and must be deleted.) It is formally specified by the following BNF:
ゲートウェイ、削除しなければならない、)。 それは以下のBNFによって正式に指定されます:
boundary := 0*69<bchars> bcharsnospace
境界:=0*69<bchars>bcharsnospace
bchars := bcharsnospace / " "
bchars:=bcharsnospace/、「」
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
「」 :=DIGIT/アルファー/「'「/「(「/」)」/「+」/」_」/」、bcharsnospace/「-」/」、」、' / "/" / ":" / "=" / "?"
Overall, the body of a multipart entity may be specified as follows:
全体的に見て、複合実体のボディーは以下の通り指定されるかもしれません:
multipart-body := preamble 1*encapsulation
close-delimiter epilogue
複合ボディー:=序文1*カプセル化近いデリミタエピローグ
encapsulation := delimiter body-part CRLF
カプセル化:=デリミタ身体パートCRLF
delimiter := "--" boundary CRLF ; taken from Content-Type field.
; There must be no space
; between "--" and boundary.
デリミタ:=「--」境界CRLF。 コンテントタイプ分野から、取ります。 ; スペースが全くあるはずがありません。 「--」と境界の間で。
close-delimiter := "--" boundary "--" CRLF ; Again, no space by "--",
近いデリミタ:=「--」境界「--」CRLF。 再び「--」によるスペースがありません。
preamble := discard-text ; to be ignored upon receipt.
序文:=、テキストを捨てる、。 領収書で無視されるために。
epilogue := discard-text ; to be ignored upon receipt.
エピローグ:=、テキストを捨てる、。 領収書で無視されるために。
discard-text := *(*text CRLF)
テキストを捨てている:=*(*テキストCRLF)
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
semantics of a part differ from the semantics
of a message, as described in the text.>
どこでもそれ自体で線かサブストリングメッセージ本体で何処にも現れない指定されたデリミタ、または、として任意のすべてのヘッダーフィールドでRFC822で定義される身体部分:=<「メッセージ。」 . テキスト>で説明されるように部分の意味論がメッセージの意味論と異なっていることに注意してください。
NOTE: In certain transport enclaves, RFC 822 restrictions such as
the one that limits bodies to printable ASCII characters may not
be in force. (That is, the transport domains may resemble
standard Internet mail transport as specified in RFC821 and
assumed by RFC822, but without certain restrictions.) The
relaxation of these restrictions should be construed as locally
extending the definition of bodies, for example to include octets
outside of the ASCII range, as long as these extensions are
supported by the transport and adequately documented in the
以下に注意してください。 ある輸送飛び地では、ボディーを印刷可能なASCII文字に制限するものなどのRFC822制限が有効でないかもしれません。 (すなわち、輸送ドメインはRFC821で指定されて、RFC822によって想定されますが、ある制限なしで標準のインターネット・メール輸送に類似するかもしれません。) これらの制限の緩和は、これらの拡大が輸送で支持される限り、例えばASCII範囲の外に八重奏を含むように局所的にボディーの定義を広げながら理解されていて、適切に記録されるべきです。
Borenstein & Freed [Page 33] RFC 1521 MIME September 1993
Borensteinと解放された[33ページ]RFC1521は1993年9月にまねます。
Content-Transfer-Encoding header field. However, in no event are
headers (either message headers or body-part headers) allowed to
contain anything other than ASCII characters.
満足している転送コード化ヘッダーフィールド。 しかしながら、ヘッダー(メッセージヘッダーか身体部分ヘッダーのどちらか)はASCII文字以外の何も決して、含むことができません。
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 need to be bundled in a particular order. Any multipart subtypes that an implementation does not recognize must be treated as being of subtype "mixed".
予備選挙が副タイプする、複合です、身体の部分が、独立していて、a特定のオーダーに束ねられる必要があるとき、「混入」は使用のために意図します。 「副-タイプ」の存在が「混入した」ので、実現が認識しないどんな複合血液型亜型も扱わなければなりません。
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.
複合の、または、代替のタイプはシンタクス上複合か混ぜられるのと同じですが、意味論は異なっています。 それぞれの部品は特に、同じ情報の「代替」のバージョンです。
Systems should recognize that the content of the various parts are interchangeable. Systems should choose the "best" type based on the local environment and preferences, in some cases even through user interaction. As with multipart/mixed, the order of body parts is significant. In this case, the alternatives appear in an order of increasing faithfulness to the original content. In general, the best choice is the LAST part of a type supported by the recipient system's local environment.
システムは、様々な部分の内容が交換可能であると認めるはずです。 システムはいくつかの場合ユーザ相互作用によるさえ地方の環境と好みに基づく「最も良い」タイプを選ぶはずです。 複合か混ぜられるように、身体の部分の注文は重要です。 この場合、代替手段はオリジナルコンテンツへの増加する忠実の注文に現れます。 一般に、最も良い選択は受取人システムの地方の環境によって支持されたタイプのLAST部分です。
Multipart/alternative may be used, for example, to send mail in a fancy text format in such a way that it can easily be displayed anywhere:
例えば、複合/代替手段は容易にどこでもそれを表示できるような方法でメールを高級テキスト形式で送るのに使用されるかもしれません:
Borenstein & Freed [Page 34] RFC 1521 MIME September 1993
Borensteinと解放された[34ページ]RFC1521は1993年9月にまねます。
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
--boundary42
Content-Type: text/plain; charset=us-ascii
コンテントタイプ: テキスト/平野。 charsetが私たちと等しい、-、ASCII
...plain text version of message goes here....
--boundary42
Content-Type: text/richtext
...メッセージのプレーンテキストバージョンはここに行きます… --boundary42コンテントタイプ: テキスト/richtext
.... RFC 1341 richtext version of same message goes here ...
--boundary42
Content-Type: text/x-whatever
.... 同じメッセージのRFC1341richtextバージョンはここに行きます… --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 must 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 multipart/alternative
entities are viewed using a non-MIME-conformant mail reader.
While this approach does impose some burden on conformant mail
readers, interoperability with older mail readers was deemed to be
more important in this case.
以下に注意してください。 作成者の見解から、この注文を逆にして、最後に最も明瞭な代替手段を持っているのは、より分別があるように思えるかもしれません。 しかしながら、複合の、または、代替の実体が非MIMEのconformantメール読者を使用することで見られるとき、最初に最も明瞭な代替手段を置くのは、可能な限り好意的なオプションです。 このアプローチがconformantメール読者に何らかの負担を課している間、より年取ったメール読者がいる相互運用性がこの場合より重要であると考えられました。
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
それは彼らが形式の1つ以上を認識できるなら選択をユーザに提供するのを好むために何人かのユーザエージェントが望んでいる場合であるかもしれません。
Borenstein & Freed [Page 35] RFC 1521 MIME September 1993
Borensteinと解放された[35ページ]RFC1521は1993年9月にまねます。
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 be given the choice.
どの形式を見ますか? 例えば、メールがうまくフォーマットされたイメージバージョンと容易に編集されたテキストバージョンの両方を含んでいるなら、これは理解できます。 しかしながら、最も批判的なことは同じデータの複数のバージョンが自動的にユーザに示されないということです。 ユーザに最後に認識されたバージョンを示すべきであるか、または選択を与えるべきです。
NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a multipart/alternative entity represents the same data, but the mappings between the two are not necessarily without information loss. For example, information is lost when translating ODA to PostScript or plain text. It is recommended that each part should have a different Content-ID value in the case where the information content of the two parts is not identical. However, where the information content is identical -- for example, where several parts of type "application/external- body" specify alternate ways to access the identical data -- the same Content-ID field value should be used, to optimize any cacheing mechanisms that might be present on the recipient's end. However, it is recommended that the Content-ID values used by the parts should not be the same Content-ID value that describes the multipart/alternative as a whole, if there is any such Content-ID field. That is, one Content-ID value will refer to the multipart/alternative entity, while one or more other Content-ID values will refer to the parts inside it.
複合か代替の満足しているIDの意味論で以下に注意してください。 複合の、または、代替の実体の各部分は同じデータを表しますが、2つの間のマッピングが必ず情報の損失なしでありません。 ポストスクリプトかプレーンテキストにODAを翻訳するとき、例えば、情報は無くなっています。 各部分が2つの部品の情報量が同じでない場合で異なったコンテントID値を持っているはずであるのは、お勧めです。 しかしながら、例えば、タイプ「アプリケーション/外部のボディー」の数個の部品が指定するところで情報量が同じであるところに、同じデータにアクセスする方法を交替してください--同じコンテントID分野価値は、受取人の方に存在するかもしれないメカニズムをcacheingしながらいずれも最適化するのに使用されるべきです。 しかしながら、部品によって使用されるコンテントID値が全体で複合か代替について説明するのと同じコンテントID値でないことはお勧めです、何かそのようなコンテントID分野があれば。 すなわち、1つのコンテントID値が複合の、または、代替の実体について言及するでしょう、他の1つ以上のコンテントID値がそれの中の部品について言及するでしょうが。
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.
このドキュメントは複合Contentタイプの「ダイジェスト」「副-タイプ」を定義します。 このタイプはシンタクス上複合か混ぜられるのと同じですが、意味論は異なっています。 ダイジェストでは、特に、身体の部分へのデフォルトコンテントタイプ価値は「テキスト/平野」から「メッセージ/rfc822」に変わります。 RFC934と主に互換性がある(引用コンベンションを除いた)より読み込み可能なダイジェスト形式を許容するためにこれをします。
Borenstein & Freed [Page 36] RFC 1521 MIME September 1993
Borensteinと解放された[36ページ]RFC1521は1993年9月にまねます。
A digest in this format might, then, look something like this:
次に、この形式のダイジェストはこのように見えるかもしれません:
From: Moderator-Address
To: Recipient-List
MIME-Version: 1.0
Subject: Internet Digest, volume 42
Content-Type: multipart/digest;
boundary="---- next message ----"
From: 議長アドレスTo: 受取人リスト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, the order of body parts is not significant.
このドキュメントは複合Contentタイプの「平行な」「副-タイプ」を定義します。 このタイプはシンタクス上複合か混ぜられるのと同じですが、意味論は異なっています。 平行な実体では、身体の部分の注文は特に、重要ではありません。
A common presentation of this type is to display all of the parts simultaneously on hardware and software that are capable of doing so. However, composing agents should be aware that many mail readers will lack this capability and will show the parts serially in any event.
このタイプの一般的なプレゼンテーションは同時にそうすることができるハードウェアとソフトウェアの上に部品をすべて、表示することです。 しかしながら、エージェントを構成するのは多くのメール読者がこの能力を欠いて、順次とにかく部品を見せるのを意識しているべきです。
7.2.6. Other Multipart subtypes
7.2.6. 他のMultipart血液型亜型
Other multipart subtypes are expected in the future. MIME implementations must in general treat unrecognized subtypes of multipart as being equivalent to "multipart/mixed".
他の複合血液型亜型は将来、予想されます。 一般に、MIME実現は「複合か混ぜられること」に同等であるとして複合の認識されていない血液型亜型を扱わなければなりません。
The formal grammar for content-type header fields for multipart data is given by:
以下は複合データのための満足しているタイプヘッダーフィールドのための形式文法を与えます。
multipart-type := "multipart" "/" multipart-subtype
";" "boundary" "=" boundary
「」 「複合複合タイプ:=」」 /複合「副-タイプ」」;、」 「境界」「=」境界
Borenstein & Freed [Page 37] RFC 1521 MIME September 1993
Borensteinと解放された[37ページ]RFC1521は1993年9月にまねます。
multipart-subtype := "mixed" / "parallel" / "digest"
/ "alternative" / extension-token
拡大複合「副-タイプ」:=「混ぜられた」か「平行な」/「ダイジェスト」/「代替手段」/象徴
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)はコンテントタイプ分野にどんな必要なパラメタも持っていません。 追加「部分的である」「外部のボディー」である血液型亜型には、必要なパラメタがあります。 これらの血液型亜型は以下で説明されます。
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". Even stronger restrictions apply to the subtypes "message/partial" and "message/external-body", as specified below. 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-1522].
Content転送コード化分野の定義で述べられているように、「7ビット」、「8ビット」、または「バイナリー」以外のコード化はメッセージかタイプ「メッセージ」の部品に受入れられません。 さらに強い制限は以下で指定されるとしての「メッセージ/部分的である」「外部のメッセージ/ボディー」の血液型亜型に適用されます。 どのような場合でも、いつもメッセージヘッダーフィールドは米国-ASCIIです、そして、まだボディーの中のデータをコード化できます、そして、その場合、要約のメッセージのContent転送コード化ヘッダーフィールドはこれを反映するでしょう。 [RFC-1522]で説明されたメカニズムを使用することで要約のメッセージのヘッダーの非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. However, unlike top-level RFC 822 messages, it is not required that each message/rfc822 body must include a "From", "Subject", and at least one destination header.
「メッセージ/rfc822」のコンテントタイプは、ボディーが要約のメッセージを含むのをRFC822メッセージの構文で示します。 しかしながら、トップレベルRFC822メッセージと異なって、それぞれのメッセージ/rfc822ボディーが“From"、「対象」、および少なくとも1個の目的地ヘッダーを含まなければならないのが必要ではありません。
It should be noted that, despite the use of the numbers "822", a
それが注意されるべきである、数「822」、aの使用にもかかわらず、それ
Borenstein & Freed [Page 38] RFC 1521 MIME September 1993
Borensteinと解放された[38ページ]RFC1521は1993年9月にまねます。
message/rfc822 entity can include enhanced information as defined in this document. In other words, a message/rfc822 message may be a MIME message.
メッセージ/rfc822実体は本書では定義されるように高められた情報を含むことができます。 言い換えれば、メッセージ/rfc822メッセージはMIMEメッセージであるかもしれません。
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 the body contains a fragment of a larger message.
メッセージの「部分的な」「副-タイプ」は、大きい物が数個の別々のメールとして届けられて、受信ユーザエージェントによって自動的に組み立て直されるのを許容するために定義されます。 (概念は基本的なインターネットプロトコルにおいてIP断片化/再アセンブリと同様です。) 中間的輸送エージェントが送ることができる個々のメッセージのサイズを制限するとき、このメカニズムを使用できます。 コンテントタイプ、「メッセージ/部分的である、」 その結果、ボディーが、より大きいメッセージの断片を含むのを示します。
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 (though encouraged) 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
終えられたメッセージの部分がこの様に置かれるとき
Borenstein & Freed [Page 39] RFC 1521 MIME September 1993
Borensteinと解放された[39ページ]RFC1521は1993年9月にまねます。
together, the result is a complete MIME entity, which may have its own Content-Type header field, and thus may contain any other data type.
結果は一緒に、完全なMIME実体です。(その実体は、それ自身のコンテントタイプヘッダーフィールドを持って、その結果、いかなる他のデータ型も含むかもしれません)。
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 entities. In this process the following rules must be observed:
メッセージ/部分的なメッセージの部分を発生して、組み立て直すとき、要約のメッセージのヘッダーを同封実体のヘッダーに合併しなければなりません。 この過程で、以下の規則を守らなければなりません:
(1) All of the header fields from the initial enclosing entity
(part one), except those that start with "Content-" and the
specific header fields "Message-ID", "Encrypted", and "MIME-
Version", must be copied, in order, to the new message.
(1) 「コード化された」「内容」と特定のヘッダーフィールド「Message ID」から始めるものを除いて、ヘッダーは皆、初期の同封実体から(パート1)をさばきます、そして、「MIMEバージョン」をコピーしなければなりません、オーダーで、新しいメッセージに。
(2) Only those header fields in the enclosed message which start
with "Content-" and "Message-ID", "Encrypted", and "MIME-Version"
must be appended, in order, to the header fields of the new
message. Any header fields in the enclosed message which do not
start with "Content-" (except for "Message-ID", "Encrypted", and
"MIME-Version") will be ignored.
(2) どれが「コード化された」「内容」と「Message ID」から始めるか、そして、「MIMEバージョン」という同封のメッセージのそれらのヘッダーフィールドだけを追加しなければなりません、オーダーで、新しいメッセージのヘッダーフィールドに。 同封のメッセージの「内容」(「Message ID」、「コード化された」、および「MIMEバージョン」を除いた)から始まらないどんなヘッダーフィールドも無視されるでしょう。
(3) All of the header fields 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
X奇妙なヘッダー1: X奇妙なヘッダー2を禁じてください: こんにちは
Borenstein & Freed [Page 40] RFC 1521 MIME September 1993
Borensteinと解放された[40ページ]RFC1521は1993年9月にまねます。
Message-ID: <anotherid@foo.com>
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
Message ID: <anotherid@foo.com>MIMEバージョン: 1.0文書内容: 基本的な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:
次に、断片化しているメッセージが組み立て直されるとき、ユーザに表示されるべき結果として起こるメッセージはこのように見えるべきです:
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...
… コード化されたオーディオデータの前半はここへ去ります… … コード化されたオーディオデータの後半はここへ去ります…
Note on encoding of MIME entities encapsulated inside message/partial entities: Because data of type "message" may never be encoded in base64 or quoted-printable, a problem might arise if message/partial entities are constructed in an environment that supports binary or 8-bit transport. The problem is that the binary data would be split into multiple message/partial objects, each of them requiring binary transport. If such objects were encountered at a gateway into a 7- bit transport environment, there would be no way to properly encode them for the 7-bit world, aside from waiting for all of the parts, reassembling the message, and then encoding the reassembled data in base64 or quoted-printable. Since it is possible that different parts might go through different gateways, even this is not an acceptable solution. For this reason, it is specified that MIME entities of type message/partial must always have a content-
MIMEのコード化のときに、実体がメッセージ/部分的な実体で要約されたことに注意してください: タイプ「メッセージ」のデータがbase64でコード化されているか、または引用されて決して印刷可能でないかもしれないので、メッセージ/部分的な実体が2進の、または、8ビットの輸送を支持する環境で構成されるなら、問題は起こるかもしれません。 問題は2進のデータが複数のメッセージ/部分的な物に分けられるだろうということです。(それらのそれぞれは物のために2進の輸送を必要とすることです)。 そのような物がゲートウェイで7の噛み付いている輸送環境に遭遇するなら、base64で部品をすべて、待っていて、メッセージを組み立て直して、次に、組み立て直されたデータをコード化することは別として世界的の7ビットか引用されて印刷可能ために適切にそれらをコード化する方法が全くないでしょうに。 異なった部品が異なったゲートウェイを通るのが、可能であるので、これさえ許容できる解決策ではありません。 この理由として、タイプメッセージ/部分的のMIME実体には内容がいつもなければならないと指定されます。
Borenstein & Freed [Page 41] RFC 1521 MIME September 1993
Borensteinと解放された[41ページ]RFC1521は1993年9月にまねます。
transfer-encoding of 7-bit (the default). In particular, even in environments that support binary or 8-bit transport, the use of a content-transfer-encoding of "8bit" or "binary" is explicitly prohibited for entities of type message/partial.
7ビット(デフォルト)の転送コード化。 2進の、または、8ビットの輸送を支持する環境でさえ、「8ビット」か「バイナリー」の満足している転送コード化の使用はタイプメッセージ/部分的の実体のために明らかに禁止されています。
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-イドがそうする参照がそれを読者に郵送するのに有益であるという断片化しているメッセージのその後の断片が参照を理解して、追跡することに注意されるべきです。 しかしながら、そのような「参照」分野の世代は完全に任意です。
Finally, it should be noted that the "Encrypted" header field has been made obsolete by Privacy Enhanced Messaging (PEM), but the rules above are believed to describe the correct way to treat it if it is encountered in the context of conversion to and from message/partial fragments.
最終的に、「コード化された」ヘッダーフィールドがPrivacy Enhanced Messaging(PEM)によって時代遅れにされたことに注意されるべきですが、変換の文脈で断片と、そして、メッセージ/部分的な断片から遭遇するなら、上の規則がそれを扱う適度の方法を述べると信じられています。
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 an entity 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
Content-ID: <id42@guppylake.bellcore.com>
Content-Transfer-Encoding: binary
文書内容: イメージ/gifコンテントID: <のid42@guppylake.bellcore.comの>の満足している転送コード化: バイナリー
Borenstein & Freed [Page 42] RFC 1521 MIME September 1993
Borensteinと解放された[42ページ]RFC1521は1993年9月にまねます。
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 auxiliary information for some 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 -- A case-insensitive word, indicating the supported
access mechanism 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 E .
ACCESS-TYPE--ファイルかデータが入手されるかもしれない支持されたアクセス機構を示す大文字と小文字を区別しない単語。 含んでいますが、値が制限されない、「FTP」、「やがて、-、FTP、」、"TFTP"、「AFS」、「ローカルファイル」、および「メールサーバ。」 将来価値であり、実験値を除いて、付録Eで説明されるように「X」と共に始まるのをIANAに登録しなければなりません。
In addition, the following three parameters are optional for ALL access-types:
さらに、すべてのアクセス型には、以下の3つのパラメタが任意です:
EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as
extended by RFC 1123 to permit 4 digits in the year 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. Note that
this describes the size of the data in its canonical form, that
is, before any Content- Transfer-Encoding has been applied or
after the data have been decoded.
SIZE--データのサイズ(八重奏における)。 このパラメタの意図は受取人が、外部のデータを検索するために必要なリソースを費やすかどうか決めるのを助けることです。 これが標準形のデータのサイズについて説明することに注意してください、すなわち、どんなContent転送コード化も適用される前かデータが解読された後に。
PERMISSION -- A case-insensitive 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.
ここで定義されたアクセス型の正確な意味論は従うセクションで説明されます。
The encapsulated headers in ALL message/external-body entities MUST include a Content-ID header field to give a unique identifier by
すべての外部のメッセージ/ボディー実体における要約のヘッダーはユニークな識別子を与えるコンテントIDヘッダーフィールドを入れなければなりません。
Borenstein & Freed [Page 43] RFC 1521 MIME September 1993
Borensteinと解放された[43ページ]RFC1521は1993年9月にまねます。
which to reference the data. This identifier may be used for cacheing mechanisms, and for recognizing the receipt of the data when the access-type is "mail-server".
どれ、参照へのデータ。 この識別子は、アクセス型が「メールサーバ」であるときにメカニズムをcacheingして、データの領収書を認識するのに使用されるかもしれません。
Note that, as specified here, the tokens that describe external-body data, such as file names and mail server commands, are required to be in the US-ASCII character set. If this proves problematic in practice, a new mechanism may be required as a future extension to MIME, either as newly defined access-types for message/external-body or by some other mechanism.
米国-ASCII文字の組にはここで指定されるとしてファイル名やメールサーバコマンドなどの外部のボディーデータについて説明する象徴がなければならないことに注意してください。 これが実際には問題が多いと判明するなら、新しいメカニズムはMIMEへの今後の拡大、外部のメッセージ/ボディーのための新たに定義されたアクセス型またはある他のメカニズムによって必要とされるかもしれません。
As with message/partial, it is specified that MIME entities of type message/external-body must always have a content-transfer-encoding of 7-bit (the default). In particular, even in environments that support binary or 8-bit transport, the use of a content-transfer- encoding of "8bit" or "binary" is explicitly prohibited for entities of type message/external-body.
メッセージ/パーシャルによって、外部のタイプメッセージ/ボディーのMIME実体には内容がコード化を移している7ビット(デフォルト)がいつもなければならないと指定されます。 2進の、または、8ビットの輸送を支持する環境でさえ、「8ビット」か「バイナリー」の満足している転送コード化の使用はタイプの実体のために明らかに外部のメッセージ/ボディーで禁止されています。
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]プロトコルを使用するのにおいてアクセスしやすいのを示します。 これらのアクセス型にとって、以下の追加パラメタは義務的です:
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. This must be a fully qualified domain name, not a
nickname.
SITE--与えられたプロトコルを使用して、ファイルが入手されるかもしれないマシン。 これはあだ名ではなく、完全修飾ドメイン名であるに違いありません。
Before any data are retrieved, using FTP, the user will generally need to be asked to provide a login id and a password for the machine named by the site parameter. For security reasons, such an id and password are not specified as content-type parameters, but must be obtained from the user.
FTPを使用して、どんなデータも検索される前に、一般に、ユーザは、サイトパラメタによって指定されたマシンのためのログインイドとパスワードを提供するように頼まれる必要があるでしょう。 安全保障上の理由で、そのようなイドとパスワードを満足している型引数として指定しませんが、ユーザから得なければなりません。
In addition, the following parameters are optional:
さらに、以下のパラメタは任意です:
DIRECTORY -- A directory from which the data named by NAME should
be retrieved.
ディレクトリ--NAMEによって指定されたデータが検索されるべきであるディレクトリ。
MODE -- A case-insensitive string indicating the mode to be used
when retrieving the information. The legal values for access-type
"TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the
TFTP protocol [RFC-783]. The legal values for access-type "FTP"
are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
decimal integer, typically 8. These correspond to the
MODE--情報を検索するとき、使用されるためにモードを示す大文字と小文字を区別しないストリング。 アクセス型"TFTP"のための法定価格は、TFTPプロトコル[RFC-783]による"NETASCII"と、「八重奏」と、指定されるとして「メール」です。 アクセス型「FTP」のための法定価格は、通常、「n」が10進整数、8である「ASCII」と、"EBCDIC"と、「イメージ」と、"LOCALn"です。 これらは相当しています。
Borenstein & Freed [Page 44] RFC 1521 MIME September 1993
Borensteinと解放された[44ページ]RFC1521は1993年9月にまねます。
representation types "A" "E" "I" and "L n" as specified by the FTP
protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid
values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be
used instead. IF MODE is not specified, the default value is
"NETASCII" for TFTP and "ASCII" otherwise.
表現は「E」FTPによって指定される「私」と「L n」プロトコル[RFC-959]をタイプします。 「「バイナリー」と"TENEX"は、モードのための有効値ではなく、その「八重奏」かイメージであるかLOCAL8"は代わりに使用されるべきです。」と述べてください。 MODEが指定されないなら、そうでなければ、デフォルト値は、TFTPのための"NETASCII"と「ASCII」です。
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. 「メールサーバ」アクセス型
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 syntaxes, 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 is provided as the "phantom body" when the content-type is
メールサーバがさまざまな構文(それのいくつかがマルチラインである)を受け入れるので、メールサーバに送られるべき完全なコマンドはcontent type系列に関するパラメタとして含まれていません。 content typeが提供するとき、代わりに、「幻影のボディー」としてそれを提供します。
Borenstein & Freed [Page 45] RFC 1521 MIME September 1993
Borensteinと解放された[45ページ]RFC1521は1993年9月にまねます。
message/external-body and the access- type is mail-server.
外部のメッセージ/ボディーとアクセスタイプはメールサーバです。
An optional parameter for this access-type is:
このアクセス型にとって、任意のパラメタは以下の通りです。
SUBJECT -- The subject that is to be used in the mail that is sent
to obtain the data. Note that keying mail servers on Subject lines
is NOT recommended, but such mail servers are known to exist.
SUBJECT--データを得るために送られるメールで使用されることになっている対象。 メールサーバをSubject系列に合わせるのが推薦されませんが、そのようなメールサーバが存在するのが知られていることに注意してください。
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 must include the phantom body in the body of the message it sends to the mail server address to retrieve the relevant data.
MIMEがメールサーバ構文を定義しないことに注意してください。 むしろ、それは幻影のボディーでの任意のメールサーバコマンドの包含を許容します。 実装はそれが関連データを検索するためにメールサーバアドレスに送るメッセージ欄に幻影のボディーを含まなければなりません。
It is worth noting that, unlike other access-types, mail-server access is asynchronous and will happen at an unpredictable time in the future. For this reason, it is important that there be a mechanism by which the returned data can be matched up with the original message/external-body entity. MIME mailservers must use the same Content-ID field on the returned message that was used in the original message/external-body entity, to facilitate such matching.
メールサーバアクセスが他のアクセス型と異なって非同期であり、将来予測できない時に起こることに注意する価値があります。 そこに、いてください。この理由で、それが重要である、それ、返されたデータがあることができるメカニズムはオリジナルの外部のメッセージ/ボディー実体に合いました。 MIME mailserversはそのようなマッチングを容易にするのにオリジナルの外部のメッセージ/ボディー実体に使用された返されたメッセージの同じコンテントID分野を使用しなければなりません。
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
実体が次に、「外部のメッセージ/ボディー」であり、タイプに、実体のボディーがカプセル化されたメッセージのヘッダーフィールドを含むということであるなら。 ボディー自体は外部の位置で見つけられることになっています。 これは、「外部のメッセージ/ボディー」メッセージのボディーが2連続したCRLFsを含むなら、それらの組後のすべてがメッセージ自体の一部でないことを意味します。 ほとんどの外部のメッセージ/ボディーメッセージに関しては、単にこの引きずっている領域を無視しなければなりません。 しかしながら、それはa便利です。
Borenstein & Freed [Page 46] RFC 1521 MIME September 1993
Borensteinと解放された[46ページ]RFC1521は1993年9月にまねます。
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 the value of the SERVER parameter.
content typeヘッダーフィールドに含むことができない追加データには、入賞してください。 特に、引きずっている領域は「アクセス型」値が「メールサーバ」であるならSERVERパラメタの値によって与えられたアドレスにメールサーバに送られるべきコマンドを含まなければなりません。
The embedded message header fields which appear in the body of the message/external-body data must be used to declare the Content-type of the external body if it is anything other than plain ASCII text, since the external body does not have a header section to declare its type. Similarly, any Content-transfer-encoding other than "7bit" must also be declared here. Thus a complete message/external-body message, referring to a document in PostScript format, might look like this:
それが明瞭なASCIIテキスト以外の何かであるなら外部のボディーに関する文書内容を宣言するのに外部のメッセージ欄/ボディーデータに現れる埋め込まれたメッセージヘッダーフィールドを使用しなければなりません、外部のボディーにはタイプを宣言するヘッダー部分がないので。 また、同様に、ここで「7ビット」を除いたどんなContent転送コード化も宣言しなければなりません。 したがって、ポストスクリプト形式でドキュメントを参照する場合、完全な外部のメッセージ/ボディーメッセージはこれに似るかもしれません:
From: Whomever
To: Someone
Subject: whatever
MIME-Version: 1.0
Message-ID: <id1@host.com>
Content-Type: multipart/alternative; boundary=42
Content-ID: <id001@guppylake.bellcore.com>
From: 誰でも、To: だれか、Subject: いかなるMIMEバージョンも: 1.0Message ID: <id1@host.com>コンテントタイプ: 複合/代替手段。 境界=42コンテントID: <id001@guppylake.bellcore.com>。
--42
Content-Type: message/external-body;
name="BodyFormats.ps";
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
--42コンテントタイプ: 外部のメッセージ/ボディー。 「BodyFormats.ps」と=を命名してください。 サイトは"thumper.bellcore.com"と等しいです。 = やがてFTPをアクセスしてタイプする、。 ディレクトリは「パブ」と等しいです。 モードは「イメージ」と等しいです。 満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>
文書内容: アプリケーション/追伸コンテントID: <id42@guppylake.bellcore.com>。
--42
Content-Type: message/external-body;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
access-type=AFS
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
--42コンテントタイプ: 外部のメッセージ/ボディー。 「/u/nsb/writing/rfcs/RFC-MIME.ps」と=を命名してください。 サイトは"thumper.bellcore.com"と等しいです。 アクセス型=AFS満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>
文書内容: アプリケーション/追伸コンテントID: <id42@guppylake.bellcore.com>。
--42
Content-Type: message/external-body;
access-type=mail-server
--42コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型はメールサーバと等しいです。
Borenstein & Freed [Page 47] RFC 1521 MIME September 1993
Borensteinと解放された[47ページ]RFC1521は1993年9月にまねます。
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
サーバは" listserv@bogus.bitnet "と等しいです。 満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>
文書内容: アプリケーション/追伸コンテントID: <id42@guppylake.bellcore.com>。
get RFC-MIME.DOC
RFC-MIME.DOCを手に入れてください。
--42--
--42--
Note that in the above examples, the default Content-transfer- encoding of "7bit" is assumed for the external postscript data.
上記の例では、「7ビット」のデフォルトContent-転送コード化が外部の追伸データのために想定されることに注意してください。
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の最初の連続した組の前の何は特に、ヘッダー情報ですでも、それの後の何がボディー情報ですがも。(それは、ほとんどのアクセス型のために無視されます)。
The formal grammar for content-type header fields for data of type message is given by:
以下はタイプメッセージに関するデータのためのcontent typeヘッダーフィールドのための形式文法を与えます。
message-type := "message" "/" message-subtype
」 「メッセージタイプ:=「メッセージ」」/メッセージ-「副-タイプ」
message-subtype := "rfc822"
/ "partial" 2#3partial-param
/ "external-body" 1*external-param
/ extension-token
メッセージ-「副-タイプ」:="rfc822"/「部分的な」2#3partial-param/「外部のボディー」の1つの*拡大外部のparam/トークン
partial-param := (";" "id" "=" value)
/ (";" "number" "=" 1*DIGIT)
/ (";" "total" "=" 1*DIGIT)
; id & number required; total required for last part
部分的なparam:=、(「」、;、「イド」が値) /と「等しい」 (「」、;、「数」が1*ケタ) /と「等しい」 (「」、;、「総」「=」1*ケタ)、。 イドと数が必要です。 合計が最後の部分に必要です。
external-param := (";" "access-type" "=" atype)
外部のparam:=(「」、;、「アクセス型」「=」atype)
Borenstein & Freed [Page 48] RFC 1521 MIME September 1993
Borensteinと解放された[48ページ]RFC1521は1993年9月にまねます。
/ (";" "expiration" "=" date-time)
; Note that date-time is quoted
/ (";" "size" "=" 1*DIGIT)
/ (";" "permission" "=" ("read" / "read-write"))
; Permission is case-insensitive
/ (";" "name" "=" value)
/ (";" "site" "=" value)
/ (";" "dir" "=" value)
/ (";" "mode" "=" value)
/ (";" "server" "=" value)
/ (";" "subject" "=" value)
; access-type required;others required based on access-type
/、(「」、;、「満了」「=」日付-時間)、。 日付-時間が引用されることに注意してください、/、(「」、;、「サイズ」が1*ケタ) /と「等しい」 (「; 」 「許可」「=」(「読む」か、または「読書して書きます」)。 許可..大文字と小文字を区別しない..名前..等しい..値..サイト..等しい..値..等しい..値..モード..等しい..値..サーバ..等しい..値..受けることがある..値 アクセス型が必要です; 他のものがアクセス型に基づいて必要です。
atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
/ "afs" / "mail-server" / extension-token
; Case-insensitive
atype:=は拡大/"tftp"/「ローカルファイル」/"afs"/「メールサーバ」/トークンを"ftpする"である、または「やがて、ftpします」。 大文字と小文字を区別しない
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 must be understood by implementors, and are considered in detail in the discussion of the application/PostScript 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 two subtypes: octet-stream, and PostScript.
そのようなアプリケーションは「アプリケーション」コンテントタイプの血液型亜型と定義されるかもしれません。 このドキュメントは2血液型亜型を定義します: 八重奏ストリーム、およびポストスクリプト。
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 (other than subtypes beginning
一般に、アプリケーションの「副-タイプ」はしばしばデータが意図するアプリケーションの名前になるでしょう。 しかしながら、これは、どんな応用プログラム名もアプリケーションの「副-タイプ」として自由に使用されるかもしれないことを意味しません。 そのような用法、(血液型亜型始め
Borenstein & Freed [Page 49] RFC 1521 MIME September 1993
Borensteinと解放された[49ページ]RFC1521は1993年9月にまねます。
with "x-") must be registered with IANA, as described in Appendix E.
「x」) 必須で、Appendix Eで説明されるように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:
「八重奏ストリーム」というアプリケーションのプライマリ「副-タイプ」は、ボディーがバイナリ・データを含むのを示すのに使用されるかもしれません。 含んでいますが、可能なパラメタのセットは制限されません:
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--バイナリ・データの一般型かカテゴリ。 これはどんな自動処理のためにもというよりむしろ人間の受取人への情報として意図します。
PADDING -- the number of bits of padding that were appended to the
bit-stream comprising the actual contents to produce the enclosed
byte-oriented data. This is useful for enclosing a bit-stream in
a body when the total number of bits is not a multiple of the byte
size.
PADDING--同封のバイト指向のデータを作り出すために実際のコンテンツを包括するビットストリームにそれを水増しするビットの数を追加しました。 ビットの総数がバイトサイズの倍数でないときに、これは一団となって少し流れた状態で同封の役に立ちます。
An additional parameter, "conversions", was defined in [RFC-1341] but has been removed.
「変換」という追加パラメタを、[RFC-1341]で定義されましたが、取り除いてあります。
RFC 1341 also defined the use of a "NAME" parameter which gave a suggested file name to be used if the data were to be written to a file. This has been deprecated in anticipation of a separate Content-Disposition header field, to be defined in a subsequent RFC.
また、RFC1341はデータがファイルに書かれていることであったなら使用されるために提案されたファイル名を与えた「名前」パラメタの使用を定義しました。 これは、別々のContent-気質ヘッダーフィールドを予測してその後のRFCで定義されるために推奨しないです。
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. Currently two variants of the PostScript language are allowed; the original level 1 variant is described in [POSTSCRIPT] and the more recent level 2 variant is described in [POSTSCRIPT2].
「アプリケーション/追伸」のコンテントタイプはポストスクリプトプログラムについて簡単に述べます。 現在の、ポストスクリプト言語の2つの異形が許容されています。 オリジナルの平らな1つの異形が[POSTSCRIPT]で説明されます、そして、より最近の平らな2異形は[POSTSCRIPT2]で説明されます。
PostScript is a registered trademark of Adobe Systems, Inc. Use of the MIME content-type "application/postscript" implies recognition of that trademark and all the rights it entails.
ポストスクリプトはMIME content type「アプリケーション/追伸」のアドビ・システムズInc.Useの登録商標がそれが伴うその商標とすべての権利の認識を含意するということです。
Borenstein & Freed [Page 50] RFC 1521 MIME September 1993
Borensteinと解放された[50ページ]RFC1521は1993年9月にまねます。
The PostScript language definition provides facilities for internal labeling of the specific language features a given program uses. This labeling, called the PostScript document structuring conventions, is very general and provides substantially more information than just the language level.
ポストスクリプト言語定義は与えられたプログラムが使用する特定の言語機能の内部のラベリングのために便宜を与えます。 コンベンションを構造化するポストスクリプトドキュメントと呼ばれるこのラベリングは、非常に一般的であり、まさしく言語水準より実質的に多くの情報を提供します。
The use of document structuring conventions, while not required, is strongly recommended as an aid to interoperability. Documents which lack proper structuring conventions cannot be tested to see whether or not they will work in a given environment. As such, some systems may assume the worst and refuse to process unstructured documents.
必要でない間にコンベンションを構造化するドキュメントの使用は相互運用性への援助として強く推薦されます。 それらが与えられた環境で働くかどうか確認するためにコンベンションを構造化しながら適切な状態で欠けているドキュメントはテストできません。 そういうものとして、いくつかのシステムが、最悪を仮定して、不統一な文書を処理するのを拒否するかもしれません。
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 re-enabling 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
ポストスクリプト言語は普通のインタプリタ、またはサーバを出るために便宜を与えて、輪にしてください。 この「外側」の環境で行われた変更は、ドキュメントの向こう側に通例に保有されて、いくつかの場合、不揮発性メモリで半永久保有されるかもしれません。 The
Borenstein & Freed [Page 51] RFC 1521 MIME September 1993
Borensteinと解放された[51ページ]RFC1521は1993年9月にまねます。
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, and eliminate the startjob and exitserver commands. If these commands cannot be eliminated, the password associated with them should at least be set to a hard-to-guess value.
インタプリタ輪を出ると関連しているオペレータには、その後の文書処理を妨げる可能性があります。 そういうものとして、彼らの気ままな使用はサービス否定の脅威を構成します。 含んでいますが、輪が制限されないかもしれないインタプリタ、exitserver、およびstartjobオペレータを出るポストスクリプトオペレータ。 メッセージ送付ソフトウェアは作動するためにインタプリタ輪を出るのによるポストスクリプトを生成するはずがありません。 出る能力はたぶん安全なポストスクリプト実装で入手できなくなるでしょう。 できれば、メッセージ受信と表示ソフトウェアはポストスクリプト環境への保有された変更を行って、startjobとexitserverコマンドを排除する能力を無効にするはずです。 これらのコマンドを排除できないなら、それらに関連しているパスワードは推測しにくい値に少なくとも設定されるべきです。
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, the password associated with them should at least be set 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
多量の様々なシステム資源を消費するポストスクリプトを書くのは可能です。 また、ポストスクリプトプログラムにその輪を無限に書くのも可能です。 両方のタイプに関するプログラムは持っています。
Borenstein & Freed [Page 52] RFC 1521 MIME September 1993
Borensteinと解放された[52ページ]RFC1521は1993年9月にまねます。
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 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. Other Application subtypes
7.4.3. 他のApplication血液型亜型
It is expected that many other subtypes of application will be defined in the future. MIME implementations must generally treat any unrecognized subtypes as being equivalent to application/octet- stream.
そんなに多く、アプリケーションの他の血液型亜型が将来定義されると予想されます。 一般に、MIME実装はアプリケーション/八重奏ストリームに同等であるとしてどんな認識されていない血液型亜型も扱わなければなりません。
The formal grammar for content-type header fields for application data is given by:
以下はアプリケーションデータのためのcontent typeヘッダーフィールドのための形式文法を与えます。
application-type := "application" "/" application-subtype
」 「アプリケーションタイプ:=「アプリケーション」」/アプリケーション-「副-タイプ」
application-subtype := ("octet-stream" *stream-param)
/ "postscript" / extension-token
拡大アプリケーション-「副-タイプ」:=(「八重奏ストリーム」*ストリームparam)/「追伸」/トークン
stream-param := (";" "type" "=" value)
/ (";" "padding" "=" padding)
ストリーム-param:=、(「」、;「タイプ」が値) /と「等しい」 (「」、;、「=」詰め物は「水増し」です)
padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
:=を水増しする、「0インチ/、「1インチ/、「2インチ/、「3インチ/、「4インチ/、「5インチ/、「6インチ/「7インチ」
7.5. The Image Content-Type
7.5. イメージコンテントタイプ
A Content-Type of "image" indicates that the body contains 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].
「イメージ」のコンテントタイプは、ボディーがイメージを含むのを示します。 「副-タイプ」は特定の画像形式を命名します。 これらの名前は大文字と小文字を区別しないです。 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 E.
ここに与えられたイメージ血液型亜型のリストは、排他的でなくて、また徹底的でなく、より多くのタイプがIANAに示されるとき成長すると予想されます、Appendix Eで説明されるように。
The formal grammar for the content-type header field for data of type image is given by:
以下はタイプイメージに関するデータのためのcontent typeヘッダーフィールドのための形式文法を与えます。
Borenstein & Freed [Page 53] RFC 1521 MIME September 1993
Borensteinと解放された[53ページ]RFC1521は1993年9月にまねます。
image-type := "image" "/" ("gif" / "jpeg" / extension-token)
「イメージタイプ:=は」 /に「像を描きます」」(拡大"gif"/"jpeg"/トークン)
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 mu-law [PCM]. When this subtype is present, a sample rate of 8000 Hz and a single channel is assumed.
「オーディオ的か基本的な」「副-タイプ」の内容はオーディオが使用の8ビットのISDNμ法をコード化したという[PCM]ことです。 この「副-タイプ」が存在しているとき、8000Hzと単独のチャンネルの見本郵送料率は想定されます。
The formal grammar for the content-type header field for data of type audio is given by:
以下はタイプオーディオに関するデータのためのcontent typeヘッダーフィールドのための形式文法を与えます。
audio-type := "audio" "/" ("basic" / extension-token)
「オーディオのタイプ:=「オーディオ」」/、」(拡大「基本的」/トークン)
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".
このドキュメントが単一のボディーでのマルチメディアの混合を一般に強くがっかりさせますが、多くのいわゆる「ビデオ」形式が連動しているオーディオの表現を含んでいると認められて、これが「ビデオ」の血液型亜型のために明らかに許可されていることに注意してください。
The formal grammar for the content-type header field for data of type video is given by:
以下はタイプビデオに関するデータのためのcontent typeヘッダーフィールドのための形式文法を与えます。
video-type := "video" "/" ("mpeg" / extension-token)
「ビデオタイプ:=「ビデオ」」/、」(拡大"mpeg"/トークン)
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
キャラクタ「X」と共に始まるコンテントタイプ値は、相談ずくの同意しているメールシステムによって使用されるためには個人的な値です。 厳しくて公共の定義のないどんな形式も命名しなければなりません。
Borenstein & Freed [Page 54] RFC 1521 MIME September 1993
Borensteinと解放された[54ページ]RFC1521は1993年9月にまねます。
with an "X-" prefix, and publicly specified values shall never begin with "X-". (Older versions of the widely-used Andrew system use the "X-BE2" name, so new systems should probably choose a different name.)
「X」で、接頭語の、そして、公的に指定された値は「X」と共に決して始まらないものとします。 (広く使用されたアンドリューシステムの旧式のバージョンが使用する、「システムがたぶん異なった名前を選ぶはずであるように、名前であって、とても新しい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 55] RFC 1521 MIME September 1993
Borensteinと解放された[55ページ]RFC1521は1993年9月にまねます。
8. Summary
8. 概要
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 message/partial, and message/external-body.
MIMEバージョン、コンテントタイプ、およびContent転送コード化ヘッダーフィールドを使用して、RFCがある標準化された道、任意のタイプのデータ・オブジェクトに822のconformantメール・メッセージを含んでいるのは可能です。 RFC821かRFC822のどちらかによって課されなかった制限は全く違反されます、そして、いくつかのインターネット・メール移送機構の特性によって課された追加制限で引き起こされた問題を避けるために、注意しました(Appendix Bを見てください)。 「複合」と「メッセージ」コンテントタイプはただ一つのメッセージに異なったタイプのオブジェクトの混合と階層構造形成を許容します。 さらなるContentタイプはオーディオ、イメージ、または他の数種類のデータとしてメッセージか身体の部分にタグ付けをするのに標準化されたメカニズムを提供します。 顕著なパラメタ構文はさらにデータの形式の詳細の仕様、特に代替の文字集合の仕様を許容します。 追加任意のヘッダーフィールドは望ましいと多くの作成者によって考えられたある拡大にメカニズムを提供します。 最終的に、多くの役に立つコンテントタイプが、一般的使用のために同意しているユーザエージェントによって定義されるのと、著しくメッセージ/部分と、外部のメッセージ/ボディーです。
9. Security Considerations
9. セキュリティ問題
Security issues are discussed in Section 7.4.2 and in Appendix F. 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 application/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では、F.Implementorsは受取人の環境における、どんな動作のリモート実行も引き起こす場合があるどんなメールcontent typeのセキュリティ含意に関する特別な注意も向けるはずです。 そのような場合、他の内容を考えるためのモデルがリモート実行能力でタイプするようにセクション7.4.2における、アプリケーション/追伸content typeの議論は役立つかもしれません。
Borenstein & Freed [Page 56] RFC 1521 MIME September 1993
Borensteinと解放された[56ページ]RFC1521は1993年9月にまねます。
10. Authors' Addresses
10. 作者のアドレス
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 909 624 7907 Fax: +1 909 621 5319 Email: ned@innosoft.com
以下に電話をしてください。 +1 909 624、7907Fax: +1 5319年の909 621メール: ned@innosoft.com
MIME is a result of the work of the Internet Engineering Task Force Working Group on Email Extensions. The chairman of that group, Greg Vaudreuil, may be reached at:
MIMEはメールExtensionsへのインターネット・エンジニアリング・タスク・フォース作業部会の作業の結果です。 そのグループ、グレッグ・ボードルイの議長は以下で連絡されるかもしれません。
Gregory M. Vaudreuil Tigon Corporation 17060 Dallas Parkway Dallas Texas, 75248
グレゴリーM.ボードルイタイゴン社17060のダラス公園道路ダラステキサス、75248
Phone: +1 214-733-2722 EMail: gvaudre@cnri.reston.va.us
以下に電話をしてください。 +1 214-733-2722 メールしてください: gvaudre@cnri.reston.va.us
Borenstein & Freed [Page 57] RFC 1521 MIME September 1993
Borensteinと解放された[57ページ]RFC1521は1993年9月にまねます。
11. Acknowledgements
11. 承認
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
ハラルド・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ライアン・ウォルドロン
Borenstein & Freed [Page 58] RFC 1521 MIME September 1993
Borensteinと解放された[58ページ]RFC1521は1993年9月にまねます。
Jim Knowles Wally Wedel
Stev Knowles Sven-Ove Westberg
Bob Kummerfeld Brian Wideen
Pekka Kytolaakso John Wobus
Stellan Lagerstrom Glenn Wright
Vincent Lau Rayan Zachariassen
Donald Lindsay David Zimmerman
Marc Andreessen Bob Braden
Brian Capouch Peter Clitherow
Dave Collier-Brown John Coonrod
Stephen Crocker Jim Davis
Axel Deininger Dana S Emery
Martin Forssen Stephen Gildea
Terry Gray Mark Horton
Warner Losh Carlyn Lowery
Laurence Lundblade Charles Lynn
Larry Masinter Michael J. McInerny
Jon Postel Christer Romson
Yutaka Sato Markku Savela
Richard Alan Schafer Larry W. Virden
Rhys Weatherly Jay Weber
Dave Wecker
ジムノウルズウォリーウェデルStevノウルズスベン-OveウェストバーグボブKummerfeldブライアンWideenペッカKytolaaksoジョンWobusステランLagerstromグレン職人のヴィンセント・ラウ・ライアン・Zachariassenドナルド・リンゼー・デヴィッド・ジンマーマン・マーク・アンドリーセン・ボブ・ブレーデン・ブライアン・Capouchピーター・クリゼロウ・デーヴ・石炭船ブラウン・ジョン・Coonrodスティーブン・Crockerジム・デイヴィス・Axel Deiningerダナ・S Emeryマーチン・Forssenスティーブン・Gildea Terryグレー・マークホートンワーナー・Losh Carlynローリー・ローレンス・Lundbladeチャールズ・リンラリー・MasinterマイケルJ; McInernyジョンポステルChrister Romsonユタカ佐藤マルックSavelaリチャードアランシェッフルラリーW.のバーデンリスWeatherlyのジェイウェーバーデーヴWecker
The authors apologize for any omissions from this list, which are certainly unintentional.
作者はこのリストからのどんな省略も謝ります。(確かに、省略は意図的ではありません)。
Borenstein & Freed [Page 59] RFC 1521 MIME September 1993
Borensteinと解放された[59ページ]RFC1521は1993年9月にまねます。
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."
-- 「米国-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.
-- 「ISO8859*」文字の組をISO8859*と米国-ASCIIに共通のそれらのキャラクタは見せることができる範囲まで認識してください、すなわち、八重奏値0-127によって代理をされたすべてのキャラクタ。
Borenstein & Freed [Page 60] RFC 1521 MIME September 1993
Borensteinと解放された[60ページ]RFC1521は1993年9月にまねます。
-- For unrecognized subtypes, show or
offer to show the user the "raw"
version of the data after
conversion of the content from
canonical form to local form.
-- 認識されていない血液型亜型には、目立つか、または内容の標準形から地方のフォームまでの変換の後にデータの「生」のバージョンをユーザに示すと申し出てください。
Message:
メッセージ:
-- Recognize and display at least the
primary (822) encapsulation.
-- 少なくとも第一の(822)カプセル化を認識して、表示してください。
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.
-- 本書では定義された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-
上記の条件を満たすユーザエージェントはMIMEであると言われています。
Borenstein & Freed [Page 61] RFC 1521 MIME September 1993
Borensteinと解放された[61ページ]RFC1521は1993年9月にまねます。
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 have the additional guarantee that the user will not be shown data that were never intended to be viewed as text.
conformant。 この句の意味は実際にはどんな種類の適切に著しいデータもそのようなメールシステムのユーザに送るために「安全である」と思われるということです、そのようなシステムが非分化しているバイナリーとしてデータを少なくとも扱うことができて、疑いを持たないユーザーのスクリーンにそれを絶対にはねかけないので。 壊れているというそのようなデータがRFC821とRFC822とconformantであるどんな知られているシステムでも壊さないで、またならないことであるMIME conformantである形式でデータを送るのがいつも「安全である」別の感覚があります。 MIME-conformantであるユーザエージェントはテキストとして見なされることを決して意図しなかったデータがユーザに示されないという追加保証を持っています。
Borenstein & Freed [Page 62] RFC 1521 MIME September 1993
Borensteinと解放された[62ページ]RFC1521は1993年9月にまねます。
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 bodies. As such, the persistence of CRLF as
something other than a line break must 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 must
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 must not rely on the persistence of
TAB (HT) characters.
(3) TAB(HT)キャラクタは、誤解されるか、または自動的に可変数の空間に変換されるかもしれません。 これはいくつかの環境、著しくASCII文字の組に基づかないもので避けられません。 起こるかもしれません、そして、そのような変換はSTRONGLY DISCOURAGEDですが、メール書式はTAB(HT)キャラクタの固執に依存してはいけません。
(4) Lines longer than 76 characters may be wrapped or truncated in
some environments. Line wrapping and line truncation are STRONGLY
(4) 76のキャラクタより長い線は、いくつかの環境で包装されるか、または先端を切られるかもしれません。 線ラッピングと線トランケーションはSTRONGLYです。
Borenstein & Freed [Page 63] RFC 1521 MIME September 1993
Borensteinと解放された[63ページ]RFC1521は1993年9月にまねます。
DISCOURAGED, but unavoidable in some cases. Applications which
require long lines must somehow differentiate between soft and
hard line breaks. (A simple way to do this is to use the quoted-
printable encoding.)
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, must 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 73
characters.
base64コード化などの最高に携帯用のメール表現はそれ自体を唯一の重要なキャラクタが73のキャラクタのこのセットから取られるテキストの比較的短い線に制限するでしょう。
(7) Some mail transport agents will corrupt data that includes
certain literal strings. In particular, a period (".") alone on a
line is known to be corrupted by some (incorrect) SMTP
implementations, and a line that starts with the five characters
"From " (the fifth character is a SPACE) are commonly corrupted as
(7) 何人かのメール輸送エージェントが、ある文字通りのストリングを含んでいるデータを崩壊させるでしょう。 特に期間、(「」、)、aでは、単独で、いくつかの(不正確)のSMTP実現、および5つのキャラクタから始まる線によって線が崩壊されるのが知られている、「」、一般的に崩壊します(5番目のキャラクタはaスペースです)。
Borenstein & Freed [Page 64] RFC 1521 MIME September 1993
Borensteinと解放された[64ページ]RFC1521は1993年9月にまねます。
well. A careful composition agent can prevent these corruptions
by encoding the data (e.g., in the quoted-printable encoding,
"=46rom " in place of "From " at the start of a line, and "=2E" in
place of "." alone on a line.
さて。 に代わって線の始めにおいて「に代わって「慎重な構成エージェントがデータをコード化することによってこれらの贈収賄を防ぐことができる、(例えば、引用されて印刷可能なコード化、「=46rom」、」、「=2E」、」 . 」 線では、単独です。
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 implementations should be robust in dealing with the bad effects they can cause.
上記のリストはMTAsのための推奨案のリストではありません。 RFC821MTAsは余白のキャラクタを変更するか、または長い線を包装するのが禁止されています。 これらのBADと不法な習慣が既存のネットワークに起こるのが知られて、実現はそれらが引き起こす場合がある悪い効果に対処する際に体力を要するべきです。
Borenstein & Freed [Page 65] RFC 1521 MIME September 1993
Borensteinと解放された[65ページ]RFC1521は1993年9月にまねます。
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>
To: Ned Freed <ned@innosoft.com>
Subject: A multipart example
Content-Type: multipart/mixed;
boundary=unique-boundary-1
MIMEバージョン: 1.0 From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッド Freed <ned@innosoft.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
mu-law-format audio data goes here....
… 8000Hzのbase64によってコード化された単独のチャンネルμ法の形式オーディオデータはここに行きます…
Borenstein & Freed [Page 66] RFC 1521 MIME September 1993
Borensteinと解放された[66ページ]RFC1521は1993年9月にまねます。
--unique-boundary-2
Content-Type: image/gif
Content-Transfer-Encoding: base64
--ユニークな境界2コンテントタイプ: gif Content転送イメージ/コード化: base64
... 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>
<smaller>as defined in RFC 1341</smaller>
<nl><nl>Isn't it
<bigger><bigger>cool?</bigger></bigger>
これは<の大胆な><イタリック体の>richtextです。それではなく、よりRFC1341</小さい>のnl><nl><Isnで<の、より大きい><より大きい>を定義するとき、</イタリック体の></大胆な><より小さい>は、よりより</大きい></大きい>を冷やします。
--unique-boundary-1
Content-Type: message/rfc822
--ユニークな境界1コンテントタイプ: メッセージ/rfc822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
From: (米国-ASCIIにおけるメールボックス) To: (米国-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 67] RFC 1521 MIME September 1993
Borensteinと解放された[67ページ]RFC1521は1993年9月にまねます。
Appendix D -- Collected Grammar
付録D--集まっている文法
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定義を呼ぶどこ。
application-subtype := ("octet-stream" *stream-param)
/ "postscript" / extension-token
拡大アプリケーション-「副-タイプ」:=(「八重奏流れ」*流れparam)/「追伸」/象徴
application-type := "application" "/" application-subtype
」 「アプリケーションタイプ:=「アプリケーション」」/アプリケーション-「副-タイプ」
attribute := token ; case-insensitive
:=象徴を結果と考えてください。 大文字と小文字を区別しない
atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
/ "afs" / "mail-server" / extension-token
; Case-insensitive
atype:=は拡大/"tftp"/「ローカルファイル」/"afs"/「メールサーバ」/象徴を"ftpする"である、または「やがて、ftpします」。 大文字と小文字を区別しない
audio-type := "audio" "/" ("basic" / extension-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(それ自体かサブストリングとしたどこでも指定されたデリミタがすべてのヘッダーフィールドが任意であってメッセージ本体で何処にも起こらないで、オンの線)で>を定義するので、:=<「メッセージ」をボディーで分けてください。
NOTE: In certain transport enclaves, RFC 822 restrictions such as
the one that limits bodies to printable ASCII characters may not
be in force. (That is, the transport domains may resemble
standard Internet mail transport as specified in RFC821 and
assumed by RFC822, but without certain restrictions.) The
relaxation of these restrictions should be construed as locally
extending the definition of bodies, for example to include octets
outside of the ASCII range, as long as these extensions are
supported by the transport and adequately documented in the
Content-Transfer-Encoding header field. However, in no event are
headers (either message headers or body-part headers) allowed to
contain anything other than ASCII characters.
以下に注意してください。 ある輸送飛び地では、ボディーを印刷可能なASCII文字に制限するものなどのRFC822制限が有効でないかもしれません。 (すなわち、輸送ドメインはRFC821で指定されて、RFC822によって想定されますが、ある制限なしで標準のインターネット・メール輸送に類似するかもしれません。) これらの制限の緩和は例えばASCII範囲の外に八重奏を含むように局所的にボディーの定義を広げるのに理解されるべきです、これらの拡大が輸送で支持されて、適切にContent転送コード化ヘッダーフィールドに記録される限り。 しかしながら、ヘッダー(メッセージヘッダーか身体部分ヘッダーのどちらか)はASCII文字以外の何も決して、含むことができません。
Borenstein & Freed [Page 68] RFC 1521 MIME September 1993
Borensteinと解放された[68ページ]RFC1521は1993年9月にまねます。
boundary := 0*69<bchars> bcharsnospace
境界:=0*69<bchars>bcharsnospace
bchars := bcharsnospace / " "
bchars:=bcharsnospace/、「」
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
「bcharsnospace:=DIGIT/アルファー/、「'「」 /「」 (「/」)/「+」/"_"/」、/「-」/」。」' / "/" / ":" / "=" / "?"
charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3"
/ "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7"
/ "iso-8859-8" / "iso-8859-9" / extension-token
; case insensitive
ASCII..1インチ..2インチ..3インチ..4インチ..5インチ..6インチ..7インチ..8インチ..9インチ..拡大..象徴 大文字と小文字を区別しない
close-delimiter := "--" boundary "--" CRLF;Again,no space by "--",
近いデリミタ:=「--」境界「--」CRLF; 再び「--」によるスペースがありません。
content := "Content-Type" ":" type "/" subtype *(";" parameter)
; case-insensitive matching of type and subtype
「「コンテントタイプ」という内容:=」:、」 」 「タイプ」/「副-タイプ」*(「;」パラメタ)。 タイプと「副-タイプ」の大文字と小文字を区別しないマッチング
delimiter := "--" boundary CRLF ;taken from Content-Type field.
; There must be no space
; between "--" and boundary.
デリミタ:=「--」境界CRLF; コンテントタイプ分野から、取ります。 ; スペースが全くあるはずがありません。 「--」と境界の間で。
description := "Content-Description" ":" *text
「記述:=「満足している記述」」:、」 *テキスト
discard-text := *(*text CRLF)
テキストを捨てている:=*(*テキストCRLF)
encapsulation := delimiter body-part CRLF
カプセル化:=デリミタ身体パートCRLF
encoding := "Content-Transfer-Encoding" ":" mechanism
「:=「満足している転送コード化」をコード化します」:、」 メカニズム
epilogue := discard-text ; to be ignored upon receipt.
エピローグ:=、テキストを捨てる、。 領収書で無視されるために。
extension-token := x-token / iana-token
iana拡大象徴:=x-象徴/象徴
external-param := (";" "access-type" "=" atype)
/ (";" "expiration" "=" date-time)
外部のparam:=、(「」、;「アクセス型」がatype) /と「等しい」 (「」、;、「満了」「=」日付-時間)
; Note that date-time is quoted
/ (";" "size" "=" 1*DIGIT)
/ (";" "permission" "=" ("read" / "read-write"))
; Permission is case-insensitive
/ (";" "name" "=" value)
/ (";" "site" "=" value)
/ (";" "dir" "=" value)
/ (";" "mode" "=" value)
/ (";" "server" "=" value)
/ (";" "subject" "=" value)
;access-type required; others required based on access-type
; 日付-時間が引用されることに注意してください、/、(「」、;、「サイズ」が1*ケタ) /と「等しい」 (「; 」 「許可」「=」(「読む」か、または「読書して書きます」)。 許可..大文字と小文字を区別しない..名前..等しい..値..サイト..等しい..値..等しい..値..モード..等しい..値..サーバ..等しい..値..受けることがある..値..アクセス型..必要 他のものがアクセス型に基づいて必要です。
Borenstein & Freed [Page 69] RFC 1521 MIME September 1993
Borensteinと解放された[69ページ]RFC1521は1993年9月にまねます。
iana-token := <a publicly-defined extension token,
registered with IANA, as specified in
appendix E>
付録E>の指定されるとしてIANAに公的に定義された拡大象徴であって、登録されたiana-象徴:=<。
id := "Content-ID" ":" msg-id
「イド:=「コンテントID」」:、」 msg-イド
image-type := "image" "/" ("gif" / "jpeg" / extension-token)
「イメージタイプ:=は」 /に「像を描きます」」(拡大"gif"/"jpeg"/象徴)
mechanism := "7bit" ; case-insensitive
/ "quoted-printable"
/ "base64"
/ "8bit"
/ "binary"
/ x-token
「7は噛み付いた」メカニズム:=。 大文字と小文字を区別しない/「引用されて印刷可能な」/「x「8ビット」/base64"/「バイナリー」/象徴」
message-subtype := "rfc822"
/ "partial" 2#3partial-param
/ "external-body" 1*external-param
/ extension-token
メッセージ-「副-タイプ」:="rfc822"/「部分的な」2#3partial-param/「外部のボディー」の1つの*拡大外部のparam/象徴
message-type := "message" "/" message-subtype
」 「メッセージタイプ:=「メッセージ」」/メッセージ-「副-タイプ」
multipart-body :=preamble 1*encapsulation close-delimiter epilogue
複合ボディー: =序文1*カプセル化近いデリミタエピローグ
multipart-subtype := "mixed" / "parallel" / "digest"
/ "alternative" / extension-token
拡大複合「副-タイプ」:=「混ぜられた」か「平行な」/「ダイジェスト」/「代替手段」/象徴
multipart-type := "multipart" "/" multipart-subtype
";" "boundary" "=" boundary
「」 「複合複合タイプ:=」」 /複合「副-タイプ」」;、」 「境界」「=」境界
octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; octet must be used for characters > 127, =, SPACE, or
TAB,
; and is recommended for any characters not listed in
; Appendix B as "mail-safe".
八重奏:=「=」2(/「B」/ケタ/「C」/「D」/「E」/「F」)。 キャラクタの>127、=、SPACE、またはTABに八重奏を使用しなければなりません。 そして、記載されなかった少しのキャラクタのためにも、推薦されます。 「メール金庫」としての付録B。
padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
:=を水増しする、「0インチ/、「1インチ/、「2インチ/、「3インチ/、「4インチ/、「5インチ/、「6インチ/「7インチ」
parameter := attribute "=" value
パラメタ:=属性「=」価値
partial-param := (";" "id" "=" value)
/ (";" "number" "=" 1*DIGIT)
/ (";" "total" "=" 1*DIGIT)
; id & number required;total required for last part
部分的なparam:=、(「」、;、「イド」が値) /と「等しい」 (「」、;、「数」が1*ケタ) /と「等しい」 (「」、;、「総」「=」1*ケタ)、。 イドと注文数; 合計が最後の部分に必要です。
preamble := discard-text ; to be ignored upon receipt.
序文:=、テキストを捨てる、。 領収書で無視されるために。
ptext := octet / <any ASCII character except "=", SPACE, or TAB>
ptext:=八重奏/<は「=」、スペース、またはタブ>以外のあらゆるASCII文字です。
Borenstein & Freed [Page 70] RFC 1521 MIME September 1993
Borensteinと解放された[70ページ]RFC1521は1993年9月にまねます。
; characters not listed as "mail-safe" in Appendix B
; are also not recommended.
; キャラクタはAppendixで「メール安全な」Bとして記載しませんでした。 また、推薦されません。
quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
; Maximum line length of 76 characters excluding CRLF
引用されて印刷可能な:=([*(ptext/SPACE/TAB)ptext][「=」]CRLF)。 CRLFを除いた76のキャラクタの最大の行長
stream-param := (";" "type" "=" value)
/ (";" "padding" "=" padding)
流れ-param:=、(「」、;「タイプ」が値) /と「等しい」 (「」、;、「=」詰め物は「水増し」です)
subtype := token ; case-insensitive
「副-タイプ」:=象徴。 大文字と小文字を区別しない
text-subtype := "plain" / extension-token
拡大テキスト-「副-タイプ」:=「平野」/象徴
text-type := "text" "/" text-subtype [";" "charset" "=" charset]
」 「テキストタイプ:=「テキスト」」/テキスト-「副-タイプ」[「」、;、"charset"「=」charset]
token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
象徴:=1*<はSPACE、CTLs、またはtspecials>以外のあらゆる(ASCII)CHARです。
tspecials := "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
「」 tspecials:=「(「/」)」/「<」 /">"/"@"/」、/」;、」 / ":" 「/「\」/<「>/」/」/「[「/」]」/“?" / "=" ; 引用文字列にあるに違いありません。 パラメタ値の中の使用に
type := "application" / "audio" ; case-insensitive
/ "image" / "message"
/ "multipart" / "text"
/ "video" / extension-token
; All values case-insensitive
:=「アプリケーション」/「オーディオ」をタイプしてください。 拡大大文字と小文字を区別しない/「イメージ」/「メッセージ」/「複合」/「テキスト」/「ビデオ」/象徴。 すべてが評価する、大文字と小文字を区別しなさ
value := token / quoted-string
値の:=象徴/引用文字列
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
「「MIMEバージョン」というバージョン:=」:、」 「1*ケタ」、」 1*ケタ
video-type := "video" "/" ("mpeg" / extension-token)
「ビデオタイプ:=「ビデオ」」/、」(拡大"mpeg"/象徴)
x-token := <The two characters "X-" or "x-" followed, with no
intervening white space, by any token>
2つのキャラクタ「X」か「x」がどんな象徴>も介入している余白なしで続けたx-象徴:=<。
Borenstein & Freed [Page 71] RFC 1521 MIME September 1993
Borensteinと解放された[71ページ]RFC1521は1993年9月にまねます。
Appendix E -- IANA Registration Procedures
付録E--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, 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.
一般に、満足しているタイプヘッダーフィールドにおけるパラメタは様々な満足しているタイプのために補足的情報を伝えるのに使用されます、そして、満足しているタイプと「副-タイプ」が定義されるとき、彼らの使用は定義されます。 新しい機能性を紹介する方法と新しいパラメタを定義するべきではありません。
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との新しい値の登録のためのテンプレートを与えます。 登録パーティーによって記入されるように、メールメッセージテンプレートの形でそれぞれのこれらを与えます。
E.1 Registration of New Content-type/subtype Values
新しい文書内容/「副-タイプ」値のE.1登録
Note that MIME is generally expected to be extended by subtypes. If a new fundamental top-level type is needed, its specification must 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:
問題をコード化します:
Borenstein & Freed [Page 72] RFC 1521 MIME September 1993
Borensteinと解放された[72ページ]RFC1521は1993年9月にまねます。
Security considerations:
セキュリティ問題:
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:
詳細のために連絡する人とEメールアドレス:
E.2 Registration of New Access-type Values
for Message/external-body
外部のメッセージ/ボディーのための新しいアクセス型値のE.2登録
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メールアドレス:
Borenstein & Freed [Page 73] RFC 1521 MIME September 1993
Borensteinと解放された[73ページ]RFC1521は1993年9月にまねます。
Appendix F -- Summary of the Seven Content-types
付録F--7つの文書内容の概要
Content-type: text
文書内容: テキスト
Subtypes defined by this document: plain
血液型亜型はこのドキュメントで定義しました: 平野
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, access-type, expiration,
size, permission, name, site, directory, mode, server, subject
重要なパラメタ: イド、数、合計、満了、サイズ、許可が、サイト、ディレクトリ、モード、サーバがかけると命名するアクセス型
Encoding notes: No content-transfer-encoding is permitted.
Specifically, only "7bit" is permitted for "message/partial" or
"message/external-body", and only "7bit", "8bit", or "binary" are
permitted for other subtypes of "message".
______________________________________________________________
Content-type: application
コード化は以下に注意します。 満足している転送コード化は受入れられません。 「メッセージ/部分的である」か「外部のメッセージ/ボディー」であることで「7ビット」だけ受入れられます、そして、「7ビット」、「8ビット」、または「バイナリー」だけ、が「メッセージ」の他の血液型亜型のために受入れられます。 ______________________________________________________________ 文書内容: アプリケーション
Subtypes defined by this document: octet-stream, postscript
血液型亜型はこのドキュメントで定義しました: 八重奏ストリーム、追伸
Important Parameters: type, padding
重要なパラメタ: そっと歩いて、タイプしてください。
Borenstein & Freed [Page 74] RFC 1521 MIME September 1993
Borensteinと解放された[74ページ]RFC1521は1993年9月にまねます。
Deprecated Parameters: name and conversions were
defined in RFC 1341.
推奨しないパラメタ: 名前と変換はRFC1341で定義されました。
Encoding notes: base64 preferred for 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. 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. ________________________________________________________________ Content-type: image
セキュリティ問題: データの伝達は局所的にインストールされたプログラムでこのタイプは解釈されるつもりでした。例えば、伝わるのに使用されるなら、一般に、実行可能な2進のプログラムかプログラムがインタープリタ型言語を目標とします、LISPプログラムやシェルスクリプトのように厳しい警備上の問題は結果として生じることができました。 メールを閲読するエージェントの作者は、セキュリティが含意であると慎重に考えないメールベースのアプリケーションデータを実行する権限を彼らのシステムに与えないように警告されます。 確かに、危険な形式のために安全な依頼書と安全なインタプリタさえ定義するのが可能である間、各インタプリタは可能な警備上の問題によって別々に評価されるべきです。________________________________________________________________ 文書内容: イメージ
Subtypes defined by this document: jpeg, gif
血液型亜型はこのドキュメントで定義しました: jpeg、gif
Important Parameters: none
重要なパラメタ: なし
Encoding notes: base64 generally preferred ________________________________________________________________ Content-type: audio
コード化は以下に注意します。 一般に、好まれたbase64________________________________________________________________ 文書内容: オーディオ
Subtypes defined by this document: basic
血液型亜型はこのドキュメントで定義しました: 基本的
Important Parameters: none
重要なパラメタ: なし
Encoding notes: base64 generally preferred ________________________________________________________________ Content-type: video
コード化は以下に注意します。 一般に、好まれたbase64________________________________________________________________ 文書内容: ビデオ
Subtypes defined by this document: mpeg
血液型亜型はこのドキュメントで定義しました: mpeg
Important Parameters: none
重要なパラメタ: なし
Encoding notes: base64 generally preferred
コード化は以下に注意します。 一般に、好まれたbase64
Borenstein & Freed [Page 75] RFC 1521 MIME September 1993
Borensteinと解放された[75ページ]RFC1521は1993年9月にまねます。
Appendix G -- Canonical Encoding Model
付録G--正準なコード化はモデル化されます。
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 entity can be modeled as being done in a number of steps. Note that these steps are roughly similar to those steps used in RFC 1421 and are performed for each 'innermost level' body:
多くのステップでするとしてMIME実体を構成するプロセスをモデル化できます。 これらのステップがおよそRFC1421で使用されるそれらのステップと同様であり、各'最も奥深いレベル'ボディーのために実行されることに注意してください:
Step 1. Creation of local form.
1を踏んでください。 地方のフォームの作成。
The body 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 body 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. Fundamentally, the data is created in the "native" form specified by the type/subtype information.
伝えられるべきボディーはシステムのネイティブの形式で作成されます。 ネイティブの文字集合はまた、適切な地方の行末コンベンションが使用されるところで使用されます。 ボディーは、UNIX-スタイルテキストファイルか、Sunラスター・イメージであるかもしれませんVMSがファイルに索引をつけたか、またはシステム依存する形式のオーディオデータが何らかのフォームの情報の表現のためのローカルのモデルに文通されるメモリ、または他の何かだけを蓄えました。 基本的に、データはタイプ/「副-タイプ」情報によって指定された「ネイティブ」のフォームで作成されます。
Step 2. Conversion to canonical form.
2を踏んでください。 標準形への変換。
The entire body, 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 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. If character set conversion is involved, however, care must be taken to understand the semantics of the content-type, which may have strong implications for any character set conversion, e.g. with regard to syntactically meaningful characters in a text subtype other than "plain".
「バンドの外に」レコード長やことによるとファイル属性情報の情報を含む全身は普遍的な標準形に変換されます。 関連属性と同様にボディーの特定のcontent typeは使用された標準形の本質を決めます。 適切な標準形への変換は文字集合変換、オーディオデータ、圧縮、または様々なcontent typeに特定の他の様々な操作の変換にかかわるかもしれません。 しかしながら、文字集合変換がかかわるなら、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によって含意された行長における制限が排除されることに注意してください。
Borenstein & Freed [Page 76] RFC 1521 MIME September 1993
Borensteinと解放された[76ページ]RFC1521は1993年9月にまねます。
Step 3. Apply transfer encoding.
3を踏んでください。 転送コード化を適用してください。
A Content-Transfer-Encoding appropriate for this body 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 a body.
これに、適切なContent転送コード化ボディーは適用されています。 content typeと転送コード化との固定関係が全くないことに注意してください。 base64かボディーの与えられたインスタンスに特定のキャラクタで印刷可能な頻度数の選択を基礎づけるのは特に、適切であるかもしれません。
Step 4. Insertion into entity.
4を踏んでください。 実体への挿入。
The encoded object is inserted into a MIME entity with appropriate headers. The entity is then inserted into the body of a higher-level entity (message or multipart) if needed.
コード化されたオブジェクトは適切なヘッダーと共に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 bodies might be carried through to the
encoder itself along with knowledge of what that format is.
1. 多くの場合、コード化の前の標準形への変換はエンコーダ自体に包括されるでしょう。(それは、直接地方の形式を理解しています)。 例えば、テキスト本文のための地方のニューラインコンベンションはその形式が何であるかに関する知識に伴うエンコーダ自体に突き抜けた状態で運ばれるかもしれません。
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 conformant 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によって指定されているconformantでないかもしれません。 もう一度、コンバータの出力が急送されるのは、標準のRFC822 CRLFデリミタを使用するよりむしろ地方のニューラインコンベンションを使用するのにおいて特に、適切であるかもしれません。
Other implementation variations are conceivable as well. The vital aspect of this discussion is that, in spite of any optimizations, collapsings of required steps, or insertion of additional processing, the resulting messages must be consistent with those produced by the model described here. For example, a message with the following header fields:
また、他の実装変化は想像できます。 この議論の重大な局面は必要なステップ、または追加処理の挿入のcollapsings、どんな最適化にもかかわらずも、結果として起こるメッセージがここで説明されたモデルによって生産されるそれらと一致しているに違いないということです。 例えば、以下のヘッダーがあるメッセージは以下をさばきます。
Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64
文書内容: テキスト/foo。 charsetはバーContent転送コード化と等しいです: base64
must be first represented in the text/foo form, then (if necessary) represented in the "bar" character set, and finally transformed via the base64 algorithm into a mail-safe form.
「バー」文字集合で最初に、テキスト/fooフォームに表されて、次に、(必要なら、)表さなければならなくて、メール安全なフォームへのbase64アルゴリズムで変えられて、最終的に表してください。
Borenstein & Freed [Page 77] RFC 1521 MIME September 1993
Borensteinと解放された[77ページ]RFC1521は1993年9月にまねます。
Appendix H -- Changes from RFC 1341
付録H--RFC1341からの変化
This document is a relatively minor revision of RFC 1341. For the convenience of those familiar with RFC 1341, the technical changes from that document are summarized in this appendix.
このドキュメントはRFC1341の比較的小さい方の改正です。 RFC1341になじみ深いそれらの都合のために、そのドキュメントからの技術変化はこの付録にまとめられます。
1. The definition of "tspecials" has been changed to no longer include ".".
1. 「"tspecials"の定義はもうインクルードに変わった」、」
2. The Content-ID field is now mandatory for message/external-body parts.
2. コンテントID分野は現在、外部のメッセージ/身体の部分に義務的です。
3. The text/richtext type (including the old Section 7.1.3 and Appendix D) has been moved to a separate document.
3. テキスト/richtextタイプ(古いセクション7.1.3とAppendix Dを含んでいる)は別々のドキュメントに動かされました。
4. The rules on header merging for message/partial data have been changed to treat the Encrypted and MIME-Version headers as special cases.
4. 特別なケースとしてEncryptedとMIMEバージョンヘッダーを扱うためにメッセージ/部分的なデータのためのヘッダー合併での規則を変えました。
5. The definition of the external-body access-type parameter has been changed so that it can only indicate a single access method (which was all that made sense).
5. シングルアクセスメソッドを示すことができるだけである(どれがそのすべてであったかが理解できた)ように、外部のボディーアクセス型パラメタの定義を変えました。
6. There is a new "Subject" parameter for message/external-body, access-type mail-server, to permit MIME-based use of mail servers that rely on Subject field information.
6. Subject分野情報を当てにするメールサーバのMIMEベースの使用を可能にするために、外部のメッセージ/ボディーのための新しい「受けることがある」パラメタ、アクセス型メールサーバがあります。
7. The "conversions" parameter for application/octet-stream has been removed.
7. 八重奏アプリケーション/ストリームのための「変換」パラメタを取り除いてあります。
8. Section 7.4.1 now deprecates the use of the "name" parameter for application/octet-stream, as this will be superseded in the future by a Content-Disposition header.
8. セクション7.4 .1 これが将来Content-気質ヘッダーによって取って代わられるとき、現在、パラメタという「名前」の八重奏アプリケーション/ストリームの使用を非難します。
9. The formal grammar for multipart bodies has been changed so that a CRLF is no longer required before the first boundary line.
9. 複合ボディーのための形式文法を変えたので、CRLFはもう最初の境界の前で必要ではありません。
10. MIME entities of type "message/partial" and "message/external- body" are now required to use only the "7bit" transfer-encoding. (Specifically, "binary" and "8bit" are not permitted.)
10. タイプのMIME実体、「」 部分的なメッセージ/「メッセージ/外部のボディー」は「7ビット」の転送コード化だけを使用するのに必要である現在です。 (明確に、「バイナリー」と「8ビット」は受入れられません。)
11. The "application/oda" content-type has been removed.
11. 「アプリケーション/oda」content typeを取り除きました。
12. A note has been added to the end of section 7.2.3, explaining the semantics of Content-ID in a multipart/alternative MIME entity.
12. 注意はセクション7.2.3の終わりに加えられます、複合の、または、代替のMIME実体におけるコンテントIDの意味論について説明して。
13. The formal syntax for the "MIME-Version" field has been tightened, but in a way that is completely compatible with the only
13. 「MIMEバージョン」分野への正式な構文はきびしくされましたが、ある意味で、それは唯一と完全に互換性があります。
Borenstein & Freed [Page 78] RFC 1521 MIME September 1993
Borensteinと解放された[78ページ]RFC1521は1993年9月にまねます。
version number defined in RFC 1341.
RFC1341で定義されたバージョン番号。
14. In Section 7.3.1, the definition of message/rfc822 has been relaxed regarding mandatory fields.
14. セクション7.3.1では、メッセージ/rfc822の定義は義務的な分野に関してリラックスしました。
All other changes from RFC 1341 were editorial changes and do not affect the technical content of MIME. Considerable formal grammar has been added, but this reflects the prose specification that was already in place.
RFC1341からの他のすべての変化は、編集の変化であり、MIMEの技術的な内容に影響しません。 かなりの形式文法が加えられますが、これは既に適所にあった散文仕様を反映します。
Borenstein & Freed [Page 79] RFC 1521 MIME September 1993
Borensteinと解放された[79ページ]RFC1521は1993年9月にまねます。
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月。
[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。
[POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Edition, 1990.
[POSTSCRIPT2]アドビ・システムズInc.、ポストスクリプト言語リファレンスマニュアル、アディソン-ウエスリー、第2版、1990。
[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., "TFTP Protocol (revision 2)", RFC 783, MIT, June 1981.
[RFC-783] Sollins、K.、「TFTPプロトコル(改正2)」、RFC783、MIT、1981年6月。
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.
[RFC-821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
Borenstein & Freed [Page 80] RFC 1521 MIME September 1993
Borensteinと解放された[80ページ]RFC1521は1993年9月にまねます。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, Delaware and NMA, January 1985.
[RFC-934] RFC934、ローズ、M.とE.Stefferud、「メッセージカプセル化の提案された標準」デラウェアとNMA、1985年1月。
[RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
[RFC-959] 科学が1985年10月に任命するポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、USC/情報。
[RFC-1049] Sirbu, M., "Content-Type Header Field for Internet Messages", STD 11, RFC 1049, CMU, March 1988.
[RFC-1049] シルブ、M.、「インターネットメッセージのためのコンテントタイプヘッダーフィールド」、STD11、RFC1049、米カーネギーメロン大学、1988年3月。
[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I - Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1421]リン、J.、「インターネット電子メールのためのプライバシー増進:」 「Iを分けてください--暗号化と認証手順を通信させてください」、RFC1421、IAB IRTF PSRG、IETF PEM WG、1993年2月。
[RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1154, Prime Computer, Inc., April 1990.
[RFC-1154] ロビンソンとD.とR.ウルマン、「インターネットメッセージのためのヘッダーフィールドをコード化します」、RFC1154、プライムコンピュータInc.、1990年4月。
[RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.
[RFC-1341]Borenstein(N.、および解放されたN.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、Innosoft、1992年6月。
[RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC 1342, University of Tennessee, June 1992.
[RFC-1342] ムーア、K.、「インターネットメッセージヘッダーの非アスキーテキストの表現」、RFC1342、テネシー大学、1992年6月。
[RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information", RFC 1343, Bellcore, June 1992.
[RFC-1343] Borenstein、N.、「マルチメディアメール書式情報のためのユーザエージェント構成メカニズム」、RFC1343、Bellcore、1992年6月。
[RFC-1344] Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC 1344, Bellcore, June 1992.
[RFC-1344] Borenstein、N.、「インターネットメール・ゲートウェイへのMIMEの含意」、RFC1344、Bellcore、1992年6月。
[RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets", RFC 1345, Rationel Almen Planlaegning, June 1992.
[RFC-1345] シモンセン、K.、「キャラクターニーモニックと文字コード」、RFC1345、Rationel Almen Planlaegning、1992年6月。
[RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993.
[RFC-1426] 「8ビットのMIME輸送のためのSMTP Service Extension」、RFC1426、国連Universit、Innosoft、ドーヴァービーチConsulting Inc.、Network Management Associates Inc.、(WG議長)、Klensin、J.、フリード、N.、(エディタ)、ローズ、M.、Stefferud、E.、およびD.クロッカー支店オフィス(1993年2月)。
[RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet Message Headers" RFC 1522, University of Tennessee, September 1993.
[RFC-1522] ムーア、K.、「インターネットメッセージヘッダーの非アスキーテキストの表現」RFC1522、テネシー大学、1993年9月。
[RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.
[RFC-1340] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
Borenstein & Freed [Page 81]
Borensteinであって解放されています。[81ページ]
一覧
スポンサーリンク
