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.

このセクションは「multipart」のサブタイプのために共通の構文を定義します。「multipart」のすべてのサブタイプはこの構文を使わなければなりません。複数パートメッセージの単純な例はまたこのセクションに出ます。より複雑な複数パートメッセージの例はRFC 2049の中であげられます。

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.

複数パート実体のためのContent-Typeフィールドは1つのパラメータ、「バウンダリ」を必要としています。 バウンダリの区切り行はその時バウンダリパラメータ値がContent-Typeヘッダーフィールド、オプションの線形の空白、および終了CRLFから後に続く2つのハイフンキャラクタ(「-」、10進値45)からすべて成る行と定義されます。

Boundary delimiters must not appear within the encapsulated material, and must be no longer than 70 characters, not counting the two leading hyphens.

バウンダリデリミタはカプセル化した素材の中で出現してはならず、2つの主要なハイフンをカウントしないで70文字以上であってはなりません。

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つのハイフンの加算によって前の区切り行に同一です。

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.

最初のバウンダリの区切り行に先がけて付加情報と最終的なバウンダリの区切り行をたどることのための場所があるように思われます。これらのエリアは一般にブランクであるままにしておかれるべきであり、インプリメンテーションは、最初のバウンダリの区切り行の前または最後のものの後で出現する何でも無視しなければなりません。

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人、および暗黙にタイプされた彼らの1人))を持っています：

This is the epilogue. It is also to be ignored.

これはその末文です。それはまた、無視されることになっています。

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.

別の「multipart」実体の中のボディ部分の「multipart」のメディアタイプの使用は明示的に許されます。明らかな理由のためのそのような場合に、注意は、各入れ子にされた「multipart」実体が違うバウンダリデリミタを使うと保証するために払われなければなりません。入れ子にされた「multipart」実体の例のためにRFC 2049を見てください。

The use of the "multipart" media type with only a single body part may be useful in certain contexts, and is explicitly permitted.

1つのボディ部分だけを持つ「multipart」メディアタイプの使用は一定のコンテキストの中で有益であるかもしれず、明示的に許されます。

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:

「multipart」メディアタイプのための唯一の義務的なグローバルなパラメータはバウンダリパラメータです(メールゲートウェイを通して非常に頑強であると知られているキャラクタのセットと空白類によって終わっているNOTから、それは1から70文字から成ります)。 (バウンダリの区切り行が、空白類によって終わるようならば、空白類は、ゲートウェイによって追加されていると推定されなければならず、削除されなければなりません。)それは以下BNFによってフォーマルに指定されます：

Overall, the body of a "multipart" entity may be specified as follows:

全体に、「multipart」実体のボディは次の通り指定されるかもしれません：

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.

データを使い果たす以外、この文書のその後のセクションの中で定義された「message/rfc822」サブタイプは終了条件を全然持っていません。同様に、不適切に切り捨てられた「multipart」実体はどのような終了バウンダリマーカも持たないかもしれず、システム誤動作をメールするために操作上賦課金を見つけることができます。

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.

それらが自身で別の「multipart」構造の中に埋め込まれる時に、そのような実体が正しく処理されることは必須です。MIMEインプリメンテーションは、従って、内側のネスティングのANYレベルで外の水平のバウンダリマーカを認識するために必要とされています。次の予期されているマーカまたは他の終了条件をチェックするだけであることは十分でありません。

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".

ボディ部分が独立で、特定の注文の中でバンドルされる必要がある時に、「multipart」の「mixed(混ぜられる)」サブタイプは使用のために意図されています。インプリメンテーションが認識していないどのような「multipart」サブタイプでも、サブタイプ「mixed」をもっていることとみなされなければなりません。

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.

「multipart/alternative」タイプは「multipart/mixed」に統語的に同一であるけれども、意味論は違います。特に、ボディ部分のそれぞれは同じ情報の「代替の」バージョンです。

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 best choice is the LAST part of a type supported by the recipient system's local environment.

システムは、様々な部分の内容が交換可能であると認めるべきです。システムは場合によってはユーザインタラクションを通してさえローカルな環境とリファレンスに基づいた「最もよい」タイプを選ぶべきです。「multipart/mixed」と同様に、ボディ部分の注文は有意です。この場合に、オリジナルの内容に忠実さを増大させる注文の中で、ほかにとりうる方法は出現します。一般に、最良の選択は受領したシステムのローカルな環境によってサポートされたタイプの最後の部分です。

"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:

「Multipart/alternative」は、例えば、それが容易にどこででも表示されることができるそのような方法で装飾的なテキスト形式の中のメッセージを送信するために使われるかもしれません：

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.

