The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type.

Content-Typeフィールドの目的は、受け取っているユーザエージェントが、ユーザにデータを示すか、さもなければ適切な方法でデータを扱うために適切なエージェントまたはメカニズムを選ぶことができるくらい十分に完全にボディの中に含まれているデータを説明することです。 このフィールドの値はメディアタイプと呼ばれます。

The Content-Type header field specifies the nature of the data in the body of an entity by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the media 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.

メディアタイプとサブタイプ識別子を与えることによって、そして一定のメディアタイプのために必要とされているかもしれない補助の情報を提供することによって、内部形式ヘッダーフィールドは実体のボディの中でデータの性質を指定します。媒体がタイプし、サブタイプが名付けた後に、attribute=value表記法の中で指定されて、ヘッダーフィールドの剰余はパラメータの単にセットです。パラメータのオーダリングは有意でありません。

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.

一般に、トップレベルのメディアタイプは、データの一般のタイプを宣言するために使われる一方、サブタイプはそのタイプのデータのために特定のフォーマットを指定します。従って、「image/xyz」のメディアタイプは、ユーザエージェントに、ユーザエージェントが特定のイメージ形式「xyz」に関する知識を全然持っていなくても、データがイメージであると言うのに十分です。そのような情報は、例えば、認められないサブタイプからユーザに生データを示すかどうかを決めるために使われることができます--そのような行動はテキストの認められないサブタイプのために妥当であるかもしれないけれども、イメージまたはオーディオの認められないサブタイプのために妥当であることができません。この理由のために、テキスト、イメージ、オーディオ、およびビデオの登録されたサブタイプは、本当に、違うタイプをもっている埋め込まれた情報を含むべきでありません。そのような複合データ形式は、「multipart」または「application」タイプを使って、表されているべきです。

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 content type or subtype or they may be optional. MIME implementations must ignore any parameters whose names they do not recognize.

パラメータはメディアサブタイプの修飾子であり、そのようなものとして、根本的に内容の性質に影響しません。有意味のパラメータのセットはメディアタイプとサブタイプに依存します。ほとんどのパラメータはシングルで特定のサブタイプと関連づけられます。しかし、与えられたトップレベルのメディアタイプは、そのタイプのどのようなサブタイプにでも適用可能なパラメータを定義するかもしれません。パラメータは、彼らがコンテントタイプまたはサブタイプを定義することによって必要とされているかもしれないか、それらはオプションであるかもしれません。 MIMEインプリメンテーションは、彼らが名前と認めていないどのようなパラメータでも無視しなければなりません。

For example, the "charset" parameter is applicable to any subtype of "text", while the "boundary" parameter is required for any subtype of the "multipart" media type.

例えば、「バウンダリ」パラメータが「複数パート」メディアタイプのどのようなサブタイプのためにでも必要とされている間、「charset」パラメータは「テキスト」のどのようなサブタイプにでも適用可能です。

There are NO globally-meaningful parameters that apply to all media types. Truly global mechanisms are best addressed, in the MIME model, by the definition of additional Content-* header fields.

すべてのメディアタイプにあてはまるグローバルに有意味のパラメータが全然ありません。 本当にグローバルなメカニズムはパントマイムモデルの中で追加のContent-*ヘッダー分野の定義によって最もよくアドレスされます。

An initial set of seven top-level media types is defined in RFC 2046. Five of these are discrete types whose content is essentially opaque as far as MIME processing is concerned. The remaining two are composite types whose contents require additional handling by MIME processors.

7種類のトップレベルのメディアタイプの初期のセットはRFC 2046の中で定義されます。MIME処理に関する限り、これらの5つは、内容が本質的に不透明な分離型です。残存2は、内容がMIMEプロセッサによって追加の取り扱いを必要としている複合形です。

This set of top-level media types is intended to be substantially complete. It is expected that additions to the larger set of supported types can generally be accomplished by the creation of new subtypes of these initial types. In the future, more top-level types may be defined only by a standards-track extension to this standard. If another top-level type is to be used for any reason, it must be given a name starting with "X-" to indicate its non-standard status and to avoid a potential conflict with a future official name.

