RFC2046 日本語訳
2046 Multipurpose Internet Mail Extensions (MIME) Part Two: MediaTypes. N. Freed, N. Borenstein. November 1996. (Format: TXT=105854 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646, RFC3798, RFC5147) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Freed
Request for Comments: 2046 Innosoft
Obsoletes: 1521, 1522, 1590 N. Borenstein
Category: Standards Track First Virtual
November 1996
ネットワークワーキンググループN.はコメントを求める要求を解放しました: 2046Innosoftは以下を時代遅れにします。 1521、1522、1590N.Borensteinカテゴリ: 標準化過程ファースト・バーチャル1996年11月
Multipurpose Internet Mail Extensions
(MIME) Part Two:
Media Types
マルチパーパスインターネットメールエクステンション(MIME)パートTwo: メディアタイプ
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for
STD11、RFC822はメッセージ内容、またはメッセージ本体を残す米国-ASCIIメッセージヘッダーに関するかなりの詳細を指定するメッセージ表現プロトコルを定義します、平坦な米国-ASCIIテキストとして。 このセットのまとめてマルチパーパスインターネットメールエクステンションと呼ばれるドキュメント、またはMIMEが考慮するメッセージの書式を再定義します。
(1) textual message bodies in character sets other than
US-ASCII,
(1) 米国-ASCIIを除いた文字集合における原文のメッセージ本体
(2) an extensible set of different formats for non-textual
message bodies,
(2) 非原文のメッセージ本体のための広げることができる異なった形式
(3) multi-part message bodies, and
そして(3) 複合メッセージ本体。
(4) textual header information in character sets other than
US-ASCII.
(4) 米国-ASCIIを除いて、原文のヘッダー情報はぴったりしたセットします。
These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
これらのドキュメントは、それらをRFC934、STD11、およびRFC1049に記録された以前の仕事に基づいていますが、広げていて、改訂します。 RFC822が、メッセージ本体に関してこれらのドキュメントが主にそうであると直交していた状態でそれほど少ししか言わなかった、(改正よりむしろ、)、RFC822
The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text
このセットにおける初期のドキュメント(RFC2045)はMIMEメッセージの構造について説明するのに使用される様々なヘッダーを指定します。 この2番目のドキュメントは、MIMEメディアタイピングシステムの一般構造体を定義して、1人の始発のメディアタイプを定義します。 3番目のドキュメント(RFC2047)は、非米国のASCIIテキストを許容するためにRFC822に拡大について説明します。
Freed & Borenstein Standards Track [Page 1] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[1ページ]。
data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
インターネットのデータはヘッダーフィールドを郵送します。 4番目のドキュメント(RFC2048)は様々なIANA登録手順をMIME関連の施設に指定します。 5番目と最終合意文書(RFC2049)は、また、MIME順応評価基準がMIMEメッセージ・フォーマット、承認、および図書目録に関するいくつかの説明に役立つ実例を提供すると記述します。
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.
これらのドキュメントはRFCs1521と1522年の改正です。(その改正は自分たちでRFCs1341と1342年の改正でした)。 RFC2049の付録は旧バージョンからの違いと変化について説明します。
Table of Contents
目次
1. Introduction ......................................... 3 2. Definition of a Top-Level Media Type ................. 4 3. Overview Of The Initial Top-Level Media Types ........ 4 4. Discrete Media Type Values ........................... 6 4.1 Text Media Type ..................................... 6 4.1.1 Representation of Line Breaks ..................... 7 4.1.2 Charset Parameter ................................. 7 4.1.3 Plain Subtype ..................................... 11 4.1.4 Unrecognized Subtypes ............................. 11 4.2 Image Media Type .................................... 11 4.3 Audio Media Type .................................... 11 4.4 Video Media Type .................................... 12 4.5 Application Media Type .............................. 12 4.5.1 Octet-Stream Subtype .............................. 13 4.5.2 PostScript Subtype ................................ 14 4.5.3 Other Application Subtypes ........................ 17 5. Composite Media Type Values .......................... 17 5.1 Multipart Media Type ................................ 17 5.1.1 Common Syntax ..................................... 19 5.1.2 Handling Nested Messages and Multiparts ........... 24 5.1.3 Mixed Subtype ..................................... 24 5.1.4 Alternative Subtype ............................... 24 5.1.5 Digest Subtype .................................... 26 5.1.6 Parallel Subtype .................................. 27 5.1.7 Other Multipart Subtypes .......................... 28 5.2 Message Media Type .................................. 28 5.2.1 RFC822 Subtype .................................... 28 5.2.2 Partial Subtype ................................... 29 5.2.2.1 Message Fragmentation and Reassembly ............ 30 5.2.2.2 Fragmentation and Reassembly Example ............ 31 5.2.3 External-Body Subtype ............................. 33 5.2.4 Other Message Subtypes ............................ 40 6. Experimental Media Type Values ....................... 40 7. Summary .............................................. 41 8. Security Considerations .............................. 41 9. Authors' Addresses ................................... 42
1. 序論… 3 2. トップレベルメディアタイプの定義… 4 3. 初期のトップレベルメディアタイプの概要… 4 4. 離散的なメディアは値をタイプします… 6 4.1 テキストメディアタイプ… 6 4.1 .1 ラインブレイクの表現… 7 4.1 .2Charsetパラメタ… 7 4.1 .3 明瞭なSubtype… 11 4.1 .4の認識されていない血液型亜型… 11 4.2 イメージメディアタイプ… 11 4.3 オーディオメディアタイプ… 11 4.4 ビデオメディアタイプ… 12 4.5 アプリケーションメディアタイプ… 12 4.5 .1 八重奏ストリームSubtype… 13 4.5 .2 ポストスクリプトSubtype… 14 4.5 .3 他のアプリケーション血液型亜型… 17 5. 合成メディアは値をタイプします… 17 5.1 複合メディアタイプ… 17 5.1 .1の一般的な構文… 19 5.1 .2 取り扱いはメッセージとMultipartsを入れ子にしました… 24 5.1 .3 Mixed Subtype… 24 5.1 .4 代替のSubtype… 24 5.1 .5 Subtypeを読みこなしてください… 26 5.1 .6 Subtypeに沿ってください… 27 5.1 他の.7の複合血液型亜型… 28 5.2 メッセージメディアタイプ… 28 5.2 .1RFC822 Subtype… 28 5.2 .2 部分的なSubtype… 29 5.2 .2 .1のメッセージ断片化とReassembly… 30 5.2 .2 .2の断片化とReassemblyの例… 31 5.2 .3 外部のボディーSubtype… 33 5.2 .4 他のメッセージ血液型亜型… 40 6. 実験メディアは値をタイプします… 40 7. 概要… 41 8. セキュリティ問題… 41 9. 作者のアドレス… 42
Freed & Borenstein Standards Track [Page 2] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[2ページ]。
A. Collected Grammar .................................... 43
A. 文法を集めます… 43
1. Introduction
1. 序論
The first document in this set, RFC 2045, defines a number of header fields, including Content-Type. The Content-Type field is used to specify the nature of the data in the body of a MIME entity, by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media 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 ordering of parameters is not significant.
このセットにおける最初のドキュメント(RFC2045)はコンテントタイプを含む多くのヘッダーフィールドを定義します。 コンテントタイプ分野は、MIME実体のボディーでデータの本質を指定するのにタイプと「副-タイプ」識別子をメディアに与えて、あるメディアに必要であるかもしれない補助の情報にタイプを提供することによって、使用されます。 タイプと「副-タイプ」名の後に、ヘッダーフィールドの残りは単に属性/値の記法で指定された1セットのパラメタです。 パラメタの注文は重要ではありません。
In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of "text", but not for unrecognized subtypes of "image" or "audio". For this reason, registered subtypes of "text", "image", "audio", and "video" should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types.
一般に、トップレベルメディアタイプはデータの一般型を宣言するのに使用されます、「副-タイプ」がそのタイプに関するデータのための特定の形式を指定しますが。 したがって、「イメージ/xyz」のメディアタイプはデータがイメージであるとユーザエージェントに言うために十分です、ユーザエージェントに特定の画像形式"xyz"に関する知識が全くなくても。 例えば、認識されていない「副-タイプ」から生データをユーザに示すかどうか決めるのにそのような情報を使用できます--そのような動作は、「テキスト」の認識されていない血液型亜型に妥当ですが、「イメージ」か「オーディオ」の認識されていない血液型亜型のために妥当でないかもしれません。 この理由で、「テキスト」、「イメージ」、「オーディオ」、および「ビデオ」の登録された血液型亜型は本当な異なったタイプにはある埋め込まれた情報を含むべきではありません。 そのような合成書式は、「複合」か「アプリケーション」タイプを使用することで表されるべきです。
Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize.
パラメタは、メディア「副-タイプ」の修飾語であり、そういうものとして基本的に内容の本質に影響しません。 重要なパラメタのセットはメディアのタイプと「副-タイプ」に頼っています。 ほとんどのパラメタが単一の特定の「副-タイプ」に関連しています。 しかしながら、与えられたトップレベルメディアタイプはそのタイプのどんな「副-タイプ」にも適切なパラメタを定義するかもしれません。 メディアタイプか「副-タイプ」を定義することによって、パラメタが必要であるかもしれません、またはそれらは任意であるかもしれません。 また、MIME実装は彼らが名前を認識しないどんなパラメタも無視しなければなりません。
MIME's Content-Type header field and media type mechanism has been carefully designed to be extensible, and it is expected that the set of media type/subtype pairs and their associated parameters will grow significantly over time. Several other MIME facilities, such as transfer encodings and "message/external-body" access types, 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 sets up a registration process which uses the Internet Assigned Numbers Authority (IANA) as a central registry for MIME's various areas of extensibility. The registration process for these areas is described in a companion document, RFC 2048.
広げることができるように設計されていて、タイプメカニズムが持っているMIMEのコンテントタイプヘッダーフィールドとメディアは慎重にそうです、そして、メディアタイプ/「副-タイプ」組と彼らの関連パラメタのセットが時間がたつにつれてかなり成長すると予想されます。 転送encodingsや「外部のメッセージ/ボディー」アクセス型などの他のいくつかのMIME施設が時間がたつにつれて定義された新しい値を持っていそうです。 そのような値のセットが規則的で、よく指定されて、公共の方法で発展するのを確実にするために、MIMEはMIMEの伸展性の様々な領域に、中央の登録としてインターネットAssigned民数記Authority(IANA)を使用する登録手続をセットアップします。 登録手続は仲間ドキュメント、RFC2048にこれらの領域に説明されます。
Freed & Borenstein Standards Track [Page 3] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[3ページ]。
The initial seven standard top-level media type are defined and described in the remainder of this document.
初期の7標準のトップレベルメディアタイプは、このドキュメントの残りで定義されて、説明されます。
2. Definition of a Top-Level Media Type
2. トップレベルメディアタイプの定義
The definition of a top-level media type consists of:
トップレベルメディアタイプの定義は以下から成ります。
(1) a name and a description of the type, including
criteria for whether a particular type would qualify
under that type,
(1) 特定のタイプがそのタイプの下で資格を得るだろうかどうか評価基準を含むタイプの名前と記述
(2) the names and definitions of parameters, if any, which
are defined for all subtypes of that type (including
whether such parameters are required or optional),
(2) もしあればそのタイプ(そのようなパラメタが必要であるか、または任意であるかを含んでいる)のすべての血液型亜型のために定義されるパラメタの名前と定義
(3) how a user agent and/or gateway should handle unknown
subtypes of this type,
(3) ユーザエージェント、そして/または、ゲートウェイはどうこのタイプの未知の血液型亜型を扱うはずであるか。
(4) general considerations on gatewaying entities of this
top-level type, if any, and
そしてこのトップレベルの実体をgatewayingするときの(4)の一般的な問題がもしあればタイプする。
(5) any restrictions on content-transfer-encodings for
entities of this top-level type.
(5) このトップレベルタイプの実体のための満足している転送encodingsにおけるどんな制限。
3. Overview Of The Initial Top-Level Media Types
3. 初期のトップレベルメディアタイプの概要
The five discrete top-level media types are:
5つの離散的なトップレベルメディアタイプは以下の通りです。
(1) text -- textual information. The subtype "plain" in
particular indicates plain text containing no
formatting commands or directives of any sort. Plain
text is intended to be displayed "as-is". No special
software is required to get the full meaning of the
text, aside from support for the indicated character
set. Other 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 of "text" thus include any
word processor format that can be read without
resorting to software that understands the format. In
particular, formats that employ embeddded binary
formatting information are not considered directly
readable. A very simple and portable subtype,
"richtext", was defined in RFC 1341, with a further
revision in RFC 1896 under the name "enriched".
(1)テキスト--文字情報。 「副-タイプ」「平野」はどんな種類の書式付けコマンドか指示も全く含まないプレーンテキストを特に示します。 プレーンテキストによって「そのままで」表示されることを意図します。 どんな特別なソフトウェアもテキストの完全な意味を得るのに必要ではありません、示された文字集合のサポートは別として。 他の血液型亜型がフォームのアプリケーション・ソフトがテキストの外観を高めるかもしれない豊かにされたテキストに使用されることですが、内容の概念を得るためにそのようなソフトウェアを必要としてはいけません。 その結果、「テキスト」の可能な血液型亜型は形式を理解しているソフトウェアに頼らないで読むことができるどんなワードプロセッサ書式も含んでいます。 特に、embeddded2進の形式情報を使う形式は直接読み込み可能であると考えられません。 非常に簡単で携帯用の「副-タイプ」"richtext"はRFC1341で定義されました、さらなる改正が「豊かにする」という名前の下におけるRFC1896にある状態で。
Freed & Borenstein Standards Track [Page 4] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[4ページ]。
(2) image -- image data. "Image" requires a display device
(such as a graphical display, a graphics printer, or a
FAX machine) to view the information. An initial
subtype is defined for the widely-used image format
JPEG. . subtypes are defined for two widely-used image
formats, jpeg and gif.
(2)イメージ--イメージデータ。 「イメージ」は、情報を見るために、ディスプレイ装置(グラフィカルなディスプレイ、グラフィックスプリンタ、またはFAXマシンなどの)を必要とします。 初期の「副-タイプ」は広く使用された画像形式JPEGのために定義されます。 . 血液型亜型は2つの広く使用された画像形式、jpeg、およびgifのために定義されます。
(3) audio -- audio data. "Audio" requires an audio output
device (such as a speaker or a telephone) to "display"
the contents. An initial subtype "basic" is defined in
this document.
(3)オーディオ--オーディオデータ。 「オーディオ」は、コンテンツを「表示する」ために、オーディオ出力装置(スピーカーか電話などの)を必要とします。 初期の「副-タイプ」「基本的」は本書では定義されます。
(4) video -- video data. "Video" requires the capability
to display moving images, typically including
specialized hardware and software. An initial subtype
"mpeg" is defined in this document.
(4) ビデオ--ビデオ・データ。 「ビデオ」は専門化しているハードウェアとソフトウェアを通常含む動画を表示する能力を必要とします。 初期の「副-タイプ」"mpeg"は本書では定義されます。
(5) application -- some other kind of data, typically
either uninterpreted binary data or information to be
processed by an application. The 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. The "PostScript" subtype is also defined
for the transport of PostScript material. Other
expected uses for "application" include spreadsheets,
data for mail-based scheduling systems, and languages
for "active" (computational) messaging, and word
processing formats that are not directly readable.
Note that security considerations may exist for some
types of application data, most notably
"application/PostScript" and any form of active
messaging. These issues are discussed later in this
document.
(5)アプリケーション--ある他の種類に関するデータ、通常、どちらかが、アプリケーションで処理されるためにバイナリ・データか情報を非解釈しました。 その場合、最も簡単なお勧めの動きは「八重奏ストリーム」がある「副-タイプ」が非解釈されたバイナリ・データの場合に使用されて、ユーザのためにファイルの中に情報を書くと申し出ることです。 また、「ポストスクリプト」「副-タイプ」はポストスクリプトの材料の輸送のために定義されます。 「アプリケーション」への他の予想された用途は直接読み込み可能でないスプレッドシート、メールベースのスケジューリングシステムのためのデータ、および「アクティブな」(コンピュータの)メッセージング、および文書処理形式のための言語を含んでいます。 セキュリティ問題が何人かのタイプに関するアプリケーションデータ(著しくほとんどの「アプリケーション/ポストスクリプト」とどんなフォームのアクティブなメッセージングも)のために存在するかもしれないことに注意してください。 後で本書ではこれらの問題について議論します。
The two composite top-level media types are:
2つの合成トップレベルメディアタイプは以下の通りです。
(1) multipart -- data consisting of multiple entities of
independent data types. Four subtypes are initially
defined, including the basic "mixed" subtype specifying
a generic mixed set of parts, "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 has a default type of "message/rfc822".
(1)複合、--独立しているデータ型の複数の実体から成るデータ。 4血液型亜型は初めは定義されます、部品のジェネリック混合セットを指定する基本的な「混ぜられた」「副-タイプ」を含んでいて、複数の形式における同じデータを表すのにおいて「代替です」、各部分には「メッセージ/rfc822」のデフォルトタイプがある複合実体のために同時に見られて、「読みこなすこと」を意図する部品に「平行です」。
Freed & Borenstein Standards Track [Page 5] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[5ページ]。
(2) message -- an encapsulated message. A body of media
type "message" is itself all or a portion of some kind
of message object. Such objects may or may not in turn
contain other entities. The "rfc822" subtype is used
when the encapsulated content is itself an RFC 822
message. The "partial" subtype is defined for partial
RFC 822 messages, to permit the fragmented transmission
of bodies that are thought to be too large to be passed
through transport facilities in one piece. Another
subtype, "external-body", is defined for specifying
large bodies by reference to an external data source.
(2)メッセージ--カプセル化されたメッセージ。 メディアタイプ「メッセージ」のボディーは、それ自体である種のメッセージオブジェクトのすべてか一部です。 そのようなオブジェクトは順番に他の実体を含むかもしれません。 カプセル化された内容がそれ自体でRFC822メッセージであるときに、"rfc822"「副-タイプ」は使用されています。 「部分的な」「副-タイプ」は部分的なRFC822メッセージのために定義されて、であることができない大きいと考えられるボディーの断片化しているトランスミッションを可能にするのは無事に運送設備を通り抜けました。 別の「外部のボディー」である「副-タイプ」は、外部のデータ送信端末の参照で大きいボディーを指定するために定義されます。
It should be noted that the list of media 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.
ここに与えられたタイプ値がそうするメディアのリストが時間内に、上で説明されたメカニズムで増大して、血液型亜型のセットが実質的に成長すると予想されることに注意されるべきです。
4. Discrete Media Type Values
4. 離散的なメディアは値をタイプします。
Five of the seven initial media type values refer to discrete bodies. The content of these types must be handled by non-MIME mechanisms; they are opaque to MIME processors.
タイプが評価する7つの初期のメディアのうち5は離散的なボディーについて言及します。 非MIMEメカニズムでこれらのタイプの内容を扱わなければなりません。 それらはMIMEプロセッサに不透明です。
4.1. Text Media Type
4.1. テキストメディアタイプ
The "text" media type is intended for sending material which is principally textual in form. A "charset" parameter may be used to indicate the character set of the body text for "text" subtypes, notably including the subtype "text/plain", which is a generic subtype for plain text. Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks. Plain text may allow the stacking of several characters in the same position in the text. Plain text in scripts like Arabic and Hebrew may also include facilitites that allow the arbitrary mixing of text segments with opposite writing directions.
「テキスト」メディアタイプはフォームで主に原文であることの送付の材料のために意図します。 "charset"パラメタは「テキスト」血液型亜型のために本文の文字集合を示すのに使用されるかもしれません、「副-タイプ」「テキスト/平野」(プレーンテキストのためのジェネリック「副-タイプ」である)を著しく含んでいて。 プレーンテキストは、書式付けコマンド、文字修飾仕様、処理命令、解釈指示、または満足しているマーク付けを備えもしませんし、許容もしません。 プレーンテキストは単にことによるとラインブレイクかページブレークによって遮られたキャラクタの線形連続と考えられます。 プレーンテキストはテキストの同じ見解のいくつかのキャラクタの積み重ねを許すかもしれません。 また、アラビア語とヘブライ語のようなスクリプトによるプレーンテキストは反対の書くことの方向でテキスト・セグメントの任意の混合を許すfacilititesを含むかもしれません。
Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most nontextual data. Such formatted textual data should be represented using subtypes of "text".
プレーンテキストを超えて、「豊かなテキスト」として知られているかもしれないことを表すための多くの形式がいます。 そのような多くの表現のおもしろい特性はそれらがそれらを解釈するソフトウェアがなくてもある程度読み込み可能であるということです。 次に、それらを区別するのは役に立ちます、上層部によって、イメージ、オーディオ、またはテキストが読みにくいフォームに表したような読みにくいデータから。 適切な解釈ソフトウェアがないとき、「テキスト」の血液型亜型をユーザに示しているのは妥当です、したがって、ほとんどのnontextualデータを処理するのが妥当ではありませんが。 そのようなフォーマットされた原文のデータは、「テキスト」の血液型亜型を使用することで表されるべきです。
Freed & Borenstein Standards Track [Page 6] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[6ページ]。
4.1.1. Representation of Line Breaks
4.1.1. ラインブレイクの表現
The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden.
どんなMIME「テキスト」「副-タイプ」の標準形もCRLF系列としていつもラインブレイクを表さなければなりません。 同様に、MIME「テキスト」における、CRLFのどんな発生もラインブレイクを表さなければなりません。 またラインブレイク系列の外部が禁じられるCRとLFの使用。
This rule applies regardless of format or character set or sets involved.
この規則は形式、文字集合または伴われるセットにかかわらず適用されます。
NOTE: The proper interpretation of line breaks when a body is displayed depends on the media type. In particular, while it is appropriate to treat a line break as a transition to a new line when displaying a "text/plain" body, this treatment is actually incorrect for other subtypes of "text" like "text/enriched" [RFC-1896]. Similarly, whether or not line breaks should be added during display operations is also a function of the media type. It should not be necessary to add any line breaks to display "text/plain" correctly, whereas proper display of "text/enriched" requires the appropriate addition of line breaks.
以下に注意してください。 ボディーを表示するとき、ラインブレイクの適切な解釈はメディアタイプに頼っています。 「テキスト/明瞭な」ボディーを表示するときの復帰改行への変遷としてラインブレイクを扱うのが適切ですが、「テキスト」の他の血液型亜型には、この処理は実際に「テキスト/豊かにされる」ように[RFC-1896]特に、不正確です。 同様に、また、ラインブレイクがディスプレイ操作の間、加えられるべきであるかどうかが、メディアタイプの関数です。 正しく「テキスト/平野」を表示するためにどんなラインブレイクも加えるのは必要であるべきではありませんが、「テキスト/豊かにされること」の適切なディスプレイはラインブレイクの適切な追加を必要とします。
NOTE: Some protocols defines a maximum line length. E.g. SMTP [RFC- 821] allows a maximum of 998 octets before the next CRLF sequence. To be transported by such protocols, data which includes too long segments without CRLF sequences must be encoded with a suitable content-transfer-encoding.
以下に注意してください。 いくつかのプロトコルが最大の行長を定義します。 例えば SMTP[RFC821]は次のCRLF系列の前に最大998の八重奏を許容します。 そのようなプロトコルによって輸送されるために、適当な満足している転送コード化でCRLF系列なしで長過ぎるセグメントを含んでいるデータをコード化しなければなりません。
4.1.2. Charset Parameter
4.1.2. 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=iso-8859-1
文書内容: テキスト/平野。 charset=iso-8859-1
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. For other subtypes of "text" than "text/plain", the semantics of the "charset" parameter should be defined to 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 to the implications of multioctet character sets for their subtype definitions.
何か「テキスト」の将来の血液型亜型のための仕様は、彼らがまた、"charset"パラメタを利用して、ことによるとまた、値を制限するかもしれないかどうか指定しなければなりません。 「テキスト/平野」以外の「テキスト」の血液型亜型において、"charset"パラメタの意味論はここで「テキスト/平野」に指定されたものと同じになるように定義されるべきです、すなわち、ボディーは与えられたcharsetでキャラクタから完全に成ります。 特に、将来の「テキスト」血液型亜型のdefinersは彼らの「副-タイプ」定義のために「マルチ-八重奏」文字集合の含意への周到な注意を支払うはずです。
Freed & Borenstein Standards Track [Page 7] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[7ページ]。
The charset parameter for subtypes of "text" gives a name of a character set, as "character set" is defined in RFC 2045. The rules regarding line breaks detailed in the previous section must also be observed -- a character set whose definition does not conform to these rules cannot be used in a MIME "text" subtype.
「テキスト」の血液型亜型のためのcharsetパラメタは文字集合の名前を与えます、「文字集合」がRFC2045で定義されるとき。 また、前項で詳細なラインブレイクに関する規則を守らなければなりません--MIME「テキスト」「副-タイプ」で定義がこれらの規則に従わない文字集合を使用できません。
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.
このセクションの端で事前に定義された文字集合名の初期のリストを見つけることができます。 追加文字セットはIANAに登録されるかもしれません。
Other media types than subtypes of "text" might choose to employ the charset parameter as defined here, but with the CRLF/line break restriction removed. Therefore, all character sets that conform to the general definition of "character set" in RFC 2045 can be registered for MIME use.
「テキスト」の血液型亜型以外のメディアタイプは、ここで定義されますが、取り除くCRLF/ラインブレイク制限と共にcharsetパラメタを使うのを選ぶかもしれません。 したがって、MIME使用のためにRFC2045との「文字集合」の一般的な定義に従うすべての文字集合は登録できます。
Note that if the specified character set includes 8-bit characters and such characters are used in the body, 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 [RFC-821].
指定された文字集合が8ビットのキャラクタを含むか、そして、そのようなキャラクタがボディーを使用されるというメモ、Contentがコード化を移しているヘッダーフィールドとデータでの対応するコード化がいくつかのメール転送プロトコルでボディーを伝えるのに必要です、SMTP[RFC-821]などのように。
The default character set, US-ASCII, has been the subject of some confusion and ambiguity in the past. Not only were there some ambiguities in the definition, there have been wide variations in practice. In order to eliminate such ambiguity and variations in the future, it is strongly recommended that new user agents explicitly specify a character set as a media type parameter in the Content-Type header field. "US-ASCII" does not indicate an arbitrary 7-bit character set, but specifies that all octets in the body must be interpreted as characters according to the US-ASCII character set. National and application-oriented versions of ISO 646 [ISO-646] are usually NOT identical to US-ASCII, and in that case their use in Internet mail is explicitly discouraged. The omission of the ISO 646 character set from this document is deliberate in this regard. The character set name of "US-ASCII" explicitly refers to the character set defined in ANSI X3.4-1986 [US- ASCII]. The new international reference version (IRV) of the 1991 edition of ISO 646 is identical to US-ASCII. The character set name "ASCII" is reserved and must not be used for any purpose.
デフォルト文字集合(米国-ASCII)は過去の何らかの混乱とあいまいさの対象です。 いくつかのあいまいさが定義中だけであったのではなく、広い変化が実際にはありました。 将来そのようなあいまいさと変化を取り除くために、新しいユーザエージェントがコンテントタイプヘッダーフィールドにおけるメディア型引数として明らかに文字集合を指定することが強く勧められます。 「米国-ASCII」は、任意の7ビットの文字集合を示しませんが、米国-ASCII文字の組によると、キャラクタとしてボディーのすべての八重奏を解釈しなければならないと指定します。 通常、ISO646[ISO-646]の国家の、そして、アプリケーション指向のバージョンは米国-ASCIIと同じではありません、そして、その場合、インターネット・メールにおける彼らの使用は明らかにお勧めできないです。 このドキュメントからのISO646文字集合の省略はこの点で慎重です。 「米国-ASCII」の文字集合名は明らかにANSI X3.4-1986[米国ASCII]で定義された文字集合について言及します。 1991年のISO646の版の新しい国際的な参照バージョン(IRV)は米国-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 media 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
以下に注意してください。 RFC821は明らかに「ASCII」を指定します、そして、参照はアメリカン・スタンダードの以前のバージョンを指定します。 受信機が、送付者がどのように解釈されるべきコード化されたメッセージを意図したかを明白に決定することを許可するメディアタイプと文字集合を指定する目的の1つがことである限り、デフォルトとしての「厳しいASCII」を除いた何かを仮定すると、現在送られるメッセージの意味論への意図的でなくて非互換な変化は危険にさらされるでしょう。 また、これはそれを含意します。
Freed & Borenstein Standards Track [Page 8] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[8ページ]。
messages containing characters coded according to other versions of ISO 646 than US-ASCII and the 1991 IRV, or using code-switching procedures (e.g., those of ISO 2022), as well as 8bit or multiple octet character encodings MUST use an appropriate character set specification to be consistent with MIME.
米国-ASCIIと1991IRV以外のISO646のバージョンによると、コード化されるか、またはコードを切り換える手順(例えば、ISO2022のもの)、および8ビットを用いることでキャラクタを含むメッセージか複数の八重奏文字符号化が、MIMEと一致しているのに適切な文字集合仕様を使用しなければなりません。
The complete US-ASCII character set is listed in ANSI X3.4- 1986. Note that the control characters including DEL (0-31, 127) have no defined meaning in apart from the combination CRLF (US-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)." Aside from these conventions, any use of the control characters or DEL in a body must either occur
完全な米国-ASCII文字の組はANSI X3.4 1986に記載されています。 DEL(0-31、127)を含む制御文字が組み合わせCRLF(米国-ASCII値13と10)表示は別として復帰改行で定義された意味を全く持っていないことに注意してください。 2つのキャラクタには、広い使用での事実上の意味があります: FF(12)は、しばしば「新しいページの始まりに関するその後のテキストを始めます」と意味します。 そして、TABかHT(9)が、しばしば「カーソルを現在の位置の後の次の有効なコラムに桁位置が8の倍数(コラム0に最初のコラムをみなして)であるところに動かします。」と意味します(いつもがではありませんが)。 これらのコンベンションは別として、ボディーにおける制御文字かDELのどんな使用も起こらなければなりません。
(1) because a subtype of text other than "plain"
specifically assigns some additional meaning, or
または(1) 「平野」を除いたテキストの「副-タイプ」が明確に何らかの追加意味を割り当てるので。
(2) within the context 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.
送付者と受取人との個人的な協定の文脈の中の(2)。 そのような個人的な協定をがっかりして、このドキュメントの他の能力に取り替えるべきです。
NOTE: An enormous proliferation of character sets exist beyond US- ASCII. A large number of partially or totally overlapping character sets is NOT a good thing. A SINGLE character set that can be used universally for representing all of the world's languages in Internet mail would be preferrable. Unfortunately, existing practice in several communities seems to point to the continued use of multiple character sets in the near future. A small number of standard character sets are, therefore, defined for Internet use in this document.
以下に注意してください。 文字集合の莫大な増殖は米国ASCIIを超えて存在しています。 文字集合を部分的か完全に重ね合わせる多くが良いものではありません。 インターネット・メールに世界の言語のすべてを表すのに一般に使用できるSINGLE文字集合は「前-フェリー-可能」でしょう。 残念ながら、いくつかの共同体の既存の習慣は近い将来の複数の文字集合の継続的な使用を示すように思えます。 したがって、少ない数の標準文字セットがインターネットの利用のために本書では定義されます。
The defined charset values are:
定義されたcharset値は以下の通りです。
(1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
(1)米国-ASCII--ANSI X3.4-1986[米国-ASCII]で定義されるように。
(2) 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 10.
(2)ISO-8859-X--「X」が必要に応じてISO-8859[ISO-8859]の部分に取り替えられることになっているところ。 ISO646文字集合が彼らの8859の交換を支持して故意に省略されたことに注意してください。交換はインターネット・メールのための指定された文字集合です。 このドキュメントの公表現在、「X」のための正統の値は1〜10にケタです。
Freed & Borenstein Standards Track [Page 9] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[9ページ]。
Characters in the range 128-159 has no assigned meaning in ISO-8859- X. Characters with values below 128 in ISO-8859-X have the same assigned meaning as they do in US-ASCII.
範囲128-159のキャラクターで、値があるISO-8859X.のキャラクターでISO-8859-Xの128未満が米国-ASCIIでするように意味を同じくらいに割り当てさせることを意味しながら、いいえを割り当てます。
Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew alphabet) includes both characters for which the normal writing direction is right to left and characters for which it is left to right, but do not define a canonical ordering method for representing bi-directional text. The charset values "ISO-8859-6" and "ISO-8859- 8", however, specify that the visual method is used [RFC-1556].
ISO8859(ラテン/アラビア文字)とパート8(ラテン語の、または、ヘブライのアルファベット)の一部6が正常な書くことの方向が左に正しいキャラクタとそれが右に残されるキャラクタの両方を含んでいますが、双方向のテキストを表すための正準なオーダー方法を定義しないでください。 そして、charsetが評価する、「ISO8859、6インチ、「しかしながら、ISO-88598インチは、視覚メソッドが使用されていると[RFC-1556]指定します」。
All of these character sets are used as pure 7bit or 8bit sets without any shift or escape functions. The meaning of shift and escape sequences in these character sets is not defined.
純粋な7ビットか8ビットが少しもシフトやエスケープ機能なしでセットするとき、これらの文字集合のすべてが使用されています。 これらの文字集合における、シフトとエスケープシーケンスの意味は定義されません。
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.
上で指定された文字集合はMIMEの草稿の間に比較的論議を呼んでいないものです。 このドキュメントは、米国-ASCIIを除いたどんな特定の文字集合の使用も是認しないで、世界文字集合の今後の発展が不明瞭なままで残っていると認めます。
Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field.
コンテントタイプ分野でいつも明らかにどちらかと言えば、米国ASCIIを除いて、使用される文字集合を指定しなければならないことに注意してください。
No character set name other than those defined above 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 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, composition software should always use the "lowest common denominator" character set possible. For example, if a body contains only US-ASCII characters, it SHOULD be marked as being in the US- ASCII character set, not ISO-8859-1, which, like all the ISO-8859 family of character sets, is a superset of US-ASCII. More generally, if a widely-used character set is a subset of another character set, and a body contains only characters in the widely-used subset, it should be labelled as being in that subset. This will increase the chances that the recipient will be able to view the resulting entity correctly.
一般に、構成ソフトウェアはいつも可能な「最小公分母」文字集合を使用するはずです。 例えば、ボディーはaであるなら米国-ASCII文字だけを含んで、それはSHOULDです。ISO-8859-1ではなく、米国ASCII文字の組にはあるとしてマークされてください、文字集合のすべてのISO-8859ファミリーのように米国-ASCIIのスーパーセットであるどれ。 より一般に、広く使用された文字集合が別の文字集合の部分集合であり、ボディーが広く使用された部分集合にキャラクタだけを含むなら、それはその部分集合にはあるとしてラベルされるべきです。 これは受取人が正しく結果として起こる実体を見ることができるという可能性を増強するでしょう。
Freed & Borenstein Standards Track [Page 10] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[10ページ]。
4.1.3. Plain Subtype
4.1.3. 明瞭なSubtype
The simplest and most important subtype of "text" is "plain". This indicates plain text that does not contain any formatting commands or directives. Plain text is intended to be displayed "as-is", that is, no interpretation of embedded formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup should be necessary for proper display. The default media type of "text/plain; charset=us-ascii" for Internet mail 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.
他の「テキスト」「副-タイプ」は全くこのドキュメントによって定義されません。
4.1.4. Unrecognized Subtypes
4.1.4. 認識されていない血液型亜型
Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset. Unrecognized subtypes which also specify an unrecognized charset should be treated as "application/octet- stream".
MIME実装がcharsetを扱う方法を知っている限り、「テキスト」の認識されていない血液型亜型は「単に」「副-タイプ」として扱われるべきです。 また、認識されていないcharsetを指定する認識されていない血液型亜型は「アプリケーション/八重奏ストリーム」として扱われるべきです。
4.2. Image Media Type
4.2. イメージメディアタイプ
A media type of "image" indicates that the body contains an image. The subtype names the specific image format. These names are not case sensitive. An initial subtype is "jpeg" for the JPEG format using JFIF encoding [JPEG].
「イメージ」のメディアタイプは、ボディーがイメージを含むのを示します。 「副-タイプ」は特定の画像形式を命名します。 これらの名前は大文字と小文字を区別していません。 初期の「副-タイプ」は[JPEG]をコード化するJFIFを使用するJPEG形式のための"jpeg"です。
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 RFC 2048.
ここに与えられた「イメージ」血液型亜型のリストは、排他的でなくて、また徹底的でなく、より多くのタイプがIANAに示されるとき成長すると予想されます、RFC2048で説明されるように。
Unrecognized subtypes of "image" should at a miniumum be treated as "application/octet-stream". Implementations may optionally elect to pass subtypes of "image" that they do not specifically recognize to a secure and robust general-purpose image viewing application, if such an application is available.
「イメージ」の認識されていない血液型亜型はminiumumで「八重奏アプリケーション/ストリーム」として扱われるべきです。 実装は、彼らが明確にアプリケーションを見る安全で強健な汎用イメージに認識しない「イメージ」の血液型亜型を通過するのを任意に選ぶかもしれません、そのようなアプリケーションが利用可能であるなら。
NOTE: Using of a generic-purpose image viewing application this way inherits the security problems of the most dangerous type supported by the application.
以下に注意してください。 このようにアプリケーションを見るジェネリック目的イメージの使用はアプリケーションでサポートされる中で最も危険なタイプの警備上の問題を引き継ぎます。
4.3. Audio Media Type
4.3. オーディオメディアタイプ
A media 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.
「オーディオ」のメディアタイプは、ボディーがオーディオデータを含むのを示します。 コンピュータによる使用のための「理想的な」オーディオ形式に関するコンセンサスがまだありませんが、共同利用できる振舞いを提供できる形式のための差し迫った必要性があります。
Freed & Borenstein Standards Track [Page 11] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[11ページ]。
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 single channel audio encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz.
「オーディオ的か基本的な」「副-タイプ」の内容は8000Hzの見本郵送料率で8ビットのISDNμ法[PCM]を使用することでコード化されたただ一つのチャンネルオーディオです。
Unrecognized subtypes of "audio" should at a miniumum be treated as "application/octet-stream". Implementations may optionally elect to pass subtypes of "audio" that they do not specifically recognize to a robust general-purpose audio playing application, if such an application is available.
「オーディオ」の認識されていない血液型亜型はminiumumで「八重奏アプリケーション/ストリーム」として扱われるべきです。 実装は、彼らが明確にアプリケーションを使う強健な汎用オーディオに認識しない「オーディオ」の血液型亜型を通過するのを任意に選ぶかもしれません、そのようなアプリケーションが利用可能であるなら。
4.4. Video Media Type
4.4. ビデオメディアタイプ
A media type of "video" indicates that the body contains a time- varying-picture image, possibly with color and coordinated sound. The term 'video' is used in its most generic sense, 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".
このドキュメントが単一のボディーでのマルチメディアの混合を一般に強くがっかりさせますが、多くのいわゆるビデオ形式が連動しているオーディオの表現を含んでいると認められて、これが「ビデオ」の血液型亜型のために明らかに許可されていることに注意してください。
Unrecognized subtypes of "video" should at a minumum be treated as "application/octet-stream". Implementations may optionally elect to pass subtypes of "video" that they do not specifically recognize to a robust general-purpose video display application, if such an application is available.
「ビデオ」の認識されていない血液型亜型はminumumで「八重奏アプリケーション/ストリーム」として扱われるべきです。 実装は、彼らが明確に体力を要している汎用ビデオディスプレイアプリケーションに認識しない「ビデオ」の血液型亜型を通過するのを任意に選ぶかもしれません、そのようなアプリケーションが利用可能であるなら。
4.5. Application Media Type
4.5. アプリケーションメディアタイプ
The "application" media type is to be used for discrete data which do not fit in any of the other categories, and particularly for data to be processed by some type of application program. This is information which must be processed by an application before it is viewable or usable by a user. Expected uses for the "application" media type include file transfer, spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) material. (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" media type.)
「アプリケーション」メディアタイプはデータがタイプに関するアプリケーション・プログラムによって処理されるために他のカテゴリのどれかに、特に合わない不連続データに使用されることになっています。 これはユーザが見えているか、または使用可能になる前にアプリケーションで処理しなければならない情報です。 「アプリケーション」メディアへの予想された用途はインクルードファイル転送、スプレッドシート、メールベースのスケジューリングシステムのためのデータ、および「アクティブな」(コンピュータの)材料のための言語をタイプします。 (後者は作成者に解釈しなければならなくて、「アプリケーション/ポストスクリプト」メディアタイプの議論で詳細に考えられる警備上の問題を特に引き起こすことができます。)
Freed & Borenstein Standards Track [Page 12] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[12ページ]。
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 additional material based on that dialog. More generally, there have been several "active" messaging languages developed in which programs in a suitably specialized language are transported to a remote location and automatically run in the recipient's environment.
例えば、ミーティングスケジューラは提案されたミーティング期日頃の情報の標準の表現を定義するかもしれません。 知的なユーザエージェントはユーザと共に対話を行うのにこの情報を使用するでしょう、そして、その時はその対話に基づく追加材料を送るかもしれませんか? より一般に、適当に専門の言語におけるどのプログラムが離れた場所に輸送されて、自動的に受取人の環境に立候補するかで開発されたいくつかの「アクティブな」メッセージング言語がありました。
Such applications may be defined as subtypes of the "application" media type. This document defines two subtypes:
そのようなアプリケーションは「アプリケーション」メディアタイプの血液型亜型と定義されるかもしれません。 このドキュメントは2血液型亜型を定義します:
octet-stream, and PostScript.
八重奏ストリーム、およびポストスクリプト。
The subtype of "application" will often be either the name or include part of 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".
「アプリケーション」の「副-タイプ」は、しばしば名前であるかデータが意図するアプリケーションの名前の一部を含むでしょう。 しかしながら、これは、どんな応用プログラム名も「アプリケーション」の「副-タイプ」として自由に使用されるかもしれないことを意味しません。
4.5.1. Octet-Stream Subtype
4.5.1. 八重奏ストリームSubtype
The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. The set of currently defined parameters is:
「八重奏ストリーム」「副-タイプ」は、ボディーが任意のバイナリ・データを含むのを示すのに使用されます。 現在定義されたパラメタのセットは以下の通りです。
(1) TYPE -- the general type or category of binary data.
This is intended as information for the human recipient
rather than for any automatic processing.
(1)TYPE--バイナリ・データの一般型かカテゴリ。 これはどんな自動処理のためにもというよりむしろ人間の受取人への情報として意図します。
(2) PADDING -- the number of bits of padding that were
appended to the bit-stream comprising the actual
contents to produce the enclosed 8bit 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
8.
(2)PADDING--8ビットの同封のバイト指向のデータを作り出すために実際のコンテンツを包括するビットストリームにそれを水増しするビットの数を追加しました。 ビットの総数が8の倍数でないときに、これは一団となって少し流れた状態で同封の役に立ちます。
Both of these parameters are optional.
これらのパラメタの両方が任意です。
An additional parameter, "CONVERSIONS", was defined in RFC 1341 but has since been removed. 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で定義されましたが、以来、取り除いてあります。 また、RFC1341はデータがファイルに書かれていることであったなら使用されるために提案されたファイル名を与えた「名前」パラメタの使用を定義しました。 これは、別々のContent-気質ヘッダーフィールドを予測してその後のRFCで定義されるために推奨しないです。
The recommended action for an implementation that receives an "application/octet-stream" entity 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転送コード化も元に戻されている状態でファイルにデータを入れるか、または恐らくそれを使用すると単に申し出ることです。
Freed & Borenstein Standards Track [Page 13] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[13ページ]。
To reduce the danger of transmitting rogue programs, 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 message body as input.
凶暴なプログラムを放送するという危険を減少させるために、実装がコンテントタイプパラメタ(例えば、「インタプリタ=」パラメタ)で指定された任意のプログラムが入力されるようにメッセージ本体を使用することで見つけられて、実行される経路検索メカニズムを実装しないことが強く勧められます。
4.5.2. PostScript Subtype
4.5.2. ポストスクリプトSubtype
A media 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 media type "application/postscript" implies recognition of that trademark and all the rights it entails.
ポストスクリプトは「アプリケーション/追伸」が、その認識が商標登録するのを含意するMIMEメディアタイプとそれが伴うすべての権利のアドビ・システムズInc.Useの登録商標です。
The PostScript language definition provides facilities for internal labelling of the specific language features a given program uses. This labelling, called the PostScript document structuring conventions, or DSC, 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.
ポストスクリプト言語定義は与えられたプログラムが使用する特定の言語機能の内部のラベルのために便宜を与えます。 コンベンション、またはDSCを構造化するポストスクリプトドキュメントと呼ばれるこのラベルは、非常に一般的であり、まさしく言語水準より実質的に多くの情報を提供します。 必要でない間にコンベンションを構造化するドキュメントの使用は相互運用性への援助として強く推薦されます。 それらが与えられた環境で働くかどうか確認するためにコンベンションを構造化しながら適切な状態で欠けているドキュメントはテストできません。 そういうものとして、いくつかのシステムが、最悪を仮定して、不統一な文書を処理するのを拒否するかもしれません。
The execution of general-purpose PostScript interpreters entails serious security risks, and implementors are discouraged from simply sending PostScript 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 by typical printer environments, implementors should consider all of the following before they add interactive display of PostScript bodies to their MIME readers.
単にポストスクリプト本体を送る、重大なセキュリティが危険にさらす汎用ポストスクリプトインタプリタ限嗣相続の実行、および作成者が落胆している「オフである、棚」 インタプリタ。 通常、害の可能性が典型的なプリンタ環境によって大いに抑制されるプリンタにポストスクリプトを送るのが安全である間、彼らがポストスクリプト本体の対話的なディスプレイをMIME読者に加える前に作成者は以下のすべてを考えるべきです。
The remainder of this section outlines some, though probably not all, of the possible problems with the transport of PostScript entities.
このセクションの残りはいくつかについて概説します、たぶんポストスクリプト実体の輸送がある起こりうる問題のすべてではありませんが。
(1) 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.
(1) 含んでいますが、言語が制限されないかもしれないポストスクリプト、ポストスクリプトオペレータ"deletefile"、"renamefile"、"filenameforall"、および「ファイル」における危険な操作。 標準の入力か出力以外の何かに適用されると、「ファイル」は危険であるだけです。 また、実装は追加標準的でないファイルのオペレータを定義するかもしれません。 また、これらはセキュリティへの脅威を引き起こすかもしれません。 "Filenameforall"(ワイルドカードファイル検索オペレータ)は、無害であるように一見したところでは見えるかもしれません。
Freed & Borenstein Standards Track [Page 14] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[14ページ]。
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.
しかしながら、このオペレータが受取人がどんなファイルに近づく手段を持つかの情報を明らかにする可能性を持っていて、この情報が持っているかもしれないことにそれ自体で注意してください。敏感であってください。 メッセージ送付者は潜在的に危険なファイルのオペレータの使用を避けるべきです、これらのオペレータがかなり安全なポストスクリプト実装で入手できない傾向があるので。 ソフトウェアを受け取って、表示するメッセージは、すべての潜在的に危険なファイルのオペレータを完全に無効にするべきであるか、または少しの特別な権威も彼らの操作へ代表として派遣しないように特別に注意を払うべきです。 ポストスクリプトドキュメントを解釈するとき外の政府機関によって行われるとこれらのオペレータは見なされるべきです。 そのような無効にする、そして/または、ポストスクリプト言語自体の範囲の外で完全に照合するべきです。 メソッドが全くこれらのオペレータの完全な機能バージョンを再可能にするために存在しないのを保障するために注意するべきです。
(2) The PostScript language provides facilities for exiting
the normal interpreter, or server, loop. Changes made
in this "outer" environment are customarily retained
across documents, and may in some cases be retained
semipermanently in nonvolatile memory. The operators
associated with exiting the interpreter loop have the
potential to interfere with subsequent document
processing. As such, their unrestrained use
constitutes a threat of service denial. PostScript
operators that exit the interpreter loop include, but
may not be limited to, the exitserver and startjob
operators. Message sending software should not
generate PostScript that depends on exiting the
interpreter loop to operate, since the ability to exit
will probably be unavailable in secure PostScript
implementations. Message receiving and displaying
software should completely disable the ability to make
retained changes to the PostScript environment by
eliminating or disabling the "startjob" and
"exitserver" operations. If these operations cannot be
eliminated or completely disabled the password
associated with them should at least be set to a hard-
to-guess value.
(2) ポストスクリプト言語は普通のインタプリタ、またはサーバを出るために便宜を与えて、輪にしてください。 この「外側」の環境で行われた変更は、ドキュメントの向こう側に通例に保有されて、いくつかの場合、不揮発性メモリで半永久保有されるかもしれません。 インタプリタ輪を出ると関連しているオペレータには、その後の文書処理を妨げる可能性があります。 そういうものとして、彼らの気ままな使用はサービス否定の脅威を構成します。 含んでいますが、輪が制限されないかもしれないインタプリタ、exitserver、およびstartjobオペレータを出るポストスクリプトオペレータ。 メッセージ送信ソフトウェアは作動するためにインタプリタ輪を出るのによるポストスクリプトを生成するはずがありません、出る能力がたぶん安全なポストスクリプト実装で入手できなくなるので。 "startjob"と"exitserver"が操作であると排除するか、または無効にすることによって、メッセージ受信とソフトウェアが作る能力を完全に無効にするはずである表示はポストスクリプト環境への変化を保有しました。 これらの操作を省くというわけではないか、または完全に無効にすることができるというわけではないなら、それらに関連しているパスワードは推測への困難な値に少なくとも設定されるべきです。
(3) 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
(3) ポストスクリプトはシステム全体の、そして、デバイス特有のパラメタを設定するのにオペレータを提供します。 これらのパラメタ設定は、仕事の向こう側に保有されて、潜在的にインタプリタの正しい操作への脅威を引き起こすかもしれません。 しかしシステムを設定するオペレータとデバイス・パラメータが含むポストスクリプトはそうではありません。
Freed & Borenstein Standards Track [Page 15] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[15ページ]。
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
disable the ability to change system and device
parameters. If these operators cannot be completely
disabled the password associated with them should at
least be set to a hard-to-guess value.
有限である、「setsystemparams」と「setdevparams」オペレータ。 メッセージ送信ソフトウェアは正しく作動するためにシステムかデバイス・パラメータの設定に依存するポストスクリプトを生成するはずがありません。 これらのパラメタを設定する能力はたぶん安全なポストスクリプト実装で入手できなくなるでしょう。 ソフトウェアを受け取って、表示するメッセージはシステムとデバイス・パラメータを変える能力を無効にするべきです。 完全にこれらのオペレータを無効にすることができるというわけではないなら、彼らに関連しているパスワードは推測しにくい値に少なくとも設定されるべきです。
(4) 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.
(4) いくつかのポストスクリプト実装が機械コードのダイレクトローディングと実行に標準的でない施設を提供します。 そのような施設は全く明らかにかなりの乱用に開かれています。 メッセージ送信ソフトウェアはそのような特徴を利用するはずがありません。 また、ハードウェア完全に特有であること以外に、それらもポストスクリプトの安全な実装で入手できない傾向があります。 彼らが存在するなら、ソフトウェアを受け取って、表示するメッセージは、そのようなオペレータが使用されるのを許容するべきではありません。
(5) 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.
(5) ポストスクリプトは、広げることができる言語と、多くかそれの実装はそれら自身の多くの拡大を最も提供します。 未知の要素を構成するので、このドキュメントは明らかにそのような拡大に対処しません。 メッセージ送信ソフトウェアは標準的でない拡大を利用するはずがありません。 それらはいくつかの実装からなくなる傾向があります。 ソフトウェアを受け取って、表示するメッセージは、どんな標準的でないポストスクリプトオペレータも確実に安全になるようにして、どんな種類の脅威も提示するべきではありません。
(6) It is possible to write PostScript that consumes huge
amounts of various system resources. It is also
possible to write PostScript programs that loop
indefinitely. Both types of programs have the
potential to cause damage if sent to unsuspecting
recipients. Message-sending software should avoid the
construction and dissemination of such programs, which
is antisocial. Message receiving and displaying
software should provide appropriate mechanisms to abort
processing 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.
(6) 多量の様々なシステム資源を消費するポストスクリプトを書くのは可能です。 また、ポストスクリプトプログラムにその輪を無期限に書くのも可能です。 両方のタイプに関するプログラムには、疑わない受取人に送るなら、損害を与える可能性があります。 メッセージ送信ソフトウェアはそのようなプログラムの工事と普及を避けるはずです(非社交的です)。 ソフトウェアを受け取って、表示するメッセージは、妥当な時間が経過した後に処理するのを中止するために適切な手段を提供するべきです。 さらに、ポストスクリプトインタプリタはどんな与えられたシステム資源の十分な量だけの消費にも制限されるべきです。
Freed & Borenstein Standards Track [Page 16] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[16ページ]。
(7) It is possible to include raw binary information inside
PostScript in various forms. This is not recommended
for use in Internet mail, both because it is not
supported by all PostScript interpreters and because it
significantly complicates the use of a MIME Content-
Transfer-Encoding. (Without such binary, PostScript
may typically be viewed as line-oriented data. The
treatment of CRLF sequences becomes extremely
problematic if binary and line-oriented data are mixed
in a single Postscript data stream.)
(7) 様々なフォームにポストスクリプトで生の2進情報を含んでいるのは可能です。これはインターネット・メールにおける使用のために推薦されません、それがすべてのポストスクリプトインタプリタによってともにサポートされないで、コード化を移してMIME Contentの使用をかなり複雑にするので。 (そのようなバイナリーがなければ、ポストスクリプトは系列指向のデータとして通常見なされるかもしれません。 2進の、そして、系列指向のデータがただ一つのPostscriptデータ・ストリームで複雑であるなら、CRLF系列の処理は非常に問題が多くなります。)
(8) 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.
(8) 最終的に、バグは何人かのポストスクリプトインタプリタに存在するかもしれません(受取人のシステムへの不正アクセスを獲得するのに、利用できました)。 この可能性に注意することは別として、いずれか見つけられるなら、そのようなバグのタイムリーな修正は別としてこれを防ぐために取るどんな特定の行動もありません。
4.5.3. Other Application Subtypes
4.5.3. 他のアプリケーション血液型亜型
It is expected that many other subtypes of "application" will be defined in the future. MIME implementations must at a minimum treat any unrecognized subtypes as being equivalent to "application/octet- stream".
そんなに多く、「アプリケーション」の他の血液型亜型が将来定義されると予想されます。 MIME実装は最小の御馳走の「アプリケーション/八重奏ストリーム」に同等であるとしてのどんな認識されていない血液型亜型もそうしなければなりません。
5. Composite Media Type Values
5. 合成メディアは値をタイプします。
The remaining two of the seven initial Content-Type values refer to composite entities. Composite entities are handled using MIME mechanisms -- a MIME processor typically handles the body directly.
7つの初期のコンテントタイプ値のうち残っている2は合成実体について言及します。 合成実体はMIMEメカニズムを使用することで扱われます--MIMEプロセッサは直接ボディーを通常扱います。
5.1. Multipart Media Type
5.1. 複合メディアタイプ
In the case of multipart entities, in which one or more different sets of data are combined in a single body, a "multipart" media type field must appear in the entity's header. The body must then contain one or more body parts, each preceded by a boundary delimiter line, and the last one followed by a closing boundary delimiter line. After its boundary delimiter line, each body part then consists of a header area, a blank line, and a body area. Thus a body part is similar to an RFC 822 message in syntax, but different in meaning.
複合実体の場合では、タイプがさばく「複合」のメディアは実体のヘッダーに現れなければなりません。(そこでは、1つ以上の異なったデータが単一のボディーで結合されます)。 次に、ボディーは1つ以上の身体の部分を含まなければなりません、そして、それぞれが境界デリミタ系列で先行しました、そして、最後のものは終わりの境界デリミタ系列で続きました。 そして、境界デリミタ系列の後に、それぞれの身体の部分はヘッダー領域、空白行、およびボディー領域から成ります。 したがって、身体の部分は、構文においてRFC822メッセージと同様ですが、意味において異なっています。
A body part is an entity and hence 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 usually indicates that the corresponding body has
身体の部分は、実体であり、したがって、実際にRFC822メッセージであるので解釈されるために、ありません。 初めに、ヘッダーフィールドは全く実際に身体の部分で必要ではありません。 したがって空白行から始まる身体の部分は、許容されていて、想定されるすべてのデフォルト値がことである身体の部分です。 このような場合には、通常、コンテントタイプヘッダーの不在は、対応するボディーがそうしたのを示します。
Freed & Borenstein Standards Track [Page 17] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[17ページ]。
a content-type of "text/plain; charset=US-ASCII".
「テキスト/平野」のcontent type。 「charsetは米国-ASCIIと等しいです。」
The only header fields that have defined meaning for body parts are those the names of which begin with "Content-". All other header fields may be ignored in body parts. Although they should generally be retained if at all possible, 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.
身体の部分と意味を定義した唯一のヘッダーフィールドがそれの名前が「内容」で始まるそれらです。 他のすべてのヘッダーフィールドが身体の部分で無視されるかもしれません。 できれば一般に保有されるべきですが、必要なら、それらはゲートウェイによって捨てられるかもしれません。 よってはいけないのを除いて、身体の部分で見える他の分野が許可されているそのようなもの。 「X」分野は実験的であるか個人的な目的のために作成されるかもしれません、それらが含む情報が数門で失われるかもしれないという認識で。
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 a JPEG image. In order to represent the latter, the body part must have "Content-Type: message/rfc822", and its body (after the blank line) must be the encapsulated message, with its own "Content-Type: image/jpeg" 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 parts actually are messages, a "digest" subtype is also defined.)
以下に注意してください。 RFC822メッセージと身体の部分での区別は、微妙ですが、重要です。 例えば、インターネットとX.400メールの間のゲートウェイはイメージを含む身体の部分とカプセル化されたメッセージを含む身体の部分の違いを言うことができなければなりません。そのボディーはJPEGイメージです。 後者、部分が持たなければならないボディーを表す、「コンテントタイプ:」 「/rfc822を通信させてください」、ボディー(空白行の後の)がそれ自身のものがあるカプセル化されたメッセージであるに違いない、「コンテントタイプ:」 「イメージ/jpeg」ヘッダーフィールド。 同様の構文の使用は逆もまた同様にメッセージの変換を身体の部分に容易にしますが、2の区別を作成者に解釈しなければなりません。 (また、部品が実際にメッセージである特別な場合において、「ダイジェスト」「副-タイプ」は定義されます。)
As stated previously, each body part is preceded by a boundary delimiter line that contains the boundary delimiter. The boundary delimiter MUST NOT appear inside any of the encapsulated parts, on a line by itself or as the prefix of any line. This implies that it is crucial that the composing agent be able to choose and specify a unique boundary parameter value that does not contain the boundary parameter value of an enclosing multipart as a prefix.
先に述べたとおり、境界デリミタを含む境界デリミタ系列はそれぞれの身体の部分に先行します。 境界デリミタはカプセル化された部品のどれかに現れてはいけません、それ自体かどんな系列の接頭語とした系列で。 これは、構成しているエージェントが接頭語としての複合の同封の境界パラメタ価値を含まないユニークな境界パラメタ価値を選んで、指定できるのが、重要であることを含意します。
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 those of an unrecognized subtype.
「複合」のタイプのすべての現在の、そして、将来の血液型亜型が同じ構文を使用しなければなりません。 血液型亜型は、それらの意味論において異なるかもしれなくて、追加制限を構文に課すかもしれませんが、「複合」のタイプに、必要な構文に従わなければなりません。 この要件は、すべてのconformantユーザエージェントがどんな複合実体の部品も認識して、少なくとも切り離すことができるのを確実にします、認識されていない「副-タイプ」のものさえ。
As stated in the definition of the Content-Transfer-Encoding field [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The "multipart" boundary delimiters and header fields are always represented as 7bit US-ASCII in any case (though the header fields may encode non-US-ASCII header text as per RFC 2047) 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転送コード化分野[RFC2045]の定義で述べられているように、「7ビット」、「8ビット」、または「バイナリー」以外のコード化は「複合タイプ」の実体のために受入れられません。 「複合」の境界デリミタとヘッダーフィールドは部分に従った部分ベースで身体の部分の中のどんなケース(ヘッダーフィールドはRFC2047に従って非米国のASCIIヘッダーテキストをコード化するかもしれませんが)とデータの7ビットの米国-ASCIIもコード化できるようにいつも表されます、それぞれの適切な身体の部分へのContent転送コード化分野で。
Freed & Borenstein Standards Track [Page 18] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[18ページ]。
5.1.1. Common Syntax
5.1.1. 一般的な構文
This section defines a common syntax for subtypes of "multipart". All subtypes of "multipart" must use this syntax. A simple example of a multipart message also appears in this section. An example of a more complex multipart message is given in RFC 2049.
このセクションは「複合」の血液型亜型のために一般的な構文を定義します。 「複合」のすべての血液型亜型がこの構文を使用しなければなりません。 また、複合メッセージの簡単な例はこのセクションに現れます。 より複雑な複合メッセージに関する例はRFC2049で出されます。
The Content-Type field for multipart entities requires one parameter,
"boundary". The boundary delimiter line is then defined as a line
consisting entirely of two hyphen characters ("-", decimal value 45)
followed by the boundary parameter value from the Content-Type header
field, optional linear whitespace, and a terminating CRLF.
複合実体のためのコンテントタイプ分野は1つのパラメタ、「境界」を必要とします。 そして、境界デリミタ線は境界パラメタ価値がコンテントタイプヘッダーフィールド、任意の直線的な空白、および終わっているCRLFからあとに続いた2つのハイフンキャラクタ(「-」、デシマル値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 boundary parameter values 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 invalid Content-type fields. Thus, a typical "multipart" Content-Type header field might look like this:
作成者への警告: Contentタイプフィールドに関するパラメタのための文法がそのようなものであるので、文書内容線に関する引用文の境界パラメタ値を同封するのがしばしば必要です。 これは、いつも必要であるというわけではありませんが、決して痛みません。 作成者は、無効の文書内容分野を生産するのを避けるために確実に慎重に文法を研究するべきです。 したがって、典型的な「複合」のコンテントタイプヘッダーフィールドはこれに似るかもしれません:
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
コンテントタイプ: 複合か混ぜられる。 境界=gc0p4Jq0M2Yt08j34c0p
But the following is not valid:
しかし、以下は有効ではありません:
Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
コンテントタイプ: 複合か混ぜられる。 境界=gc0pJq0M: 08jU534c0p
(because of the colon) and must instead be represented as
そして、(コロンによる)、代わりに、表さなければなりません。
Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
コンテントタイプ: 複合か混ぜられる。 境界=「gc0pJq0M: 08jU534c0p」
This Content-Type value indicates that the content consists of one or more parts, each with a structure that is syntactically identical to an RFC 822 message, except that the header area is allowed to be completely empty, and that the parts are each preceded by the line
このコンテントタイプ値は、内容が1つ以上の部品から成るのを示します、そして、それぞれ構造で、ヘッダー領域が完全に空であることが許容されているのを除いて、それはシンタクス上RFC822メッセージと同じです、そして、部品がそれぞれであることが線のそばで先行しました。
Freed & Borenstein Standards Track [Page 19] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[19ページ]。
--gc0pJq0M:08jU534c0p
--gc0pJq0M: 08jU534c0p
The boundary delimiter MUST occur at the beginning of a line, i.e., following a CRLF, and the initial CRLF is considered to be attached to the boundary delimiter line rather than part of the preceding part. The boundary may be followed by zero or more characters of linear whitespace. It is then terminated by either 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. If no Content-Type field is present it is assumed to be "message/rfc822" in a "multipart/digest" and "text/plain" otherwise.
すなわち、CRLFに続いて、境界デリミタは線の始めに起こらなければなりません、そして、初期のCRLFによって前の部分の一部よりむしろ境界デリミタ線に付けられていると考えられます。 境界は直線的な空白のゼロか、より多くのキャラクタによって従われるかもしれません。 次に、それは次の部分への別のCRLFとヘッダーフィールド、または2CRLFsが終えられます、次の部分へのヘッダーフィールドが全くどのケースにないかで。 どんなコンテントタイプ分野も存在していないなら、それはそうでなければ、「複合/ダイジェスト」と「テキスト/平野」の「メッセージ/rfc822」であると思われます。
NOTE: The CRLF preceding the boundary delimiter 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 boundary delimiter 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番目はそれによるカプセル化境界の一部です。
Boundary delimiters must not appear within the encapsulated material, and must be no longer than 70 characters, not counting the two leading hyphens.
境界デリミタは、70のキャラクタより要約の材料の中に現れてはいけなくて、もうであるに違いありません、2つの主なハイフンを数えないで。
The boundary delimiter line following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter line is identical to the previous delimiter lines, with the addition of two more hyphens after the boundary parameter value.
最後の身体の部分に続く境界デリミタ線はどんな一層の身体の部分も続かないのを示す顕著なデリミタです。 そのようなデリミタ線は前のデリミタ線と同じです、境界パラメタ価値の後のもう2つのハイフンの添加で。
--gc0pJq0M:08jU534c0p--
--gc0pJq0M: 08jU534c0p--
NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the boundary value with the beginning of each candidate line. An exact match of the entire candidate line is not required; it is sufficient that the boundary appear in its entirety following the CRLF.
作成者に以下に注意してください。 境界ストリング比較はそれぞれの候補線の始まりと境界値を比べなければなりません。 全体の候補線の完全な一致は必要ではありません。 CRLFに続いて、境界が全体として現れるのは、十分です。
There appears to be room for additional information prior to the first boundary delimiter line and following the final boundary delimiter line. These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line 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
以下に注意してください。 一般に、これらの「序文」と「エピローグ」領域はこれらの部品の適切なタイプの不足とゲートウェイ(特にX.400ゲートウェイ)でこれらの領域を扱うための明確な意味論の不足のために使用されません。 しかしながら、序文部門を空白の状態でおくよりむしろ多くのMIME実現によって、これがa近いのがわかりました。
Freed & Borenstein Standards Track [Page 20] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[20ページ]。
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.
入賞して、プレMIMEソフトウェアでメッセージを読む受取人のために注記を挿入してください、そのような注意がMIME対応することのソフトウェアによって無視されるので。
NOTE: Because boundary delimiters must not appear in the body parts being encapsulated, a user agent must exercise care to choose a unique boundary parameter value. The boundary parameter value in the example above could have been the result of an algorithm designed to produce boundary delimiters with a very low probability of already existing in the data to be encapsulated without having to prescan the data. Alternate algorithms might result in more "readable" boundary delimiters for a recipient with an old user agent, but would require more attention to the possibility that the boundary delimiter might appear at the beginning of some line in the encapsulated part. The simplest boundary delimiter line possible is something like "---", with a closing boundary delimiter line of "-----".
以下に注意してください。 境界デリミタを身体の数回に分けて要約される掲載してはいけないので、ユーザエージェントはユニークな境界パラメタ価値を選ぶために注意しなければなりません。 上記の例の境界パラメタ価値は前スキャンにデータを持っていなくて要約されるためにデータに既に存在するという非常に低い確率で境界デリミタを作成するように設計されたアルゴリズムの結果であったかもしれません。 交互のアルゴリズムは、年取ったユーザエージェントと共に受取人のための、より「読み込み可能な」境界デリミタをもたらすかもしれませんが、境界デリミタが何らかの線の始めに要約の部分に現れるかもしれない可能性に関する、より多くの注意を必要とするでしょう。 「可能なデリミタ線が似ている最も簡単な境界」---「デリミタが立ち並ぶ境界を閉じるa」-----".
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>
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
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;、日付: Sun、1993年3月21日23:56:48 -0800(太平洋標準時の)のSubject: メッセージMIMEバージョンを抽出してください: 1.0文書内容: 複合か混ぜられる。 境界は「簡単な境界」と等しいです。
This is the preamble. It is to be ignored, though it
is a handy place for composition agents to include an
explanatory note to non-MIME conformant readers.
これは序文です。 それは無視されることになっています、それが構成エージェントが非MIME conformant読者に注記を含む便利な場所ですが。
--simple boundary
--簡単な境界
This is implicitly typed plain US-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 US-ASCII text.
It DOES end with a linebreak.
これは明らかにタイプされた明瞭な米国-ASCIIテキストです。 それ、DOESはlinebreakで終わります。
--simple boundary--
--簡単な境界--
This is the epilogue. It is also to be ignored.
これはエピローグです。 また、それは無視されることになっています。
Freed & Borenstein Standards Track [Page 21] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[21ページ]。
The use of a media 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 uses a different boundary delimiter. See RFC 2049 for an example of nested "multipart" entities.
別の「複合」の実体の中の身体の部分の「複合」のメディアタイプの使用は明らかに許されています。 そのような場合、明白な理由によって、それぞれの入れ子にされた「複合」の実体が異なった境界デリミタを使用するのを保証するために注意しなければなりません。 入れ子にされた「複合」の実体の例に関してRFC2049を見てください。
The use of the "multipart" media type with only a single body part may be useful in certain contexts, and is explicitly permitted.
ただ一つの身体の部分だけがある「複合」のメディアタイプの使用は、ある文脈で役に立つかもしれなくて、明らかに受入れられます。
NOTE: Experience has shown that a "multipart" media type with a single body part is useful for sending non-text media types. It has the advantage of providing the preamble as a place to include decoding instructions. In addition, a number of SMTP gateways move or remove the MIME headers, and a clever MIME decoder can take a good guess at multipart boundaries even in the absence of the Content-Type header and thereby successfully decode the message.
以下に注意してください。 経験は、ただ一つの身体の部分がある「複合」のメディアタイプが送付非テキストメディアタイプの役に立つのを示しました。 それには、指示を解読するのを含む場所として序文を提供する利点があります。 多くのSMTPゲートウェイがさらに、MIMEヘッダーを動くか、または取り除いて、賢明なMIMEデコーダは、コンテントタイプヘッダーがないときでさえ複合境界で良い推測を取って、その結果、首尾よくメッセージを解読できます。
The only mandatory global parameter for the "multipart" media type is the boundary parameter, which consists of 1 to 70 characters from a set of characters known to be very robust through mail gateways, and NOT ending with white space. (If a boundary delimiter line appears to end with white space, the white space must be presumed to have been added by a gateway, and must be deleted.) It is formally specified by the following BNF:
唯一の「複合」のメディアタイプに、義務的なグローバルなパラメタが境界パラメタです。(そのパラメタはメール・ゲートウェイを通して非常に強健であることが知られて、余白で終わらない1セットのキャラクタからの1〜70のキャラクタから成ります)。 (境界デリミタ線が余白で終わるように見えるなら、余白をあえてゲートウェイによって加えられたに違いなくて、削除しなければなりません。) それは以下のBNFによって正式に指定されます:
boundary := 0*69<bchars> bcharsnospace
境界:=0*69<bchars>bcharsnospace
bchars := bcharsnospace / " "
bchars:=bcharsnospace/、「」
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"
「bcharsnospace:=DIGIT/アルファー/、「'「」 /「」 (「/」)/「+」/"_"/」、/「-」/」。」' / "/" / ":" / "=" / "?"
Overall, the body of a "multipart" entity may be specified as follows:
全体的に見て、「複合」の実体のボディーは以下の通り指定されるかもしれません:
dash-boundary := "--" boundary
; boundary taken from the value of
; boundary parameter of the
; Content-Type field.
ダッシュ境界:=「--」境界。 境界、値から取る、。 境界パラメタ、。 コンテントタイプ分野。
multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
輸送をそっと歩く複合ボディー:=[序文CRLF]身体部分*カプセル化近いデリミタ輸送ダッシュ境界CRLF詰め物[CRLFエピローグ]
Freed & Borenstein Standards Track [Page 22] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[22ページ]。
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
輸送をそっと歩く:=*LWSP-炭。 作曲家、発生してはいけません。 非ゼロ・レングス輸送。 しかし、詰め物、受信機はそうしなければなりません。 詰め物を扱うことができてください。 メッセージ転送で、加えられます。
encapsulation := delimiter transport-padding
CRLF body-part
輸送をそっと歩くカプセル化の:=デリミタCRLF身体部分
delimiter := CRLF dash-boundary
デリミタ:=CRLFダッシュ限界
close-delimiter := delimiter "--"
近いデリミタ:=デリミタ「--」
preamble := discard-text
序文:=、テキストを捨てます。
epilogue := discard-text
エピローグ:=、テキストを捨てます。
discard-text := *(*text CRLF) *text
; May be ignored or discarded.
テキストを捨てている:=*(*テキストCRLF)*テキスト。 無視されるか捨てられるかもしれなくなってください。
body-part := MIME-part-headers [CRLF *OCTET]
; Lines in a body-part must not start
; with the specified dash-boundary and
; the delimiter must not appear anywhere
; in the body part. Note that the
; semantics of a body-part differ from
; the semantics of a message, as
; described in the text.
身体部分:=MIME部分ヘッダー[CRLF*OCTET]。 身体部分の線は始動してはいけません。 そして、指定されたダッシュ境界、。 デリミタはどこでも現れてはいけません。 ボディーでは、離れてください。 それに注意してください、。 身体部分が異なるaの意味論。 メッセージの意味論、。 テキストでは、説明されます。
OCTET := <any 0-255 octet value>
OCTET:=<はどんな0-255八重奏値の>です。
IMPORTANT: The free insertion of linear-white-space and RFC 822 comments between the elements shown in this BNF is NOT allowed since this BNF does not specify a structured header field.
重要: このBNFが構造化されたヘッダーフィールドを指定しないので、このBNFで見せられた要素の間の直線的な余白とRFC822コメントの無料の挿入は許容されていません。
NOTE: In certain transport enclaves, RFC 822 restrictions such as the one that limits bodies to printable US-ASCII characters may not be in force. (That is, the transport domains may exist that resemble standard Internet mail transport as specified in RFC 821 and assumed by RFC 822, 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 US-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 US-ASCII characters.
以下に注意してください。 ある輸送飛び地では、ボディーを印刷可能な米国-ASCII文字に制限するものなどのRFC822制限が有効でないかもしれません。 (すなわち、RFC821で指定されて、RFC822によって想定されますが、ある制限なしで標準のインターネット・メール輸送に類似している輸送ドメインは存在するかもしれません。) これらの制限の緩和は例えば米国-ASCII範囲の外に八重奏を含むように局所的にボディーの定義を広げるのに理解されるべきです、これらの拡大が輸送で支持されて、適切に転送をコード化するContentヘッダーフィールドに記録される限り。 しかしながら、ヘッダー(メッセージヘッダーかボディー部分ヘッダーのどちらか)は米国-ASCII文字以外の何も決して、含むことができません。
Freed & Borenstein Standards Track [Page 23] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[23ページ]。
NOTE: Conspicuously missing from the "multipart" type is a notion of structured, related body parts. It is recommended that those wishing to provide more structured or integrated multipart messaging facilities should define subtypes of multipart that are syntactically identical but define relationships between the various parts. For example, subtypes of multipart could be defined that include a distinguished part which in turn is used to specify the relationships between the other parts, probably referring to them by their Content-ID field. Old implementations will not recognize the new subtype if this approach is used, but will treat it as multipart/mixed and will thus be able to show the user the parts that are recognized.
以下に注意してください。 「複合」のタイプから著しく消えるのは、構造化されて、関連する身体の部分の概念です。 さらに構造化されたか、統合している複合メッセージング施設を提供したがっている人が複合のシンタクス上同じ血液型亜型を定義しますが、様々な部分の間の関係を定義するのは、お勧めです。 例えば、他の部品の間の関係を指定するのに順番に使用される顕著な部分を含んでいる複合の血液型亜型は定義できました、たぶんそれらのコンテントID分野のそばでそれらについて言及して。 このアプローチが使用されていると、古い実現は新しい「副-タイプ」を認識しないでしょう、複合か混ぜられるとしてそれを扱って、その結果、認識される部品はユーザに見せることができるでしょう。
5.1.2. Handling Nested Messages and Multiparts
5.1.2. 取り扱いはメッセージとMultipartsを入れ子にしました。
The "message/rfc822" subtype defined in a subsequent section of this document has no terminating condition other than running out of data. Similarly, an improperly truncated "multipart" entity may not have any terminating boundary marker, and can turn up operationally due to mail system malfunctions.
このドキュメントのその後のセクションで定義された「メッセージ/rfc822」「副-タイプ」はデータを使い果たす以外の終わり状態を全く持っていません。 同様に、不適切に先端を切っている「複合」の実体は、どんな終わっている境界マーカーもないかもしれなくて、メールシステム異常のため操作上現れることができます。
It is essential that such entities be handled correctly when they are themselves imbedded inside of another "multipart" structure. MIME implementations are therefore required to recognize outer level boundary markers at ANY level of inner nesting. It is not sufficient to only check for the next expected marker or other terminating condition.
それらが自分たちで別の「複合」の構造の埋め込まれた内部であるときに、そのような実体が正しく扱われるのは、不可欠です。 したがって、MIME実現が、どんなレベルの内側の巣篭もりでも外側の平らな境界マーカーを見分けるのに必要です。 次の予想されたマーカーや他の終わり状態がないかどうかチェックするだけが十分ではありません。
5.1.3. Mixed Subtype
5.1.3. Mixed Subtype
The "mixed" subtype of "multipart" 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".
身体の部分が、独立していて、特定のオーダーに束ねられる必要があるとき、「複合」の「混ぜられた」「副-タイプ」は使用のために意図します。 「副-タイプ」の存在が「混入した」ので、実現が認識しないどんな「複合」の血液型亜型も扱わなければなりません。
5.1.4. Alternative Subtype
5.1.4. 代替のSubtype
The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body 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 references, 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
システムは、様々な部分の内容が交換可能であると認めるはずです。 システムはいくつかの場合ユーザ相互作用によるさえ地方の環境と参照に基づく「最も良い」タイプを選ぶはずです。 「複合か混ぜられる」のように、身体の部分の注文は重要です。 この場合、代替手段はオリジナルコンテンツへの増加する忠実の注文に現れます。 一般に
Freed & Borenstein Standards Track [Page 24] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[24ページ]。
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 a message in a fancy text format in such a way that it can easily be displayed anywhere:
例えば、「複合か代替」は容易にどこでもそれを表示できるような方法でメッセージを高級テキスト形式で送るのに使用されるかもしれません:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
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;、日付: 月曜日、1993年3月22日09:41:09 -0800(太平洋標準時の)のSubject: フォーマット済みのテキストメールMIMEバージョン: 1.0コンテントタイプ: 複合/代替手段。 境界=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
--boundary42コンテントタイプ: テキスト/平野。 charsetが私たちと等しい、-、ASCII
... plain text version of message goes here ...
… メッセージのプレーンテキストバージョンはここに行きます…
--boundary42
Content-Type: text/enriched
--boundary42コンテントタイプ: テキスト/豊かにされます。
... RFC 1896 text/enriched version of same message
goes here ...
... 同じメッセージのRFC1896のテキスト/豊かにされたバージョンはここに行きます…
--boundary42
Content-Type: application/x-whatever
--boundary42コンテントタイプ: すべてのアプリケーション/x
... fanciest version of same message goes here ...
… 同じメッセージの最も高級なバージョンはここに行きます…
--boundary42--
--boundary42--
In this example, users whose mail systems understood the "application/x-whatever" format would see only the fancy version, while other users would see only the enriched or plain text version, depending on the capabilities of their system.
この例では、メールシステムが「すべてのアプリケーション/x」形式を理解していたユーザは高級バージョンだけを見るでしょう、他のユーザが豊かにされるかプレーンテキストバージョンだけを見るでしょうが、それらのシステムの能力によって。
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つがタイプ「複合」がそれ自体であって、認識されていないサブの部品を含む場合では、ユーザエージェントは、その代替手段、以前の代替手段、または両方を示すのを選ぶかもしれません。
Freed & Borenstein Standards Track [Page 25] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[25ページ]。
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 viewer. While this approach does impose some burden on conformant MIME viewers, interoperability with older mail readers was deemed to be more important in this case.
以下に注意してください。 作成者の見解から、この注文を逆にして、最後に最も明瞭な代替手段を持っているのは、より分別があるように思えるかもしれません。 しかしながら、「複合か代替」の実体が非MIMEのconformantビューアーを使用することで見られるとき、最初に最も明瞭な代替手段を置くのは、可能な限り好意的なオプションです。 このアプローチがconformant MIMEビューアーに何らかの負担を課している間、より年取ったメール読者がいる相互運用性がこの場合より重要であると考えられました。
It may be the case that some user agents, if they can recognize more than one of the formats, will prefer to offer the user the choice of which format to view. This makes sense, for example, if a message 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.
彼らが形式の1つ以上を認識できると何人かのユーザエージェントが、選択をどの形式を見るかをユーザに提供するのを好むのは、事実であるかもしれません。 例えば、メッセージがうまくフォーマットされたイメージバージョンと容易に編集されたテキストバージョンの両方を含んでいるなら、これは理解できます。 しかしながら、最も批判的なことは同じデータの複数のバージョンが自動的にユーザに示されないということです。 ユーザに最後に認識されたバージョンを示すべきであるか、または選択を与えるべきです。
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. And when the information content is identical -- for example, where several parts of type "message/external-body" specify alternate ways to access the identical data -- the same Content-ID field value should be used, to optimize any caching mechanisms that might be present on the recipient's end. However, 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分野価値は、受取人の方に存在するかもしれないメカニズムをキャッシュしながらいずれも最適化するのに使用されるべきです。 しかしながら、部品によって使用されるコンテントID値は全体で「複合か代替」について説明するのと同じコンテントID値であるべきではありません、何かそのようなコンテントID分野があれば。 すなわち、1つのコンテントID値が「複合か代替」の実体について言及するでしょう、他の1つ以上のコンテントID値がそれの中の部品について言及するでしょうが。
5.1.5. Digest Subtype
5.1.5. ダイジェストSubtype
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と主に互換性がある(引用コンベンションを除いた)より読み込み可能なダイジェスト形式を許容するためにこれをします。
Note: Though it is possible to specify a Content-Type value for a body part in a digest which is other than "message/rfc822", such as a "text/plain" part containing a description of the material in the
以下に注意してください。 ダイジェストの身体の部分にコンテントタイプ値を指定するのが可能ですが、どれに、「テキスト/平野」などの「メッセージ/rfc822」を除いて、材料の記述を含む部分があるか。
Freed & Borenstein Standards Track [Page 26] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[26ページ]。
digest, actually doing so is undesireble. The "multipart/digest" Content-Type is intended to be used to send collections of messages. If a "text/plain" part is needed, it should be included as a seperate part of a "multipart/mixed" message.
読みこなしてください、そして、実際にそうするのは、undesirebleです。 メッセージの収集を送るのに「複合/ダイジェスト」コンテントタイプが使用されることを意図します。 「テキスト/明瞭な」部分が必要であるなら、それは「複合か混ぜられた」メッセージのseperate部分として含まれるべきです。
A digest in this format might, then, look something like this:
次に、この形式のダイジェストはこのように見えるかもしれません:
From: Moderator-Address
To: Recipient-List
Date: Mon, 22 Mar 1994 13:34:51 +0000
Subject: Internet Digest, volume 42
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="---- main boundary ----"
From: 議長アドレスTo: 受取人リスト日付: 月曜日、1994年3月22日の13:34:51+0000Subject: インターネットDigest、第42巻のMIMEバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 「境界=」---- 主な境界----"
------ main boundary ----
------ 主な境界----
...Introductory text or table of contents...
...紹介しているテキストか目次…
------ main boundary ----
Content-Type: multipart/digest;
boundary="---- next message ----"
------ 主な境界---- コンテントタイプ: 複合/ダイジェスト。 「境界=」---- 次のメッセージ----"
------ next message ----
------ 次のメッセージ----
From: someone-else
Date: Fri, 26 Mar 1993 11:13:32 +0200
Subject: my opinion
From: 他の誰か、日付: 金曜日、1993年3月26日の11:13:32+0200Subject: 私の意見
...body goes here ...
...ボディーはここに行きます…
------ next message ----
------ 次のメッセージ----
From: someone-else-again
Date: Fri, 26 Mar 1993 10:07:13 -0500
Subject: my different opinion
From: だれか、ほか、再び、日付: 金曜日、1993年3月26日の10:07:13 -0500Subject: 私の異なった意見
... another body goes here ...
… 別のボディーはここに行きます…
------ next message ------
------ 次のメッセージ------
------ main boundary ------
------ 主な境界------
5.1.6. Parallel Subtype
5.1.6. 平行なSubtype
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,
このドキュメントは「複合」のコンテントタイプの「平行な」「副-タイプ」を定義します。 このタイプはシンタクス上「複合か混ぜられること」と同じですが、意味論は異なっています。 特に
Freed & Borenstein Standards Track [Page 27] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[27ページ]。
in a parallel entity, the order of body parts is not significant.
平行な実体では、身体の部分の注文は重要ではありません。
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.
このタイプの一般的なプレゼンテーションは同時にそうすることができるハードウェアとソフトウェアの上に部品をすべて、表示することです。 しかしながら、エージェントを構成するのは多くのメール読者がこの能力を欠いて、順次とにかく部品を見せるのを意識しているべきです。
5.1.7. Other Multipart Subtypes
5.1.7. 他の複合血液型亜型
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実現は「複合か混ぜられること」に同等であるとして「複合」の認識されていない血液型亜型を扱わなければなりません。
5.2. Message Media Type
5.2. メッセージメディアタイプ
It is frequently desirable, in sending mail, to encapsulate another mail message. A special media type, "message", is defined to facilitate this. In particular, the "rfc822" subtype of "message" is used to encapsulate RFC 822 messages.
それは、別のメール・メッセージを要約するために送付メールで頻繁に望ましいです。 「メッセージ」という特別なメディアタイプは、これを容易にするために定義されます。 特に、「メッセージ」の"rfc822"「副-タイプ」は、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」の第二部が進められたか拒絶されたメッセージであるので、進められて拒絶されたメッセージを扱うことができます。 拒絶を構成して、メッセージを転送するのは、この様にオリジナルのメッセージのタイプ情報を保存して、それが正しく受取人に提示されるのを許容して、したがって、強く奨励されます。
Subtypes of "message" often impose restrictions on what encodings are allowed. These restrictions are described in conjunction with each specific subtype.
「メッセージ」の血液型亜型はしばしばencodingsが許容されていることに制限を課します。 これらの制限はそれぞれの特定の「副-タイプ」に関連して説明されます。
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. These operations are explicitly forbidden for the encapsulated headers embedded in the bodies of messages of type "message."
メール・ゲートウェイ、リレー、および他のメール取り扱いエージェントがRFC822メッセージのトップレベルヘッダーを変更するのが一般的に知られています。 彼らが、頻繁に特に取り外すように言い足す、または、追加注文ヘッダーフィールド。 これらの操作はタイプ「メッセージ」に関するメッセージのボディーを埋め込まれた要約のヘッダーのために明らかに禁じられます。
5.2.1. RFC822 Subtype
5.2.1. RFC822 Subtype
A media 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, the restriction that each "message/rfc822" body must include a "From", "Date", and at least one destination header is removed and replaced with the requirement that at least one of "From", "Subject", or "Date" must be present.
「メッセージ/rfc822」のメディアタイプは、ボディーが要約のメッセージを含むのを示します、RFC822メッセージの構文で。 しかしながら、トップレベルRFC822メッセージと異なって、それぞれの「メッセージ/rfc822」ボディーが“From"、「日付」、および少なくとも1個の目的地ヘッダーを含まなければならないという制限を少なくとも“From"の1つ、「対象」、または「日付」が存在していなければならないという要件に移して、取り替えます。
Freed & Borenstein Standards Track [Page 28] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[28ページ]。
It should be noted that, despite the use of the numbers "822", a "message/rfc822" entity isn't restricted to material in strict conformance to RFC822, nor are the semantics of "message/rfc822" objects restricted to the semantics defined in RFC822. More specifically, a "message/rfc822" message could well be a News article or a MIME message.
数「822」の使用にもかかわらず、「メッセージ/rfc822」実体がRFC822への厳しい順応では材料に制限されないことに注意されるべきであり、「メッセージ/rfc822」オブジェクトの意味論はRFC822で定義された意味論に制限されません。 より明確に、「メッセージ/rfc822」メッセージは、News記事かたぶんMIMEメッセージでしょう。
No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. 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-US-ASCII text in the headers of an encapsulated message can be specified using the mechanisms described in RFC 2047.
「7ビット」、「8ビット」、または「バイナリー」以外のコード化は「メッセージ/rfc822」実体のボディーのために受入れられません。 どのような場合でも、いつもメッセージヘッダーフィールドは米国-ASCIIです、そして、まだボディーの中のデータをコード化できます、そして、その場合、カプセル化されたメッセージのContent転送コード化ヘッダーフィールドはこれを反映するでしょう。 RFC2047で説明されたメカニズムを使用することでカプセル化されたメッセージのヘッダーの非米国のASCIIテキストを指定できます。
5.2.2. Partial Subtype
5.2.2. 部分的なSubtype
The "partial" subtype is defined to allow large entities to be delivered as several separate pieces of mail and automatically reassembled by a receiving user agent. (The concept is similar to IP fragmentation and 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. The media type "message/partial" thus indicates that the body contains a fragment of a larger entity.
「部分的な」「副-タイプ」は、大きい実体が数個の別々のメールとして提供されて、受信ユーザエージェントによって自動的に組み立て直されるのを許容するために定義されます。 (概念は基本的なインターネットプロトコルにおいてIP断片化と再アセンブリと同様です。) 中間的輸送エージェントが送ることができる個々のメッセージのサイズを制限するとき、このメカニズムを使用できます。 メディアがタイプされる、「メッセージ/部分的である、」 その結果、ボディーが、より大きい実体の断片を含むのを示します。
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 8bit transport. The problem is that the binary data would be split into multiple "message/partial" messages, each of them requiring binary transport. If such messages were encountered at a gateway into a 7bit transport environment, there would be no way to properly encode them for the 7bit world, aside from waiting for all of the fragments, reassembling the inner message, and then encoding the reassembled data in base64 or quoted-printable. Since it is possible that different fragments might go through different gateways, even this is not an acceptable solution. For this reason, it is specified that entities of type "message/partial" must always have a content- transfer-encoding of 7bit (the default). In particular, even in environments that support binary or 8bit transport, the use of a content- transfer-encoding of "8bit" or "binary" is explicitly prohibited for MIME entities of type "message/partial". This in turn implies that the inner message must not use "8bit" or "binary" encoding.
タイプ「メッセージ」のデータがbase64でコード化されているか、または引用されて決して印刷可能でないかもしれないので、「メッセージ/部分的な」実体がバイナリーか8ビットが輸送であるとサポートする環境で構成されるなら、問題は起こるかもしれません。 問題はバイナリ・データが複数の「メッセージ/部分的な」メッセージに分けられるだろうということです。(それらのそれぞれはメッセージのために2進の輸送を必要とすることです)。 そのようなメッセージがゲートウェイで7ビットの輸送環境に遭遇するなら、断片のすべてを待っていて、内側のメッセージを組み立て直して、次に、base64の組み立て直されたデータをコード化することは別として世界的で噛み付いているか引用されて印刷可能な7のために適切にそれらをコード化する方法が全くないでしょうに。 異なった断片が異なったゲートウェイを通るのが、可能であるので、これさえ許容できるソリューションではありません。 この理由として、aがタイプの「メッセージ/部分的な」必須の実体で7ビット(デフォルト)の転送コード化をいつも満足させると指定されます。 バイナリーか8ビットが輸送、内容の使用であるとサポートする環境でさえ「8ビット」か「バイナリー」の転送コード化はタイプのMIME実体のために明らかに禁止されています。「メッセージ/部分的です」。 これは、内側のメッセージが「8ビット」か「2進」のコード化を使用してはいけないのを順番に含意します。
Freed & Borenstein Standards Track [Page 29] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[29ページ]。
Because some message transfer agents may choose to automatically fragment large messages, and because such agents may use very 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.
いくつかのメッセージ転送エージェントが、自動的に大きいメッセージを断片化するのを選ぶかもしれなくて、そのようなエージェントが非常に異なった断片化敷居を使用するかもしれないので、部分的なメッセージの断片が、再アセンブリで自分たちが部分的なメッセージを包括すると立証するのは、可能です。 これは明らかに受入れられます。
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 fragments 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 in RFC 2045.) The second, "number", an integer, is the fragment number, which indicates where this fragment fits into the sequence of fragments. The third, "total", another integer, is the total number of fragments. This third subfield is required on the final fragment, and is optional (though encouraged) on the earlier fragments. Note also that these parameters may be given in any order.
コンテントタイプがさばくタイプの指定されたコネが「メッセージ/部分的であった」なら、3つのパラメタはそうしなければなりません: 「イド」という1番目は、可能であるとしての世界ユニークな識別子の近くように断片を一緒に合わせるのに使用されるためにはユニークな識別子です。 (一般に、識別子は本質的にはメッセージイドです; 二重引用符に置かれるなら、それはどんなメッセージイドであるかもしれません、RFC2045で与えられた「パラメタ」のためのBNFによると。) 2番目(「数」、整数)は断片番号です。(その番号は、この断片がどこに断片の系列に収まるかを示します)。 3(「合計」、別の整数)番目は断片の総数です。 この3番目の部分体は、最終的な断片の上に必要であり、以前の断片で任意です(奨励されますが)。 また、これらのパラメタが順不同に与えられるかもしれないことに注意してください。
Thus, the second piece of a 3-piece 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 the third piece MUST specify the total number of fragments:
しかし、3番目の断片は断片の総数を指定しなければなりません:
Content-Type: Message/Partial; number=3; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
コンテントタイプ: メッセージ/部分的。 数=3。 =3を合計してください。 イド=「oc= jpbe0M2Yt4s@thumper.bellcore.com 」
Note that fragment numbering begins with 1, not 0.
0ではなく付番が1で始めるその断片に注意してください。
When the fragments of an entity broken up in this manner are put together, the result is always a complete MIME entity, which may have its own Content-Type header field, and thus may contain any other data type.
終えられた実体の断片がこの様に組み立てられるとき、いつも結果は完全なMIME実体です。(その実体は、それ自身のコンテントタイプヘッダーフィールドを持って、その結果、いかなる他のデータ型も含むかもしれません)。
5.2.2.1. Message Fragmentation and Reassembly
5.2.2.1. メッセージ断片化と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
組み立て直された部分的なメッセージの意味論はメッセージが内側のメッセージを含むのについてというよりむしろ「内側」のメッセージのものであるに違いありません。 これでいくつかの部分的なメッセージとして大きいオーディオメッセージを送って、簡単なオーディオメッセージとして受取人にとってまだむしろ現れさせているのが例えば、可能になる、要約
Freed & Borenstein Standards Track [Page 30] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[30ページ]。
message containing an audio message. That is, the encapsulation of the message is considered to be "transparent".
オーディオメッセージを含むメッセージ。 すなわち、メッセージのカプセル化が「透明である」と考えられます。
When generating and reassembling the pieces 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) Fragmentation agents must split messages at line
boundaries only. This restriction is imposed because
splits at points other than the ends of lines in turn
depends on message transports being able to preserve
the semantics of messages that don't end with a CRLF
sequence. Many transports are incapable of preserving
such semantics.
(1) 断片化エージェントは系列境界だけでメッセージを分けなければなりません。 行の終わり以外のポイントでの股割りが順番にCRLF系列で終わらないメッセージの意味論を保存できるメッセージ転送によるので、この制限は課されます。 多くの輸送はそのような意味論を保存できません。
(2) All of the header fields from the initial enclosing
message, except those that start with "Content-" and
the specific header fields "Subject", "Message-ID",
"Encrypted", and "MIME-Version", must be copied, in
order, to the new message.
(2) 「Message ID」という「内容」と特定のヘッダーフィールド「対象」との始めが「暗号化した」もの以外の初期の同封メッセージからのヘッダーフィールドのすべて、および「MIMEバージョン」をコピーしなければなりません、オーダーで、新しいメッセージに。
(3) The header fields in the enclosed message which start
with "Content-", plus the "Subject", "Message-ID",
"Encrypted", and "MIME-Version" fields, 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 the
"Subject", "Message-ID", "Encrypted", and "MIME-
Version" fields) will be ignored and dropped.
(3) 同封のメッセージの「Message ID」という「内容」、および「対象」との始めが「暗号化した」ヘッダーフィールド、および「MIMEバージョン」野原を追加しなければなりません、オーダーで、新しいメッセージのヘッダーフィールドに。 同封のメッセージの「内容」(「対象」、「Message ID」、「暗号化された」、および「MIMEバージョン」分野を除いた)から始まらないどんなヘッダーフィールドも、無視されて、下げられるでしょう。
(4) All of the header fields from the second and any
subsequent enclosing messages are discarded by the
reassembly process.
(4) 2番目からのヘッダーフィールドとどんなその後の同封メッセージのすべても再アセンブリプロセスによって捨てられます。
5.2.2.2. Fragmentation and Reassembly Example
5.2.2.2. 断片化とReassemblyの例
If an audio message is broken into two pieces, the first piece might look something like this:
2つの断片がオーディオメッセージに細かく分けられるなら、最初の断片はこのように見えるかもしれません:
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 1 of 2)
Message-ID: <id1@host.com>
MIME-Version: 1.0
Content-type: message/partial; id="ABC@host.com";
X奇妙なヘッダー1: Foo From: Bill@host.com To: joe@otherhost.com 日付: 金曜日、1993年3月26日12:59:38 -0500(米国東部標準時の)のSubject: オーディオメール(2の第1部)メッセージID: <id1@host.com>MIMEバージョン: 1.0文書内容: メッセージ/部分的。 イドは" ABC@host.com "と等しいです。
Freed & Borenstein Standards Track [Page 31] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[31ページ]。
number=1; total=2
数=1。 =2を合計してください。
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID: <anotherid@foo.com>
Subject: Audio mail
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
X奇妙なヘッダー1: X奇妙なヘッダー2を禁じてください: こんにちは、Message ID: <anotherid@foo.com>Subject: オーディオメール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
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 2 of 2)
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 日付: 金曜日、1993年3月26日12:59:38 -0500(米国東部標準時の)のSubject: オーディオメール(2の第2部)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
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
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 日付: 金曜日、1993年3月26日12:59:38 -0500(米国東部標準時の)の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 ...
… コード化されたオーディオデータの前半はここへ去ります… … コード化されたオーディオデータの後半はここへ去ります…
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-イドがそうする参照がそれを読者に郵送するのに有益であるという断片化しているメッセージのその後の断片は、参照を理解して、追跡します。 しかしながら、そのような「参照」分野の世代は完全に任意です。
Freed & Borenstein Standards Track [Page 32] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[32ページ]。
Finally, it should be noted that the "Encrypted" header field has been made obsolete by Privacy Enhanced Messaging (PEM) [RFC-1421, RFC-1422, RFC-1423, RFC-1424], but the rules above are nevertheless 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)[RFC-1421、RFC-1422、RFC-1423、RFC-1424]によって時代遅れにされたことに注意されるべきですが、それにもかかわらず、変換の文脈で断片と、そして、「メッセージ/部分的な」断片から遭遇するなら、上の規則がそれを扱う適度の方法を述べると信じられています。
5.2.3. External-Body Subtype
5.2.3. 外部のボディーSubtype
The external-body subtype indicates that the actual body data are not included, but merely referenced. In this case, the parameters describe a mechanism for accessing the external data.
外部のボディー「副-タイプ」は、実際のボディーデータが含まれていませんが、単に参照をつけられるのを示します。 この場合、パラメタは、外部のデータにアクセスするためにメカニズムについて説明します。
When a MIME 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:
タイプにはMIME実体があるとき、「外部のメッセージ/ボディー」であり、それはカプセル化されたメッセージのためのヘッダー、2連続したCRLFs、およびメッセージヘッダーから成ります。 連続したCRLFsのもう1組が現れるなら、これはもちろんカプセル化されたメッセージのためのメッセージヘッダーを終わらせます。 しかしながら、カプセル化されたメッセージのボディーがそれ自体で外部であるので、その領域では、それが続くように見えません。 例えば、以下のメッセージを考えてください:
Content-type: message/external-body;
access-type=local-file;
name="/u/nsb/Me.jpeg"
文書内容: 外部のメッセージ/ボディー。 アクセス型はローカルファイルと等しいです。 名前=「/u/nsb/Me.jpeg」
Content-type: image/jpeg
Content-ID: <id42@guppylake.bellcore.com>
Content-Transfer-Encoding: binary
文書内容: イメージ/jpegコンテントID: <のid42@guppylake.bellcore.comの>の満足している転送コード化: バイナリー
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". The only access-type defined in this document that uses the phantom body is "mail-server", but other access-types may be defined in the future in other specifications that use this area.
終わりの領域はほとんどの外部のボディーメッセージのために無視されます。(終わりは「幻影のボディー」と呼ばれるかもしれません)。 しかしながら、それはそのようないくつかのメッセージのための補助の情報を含むのに使用されるかもしれません、本当にアクセス型が「メールサーバ」である時であるときに。 幻影のボディーを使用する本書では定義された唯一のアクセス型が「メールサーバ」ですが、他のアクセス型は将来、この領域を使用する他の仕様に基づき定義されるかもしれません。
The encapsulated headers in ALL "message/external-body" entities MUST include a Content-ID header field to give a unique identifier by which to reference the data. This identifier may be used for caching mechanisms, and for recognizing the receipt of the data when the access-type is "mail-server".
すべての「外部のメッセージ/ボディー」実体におけるカプセル化されたヘッダーは、データに参照をつけるユニークな識別子を与えるためにコンテントIDヘッダーフィールドを入れなければなりません。 この識別子は、アクセス型が「メールサーバ」であるときにメカニズムをキャッシュして、データの領収書を認識するのに使用されるかもしれません。
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.
ファイル名やメールサーバコマンドなどの外部のボディーデータについて説明するトークンが米国-ASCII文字の組にはあるのにここで指定されるとして必要であることに注意してください。
Freed & Borenstein Standards Track [Page 33] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[33ページ]。
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.
これが実際には問題が多いと判明するなら、新しいメカニズムはMIMEへの今後の拡大、「外部のメッセージ/ボディー」のための新たに定義されたアクセス型またはある他のメカニズムによって必要とされるかもしれません。
As with "message/partial", MIME entities of type "message/external- body" MUST have a content-transfer-encoding of 7bit (the default). In particular, even in environments that support binary or 8bit transport, the use of a content- transfer-encoding of "8bit" or "binary" is explicitly prohibited for entities of type "message/external-body".
タイプの「メッセージ/部分的な」MIME実体なら、「メッセージ/外部のボディー」には、7の満足している転送コード化ビット(デフォルト)がなければなりません。 バイナリーか8ビットが輸送、内容の使用であるとサポートする環境でさえ、「8ビット」か「バイナリー」の転送コード化はタイプの実体のために明らかに「外部のメッセージ/ボディー」で禁止されています。
5.2.3.1. General External-Body Parameters
5.2.3.1. 一般外部のボディーパラメタ
The parameters that may be used with any "message/external- body" are:
どんな「メッセージ/外部のボディー」と共にも使用されるかもしれないパラメタは以下の通りです。
(1) ACCESS-TYPE -- A word indicating the supported access
mechanism by which the file or data may be obtained.
This word is not case sensitive. Values include, but
are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL-
FILE", and "MAIL-SERVER". Future values, except for
experimental values beginning with "X-", must be
registered with IANA, as described in RFC 2048.
This parameter is unconditionally mandatory and MUST be
present on EVERY "message/external-body".
(1)ACCESS-TYPE--ファイルかデータが入手されるかもしれないサポートしているアクセス機構を示す単語。 この単語は大文字と小文字を区別していません。 含んでいますが、値が制限されない、「FTP」、「やがて、-、FTP、」、"TFTP"、「ローカルのファイル」、および「メールサーバ。」 「X」と共に始まる実験値を除いて、RFC2048で説明されるようにIANAに将来価値を登録しなければなりません。 このパラメタは、無条件に義務的であり、EVERY「外部のメッセージ/ボディー」に存在していなければなりません。
(2) 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. This parameter may be
used with ANY access-type and is ALWAYS optional.
(2)EXPIRATION--外部のデータの存在が保証されない日付(RFC822「日付-時間」構文年の分野の4ケタを可能にするためにRFC1123によって広げられるように)。 このパラメタは、どんなアクセス型でも使用されるかもしれなくて、ALWAYS任意です。
(3) 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. This parameter
may be used with ANY access-type and is ALWAYS
optional.
(3)SIZE--データのサイズ(八重奏における)。 このパラメタの意図は受取人が、外部のデータを検索するために必要なリソースを費やすかどうか決めるのを助けることです。 これが標準形のデータのサイズについて説明することに注意してください、どんなContent転送コード化も適用される前かすなわち、データが解読された後に。 このパラメタは、どんなアクセス型でも使用されるかもしれなくて、ALWAYS任意です。
(4) 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",
(4)PERMISSION--また、クライアントが、データを上書きするのを試みるかもしれないと予想されるかどうかを示す大文字と小文字を区別しない分野。 デフォルトでか許可が「読んでください」であるなら、仮定はそれらがそうでなく、またデータが一度検索されるなら、それは二度と必要でないということです。 PERMISSIONがそうであるなら「-読まれて、書いてください」
Freed & Borenstein Standards Track [Page 34] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[34ページ]。
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. This
parameter may be used with ANY access-type and is
ALWAYS optional.
この仮定は無効です、そして、キャッシュだけであるとどんな地方のコピーも考えなければなりません。 「読んでください」と「読まれて、書いてください」は許可の唯一の定義された値です。 このパラメタは、どんなアクセス型でも使用されるかもしれなくて、ALWAYS任意です。
The precise semantics of the access-types defined here are described in the sections that follow.
ここで定義されたアクセス型の正確な意味論は従うセクションで説明されます。
5.2.3.2. The 'ftp' and 'tftp' Access-Types
5.2.3.2. '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[RFC783]プロトコルを使用するのにおいてアクセスしやすいのを示します。 これらのアクセス型にとって、以下の追加パラメタは義務的です:
(1) NAME -- The name of the file that contains the actual
body data.
(1)NAME--実際のボディーデータを含むファイルの名前。
(2) 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.
(2)SITE--与えられたプロトコルを使用して、ファイルが入手されるかもしれないマシン。 これはあだ名ではなく、完全修飾ドメイン名であるに違いありません。
(3) 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.
(3) FTPを使用して、どんなデータも検索される前に、一般に、ユーザは、サイトパラメタによって指定されたマシンのためのログインイドとパスワードを提供するように頼まれる必要があるでしょう。 安全保障上の理由で、そのようなイドとパスワードをcontent typeパラメタとして指定しませんが、ユーザから得なければなりません。
In addition, the following parameters are optional:
さらに、以下のパラメタは任意です:
(1) DIRECTORY -- A directory from which the data named by
NAME should be retrieved.
(1)ディレクトリ--NAMEによって指定されたデータが検索されるべきであるディレクトリ。
(2) MODE -- A case-insensitive string indicating the mode
to be used when retrieving the information. The valid
values for access-type "TFTP" are "NETASCII", "OCTET",
and "MAIL", as specified by the TFTP protocol [RFC-
783]. The valid values for access-type "FTP" are
"ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
decimal integer, typically 8. These correspond to the
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 and 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.
(2)MODE--情報を検索するとき、使用されるためにモードを示す大文字と小文字を区別しないストリング。 アクセス型"TFTP"のための有効値は、TFTPプロトコル[RFC783]による"NETASCII"と、「八重奏」と、指定されるとして「メール」です。 アクセス型「FTP」のための有効値は、通常、「n」が10進整数、8である「ASCII」と、"EBCDIC"と、「イメージ」と、"LOCALn"です。 これらは表現タイプ指定されるとしてのFTPによる「私」と「L n」が議定書の中で述べる「E」[RFC-959]に対応しています。 「バイナリー」と"TENEX"がそのモードと「八重奏」か「イメージ」のための有効値でない「LOCAL8"は代わりに使用されるべきである」と述べてください。 MODEが指定されないなら、そうでなければ、デフォルト値は、TFTPのための"NETASCII"と「ASCII」です。
Freed & Borenstein Standards Track [Page 35] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[35ページ]。
5.2.3.3. The 'anon-ftp' Access-Type
5.2.3.3. 'やがて、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 mail address.
"ftp"アクセス型にとって、「やがて、ftpな」アクセス型は同じです、ユーザが指定されたサイトのための名前とパスワードを提供するように頼まれる必要はないのを除いて。 代わりに、ftpプロトコルは、ログインが「匿名」で使用されていてユーザの郵便の宛先に対応するパスワードになるでしょう。
5.2.3.4. The 'local-file' Access-Type
5.2.3.4. 'ローカルファイル'アクセス型
An access-type of "local-file" indicates that the actual body is accessible as a file on the local machine. Two additional parameters are defined for this access type:
「ローカルファイル」のアクセス型は、実際のボディーが地方のマシンのファイルとしてアクセスしやすいのを示します。 2つの追加パラメタがこのアクセス型のために定義されます:
(1) NAME -- The name of the file that contains the actual
body data. This parameter is mandatory for the
"local-file" access-type.
(1)NAME--実際のボディーデータを含むファイルの名前。 このパラメタは「ローカルファイル」アクセス型に義務的です。
(2) SITE -- A domain specifier for a machine or set of
machines that are known to have access to the data
file. This optional parameter is 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.
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.
(2)SITE--データファイルに近づく手段を持っているのが知られているマシンのマシンかセットのためのドメイン特許説明書の作成書。 この任意のパラメタは、すなわち、ファイルが目に見えると予想されるデータの参照の場所、サイトまたはサイトについて説明するのに使用されます。 ただ一つのアスタリスクをゆったり過ごします。「アスタリスクはワイルドカードマッチングにドメイン名の一部まで使用されるかもしれません、」 *.bellcore.comなどのように」一般に利用可能であると予想されるファイルを示すのに使用されるかもしれません、データが直接目に見えるべきである1セットのマシンを示してください、そして、例えば、グローバルなファイルシステムで。
5.2.3.5. The 'mail-server' Access-Type
5.2.3.5. 'メールサーバ'アクセス型
The "mail-server" access-type indicates that the actual body is available from a mail server. Two additional parameters are defined for this access-type:
「メールサーバ」アクセス型は、実際のボディーがメールサーバから利用可能であることを示します。2つの追加パラメタがこのアクセス型のために定義されます:
(1) SERVER -- The addr-spec of the mail server from which
the actual body data can be obtained. This parameter
is mandatory for the "mail-server" access-type.
(1)SERVER--実際のボディーデータを得ることができるメールサーバのaddr-仕様。 このパラメタは「メールサーバ」アクセス型に義務的です。
(2) 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. This is an optional
parameter.
(2)SUBJECT--データを得るために送られるメールで使用されることになっている対象。 メールサーバをSubject系列に合わせるのが推薦されませんが、そのようなメールサーバが存在するのが知られていることに注意してください。 これは任意のパラメタです。
Freed & Borenstein Standards Track [Page 36] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[36ページ]。
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 in the content-type header field. Instead, it is provided as the "phantom body" when the media type is "message/external-body" and the access-type is mail-server.
メールサーバがさまざまな構文(それのいくつかがマルチラインである)を受け入れるので、メールサーバに送られるべき完全なコマンドはパラメタとしてcontent typeヘッダーフィールドに含まれていません。 代わりに、メディアがタイプされるとき、「幻影のボディー」が「外部のメッセージ/ボディー」であり、アクセス型がメールサーバであるので、それを提供します。
Note that MIME does not define a mail server syntax. Rather, it allows the inclusion of arbitrary mail server commands in the phantom body. Implementations must include the phantom body in the body of the message it sends to the mail server address to retrieve the relevant data.
MIMEがメールサーバ構文を定義しないことに注意してください。 むしろ、それは幻影のボディーでの任意のメールサーバコマンドの包含を許容します。 実装はそれが関連データを検索するためにメールサーバアドレスに送るメッセージ欄に幻影のボディーを含まなければなりません。
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 mail servers must use the same Content-ID field on the returned message that was used in the original "message/external-body" entities, to facilitate such matching.
他のアクセス型と異なって、メールサーバアクセスは、非同期であり、将来、予測できない時に起こるでしょう。 そこに、いてください。この理由で、それが重要である、それ、返されたデータがあることができるメカニズムはオリジナルの「外部のメッセージ/ボディー」実体に合いました。 MIMEメールサーバはそのようなマッチングを容易にするのにオリジナルの「外部のメッセージ/ボディー」実体に使用された返されたメッセージの同じコンテントID分野を使用しなければなりません。
5.2.3.6. External-Body Security Issues
5.2.3.6. 外部のボディー安全保障問題
"Message/external-body" entities give rise to two important security issues:
「外部のメッセージ/ボディー」実体は2つの重要な安全保障問題をもたらします:
(1) Accessing data via a "message/external-body" reference
effectively results in the message recipient performing
an operation that was specified by the message
originator. It is therefore possible for the message
originator to trick a recipient into doing something
they would not have done otherwise. For example, an
originator could specify a action that attempts
retrieval of material that the recipient is not
authorized to obtain, causing the recipient to
unwittingly violate some security policy. For this
reason, user agents capable of resolving external
references must always take steps to describe the
action they are to take to the recipient and ask for
explicit permisssion prior to performing it.
(1) 「外部のメッセージ/ボディー」参照で有効にデータにアクセスするのはメッセージ創始者によって指定された操作を実行しているメッセージ受取人をもたらします。 したがって、メッセージ創始者が、受取人が彼らが別の方法でしていないことをするようにだますのは、可能です。 例えば、創始者は受取人が得るのは権限を与えられない材料の検索を試みる動作を指定できました、受取人が何らかの安全保障政策に知らず知らず違反することを引き起こして。 この理由で、外部参照を決議できるユーザエージェントは、それらが受取人に取ることになっている行動について説明して、それを実行する前に明白なpermisssionを求めるためにいつも手を打たなければなりません。
The 'mail-server' access-type is particularly
vulnerable, in that it causes the recipient to send a
new message whose contents are specified by the
original message's originator. Given the potential for
abuse, any such request messages that are constructed
should contain a clear indication that they were
generated automatically (e.g. in a Comments: header
field) in an attempt to resolve a MIME
'メールサーバ'アクセス型は特に被害を受け易いです、受取人がそれで、コンテンツがオリジナルのメッセージの創始者によって指定される新しいメッセージを送るので。 乱用の可能性を考えて、構成されるどんなそのような要求メッセージもそれらがMIMEを決議する試みで自動的に生成されたという(Comments: 例えば、ヘッダーフィールドで)明確な指示を含むべきです。
Freed & Borenstein Standards Track [Page 37] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[37ページ]。
"message/external-body" reference.
「外部のメッセージ/ボディー」参照。
(2) MIME will sometimes be used in environments that
provide some guarantee of message integrity and
authenticity. If present, such guarantees may apply
only to the actual direct content of messages -- they
may or may not apply to data accessed through MIME's
"message/external-body" mechanism. In particular, it
may be possible to subvert certain access mechanisms
even when the messaging system itself is secure.
(2) MIMEはメッセージの保全と信憑性の何らかの保証を提供する環境で時々使用されるでしょう。 存在しているなら、そのような保証はメッセージの実際のダイレクト内容だけに申請されるかもしれません--それらはMIMEの「外部のメッセージ/ボディー」メカニズムを通してアクセスされたデータに適用するかもしれません。 メッセージシステム自体が安全であるときにさえ、あるアクセス機構を打倒するのは特に、可能であるかもしれません。
It should be noted that this problem exists either with
or without the availabilty of MIME mechanisms. A
casual reference to an FTP site containing a document
in the text of a secure message brings up similar
issues -- the only difference is that MIME provides for
automatic retrieval of such material, and users may
place unwarranted trust is such automatic retrieval
mechanisms.
安全なメッセージのテキストにドキュメントを含むFTPサイトのカジュアルな参照は同様の問題を持って来ます--唯一の違いはMIMEがそのような材料の自動検索に備えて、ユーザが備えるかもしれないということです。この問題がavailabiltyもMIMEメカニズムのavailabiltyなしで存在することに注意されるべきです。場所の保証のない信頼はそのように自動回収機構です。
5.2.3.7. Examples and Further Explanations
5.2.3.7. 例とさらなる説明
When the external-body mechanism is used in conjunction with the "multipart/alternative" media type it extends the functionality of "multipart/alternative" to include the case where the same entity is provided in the same format but via different accces mechanisms. When this is done the originator of the message must order the parts first in terms of preferred formats and then by preferred access mechanisms. The recipient's viewer should then evaluate the list both in terms of format and access mechanisms.
外部のボディーメカニズムが「複合か代替」のメディアタイプに関連して使用されるとき、それは同じ実体が形式にもかかわらず、異なったacccesメカニズムで同じくらいに提供されるケースを含むためには「複合か代替」の機能性を広げています。これが完了していると、メッセージの創始者は最初に都合のよい形式とそして、都合のよいアクセス機構で部品を注文しなければなりません。次に、受取人のビューアーは形式とアクセス機構でリストを評価するべきです。
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 entities of type "message/external-body" within the body parts of an enclosing "multipart/alternative" entity.
非常に広い領域のファイルシステムの現れている可能性によると、あらかじめファイルがアクセス可能であり、直接ファイルシステムからアクセス可能にならないマシンのセットを知るのは非常に困難になります。 したがって、それはファイル名を両方に提供している、直接試みられるべき意味、およびファイルがアクセスしやすいのが知られている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.
しかしながら、メールサーバアクセス型によって示されるように検索をファイルするために外部のボディーメカニズムが制限されることを意図しません。 これを超えて、人は、例えば、外部参照にビデオクリップにビデオ・サーバを使用すると想像できます。
Freed & Borenstein Standards Track [Page 38] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[38ページ]。
The embedded message header fields which appear in the body of the "message/external-body" data must be used to declare the media type of the external body if it is anything other than plain US-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 an object in PostScript format, might look like this:
明瞭な米国-ASCIIテキストを除いて、メディアがそれが何かであるなら外部のボディーをタイプすると宣言するのに「外部のメッセージ/ボディー」データのボディーに現れる埋め込まれたメッセージヘッダーフィールドを使用しなければなりません、外部のボディーにはタイプを宣言するヘッダー部分がないので。 また、同様に、ここで「7ビット」を除いたどんなContent転送コード化も宣言しなければなりません。 したがって、ポストスクリプト形式でオブジェクトについて言及する場合、完全な「外部のメッセージ/ボディー」メッセージはこれに似るかもしれません:
From: Whomever
To: Someone
Date: Whenever
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"; mode="image";
access-type=ANON-FTP; directory="pub";
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; access-type=local-file;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
--42コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型はローカルファイルと等しいです。 「/u/nsb/writing/rfcs/RFC-MIME.ps」と=を命名してください。 サイトは"thumper.bellcore.com"と等しいです。 満了=「金曜日、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
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
--42コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型はメールサーバサーバ=" listserv@bogus.bitnet "と等しいです。 満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>
文書内容: アプリケーション/追伸コンテントID: <id42@guppylake.bellcore.com>。
get RFC-MIME.DOC
RFC-MIME.DOCを手に入れてください。
--42--
--42--
Freed & Borenstein Standards Track [Page 39] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[39ページ]。
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" media 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 and Subject fields are overridden, but the From field is preserved.
「メッセージ/部分的な」タイプのように、「外部のメッセージ/ボディー」メディアタイプが透明であることを意図して、そのタイプのボディーでメッセージを伝えるというよりむしろ外部のボディーでデータ型を伝えるために、それはいます。 したがって、「メッセージ/部分的」のように同じ規則を使用することで外側の、そして、内側の部品の上のヘッダーを合併しなければなりません。 特に、これは、文書内容とSubject分野が優越されますが、From分野が保持されることを意味します。
Note that since the external bodies are not transported along with the external body reference, they need not conform to transport limitations that apply to the reference itself. In particular, Internet mail transports may impose 7bit and line length limits, but these do not automatically apply to binary external body references. Thus a Content-Transfer-Encoding is not generally necessary, though it is permitted.
外部のボディーが外部のボディー参照と共に輸送されないのでそれらが参照自体に適用される制限を輸送するために従う必要はないことに注意してください。 特に、インターネット・メール輸送は7ビットと行長限界を課すかもしれませんが、これらは自動的に2進の外部のボディー参照に適用されません。 したがって、それは受入れられますが、一般に、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の最初の連続した組の前の何は特に、ヘッダー情報ですでも、それの後の何がボディー情報ですがも。(それは、ほとんどのアクセス型のために無視されます)。
5.2.4. Other Message Subtypes
5.2.4. 他のメッセージ血液型亜型
MIME implementations must in general treat unrecognized subtypes of "message" as being equivalent to "application/octet-stream".
一般に、MIME実装は「八重奏アプリケーション/ストリーム」に同等であるとして「メッセージ」の認識されていない血液型亜型を扱わなければなりません。
Future subtypes of "message" intended for use with email should be restricted to "7bit" encoding. A type other than "message" should be used if restriction to "7bit" is not possible.
メールがある使用のために意図する「メッセージ」の将来の血液型亜型は「7ビット」のコード化に制限されるべきです。 「7ビット」への制限が可能でないなら、「メッセージ」を除いたタイプは使用されるべきです。
6. Experimental Media Type Values
6. 実験メディアは値をタイプします。
A media type value beginning with the characters "X-" is a private value, to be used by consenting systems by mutual agreement. Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-". (Older versions of the widely used Andrew system use the "X- BE2" name, so new systems should probably choose a different name.)
キャラクタ「X」と共に始まるメディアタイプ価値は、相談ずくの同意システムによって使用されるためには個人的な値です。 「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. In many cases, a subtype of "application" will be more appropriate than a new top-level type.
一般に、「X」トップレベルタイプの使用は強くお勧めできないです。 可能であるときはいつも、作成者は既存のタイプの血液型亜型を発明するべきです。 多くの場合、「アプリケーション」の「副-タイプ」は新しいトップレベルタイプよりさらに適切になるでしょう。
Freed & Borenstein Standards Track [Page 40] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[40ページ]。
7. Summary
7. 概要
The five discrete media types provide provide a standardized mechanism for tagging entities as "audio", "image", or several other kinds of data. The composite "multipart" and "message" media types allow mixing and hierarchical structuring of entities of different types in a single message. 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 media types are defined for general use by consenting user agents, notably "message/partial" and "message/external-body".
離散的なメディアが提供するのをタイプする5は「オーディオ」、「イメージ」、または他の数種類のデータとして標準化されたメカニズムをタグ付け実体に提供します。 「複合」と「メッセージ」合成メディアタイプはただ一つのメッセージの異なったタイプの実体の混合と階層構造形成を許容します。 顕著なパラメタ構文はさらにデータの形式の詳細の仕様、特に代替の文字集合の仕様を許容します。 追加任意のヘッダーフィールドは望ましいと多くの作成者によって考えられたある拡大にメカニズムを提供します。 最終的に、多くの役に立つメディアタイプが、一般的使用のために同意しているユーザエージェントによって定義されるのと、著しく「メッセージ/部分的」、そして、「外部のメッセージ/ボディー。」です。
9. Security Considerations
9. セキュリティ問題
Security issues are discussed in the context of the "application/postscript" type, the "message/external-body" type, and in RFC 2048. Implementors should pay special attention to the security implications of any media types that can cause the remote execution of any actions in the recipient's environment. In such cases, the discussion of the "application/postscript" type may serve as a model for considering other media types with remote execution capabilities.
「アプリケーション/追伸」タイプ、「外部のメッセージ/ボディー」タイプの文脈とRFC2048で安全保障問題について議論します。 作成者は受取人の環境における、どんな動作のリモート実行も引き起こす場合があるどんなメディアタイプのセキュリティ含意に関する特別な注意も向けるべきです。 そのような場合、他のメディアを考えるためのモデルがリモート実行能力でタイプするように「アプリケーション/追伸」タイプの議論は役立つかもしれません。
Freed & Borenstein Standards Track [Page 41] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[41ページ]。
9. Authors' Addresses
9. 作者のアドレス
For more information, the authors of this document are best contacted via Internet mail:
詳しくは、インターネット・メールでこのドキュメントの作者に連絡するのは最も良いです:
Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA
ネッドは東ガーヴェーアベニューSouth West Innosoftの国際Inc.1050カリフォルニア91790コビーナ(米国)を解放しました。
Phone: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com
以下に電話をしてください。 +1 818 919、3600Fax: +1 3614年の818 919メール: ned@innosoft.com
Nathaniel S. Borenstein First Virtual Holdings 25 Washington Avenue Morristown, NJ 07960 USA
ナザニエルS.Borensteinファースト・バーチャル持ち株25ワシントン・Avenueニュージャージー07960モリスタウン(米国)
Phone: +1 201 540 8967 Fax: +1 201 993 3032 EMail: nsb@nsb.fv.com
以下に電話をしてください。 +1 201 540、8967Fax: +1 3032年の201 993メール: nsb@nsb.fv.com
MIME is a result of the work of the Internet Engineering Task Force Working Group on RFC 822 Extensions. The chairman of that group, Greg Vaudreuil, may be reached at:
MIMEはRFC822Extensionsへのインターネット・エンジニアリング・タスク・フォース作業部会の作業の結果です。 そのグループ、グレッグ・ボードルイの議長は以下で連絡されるかもしれません。
Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA
グレゴリーM.ボードルイのOctelネットワーク・サービス17080ダラスParkwayテキサス75248-1905ダラス(米国)
EMail: Greg.Vaudreuil@Octel.Com
メール: Greg.Vaudreuil@Octel.Com
Freed & Borenstein Standards Track [Page 42] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[42ページ]。
Appendix A -- Collected Grammar
付録A--集まっている文法
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 by name to several syntax rules that are defined by RFC 822. Rather than reproduce those definitions here, and risk unintentional differences between the two, this document simply refers the reader to RFC 822 for the remaining definitions. Wherever a term is undefined, it refers to the RFC 822 definition.
しかしながら、それ自体で、この文法は不完全です。 それは名前でRFC822によって定義されるいくつかのシンタックス・ルールを参照します。 むしろ、このドキュメントはここでそれらの定義を再生させて、2の意図的でない違いを危険にさらすより残っている定義について単にRFC822の読者を参照します。 用語が未定義である、それがRFC822定義を呼ぶどこ。
boundary := 0*69<bchars> bcharsnospace
境界:=0*69<bchars>bcharsnospace
bchars := bcharsnospace / " "
bchars:=bcharsnospace/、「」
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"
「bcharsnospace:=DIGIT/アルファー/、「'「」 /「」 (「/」)/「+」/"_"/」、/「-」/」。」' / "/" / ":" / "=" / "?"
body-part := <"message" as defined in RFC 822, with all
header fields optional, not starting with the
specified dash-boundary, and with the
delimiter not occurring anywhere in the
body part. Note that the semantics of a
part differ from the semantics of a message,
as described in the text.>
すべてのヘッダーフィールドが任意の状態で指定されたダッシュ境界から始まるのではなく、RFC822で定義される、およびデリミタが身体の部分で何処にも起こっていない身体部分:=<「メッセージ。」 . テキスト>で説明されるように部分の意味論がメッセージの意味論と異なっていることに注意してください。
close-delimiter := delimiter "--"
近いデリミタ:=デリミタ「--」
dash-boundary := "--" boundary
; boundary taken from the value of
; boundary parameter of the
; Content-Type field.
ダッシュ境界:=「--」境界。 境界、値から取る、。 境界パラメタ、。 コンテントタイプ分野。
delimiter := CRLF dash-boundary
デリミタ:=CRLFダッシュ限界
discard-text := *(*text CRLF)
; May be ignored or discarded.
テキストを捨てている:=*(*テキストCRLF)。 無視されるか捨てられるかもしれなくなってください。
encapsulation := delimiter transport-padding
CRLF body-part
輸送をそっと歩くカプセル化の:=デリミタCRLF身体部分
epilogue := discard-text
エピローグ:=、テキストを捨てます。
multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
輸送をそっと歩く複合ボディー:=[序文CRLF]ダッシュ境界CRLF身体部分*カプセル化
Freed & Borenstein Standards Track [Page 43] RFC 2046 Media Types November 1996
解放されるのとBorenstein規格は1996年11月にRFC2046メディアタイプを追跡します[43ページ]。
close-delimiter transport-padding
[CRLF epilogue]
近いデリミタ輸送詰め物[CRLFエピローグ]
preamble := discard-text
序文:=、テキストを捨てます。
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
輸送をそっと歩く:=*LWSP-炭。 作曲家、生成してはいけません。 非ゼロ・レングス輸送。 しかし、詰め物、受信機はそうしなければなりません。 詰め物を扱うことができてください。 メッセージ転送で、加えられます。
Freed & Borenstein Standards Track [Page 44]
解放されるのとBorenstein標準化過程[44ページ]
一覧
スポンサーリンク
