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.

「テキスト」の最も簡単で、最も重要なサブタイプは「plain」です。これは、どのような書式作成コマンドまたは指示語も含んでいない普通テキストを示します。 普通テキストは、表示された「現状のまま」であることを意図していて、すなわち、埋め込まれた書式作成コマンド、文字修飾仕様、処理指示、翻訳指示語、または内容マークアップのどの翻訳も適切なディスプレイに必要であるべきでありません。インターネットメールのための「text/plain; charset=us-ascii」のデフォルトメディアタイプは既存のインターネット実行を説明します。すなわちそれはRFC 822によって定義されたボディのタイプです。

No other "text" subtype is defined by this document.

どの他の「テキスト」サブタイプもこの文書によって定義されません。

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

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

「イメージ」のメディアタイプは、ボディがイメージを含んでいることを示します。サブタイプは特定のイメージ形式を名付けます。これらの名前はケースで敏感でありません。 JFIFエンコーディング[JPEG]を使って、初期のサブタイプは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.

ここに与えられた「イメージ」サブタイプのリストは排他的でなく、徹底的でなく、RFC 2048の中で説明されるように、より多くのタイプがIANAと登録される時に、成長することを期待されています。

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で「application/octet-stream」として扱われるべきです。実装では、オプションで、それらが、そのようなアプリケーションが使用可能ならば、アプリケーションを見て像を映していると特に安全で、頑強な汎用に認めていない「イメージ」のサブタイプを通過することを決定するかもしれません。

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.

「オーディオ」のメディアタイプは、ボディが音声データを含んでいることを示します。コンピュータとの使用のために「理想的な」オーディオのフォーマットの上にまだ、コンセンサスがないけれども、相互運用可能な行動を提供することが可能なフォーマットのための切迫した要求があります。

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.

「audio/basic」サブタイプのコンテンツは、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で「application/octet-stream」として扱われるべきです。インプリメンテーションは、オプションで、彼らが、そのようなアプリケーションが使用可能ならばアプリケーションをしている頑強な汎用オーディオに特に認めていない「オーディオ」のサブタイプを通過することを決定するかもしれません。

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

一般に、この文書が強く1つのボディの中で複数のメディアの混合に不賛成を表するけれども、多くのいわゆるビデオフォーマットが同期されたオーディオのために表現を含み、これが「ビデオ」のサブタイプのために明示的に許されることが認められていることに注意してください。

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で「application/octet-stream」として扱われるべきです。インプリメンテーションは、オプションで、そのようなアプリケーションが使用可能ならば、彼らが頑強な汎用ビデオディスプレイアプリケーションに特に認めていない「ビデオ」のサブタイプを通過することを決定するかもしれません。

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

「アプリケーション」メディアタイプは、あるタイプのアプリケーションプログラムによって処理されるために、他のカテゴリのどれにも納まらない離散的データのために、そして特にデータのために使われることになっています。これは、それが表示可能な前のアプリケーションによって処理されるか、ユーザによって使用可能でなければならない情報です。「アプリケーション」メディアのための予期されている用途はインクルードファイル転送、スプレッドシート、メールベースのスケジューリングシステムのためのデータ、および「アクティブな」(計算です)素材のための言語をタイプします。(後者は特に、作成者によって理解されていなければならず、「application/PostScript」メディアタイプの議論において詳細に考慮されるセキュリティ問題を提起することができます。)

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.

例えば、ミーティングスケジューラは提案されたミーティング日付についての情報のために標準表現を定義するかもしれません。聡明なユーザエージェントは、ユーザとのダイアログを実施するためにこの情報を使うであろうし、その時そのダイアログに基づいた追加の素材を送るかもしれません。より一般に、適切に専門的な言語の中のどのプログラムが遠隔地に輸送されるかにおいて開発されて、受領者の環境の中で自動的に実行された言語をメッセージで送っているいくつかの「active」がありました。

Such applications may be defined as subtypes of the "application" media type. This document defines two subtypes:

そのようなアプリケーションは「アプリケーション」メディアタイプのサブタイプと定義されるかもしれません。 この文書は2つのサブタイプを定義します：

octet-stream, and PostScript.

octet-stream と 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".

「アプリケーション」のサブタイプはしばしば、名前になるか、データが意図されているアプリケーションの名前の一部を含みます。これは、しかし、そのどのようなアプリケーションプログラム名も「アプリケーション」のサブタイプとして自由に使われるかもしれないのを意味していません。

The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. The set of currently defined parameters is:

「octet-stream」サブタイプは、ボディが任意の2進データを含んでいることを示すために使われます。現在定義されたパラメータのセットは以下の通りです：

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.

追加のパラメータ、「CONVERSIONS」はRFC 1341中で定義されたけれども、以来ずっと、削除されています。RFC 1341はまた、データが、ファイルに書き込まれることになっていたならば使われる提案されたファイル名を与えた「NAME」パラメータの使用を定義しました。これは、その後の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.