トップレベルのメディアタイプのこのセットは、大幅に完全であることを意図しています。サポートされたタイプのより大きなセットへの加算が一般にこれらの初期のタイプの新しいサブタイプの作成によって遂行されることができることは予期されています。未来に、より多くのトップレベルのタイプはこの標準への標準トラック拡張によってだけ定義されるかもしれません。別のトップレベルのタイプが、どのような理由のためにでも使われることになっているならば、それは、その非標準のステータスを示すためと未来の正称との潜在的な衝突を避けるために「X-」によって起動する名前を与えられなければなりません。

In the Augmented BNF notation of RFC 822, a Content-Type header field value is defined as follows:

RFC 822の増大したBNF記法の中で、Content-Typeヘッダーフィールド値は次の通り定義されます：

Note that the definition of "tspecials" is the same as the RFC 822 definition of "specials" with the addition of the three characters "/", "?", and "=", and the removal of ".".

「tspecials」の定義が3文字「/」、「？」、および「=」の付加と「.」の除去によって「specials」のRFC 822定義と同じであることに注意してください。

Note also that a subtype specification is MANDATORY -- it may not be omitted from a Content-Type header field. As such, there are no default subtypes.

サブタイプ仕様が義務的であることにまた注意してください -- それはContent-Typeヘッダーフィールドから省略されないかもしれません。そのようなものとして、デフォルトサブタイプが存在するわけではありません。

The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent top-level media types. Parameter values are normally case sensitive, but sometimes are interpreted in a case-insensitive fashion, depending on the intended use. (For example, multipart boundaries are case-sensitive, but the "access-type" parameter for message/External-body is not case-sensitive.)

タイプ、サブタイプ、およびパラメータ名はケースで敏感でありません。例えば、TEXT、テキスト、およびテキストはすべて等しいトップレベルのメディアタイプです。パラメータ値は正常にケースで敏感であるけれども、時々、用途に依存して、ケースインセンシティブ流行において解釈されます。(例えば、複数パートバウンダリは大文字小文字を区別しないけれども、メッセージ/外部ボディのための「アクセスタイプ」パラメータは大文字小文字を区別します。)

Note that the value of a quoted string parameter does not include the quotes. That is, the quotation marks in a quoted-string are not a part of the value of the parameter, but are merely used to delimit that parameter value. In addition, comments are allowed in accordance with RFC 822 rules for structured header fields. Thus the following two forms

引用符付きストリングパラメータの値が引用文を含まないことに注意してください。すなわち引用符で囲まれたストリングの中の引用符はパラメータの値の一部ではないけれども、そのパラメータ値を区切るために単に使われます。さらに、コメントは構造化されたヘッダーフィールドのためにRFC 822規則に従って許されます。従って以下の2つの形式

are completely equivalent.

は、完全に等しい。

Beyond this syntax, the only syntactic constraint on the definition of subtype names is the desire that their uses must not conflict. That is, it would be undesirable to have two different communities using "Content-Type: application/foobar" to mean two different things. The process of defining new media subtypes, then, is not intended to be a mechanism for imposing restrictions, but simply a mechanism for publicizing their definition and usage. There are, therefore, two acceptable mechanisms for defining new media subtypes:

この構文を越えて、サブタイプ名の定義の上の唯一の統語的な制約は、それらの用途が矛盾してはならないという要望です。すなわち、2つの違うコミュニティに「Content-Type：」を使わせておくことは不適当でしょう。 2つの違う物を意味する「application/foobar」。そして、ニューメディアサブタイプを定義するプロセスは、制限を課すためのメカニズムではなくそれらの定義と使用を公表するための単にメカニズムであることを意図しています。従って、ニューメディアサブタイプを定義するための2つの受入れ可能なメカニズムがあります：

The second document in this set, RFC 2046, defines the initial set of media types for MIME.

このセットにおける2番目の文書、RFC 2046はMIMEのためにメディアタイプの初期のセットを定義します。

Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as:

デフォルトで、MIME内部形式ヘッダーのないRFC 822メッセージは、US-ASCII文字セットの中で普通テキストであるためにこのプロトコルによってとられます(それは次として明示的に指定されることができます)：

This default is assumed if no Content-Type header field is specified. It is also recommend that this default be assumed when a syntactically invalid Content-Type header field is encountered. In the presence of a MIME-Version header field and the absence of any Content-Type header field, a receiving User Agent can also assume that plain US-ASCII text was the sender's intent. Plain US-ASCII text may still be assumed in the absence of a MIME-Version or the presence of an syntactically invalid Content-Type header field, but the sender's intent might have been otherwise.