この例において、メールシステムが「application/x-whatever」でもフォーマットを理解していたユーザは装飾的なバージョンだけを見るしょう。一方、他のユーザは、彼らのシステムの能力に依存して、豊かにされたか、普通テキストのバージョンだけを見るでしょう。

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.

一般に「multipart/alternative」実体を創作するユーザエージェントは、最後にボディ部分を、好みの順を増大させることに、すなわち好まれたフォーマットによって置かなければなりません。装飾的なテキストのために、送信ユーザエージェントは最後に最も平易なフォーマット一番目と最も豊かなフォーマットを置くべきです。受け取っているユーザエージェントは、彼らが、表示することが可能な最後のフォーマットを選び、表示するべきです。ほかにとりうる方法の1つが自身でタイプ「multipart」をもっていて、認められないサブ部分を含んでいるケースの中で、ユーザエージェントは、そのほかにとりうる方法、先のほかにとりうる方法、または両方を示すことに決めることができます。

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つ以上を認めることができるならば、どのフォーマットを見るかの選択をユーザに提供することを好むであろうのはそのケースであるかもしれません。メッセージがきちんとフォーマットされたイメージバージョンと容易に編集されたテキストバージョンの両方を含むならば、例えばこれは意味をなします。しかし、何がとても臨界であるかは、ユーザが自動的でないで同じデータの複数のバージョンを示されることです。ユーザは最後の認められているバージョンを示されるべきであるか、選択を与えられるべきです。

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.

この文書は「multipart」Content-Typeの「ダイジェスト」サブタイプを定義します。このタイプは「multipart/mixed」に統語的に同一であるけれども、意味論は違います。ダイジェストの特に中で、ボディ部分のためのデフォルトContent-Type値は「text/plain」から「message/rfc822」に変更されます。これは、主としてRFC 934によって互換の(引用規定を除いて)より読取り可能のダイジェストフォーマットを許すためにされます。

A digest in this format might, then, look something like this:

このフォーマットの中のダイジェストはするかもしれず、そして、このような何かのようであってください：

This document defines a "parallel" subtype of the "multipart" Content-Type. This type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, in a parallel entity, the order of body parts is not significant.

この文書は「multipart」Content-Typeの「並列の」サブタイプを定義します。このタイプは「multipart/mixed」に統語的に同一であるけれども、意味論は違います。並列の実体の特に中で、ボディ部分の注文は有意でありません。

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.

このタイプの共通のプレゼンテーションは、そうすることが可能なハードウェアとソフトウェアの上で同時に部分のすべてを表示することです。しかし、創作エージェントは、多くのメールリーダがこの能力を欠くであろうし、とにかく連続して部分を示すであろうということに気づいているべきです。

Other "multipart" subtypes are expected in the future. MIME implementations must in general treat unrecognized subtypes of "multipart" as being equivalent to "multipart/mixed".

他の「multipart」サブタイプは未来に予期されています。MIMEインプリメンテーションは一般に「multipart/mixed」と等しいこととして「multipart」の認められないサブタイプを扱わなければなりません。

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」サブタイプは、RFC 822メッセージをカプセル化するために使われます。

Subtypes of "message" often impose restrictions on what encodings are allowed. These restrictions are described in conjunction with each specific subtype.

「メッセージ」のサブタイプはしばしば、どんなエンコーディングが許されるかに制限を課します。これらの制限は各特定のサブタイプと連携して説明されます。

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."

メールゲートウェイ、リレー、およびエージェントを扱っている他のメールは、一般的に、RFC 822メッセージのトップレベルのヘッダーを変更すると知られています。特に、彼らは頻繁にヘッダーフィールドを追加し、削除するか、再注文します。これらの操作はタイプ「メッセージ」のメッセージのボディに埋め込まれたカプセル化したヘッダーのために明示的に禁じられます。

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.