「application/octet-stream」実体を受け取るインプリメンテーションのための推奨された行動は、単に、どのようなコンテンツ転送エンコーディングでも取り消す状態でデータをファイルに入れるか、たぶんユーザで指定されたプロセスへのインプットとしてそれを使うことを申し出ることです。

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.

悪質なプログラムを転送する危険を減らすために、Content-Typeパラメータ(e.g.、パラメータ)で名前を挙げられた任意のプログラムが、入力として本文を使って、見つかり、実行される、インプリメンテーションが経路探索メカニズムを実施しないことは強く勧められます。

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

「application/postscript」のメディアタイプはPostScriptプログラムを示します。現在、PostScript言語の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.

PostScriptは、MIMEメディアタイプ「application/postscript」のAdobe Systems,Inc.使用の登録商標が、その商標の認識とそれが伴っているすべての権利を暗示していることです。

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.

与えられたプログラムが使う特定の言語機能の内部のラベル付けのために、PostScript言語定義は施設を提供します。このラベル付けは、規定を構造化しているPostScript文書または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.

汎用PostScriptインタプリタの処刑は真面目な危険人物を課していて、作成者は、PostScriptボディを「岩棚から離れています」インタプリタに単に送信することを思いとどまらせられます。害の可能性が典型的なプリンタ環境によって大いに強制される所で、PostScriptをプリンタに送信することが通常安全な間、彼らがPostScriptボディの対話形のディスプレイを彼らのMIMEリーダに追加する前に、作成者は以下のすべてを考慮するべきです。

The remainder of this section outlines some, though probably not all, of the possible problems with the transport of PostScript entities.

たぶんPostScript実体のトランスポートについての起こり得る問題のすべてではないけれども、このセクションの剰余はいくつかを概説します。

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インプリメンテーションは最小で「application/octet-stream」と等しいこととしてどのような認められないサブタイプでも扱わなければなりません。

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つの初期のContent-Type値のうちの残存2つは複合エンティティを参照します。複合エンティティは、MIMEメカニズムを使って、処理されます--MIMEプロセッサは一般に直接ボディを処理します。

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つのボディの中で結合されます)場合に、「複数パート」メディアタイプフィールドは実体のヘッダーの中で出現しなければなりません。ボディは、それぞれバウンダリの区切り行によって先行されて、最後のもので閉局中のバウンダリの区切り行が続いていて、その時1つ以上のボディ部分を含まなければなりません。そのバウンダリの区切り行の後に、各ボディ部分はその時ヘッダーエリア、空白行、およびボディエリアから成ります。従って、ボディ部分は構文の中でRFC 822メッセージに類似しているけれども意味において違います。

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 a content-type of "text/plain; charset=US-ASCII".

ボディ部分を転送する危険を減らすことは実体であり、それゆえ、実際RFC 822メッセージであることとして解釈されないことです。まず第一に、どのヘッダーフィールドも実際ボディ部分で必要とされていません。従って、空白行によって起動するボディ部分は許されて、すべての規定値が、仮定されることであるボディ部分です。そのような場合に、content-typeヘッダーの不在は通常、対応するボディが「text/plain; charset=US-ASCII」のcontent-typeを持っていることを示します。

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.

ボディ部分のために意味を定義した唯一のヘッダーフィールドは、名前が「Content-」から始まるそれらです。他のすべてのヘッダーフィールドはボディ部分で無視されるかもしれません。もし可能ならば、それらが一般に保持されているべきであるけれども、それらは必要ならゲートウェイによって処分されることができます。そのような他のフィールドは、ボディ部分に出ることを許されるけれども、依存されてはなりません。「X-」フィールドは、それらが含んでいる情報がいくつかのゲートウェイでなくされるかもしれないという認識によって実験的な、または私用の目的のために作成されるかもしれません。

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.

「multipart」タイプのすべての現在と未来のサブタイプは同一のシンタックスを使わなければなりません。サブタイプはそれらの意味論において異なるかもしれず、シンタックスに追加の制限を課すかもしれないけれども、「複数パート」タイプのために必要とされているシンタックスに対応しなければなりません。この必要条件は、すべての準拠しているユーザエージェントが、少なくとも、どのような複数パート実体、認められないサブタイプのそれらさえの部分でも認めて、隔てることができるであろうと保証します。

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.

[RFC 2045]がタイプ「複数パート」の実体のために許されて、「7ビット」、「8ビット」、または「2進です」以外のどのエンコーディングもをコンテンツ転送エンコーディング分野の定義の中で述べた時。「複数パート」バウンダリデリミタとヘッダーフィールドは、ともかく(ヘッダーフィールドがRFC 2047に従って非US-ASCIIヘッダーテキストを符号化するかもしれないけれども)7ビットUS-ASCIIとしていつも見せられて、ボディ部分の中のデータは各適切なボディ部分のためのコンテンツ転送エンコーディングフィールドによって部分単位で符号化されることができます。