どの内部形式ヘッダーフィールドも指定されないならば、このデフォルトは仮定されます。それは、また、統語的に無効な内部形式ヘッダーフィールドが遭遇される時に、このデフォルトが仮定されるように勧めることです。 MIMEバージョンヘッダーフィールドがあり、すべての内部形式ヘッダーフィールドの不在と、受け取っているユーザエージェントは、平易なUS-ASCIIテキストが送信側の意思であったと仮定することもできます。平易なUS-ASCIIテキストはまだMIMEバージョンまたは統語的に無効な内部形式ヘッダーフィールドの存在の不在において仮定されるかもしれないけれども、送信側の意思は違っていたかもしれません。

Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary data. Such data cannot be transmitted over some transfer protocols. For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator.

Eメール経由で有効に輸送されることができた多くのメディアタイプは8ビットのキャラクタまたは2進データとしてそれらの「自然の」フォーマットの中で表されています。そのようなデータはいくつかの転送プロトコルの上に転送されることができません。例えば、(SMTP)が私信メッセージを7ビットのUS-ASCIIデータに限定するRFC 821はどのような引きずるCRLFラインセパレータでも含む1000文字以上に線を引きません。

It is necessary, therefore, to define a standard mechanism for encoding such data into a 7bit short line format. Proper labelling of unencoded material in less restrictive formats for direct use over less restrictive transports is also desireable. This document specifies that such encodings will be indicated by a new "Content-Transfer-Encoding" header field. This field has not been defined by any previous standard.

従って、7ビットの短いラインフォーマットの中にそのようなデータを符号化するために標準のメカニズムを定義することは必要です。より少ない制限的なトランスポートの上の直接的な使用のためのより少ない制限的なフォーマットの中の符号化されなかった資料の適切なラベル付けはまたdesireableです。この文書は、そのようなエンコーディングが新しい「コンテンツ転送エンコーディング」ヘッダーフィールドによって示されるであろうと指定します。このフィールドはどのような前の標準によっても定義されていません。

The Content-Transfer-Encoding field's value is a single token specifying the type of encoding, as enumerated below. Formally:

下で列挙されるように、コンテンツ転送エンコーディングフィールドの値はエンコーディングのタイプを指定している1つのトークンです。フォーマルに：

These values are not case sensitive -- Base64 and BASE64 and bAsE64 are all equivalent. An encoding type of 7BIT requires that the body is already in a 7bit mail-ready representation. This is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.

これらの値は大文字小文字を区別しません--Base64とBASE64とbAsE64はすべて等しくなります。7ビットの符号化タイプは、ボディがすでに7ビットのメール対応の表現の中にあることを必要としています。これは規定値です--すなわち「コンテンツ転送エンコーディング：」 コンテンツ転送エンコーディングヘッダーフィールドが存在しないならば、「7BIT」は仮定されます。

This single Content-Transfer-Encoding token actually provides two pieces of information. It specifies what sort of encoding transformation the body was subjected to and hence what decoding operation must be used to restore it to its original form, and it specifies what the domain of the result is.

このシングルコンテンツ転送エンコーディングトークンは実際2つの情報を提供します。それは、ボディがどんな種類のエンコーディング変形を受けたか、そしてそれゆえ、どんなデコーディング操作が、それをそのオリジナルフォームに復元するために使われなければならないかを指定し、それは、結果のドメインが何であるかを指定します。

The transformation part of any Content-Transfer-Encodings specifies, either explicitly or implicitly, a single, well-defined decoding algorithm, which for any sequence of encoded octets either transforms it to the original sequence of octets which was encoded, or shows that it is illegal as an encoded sequence. Content-Transfer-Encodings transformations never depend on any additional external profile information for proper operation. Note that while decoders must produce a single, well-defined output for a valid encoding no such restrictions exist for encoders: Encoding a given sequence of octets to different, equivalent encoded sequences is perfectly legal.

どのようなコンテンツ転送エンコーディングの変形部分でも、符号化された8ビットバイトのどのようなシーケンスのためにでも、符号化された8ビットバイトのオリジナルのシーケンスに、それを変形させる1つの、明確なデコーディングアルゴリズムを明示的であるか、暗黙に指定するか、それが符号化されたシーケンスとして不当であることを示します。内容転送エンコーディング変形は決して適切な操作をどのような追加の外部のプロファイル情報にも頼りません。 デコーダが有効なエンコーディングのために1つの、明確な出力を引き起こさなければならない間、どのそのような制限もエンコーダのために存在していないことに注意してください： 8ビットバイトの与えられた系列を異なって、同等なコード化された系列にコード化するのは完全に正当です。