「message/rfc822」のメディアタイプは、ボディがRFC 822メッセージのシンタックスによってカプセル化したメッセージを含んでいることを示します。トップレベルのRFC 822メッセージと違ってどのように、各「message/rfc822」が具体化する制限が「から」、「日付」、および少なくとも1つの宛先ヘッダーを含まなければならないかは、削除されて、「から」、「サブジェクト」、または「日付」の少なくとも1つが出席していなければならないという必要条件と置換されます。

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」の使用にもかかわらず、「message/rfc822」実体がRFC 822への厳密な対応における素材に限定されないことは注目されるべきですが、RFC 822において定義された意味論に限定された「message/rfc822」オブジェクトの意味論です。 より特に、「message/rfc822」メッセージはうまくニュース記事または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ビット」、または「2進です」以外のどのエンコーディングも「message/rfc822」実体のボディのために許されません。メッセージヘッダフィールドはいつもともかくUS-ASCIIであり、ボディの中のデータはまだ符号化されることができます(ケースの中で、カプセル化したメッセージの中のコンテンツ転送エンコーディングヘッダーフィールドがこれを反映するでしょう)。カプセル化したメッセージのヘッダーの中の非[Non-US]-ASCIIテキストは、RFC 2047の中で説明されたメカニズムを使って、指定されることができます。

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断片化と再アセンブリに類似しています。)中間の運送業者が、送られることができる個々のメッセージのサイズを制限する時に、このメカニズムは使われることができます。従って、メディアタイプ「message/partial」は、ボディがより大きな実体のフラグメントを含んでいることを示します。

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またはquoted-printableにおいて符号化されないかもしれないので、「message/partial」実体が、二進または8ビットのトランスポートをサポートする環境の中で構成されるならば、問題は生じるかもしれません。問題は、バイナリデータが、それらのそれぞれがバイナリのトランスポートを必要として、複数の「message/partial」メッセージに分割されるであろうということです。そのようなメッセージが7ビットのトランスポート環境の中にゲートウェイで遭遇されたならば、内側のメッセージを再集合し、それからBase64またはquoted-printableにおいて再集合されたデータを符号化して、フラグメントのすべてを待つことは別として7ビットの世界のために適切にそれらを符号化する方法が全然ないでしょう。違うフラグメントが違うゲートウェイを通してなるかもしれないのが可能なので、これさえ受入れ可能な解決策ではありません。この理由のために、タイプ「message/partial」の実体がいつも7ビット(デフォルト)のcontent-transfer-encodingを持たなければならないことは指定されます。特に、二進または8ビットのトランスポートをサポートする環境の中で、「8ビット」または「バイナリ」のコンテンツ転送エンコーディングの使用はタイプ「message/partial」のMIME実体のために明示的に禁止されています。 これは、内側のメッセージが「8ビット」または「バイナリ」コード化を使ってはならないことを次々暗示しています。

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つのパラメータがタイプmessage/partialのContent-Typeフィールドで指定されなければなりません：一番目、「ID」は、一緒にフラグメントとマッチするために使われるために可能な限り世界一意の名前に近い一意の名前です。(一般に、識別子は本質的にmessage-idです;二重引用符に置かれるならば、それはRFC 2045の中で与えられた「パラメータ」のためのBNFに従って少しmessage-idであるかもしれません。)2番目のThe、「数」、整数はフラグメント番号です(それは、どこでこのフラグメントがフラグメントのシーケンスに納まるかを示します)。3番目、「全部です」、別の整数は、フラグメントの総数です。この3番目のサブフィールドは最終的なフラグメントの上で必要とされていて、より早いフラグメントの上でオプションです(奨励されるけれども)。これらのパラメータがどのような注文の中ででも与えられるかもしれないことにまた注意してください。

Thus, the second piece of a 3-piece message may have either of the following header fields:

従って、3断片メッセージの2番目の断片は以下のヘッダーフィールドのどちらかを持つかもしれません：

But the third piece MUST specify the total number of fragments:

しかし、3番目の断片はフラグメントの総数を指定しなければなりません：

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.

この方法で解体した実体のフラグメントがまとめられる時に、結果はいつも、それ自身のContent-Typeヘッダーフィールドを持つかもしれない完全なMIME実体であり、それから、どのような他のデータ型でも含むかもしれません。

The semantics of a reassembled partial message must be those of the "inner" message, rather than of a message containing the inner message. This makes it possible, for example, to send a large audio message as several partial messages, and still have it appear to the recipient as a simple audio message rather than as an encapsulated message containing an audio message. That is, the encapsulation of the message is considered to be "transparent".

再集合された部分的なメッセージの意味論は内側のメッセージを含んでいるメッセージのというよりも「内圏」メッセージのそれらでなければなりません。これは、例えばいくつかの部分的なメッセージとして大型のオーディオのメッセージを送ることを可能にし、それでも、それをオーディオのメッセージを含んでいるカプセル化したメッセージとしてというよりも単純なオーディオのメッセージとして受領者に出現させてください。すなわちメッセージのカプセル封じは、「透過的である」と考えられます。

When generating and reassembling the 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:

「message/partial」メッセージの断片を生成し、再集合する時に、カプセル化したメッセージのヘッダーは取り囲んでいる実体のヘッダーによってマージされなければなりません。このプロセスの中で、以下の規則は遵守されなければなりません：