Three transformations are currently defined: identity, the "quoted-printable" encoding, and the "base64" encoding. The domains are "binary", "8bit" and "7bit".

3つの変形が現在定義されます： 識別、「quoted- printable」エンコーディング、および「base64」エンコーディング。ドメインは「binary」、「8bit」と「7bit」です。

The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all mean that the identity (i.e. NO) encoding transformation has been performed. As such, they serve simply as indicators of the domain of the body data, and provide useful information about the sort of encoding that might be needed for transmission in a given transport system. The terms "7bit data", "8bit data", and "binary data" are all defined in Section 2.

Content-Transfer-Encoding値「7ビット」、「8ビット」、および「2進です」はすべて、識別(すなわちNO)エンコーディング変形が実行されていることを意味しています。そのようなものとして、彼らは単にボディデータのドメインのインジケータとして勤務していて、与えられた輸送システムの中のトランスミッションのために必要であるかもしれない種類のエンコーディングについての有益な情報を提供します。項「7ビットのデータ」、「8ビットのデータ」、および「binaryデータ」はセクション2中ですべて定義されます。

The quoted-printable and base64 encodings transform their input from an arbitrary domain into material in the "7bit" range, thus making it safe to carry over restricted transports. The specific definition of the transformations are given below.

quoted-printable と base64のエンコーディングは、任意のドメインからのそれらの入力を「7ビット」範囲の素材に変形させて、従って、限定されたトランスポートを持ち越すためにそれを安全にします。変形の特定の定義は下に与えられます。

The proper Content-Transfer-Encoding label must always be used. Labelling unencoded data containing 8bit characters as "7bit" is not allowed, nor is labelling unencoded non-line-oriented data as anything other than "binary" allowed.

適切なコンテンツ転送エンコーディングラベルはいつも使われなければなりません。「7ビット」として8ビットのキャラクタを含んでいるラベル付け符号化されなかったデータは許されなく、「2進です」以外の何かとしてのラベル付け符号化されなかった非ライン指向のデータも許されません。

Unlike media subtypes, a proliferation of Content-Transfer-Encoding values is both undesirable and unnecessary. However, establishing only a single transformation into the "7bit" domain does not seem possible. There is a tradeoff between the desire for a compact and efficient encoding of largely- binary data and the desire for a somewhat readable encoding of data that is mostly, but not entirely, 7bit. For this reason, at least two encoding mechanisms are necessary: a more or less readable encoding (quoted-printable) and a "dense" or "uniform" encoding (base64).

メディアサブタイプと違って、コンテンツ転送エンコーディング値の増殖は不適当で、不要です。しかし、「7ビット」ドメインの中に1つの変形だけも設立することは可能であるようでありません。主として2進データのコンパクトで、効率的なエンコーディングへの欲望と完全であることではなくたいてい、7ビットであるデータの多少読取り可能のエンコーディングへの欲望の間に、トレードオフがあります。この理由にとって、少なくとも2つの符号化メカニズムが必要です： 多少読取り可能のエンコーディング(quoted-printable)と「濃い」または「一様な」エンコーディング(base64)。

Mail transport for unencoded 8bit data is defined in RFC 1652. As of the initial publication of this document, there are no standardized Internet mail transports for which it is legitimate to include unencoded binary data in mail bodies. Thus there are no circumstances in which the "binary" Content-Transfer-Encoding is actually valid in Internet mail. However, in the event that binary mail transport becomes a reality in Internet mail, or when MIME is used in conjunction with any other binary-capable mail transport mechanism, binary bodies must be labelled as such using this mechanism.

符号化されなかった8ビットのデータのためのメールトランスポートはRFC 1652中で定義されます。この文書の初期の出版現在、符号化されなかった2進データをメールボディに含めることが合法な標準化されたインターネットメールトランスポートが全然ありません。従って、「2進の」コンテンツ転送エンコーディングが実際インターネットメールの中で有効な状況が全然ありません。しかし、2進のメールトランスポートがインターネットメールの中で現実になる場合、またはMIMEがどのような他の二進が有能なメール移送機構と連携してでも使われる時に、2進のボディは、このメカニズムを使って、そのようなものとしてラベルを付けて分類されなければなりません。

Implementors may, if necessary, define private Content-Transfer-Encoding values, but must use an x-token, which is a name prefixed by "X-", to indicate its non-standard status, e.g., "Content-Transfer-Encoding: x-my-new-encoding". Additional standardized Content-Transfer-Encoding values must be specified by a standards-track RFC. The requirements such specifications must meet are given in RFC 2048. As such, all content-transfer-encoding namespace except that beginning with "X-" is explicitly reserved to the IETF for future use.

作成者は必要なら私用のコンテンツ転送エンコーディング値を定義することができるけれども、xトークンを使わなければなりません(それは、その非標準のステータス(例えば「コンテンツ転送エンコーディング：」)を示すために「X-」によって前置された名前です) 「x私新エンコーディング」。追加の標準化されたコンテンツ転送エンコーディング値は標準トラックRFCによって指定されなければなりません。そのような仕様が合わなければならないという必要条件はRFC 2048の中で与えられます。それを除いた「X」と共に始まる名前空間をコード化するすべての内容転送が今後の使用のために明らかにIETFに予約されます。

Unlike media types and subtypes, the creation of new Content-Transfer-Encoding values is STRONGLY discouraged, as it seems likely to hinder interoperability with little potential benefit

メディアタイプとサブタイプと違って、それが、ほとんどない潜在的利益との相互運用性を妨げそうであるような時に、新しいコンテンツ転送エンコーディング値の作成は強くやめさせられます。

If a Content-Transfer-Encoding header field appears as part of a message header, it applies to the entire body of that message. If a Content-Transfer-Encoding header field appears as part of an entity's headers, it applies only to the body of that entity. If an entity is of type "multipart" the Content-Transfer-Encoding is not permitted to have any value other than "7bit", "8bit" or "binary". Even more severe restrictions apply to some subtypes of the "message" type.

コンテンツ転送エンコーディングヘッダーフィールドがメッセージヘッダの一部として出現するならば、それはそのメッセージの全身にあてはまります。コンテンツ転送エンコーディングヘッダーフィールドが実体のヘッダーの一部として出現するならば、それはその実体のボディにだけあてはまります。実体がタイプ「複数パート」をもっているならば、コンテンツ転送エンコーディングは、「7ビット」、「8ビット」、または「2進です」以外のどのような値も持つことを許されません。よりいっそう厳しい制限は「メッセージ」タイプのいくつかのサブタイプにあてはまります。

It should be noted that most media types are defined in terms of octets rather than bits, so that the mechanisms described here are mechanisms for encoding arbitrary octet streams, not bit streams. If a bit stream is to be encoded via one of these mechanisms, it must first be converted to an 8bit byte stream using the network standard bit order ("big-endian"), in which the earlier bits in a stream become the higher-order bits in a 8bit byte. A bit stream not ending at an 8bit boundary must be padded with zeroes. RFC 2046 provides a mechanism for noting the addition of such padding in the case of the application/octet-stream media type, which has a "padding" parameter.

ここで説明されたメカニズムが、ビットストリームではなく任意の8ビットバイトストリームを符号化するためのメカニズムであるように、ほとんどのメディアタイプがビットというよりも8ビットバイトと定義されることは注目されるべきです。ビットストリームが、これらのメカニズムの1つ経由で符号化されることになっているならば、それは、最初に、ネットワークの標準のビットの順番(「ビッグエンディアン」)を使って、8ビットのバイトストリームに変換されなければなりません(それにおいて、ストリームの中のより早いビットは8ビットのバイトの中でより高命令ビットになります)。8ビットのバウンダリで終わっていないビットストリームはゼロによってパディングされなければなりません。 アプリケーション/8ビットバイトストリームメディアタイプの場合にそのような充てん文字の加算に言及するために、RFC 2046はメカニズムを提供します(それは「充てん文字」パラメータを持っています)。

The encoding mechanisms defined here explicitly encode all data in US-ASCII. Thus, for example, suppose an entity has header fields such as:

明示的にここで定義された符号化メカニズムはUS-ASCIIにおいてすべてのデータを符号化します。例えば、従って、実体が次などのヘッダーフィールドを持っていると思ってください：

This must be interpreted to mean that the body is a base64 US-ASCII encoding of data that was originally in ISO-8859-1, and will be in that character set again after decoding.

これは、ボディが、独創的に、ISO-8859-1にあったデータのBase64 US-ASCIIエンコーディングであることを意味すると解釈されなければならず、デコードした後に、再びその文字セットの中にあるでしょう。

Certain Content-Transfer-Encoding values may only be used on certain media types. In particular, it is EXPRESSLY FORBIDDEN to use any encodings other than "7bit", "8bit", or "binary" with any composite media type, i.e. one that recursively includes other Content-Type fields. Currently the only composite media types are "multipart" and "message". All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded.

一定のコンテンツ転送エンコーディング値は一定のメディアタイプの上で使われるだけであるかもしれません。特に、どのような複合のメディアタイプ(すなわち、再帰的に、他の内部形式フィールドを含む一方)でも持つ「7ビット」、「8ビット」、または「2進です」以外のどのようなエンコーディングでも使うことははっきりと禁じられています。現在、唯一の複合のメディアタイプは「複数パート」と「メッセージ」です。『multipart』または『message』タイプのボディのために要求されるすべてのエンコーディングは、符号化される必要がある実際のボディを符号化することによって最も奥のレベルでされなければなりません。

It should also be noted that, by definition, if a composite entity has a transfer-encoding value such as "7bit", but one of the enclosed entities has a less restrictive value such as "8bit", then either the outer "7bit" labelling is in error, because 8bit data are included, or the inner "8bit" labelling placed an unnecessarily high demand on the transport system because the actual included data were actually 7bit-safe.

「7ビット」ではなく同封された実体の1つなど、複合エンティティが転送エンコーディングに見積もらせるならば、それは定義によって注意した、それほど、「8ビット」などの制限的な値を持っていることはまたそうであるべきであり、そして、8ビットのデータが含まれるので、外の「7ビット」ラベル付けは誤りであるか、実際の含まれたデータが実際7ビットの金庫であったので、内側の「8ビット」ラベル付けは不必要に高い要求を輸送システムに置きました。

Any entity with an unrecognized Content-Transfer-Encoding must be treated as if it has a Content-Type of "application/octet-stream", regardless of what the Content-Type header field actually says.

Content-Typeヘッダーフィールドが実際言うことを問わず、それが「application/octet-stream」の内部形式を持っているかのように、認められないコンテンツ転送エンコーディングを持つどのような実体でも扱われなければなりません。

The quoted-printable and base64 encodings are designed so that conversion between them is possible. The only issue that arises in such a conversion is the handling of hard line breaks in quoted-printable encoding output. When converting from quoted-printable to base64 a hard line break in the quoted-printable form represents a CRLF sequence in the canonical form of the data. It must therefore be converted to a corresponding encoded CRLF in the base64 form of the data. Similarly, a CRLF sequence in the canonical form of the data obtained after base64 decoding must be converted to a quoted-printable hard line break, but ONLY when converting text data.

それらの間のコンバージョンが可能であるように、印刷可能に引用されて、ベースの64回のエンコーディングはデザインされます。そのようなコンバージョンにおいて生じる唯一の問題は印刷可能に引用されたエンコーディング出力において強硬路線破壊の取り扱いです。 印刷可能な引用からBase64まで変換する時に、印刷可能に引用された形式における強硬路線破壊はデータの基準形式の中でCRLFシーケンスを表しています。 それは従ってデータのBase64形式における対応する符号化されたCRLFに変換されなければなりません。同様に、Base64デコーディングが印刷可能に引用された強硬路線破壊に変換されなければならなかった後けれどもテキストデータを変換する時だけに、データの基準形式の中のCRLFシーケンスは通用していました。

There was some confusion, in the previous versions of this RFC, regarding the model for when email data was to be converted to canonical form and encoded, and in particular how this process would affect the treatment of CRLFs, given that the representation of newlines varies greatly from system to system, and the relationship between content-transfer-encodings and character sets. A canonical model for encoding is presented in RFC 2049 for this reason.

復改の表現が大いにシステムからシステムとコンテンツ転送エンコーディングとキャラクタセットの間の関係に変わると仮定すると、Eメールデータが、基準形式に変換されて、符号化されることになっていて、特にどのようにこのプロセスがCRLFsの取り扱いに影響するであろうかの時の間、このRFCの前のバージョンの中、モデルについていくらかの混乱がありました。エンコーディングのための規範的モデルはこの理由のためにRFC 2049の中で提出されます。