標準仕様書(TS)   TS X 0069:2005

多目的インターネットメール拡張(MIME)−
第１部：インターネットメッセージ本体のフォーマット

Multipurpose Internet Mail Extensions (MIME) —
Part 1: Format of Internet Message Bodies



序文

この標準仕様書(TS)は，1996年11月にInternat Engineering Task Force (IETF)から公表されたRFC 2045“Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”を翻訳し，技術的内容を変更することなく作成した標準仕様書(TS)である。

Network Working Group N. Freed Request for Comments: 2045 Innosoft Obsoletes: 1521, 1522, 1590 N. Borenstein Category: Standards Track First Virtual November 1996 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies Status of this 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.

1. 導入

1.1 適用範囲

Abstract

インターネット公式プロトコル規定STD 11であるRFC 822では，US-ASCIIメッセージヘッダについて多くの詳細を規定したメッセージ表現プロトコルを定義しているが，メッセージ内容又は，すなわちメッセージ本体については，構造のないUS-ASCIIテキストだけとしている。この標準仕様書(TS)を含む一連の標準仕様書(TS)は，多目的インターネットメール拡張又はMIMEと総称され，次のことを可能とするために，メッセージのフォーマットを再定義する。

  1. US-ASCII以外の文字集合でのテキストのメッセージ本体。
  2. 非テキストのメッセージ本体のための種々の異なるフォーマットの拡張集合。
  3. マルチパートのメッセージ本体。
  4. US-ASCII以外の文字集合でのテキストのヘッダ情報。
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and 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 (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII.

MIMEを規定する一連の標準仕様書(TS)は，RFC 934，STD 11及びRFC 1049に文書化されている初期の成果に基づくが，それらを拡張及び改訂する。RFC 822では，メッセージ本体についてはごくわずかに述べているだけであるから示しているだけなので，これらの標準仕様書(TS)の大部分は，RFC 822の改訂というよりは，直交的である？RFC 822を補うものである。

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.

1番目のRFC 2045を翻訳したこれら一連の標準仕様書(TS)の最初であって，RFC 2045を原規定とするこの標準仕様書(TS)では，MIMEメッセージの構造を記述するために使用される多くのヘッダを規定する。2番目のRFC 2046を翻訳した原規定とする標準仕様書(TS)（TS X 0070）では，MIMEメディア型付けシステムの一般的構造を定義し，メディア型の初期集合を定義する。3番目のRFC 2047を翻訳した原規定とする標準仕様書(TS)（TS X 0071）では，非US-ASCIIでのインターネットメールヘッダフィールドインターネットメールヘッダフィールドの中で非US-ASCIIデータを可能にするためのRFC 822の拡張について記述する。4番目のRFC 2048を翻訳した原規定とする標準仕様書(TS)（TS X 0106）では，MIME関連制度？機能のための多くのIANA登録手続について規定する。最後の5番目のRFC 2049を翻訳した原規定とする標準仕様書(TS)（TS X 0107）では，MIME適合基準について記述し，それと共に，幾つかのMIMEメッセージフォーマットの例示，貢献者及び参考文献を提供する。

This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, 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 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.

RFC 2045(TS X 0069), RFC 2046(TS X 0070), RFC 2047(TS X 0071), RFC 2048(TS X 0106)及びRFC 2049(TS X 0107)は，RFC 1521, RFC 1522及びRFC 1590の改訂であって，RFC 1521, RFC 1522及びRFC 1590はRFC 1341及びRFC 1342の改訂であった。TS X 0107RFC 2049を翻訳した原規定とする標準仕様書(TS)の附属書に，過去の版との違い及び変更について記述する。

These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Table of Contents 1. Introduction ......................................... 3 2. Definitions, Conventions, and Generic BNF Grammar .... 5 2.1 CRLF ................................................ 5 2.2 Character Set ....................................... 6 2.3 Message ............................................. 6 2.4 Entity .............................................. 6 2.5 Body Part ........................................... 7 2.6 Body ................................................ 7 2.7 7bit Data ........................................... 7 2.8 8bit Data ........................................... 7 2.9 Binary Data ......................................... 7 2.10 Lines .............................................. 7 3. MIME Header Fields ................................... 8 4. MIME-Version Header Field ............................ 8 5. Content-Type Header Field ............................ 10 5.1 Syntax of the Content-Type Header Field ............. 12 5.2 Content-Type Defaults ............................... 14 6. Content-Transfer-Encoding Header Field ............... 14 6.1 Content-Transfer-Encoding Syntax .................... 14 6.2 Content-Transfer-Encodings Semantics ................ 15 6.3 New Content-Transfer-Encodings ...................... 16 6.4 Interpretation and Use .............................. 16 6.5 Translating Encodings ............................... 18 6.6 Canonical Encoding Model ............................ 19 6.7 Quoted-Printable Content-Transfer-Encoding .......... 19 6.8 Base64 Content-Transfer-Encoding .................... 24 7. Content-ID Header Field .............................. 26 8. Content-Description Header Field ..................... 27 9. Additional MIME Header Fields ........................ 27 10. Summary ............................................. 27 11. Security Considerations ............................. 27 12. Authors' Addresses .................................. 28d A. Collected Grammar .................................... 29

1.2 概要

1. Introduction

RFC 822は，1982年に出版されて以来，インターネットにおけるテキストのメールメッセージの標準フォーマットを定義してきた。このフォーマットは成功を収め，インターネット及びRFC 821で定義されるインターネットSMTPトランスポートの範囲外においても，RFC 822のフォーマットが全部又は一部採択されるなどしている。このフォーマットは，広範に使えるようにみえるが，利用者コミュニティにとって制約となる，数々の限界があることが，明らかになってきた。

Since its publication in 1982, RFC 822 has defined the standard format of textual mail messages on the Internet. Its success has been such that the RFC 822 format has been adopted, wholly or partially, well beyond the confines of the Internet and the Internet SMTP transport defined by RFC 821. As the format has seen wider use, a number of limitations have proven increasingly restrictive for the user community.

RFC 822はテキストメッセージのためのフォーマットを規定することを想定していた。したがって，音声又は画像を含むかもしれないマルチメディアメッセージなどの，非テキストメッセージについては言及していない。テキストの場合であっても，US-ASCIIより豊富な文字集合の使用を必要とする言語を使うメール利用者の必要を満たさない。RFC 822は，音声，映像，アジア言語のテキスト，又は多くの大部分の欧州言語のテキストでさえも，それらを含むメールのための機構を規定していないので，追加の規定が必要であるになる。

RFC 822 was intended to specify a format for text messages. As such, non-text messages, such as multimedia messages that might include audio or images, are simply not mentioned. Even in the case of text, however, RFC 822 is inadequate for the needs of mail users whose languages require the use of character sets richer than US-ASCII. Since RFC 822 does not specify mechanisms for mail containing audio, video, Asian language text, or even text in most European languages, additional specifications are needed.

RFC 821及びRFC 822に基づくメールシステムひとつの顕著な制限の一つは，電子メールメッセージの内容が，7ビットのUS-ASCIIの比較的短い行(例えば，1000文字以下 [RFC-821])に制限されていることである。このことは，局所的なメールUA(利用者エージェント，人間の利用者がメールを送信したり受信したりするプログラム)を起動する前に，送りたいテキストでないテキストではない送りたいデータを，印字可能なUS-ASCII文字で表現される7ビットのバイト列に変換することを，利用者に強いる。インターネットで現在使われているこのような符号化の例はには，純粋な16進数，uuencode，RFC 1421で規定される3-in-4 base 64方式，Andrewツールキット表現 [ATK]，及びその他の多くの符号化であるがある。

One of the notable limitations of RFC 821/822 based mail systems is the fact that they limit the contents of electronic mail messages to relatively short lines (e.g. 1000 characters or less [RFC-821]) of 7bit US-ASCII. This forces users to convert any non-textual data that they may wish to send into seven-bit bytes representable as printable US-ASCII characters before invoking a local mail UA (User Agent, a program with which human users send and receive mail). Examples of such encodings currently used in the Internet include pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in RFC 1421, the Andrew Toolkit Representation [ATK], and many others.

RFC 822ホストとX.400ホストとの間のメールメッセージの交換を可能にするために，ゲートウェイが設計されると，RFC 822メールの制限はさらに明らかになった。X.400 [X400] は，電子メールメッセージ内にテキストでないデータを含める機構を規定する。X.400メッセージにRFC 822メッセージを対応付けするための現在の規格は，X.400のテキストでないテキストでないX.400のデータを，(符号化するのではなく)IA5TextフォーマットにIA5Textフォーマットに(符号化するのではなく)変換するか，又は，RFC 822利用者に廃棄が起こったことを通知して廃棄するかのどちらかでなければならないことを規定する。このことは，利用者が受け取ることを望むかもしれない情報を失うので，明らかに好ましくない。利用者エージェントがテキストでないデータを処理する能力をもたない場合であっても，利用者は，データから利用可能な情報を抽出する機構をUAの外部にもっているかもしれない。さらに，こうした状況は，メッセージが最終的にX.400メッセージ通信処理システムへゲートウェイによって転送されて(すなわち，X.400メッセージがインターネットメールを通り抜けるだけで)，明らかにテキストでない情報が確かに再び使えるようになる，ということを許容しない。

The limitations of RFC 822 mail become even more apparent as gateways are designed to allow for the exchange of mail messages between RFC 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the inclusion of non-textual material within electronic mail messages. The current standards for the mapping of X.400 messages to RFC 822 messages specify either that X.400 non-textual material must be converted to (not encoded in) IA5Text format, or that they must be discarded, notifying the RFC 822 user that discarding has occurred. This is clearly undesirable, as information that a user may wish to receive is lost. Even though a user agent may not have the capability of dealing with the non-textual material, the user might have some mechanism external to the UA that can extract useful information from the material. Moreover, it does not allow for the fact that the message may eventually be gatewayed back into an X.400 message handling system (i.e., the X.400 message is "tunneled" through Internet mail), where the non-textual information would definitely become useful again.

この標準仕様書(TS)は，現存するRFC 822の世界に深刻な非互換性をもたらすことなしに，これらの問題の多くを解決するために組み合わせて使う，幾つかの機構について記述する。特に，次の四つの事項を記述する。

This document describes several mechanisms that combine to solve most of these problems without introducing any serious incompatibilities with the existing world of RFC 822 mail. In particular, it describes:

(1) MIME-Version(MIME版)ヘッダフィールド。 MIMEに適合するメッセージを宣言するために版番号を使用し，MIMEに適合するメッセージと，このようなフィールドがないことを仮定した旧式又は非適合のソフトウェアによって作成されたメッセージとを，メール処理エージェントが区別することを可能にする。

(1) A MIME-Version header field, which uses a version number to declare a message to be conformant with MIME and allows mail processing agents to distinguish between such messages and those generated by older or non-conformant software, which are presumed to lack such a field.

(2) Content-Type(内容型)ヘッダフィールド。 RFC 1049から一般化されたもので，メッセージの本体のデータのメディア型と及び下位型を指定するため，及び，並びにこれらのデータの本来の表現(正準形式)を完全に指定するために使用することができる。

(2) A Content-Type header field, generalized from RFC 1049, which can be used to specify the media type and subtype of data in the body of a message and to fully specify the native representation (canonical form) of such data.

(3) Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド。 本体に適用された符号化変換及びその結果の領域の双方を指定するのに使用することができる。同一(identity)変換以外の符号化変換は，通常，データ又は文字集合に制限をもつかもしれないメール転送機構を通過する通り抜けることを可能にするために，データに適用される。

(3) A Content-Transfer-Encoding header field, which can be used to specify both the encoding transformation that was applied to the body and the domain of the result. Encoding transformations other than the identity transformation are usually applied to data in order to allow it to pass through mail transport mechanisms which may have data or character set limitations.

(4) Content-IDヘッダフィールド及びContent-Descriptionヘッダフィールド。 本体内のデータをさらに記述するために使うことができる二つの追加のヘッダフィールドである。

(4) Two additional header fields that can be used to further describe the data in a body, the Content-ID and Content-Description header fields.

この標準仕様書(TS)で定義されるすべてのヘッダフィールドは，RFC 822に規定されるヘッダフィールドの一般構文規則に従っている。特に，Content-Disposition(内容配置)を除くこれらのすべてのフィールドは，意味解析上の意味的な内容を持たずもたずMIME処理で中には無視してもよい無視することが望ましいRFC 822注釈を含むことができる。

All of the header fields defined in this document are subject to the general syntactic rules for header fields specified in RFC 822. In particular, all of these header fields except for Content-Disposition can include RFC 822 comments, which have no semantic content and should be ignored during MIME processing.

最後に，相互運用性を規定し促進するため，TS X 0107RFC 2049を翻訳した原規定とする標準仕様書(TS)は，この標準仕様書(TS)に“適合”する最小レベル最小限のレベルを定義する上記の機構のサブセットのための，基本の的な適用可能性宣言を提供する。

Finally, to specify and promote interoperability, RFC 2049 provides a basic applicability statement for a subset of the above mechanisms that defines a minimal level of "conformance" with this document.

備考 MIMEを規定する標準仕様書(TS)に記述される機構の多くは，はじめに読んだ最初に読むときには，何か奇妙又は奇異幾分不思議又は風変わりに見える思われるかもしれない。既存の規定との互換性及び既存の実践における頑健さは，この一連の規定標準仕様書(TS)の原規定を作成した作業グループの，二つの最優先事項最優先事項のうちの二つであった。特に，互換性が，優雅さよりも，常に支持された。このプロトコルの標準化状況と及び状態については，“インターネット公式プロトコル規定”の現在の版を参照すること。RFC 822及びSTD 3であるRFC 1123も，MIMEの適合実装はそれらに違反できないため，MIMEの本質的な背景を供給している。加えて，他の多くの参考情報(Informational) RFC文書，特に，RFC 1344，RFC 1345及びRFC 1524は興味深いであろう。

HISTORICAL NOTE: Several of the mechanisms described in this set of documents may seem somewhat strange or even baroque at first reading. It is important to note that compatibility with existing standards AND robustness across existing practice were two of the highest priorities of the working group that developed this set of documents. In particular, compatibility was always favored over elegance. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. RFC 822 and STD 3, RFC 1123 also provide essential background for MIME since no conforming implementation of MIME can violate them. In addition, several other informational RFC documents will be of interest to the MIME implementor, in particular RFC 1344, RFC 1345, and RFC 1524.

2. 定義，規約及び共通BNF文法

2. Definitions, Conventions, and Generic BNF Grammar

MIMEを規定する標準仕様書(TS)で規定される機構は，すべて普通文通常の文章で記述されているが，そのほとんどどはRFC 822の強化BNF記法を用いて形式的ににも記述される。実装者は，MIMEを規定する標準仕様書(TS)を理解するためには，この記法に親しむ必要があり，そして強化BNF記法の完全な説明のためにRFC 822を参照する。

Although the mechanisms specified in this set of documents are all described in prose, most are also described formally in the augmented BNF notation of RFC 822. Implementors will need to be familiar with this notation in order to understand this set of documents, and are referred to RFC 822 for a complete explanation of the augmented BNF notation.

MIMEを規定する標準仕様書(TS)における強化BNFの幾つかは，RFC 822で定義される構文規則への名前付けされた参照を形成する名前付きで参照されている。そのため，完全な形式文法は，この標準情報(TR)MIMEを規定する標準仕様書(TS)の文法一覧の附属書と，RFC 822のBNF及びRFC 1123で定義されるRFC 822の修正(具体的には，“return”，“date”及び“mailbox”の構文の変更)のそれぞれの附属書の文法一覧を併用することによってとを組み合わせることによって得られる。

Some of the augmented BNF in this set of documents makes named references to syntax rules defined in RFC 822. A complete formal grammar, then, is obtained by combining the collected grammar appendices in each document in this set with the BNF of RFC 822 plus the modifications to RFC 822 defined in RFC 1123 (which specifically changes the syntax for `return', `date' and `mailbox').

MIMEを規定する標準仕様書(TS)では，すべての数数値及びオクテット値は，10進記法で与えられる。定義されているとおりの，すべてのメディア型値，下位型値、及びパラメタ名は，定義されている通り，大文字・小文字を区別しない。しかし，パラメタ値は，特定のパラメタで特に指定される場合を除いて，大文字・小文字を区別する。

All numeric and octet values are given in decimal notation in this set of documents. All media type values, subtype values, and parameter names as defined are case-insensitive. However, parameter values are case-sensitive unless otherwise specified for the specific parameter.

次の記述からすると，この標準仕様書(TS)の“備考”は，本当は“参考”とするのが正しいのかもしれない。

備考 本質的な事項ではなくを失うことなく読み飛ばしてもよい，追加の非本質的な情報は，このような備考として提供する。このようなこれらの非本質的な備考の主な目的は，MIMEを規定する標準仕様書(TS)の理論的解釈を通知すること理論的根拠についての情報を与えること，又は，は，MIMEを規定する標準仕様書(TS)を適切な歴史的又は進展的な発展的な文脈に位置づけることである。このようなこれら情報は，とりわけ，適合した実装をする構築することだけに注目している人々は読み飛ばすだろうがしてもよいが，特定の設計上の選択が何故なされたかを理解したい人々には有用であろうかもしれない。

FORMATTING NOTE: Notes, such at this one, provide additional nonessential information which may be skipped by the reader without missing anything essential. The primary purpose of these non- essential notes is to convey information about the rationale of this set of documents, or to place these documents in the proper historical or evolutionary context. Such information may in particular be skipped by those who are focused entirely on building a conformant implementation, but may be of use to those who wish to understand why certain design choices were made.

2.1 CRLF(復帰改行)

2.1. CRLF

用語CRLFは，MIMEを規定する標準仕様書(TS)では，CR(10進値の10進の値が13)及びLF(10進値の10進の値が10)の二つのUS-ASCII文字に対応するし，この順番で一緒に用いられ，RFC 822メールでは行区切りを示している，オクテット列として参照されるとする。CRとLFはこの順序で共に用いられ，RFC 822メールにおける改行を示すものである。

The term CRLF, in this set of documents, refers to the sequence of octets corresponding to the two US-ASCII characters CR (decimal value 13) and LF (decimal value 10) which, taken together, in this order, denote a line break in RFC 822 mail.

2.2 文字集合

2.2. Character Set

用語“文字集合”は，MIMEでは，オクテット列を文字列をに変換する方法として参照されるものとする。無条件であいまいでないあいまい性のない逆方向への変換は要求されないことに注意すること。すなわち，与えられた一つの与えられた文字集合によってはが，必ずしもすべての文字が表現可能でなくともよくを表現できないともよいし，特定の文字列を表現するのに２通り二つ以上のオクテット列を提供してもよい。

The term "character set" is used in MIME to refer to a method of converting a sequence of octets into a sequence of characters. Note that unconditional and unambiguous conversion in the other direction is not required, in that not all characters may be representable by a given character set and a character set may provide more than one sequence of octets to represent a particular sequence of characters.

この定義は，US-ASCIIのようななどの単純な単一の表による対応付けから，ISO 2022の技法を使うような複雑な表の切換え方法まで，多くの種類の文字符号化を，(抜け)文字集合として使用するために許すことが意図されている。しかし，MIME文字集合名に関連する定義は，実行される対応付けを完全に規定しなければならない。特に，正確な対応付けを決定するための外部プロファイル情報の使用を使用してはならない。

This definition is intended to allow various kinds of character encodings, from simple single-table mappings such as US-ASCII to complex table switching methods such as those that use ISO 2022's techniques, to be used as character sets. However, the definition associated with a MIME character set name must fully specify the mapping to be performed. In particular, use of external profiling information to determine the exact mapping is not permitted.

備考 用語“文字集合”は，元来は，1オクテットから1文字への単純な1対1のマッピング写像(対応付け)をもつ，US-ASCII及びISO-8859-1のようなといった直接的な単純な方式を記述するものであった。複数オクテット符号化文字集合及び切換え技法は，状況をより複雑にしたしている。たとえば例えば，あるコミュニティ人々は，MIMEでいうところの“文字集合(character set)”に対して，“文字符号化(character encoding)”という用語を使う一方が，オクテットではない整数から文字への抽象マッピング的な対応付けを表すのに語句“符号化文字集合(coded character set)”を使う。

NOTE: The term "character set" was originally to describe such straightforward schemes as US-ASCII and ISO-8859-1 which have a simple one-to-one mapping from single octets to single characters. Multi-octet coded character sets and switching techniques make the situation more complex. For example, some communities use the term "character encoding" for what MIME calls a "character set", while using the phrase "coded character set" to denote an abstract mapping from integers (not octets) to characters.

2.3 メッセージ

2.3. Message

用語“メッセージ”は，さらに限定されない限りは場合には，ネットワークに転送される(完全又は最上位の)RFC 822メッセージを示す意味するか，若しくは，又は“message/rfc822”又は若しくは“message/partial”の型で本体にカプセル化されたメッセージを示すとする意味する。

The term "message", when not further qualified, means either a (complete or "top-level") RFC 822 message being transferred on a network, or a message encapsulated in a body of type "message/rfc822" or "message/partial".

2.4 実体

2.4. Entity

用語“実体”は，(抜け)特に，メッセージ，又はメッセージか，又はマルチパート実体？の本体の一部分の中身における複数の部分の一つか，それらのいずれかの，及び，MIMEで定義されたヘッダフィールドとするMIMEで定義されたヘッダフィールド及び内容を参照するとする。このようなこれら実体の規定はが，MIMEの本質であるになっている。実体の内容はしばしば“本体”と呼ばれるので“本体”と呼ばれることが多いので，実体の本体について話すと意味がわかる語ることは意味がある。実体のヘッダには，どのような種類のフィールドも表示存在してよいが，(抜け)実際には，“content-”で始まるフィールドだけがMIMEに関連関係する意味をもつ。このことは，これら“content-”で始まらないフィールド？が意味を持たないことは少しも全く意味をもたないことを意味しないするわけではない。RFC 822で意味が定義されている非MIMEヘッダフィールドをもつメッセージも実体である。？メッセージでもある実体は，RFC 822が意味を定義する非MIMEヘッダフィールドをもつ。？

The term "entity", refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. The specification of such entities is the essence of MIME. Since the contents of an entity are often called the "body", it makes sense to speak about the body of an entity. Any sort of field may be present in the header of an entity, but only those fields whose names begin with "content-" actually have any MIME-related meaning. Note that this does NOT imply thay they have no meaning at all -- an entity that is also a message has non- MIME header fields whose meanings are defined by RFC 822.

2.5 本体部分

2.5. Body Part

用語“本体部分”は，マルチパート実体の中の内部の実体とする。

The term "body part" refers to an entity inside of a multipart entity.

2.6 本体

2.6. Body

用語“本体”は，さらに限定されない限りは場合には，実体の本体の意味とする。すなわち，メッセージ又は本体部分の本体であるとする。

The term "body", when not further qualified, means the body of an entity, that is, the body of either a message or of a body part.

備考 前述の2.3〜2.6の四つの定義は，明確に明らかに循環的である。MIMEメッセージ全体の構造は実際に再帰的であるからなので，このことは避けられない。

NOTE: The previous four definitions are clearly circular. This is unavoidable, since the overall structure of a MIME message is indeed recursive.

2.7 7ビットデータ

“7ビットデータ”は，CRLF行分離シーケンスの間の，998オクテット以下の相対的に短い行として表現されるデータとする[RFC-821]。10進の値が127より大きいオクテットがあってはならず，NUL(10進の値が0のオクテット)があってはならない。CR(10進の(抜け)値が13)及びLF(10進の(抜け)値が10)は，CRLF行分離シーケンス(抜け)の一部としてだけあらわれる現れるものとする。

2.7. 7bit Data "7bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]. No octets with decimal values greater than 127 are allowed and neither are NULs (octets with decimal value 0). CR (decimal value 13) and LF (decimal value 10) octets only occur as part of CRLF line separation sequences.

2.8 8ビットデータ

2.8. 8bit Data

“8ビットデータ”は，CRLF行分離シーケンスの間の，998オクテット以下の相対的に短い行として表現されるデータとする[RFC-821]。10進の値が127より大きいオクテットを使用してもよい。7ビットデータと同様に，NULがあってはならず，CR(10進の？値が13)及びLF(10進の？値が10)は，CRLF行分離シーケンスとしてだけあらわれる現れるものとする。

"8bit data" refers to data that is all represented as relatively short lines with 998 octets or less between CRLF line separation sequences [RFC-821]), but octets with decimal values greater than 127 may be used. As with "7bit data" CR and LF octets only occur as part of CRLF line separation sequences and no NULs are allowed.

2.9 2値データ

2.9. Binary Data

“2値データ”は，どのようなオクテットの列も含むことができるデータとする。

"Binary data" refers to data where any sequence of octets whatsoever is allowed.

2.10 行

2.10. Lines

“行”は，CRLFシーケンスによりよって分離された，オクテットの列として定義される。これこの定義は，RFC 821及びRFC 822の両方と一貫している整合している。“行”は，メッセージの中のデータの要素単位としてだけ参照され，利用者エージェントにおいてが実際に表示されるするものと対応していてもよいし，対応していなくてもよい。

"Lines" are defined as sequences of octets separated by a CRLF sequences. This is consistent with both RFC 821 and RFC 822. "Lines" only refers to a unit of data in a message, which may or may not correspond to something that is actually displayed by a user agent.

3. MIMEヘッダフィールド

3. MIME Header Fields

MIMEは，MIME実体の内容を記述するために使用される幾つかの多くの新しいRFC 822ヘッダフィールドを定義する。これらのヘッダフィールドは，少なくとも次の二つの文脈で生じる出現する。

  1. 通常のRFC 822メッセージヘッダの一部として。
  2. マルチパート構成内でMIME本体部部分ヘッダの中で。
MIME defines a number of new RFC 822 header fields that are used to describe the content of a MIME entity. These header fields occur in at least two contexts: (1) As part of a regular RFC 822 message header. (2) In a MIME body part header within a multipart construct.

これらのヘッダ(抜け)フィールドの形式定義は次とする，次のとおりとする。

     entity-headers := [ content CRLF ]
                       [ encoding CRLF ]
                       [ id CRLF ]
                       [ description CRLF ]
                       *( MIME-extension-field CRLF )

     MIME-message-headers := entity-headers
                             fields
                             version CRLF
                             ; このBNF定義により含まれるが含むヘッダフィールドの順序付けは,
                             ; 無視するほうがよい。

     MIME-part-headers := entity-headers
                          [ fields ]
                          ; “content-”で始まらないすべてのフィールドは,
                          ; 定義された意味を持たずもつことはできず，無視してよい。
                          ; このBNF定義により含まれるが含むヘッダフィールドの順序付けは,
                          ; 無視するほうがよい。

種々の特定のMIMEヘッダフィールドの構文は，後続の章に記述される4.以下に示す。

The formal definition of these header fields is as follows: entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF ) MIME-message-headers := entity-headers fields version CRLF ; The ordering of the header ; fields implied by this BNF ; definition should be ignored. MIME-part-headers := entity-headers [ fields ] ; Any field not beginning with ; "content-" can have no defined ; meaning and may be ignored. ; The ordering of the header ; fields implied by this BNF ; definition should be ignored. The syntax of the various specific MIME header fields will be described in the following sections.

4. MIME-Version(MIME版)ヘッダフィールド

4. MIME-Version Header Field

1982年にRFC 822が出版公開されて以来，それがインターネットメッセージのフォーマットの標準規定として唯一のものであり，使われているフォーマットの規定を宣言するという，認知された必要性はほとんど必要性はほとんど認知されていなかった。この文書標準仕様書(TS)は，RFC 822を補完する，独立の規定であるとする。この標準仕様書(TS)で，拡張は，RFC 822と互換性のあるように方法で定義されてはいるが，そうであっても，新しい規定でを用いてメッセージがどう作成されるか作成されたかどうかを，メール処理エージェントが知っていることが好ましい(抜け)かもしれない状況が存在する。

Since RFC 822 was published in 1982, there has really been only one format standard for Internet messages, and there has been little perceived need to declare the format standard in use. This document is an independent specification that complements RFC 822. Although the extensions in this document have been defined in such a way as to be compatible with RFC 822, there are still circumstances in which it might be desirable for a mail-processing agent to know whether a message was composed with the new standard in mind.

それゆえそのために，この標準仕様書(TS)は，使われているインターネットメッセージ本体のフォーマット規定の版を宣言するために(抜け)使用する，新しいヘッダーフィールド“MIME-Version”を定義する。

Therefore, this document defines a new header field, "MIME-Version", which is to be used to declare the version of the Internet message body format standard in use.

この標準仕様書(TS)にしたがって従って作成されるメッセージは，このヘッダフィールドを，次のテキストの通りにをそのまま，含まなければならない。

	MIME-Version: 1.0
Messages composed in accordance with this document MUST include such a header field, with the following verbatim text: MIME-Version: 1.0

このヘッダフィールドがあることは，メッセージがこの規定に従って作成されていることの断言であるを明言している。

The presence of this header field is an assertion that the message has been composed in compliance with this document.

将来の規定がメッセージフォーマットの規定を再び拡張することするかもしれないことを可能とするので，MIME-Versionフィールドの内容のための形式BNFは，次とするによる。

	version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Since it is possible that a future document might extend the message format standard again, a formal BNF is given for the content of the MIME-Version field: version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

ゆえにそこで，“1.0”を置き換えるか又は拡張するであろうかもしれない，将来のフォーマット指定子は，ピリオドで分離された2つの整数フィールドに制限される。もし，“MIME-Version”値が“1.0”以外のメッセージを受け取ったら取る場合，それは，この規定に適合するとみなすことはできない。

Thus, future format specifiers, which might replace or extend "1.0", are constrained to be two integer fields, separated by a period. If a message is received with a MIME-version value other than "1.0", it cannot be assumed to conform with this document.

MIME-Versionヘッダフィールドは，メッセージの最上位段階に要求されることに注意すること。マルチパート実体のそれぞれの本体部分には要求されない。“message/rfc822”型又は“message/partial”型の本体に組込まれた組み込まれたヘッダでに対しては，組込まれた組み込まれたメッセージそのものそれ自体がMIME適合であるになっていると主張するされる場合にのみだけ，要求される。

Note that the MIME-Version header field is required at the top level of a message. It is not required for each body part of a multipart entity. It is required for the embedded headers of a body of type "message/rfc822" or "message/partial" if and only if the embedded message is itself claimed to be MIME-conformant.

この規定で定義される(抜け)とおりにMIMEにと適合するメール読取り器？リーダが，将来到着するかもしれない“1.0”以外のMIME-Version(抜け)の値を持ったもつメッセージをどう扱うのがよいかを，完全に規定することは不可能である可能ではない。

It is not possible to fully specify how a mail reader that conforms with MIME as defined in this document should treat a message that might arrive in the future with some value of MIME-Version other than "1.0".

特定のメディア型の版管理は，MIME-Version機構を使っては，できない達成されないことに注意する。特に，application/postscriptのようなといった幾つかのフォーマットは，メディアフォーマット内部？に版番号付け規約をもつ。このようなこれら規約が存在する所では場合には，MIMEはそれにとって代わることはしない。そのようなこれら規約が存在しないところでは場合には，必要があれば，MIMEメディア型は，内容型フィールドの中にで“version”パラメタを使うことができるかもしれない。

It is also worth noting that version control for specific media types is not accomplished using the MIME-Version mechanism. In particular, some formats (such as application/postscript) have version numbering conventions that are internal to the media format. Where such conventions exist, MIME does nothing to supersede them. Where no such conventions exist, a MIME media type might use a "version" parameter in the content-type field if necessary.

備考 MIME-Version(抜け)の値を検査するとき，RFC 822注釈文字列がある場合には，それらを無視しなければならない。特に，次の四つのMIME-Versionフィールドは等価であるとする。

     MIME-Version: 1.0

     MIME-Version: 1.0 (produced by MetaSend Vx.x)

     MIME-Version: (produced by MetaSend Vx.x) 1.0

     MIME-Version: 1.(produced by MetaSend Vx.x)0
NOTE TO IMPLEMENTORS: When checking MIME-Version values any RFC 822 comment strings that are present must be ignored. In particular, the following four MIME-Version fields are equivalent: MIME-Version: 1.0 MIME-Version: 1.0 (produced by MetaSend Vx.x) MIME-Version: (produced by MetaSend Vx.x) 1.0 MIME-Version: 1.(produced by MetaSend Vx.x)0

MIME-Versionフィールドがなかった場合，受取り受信側のメール利用者エージェントは，MIME要求要件に適合していてもしていなくても，局所的な規約に基づき，メッセージの本体を解釈することを選んでよい。多くのこのようなこれら規約は現在使われており，実際には非MIMEメッセージが，大方なんでもほとんど何でも含むことができることに注意したほうがよい。

In the absence of a MIME-Version field, a receiving mail user agent (whether conforming to MIME requirements or not) may optionally choose to interpret the body of the message according to local conventions. Many such conventions are currently in use and it should be noted that in practice non-MIME messages can contain just about anything.

非MIMEメールメッセージが，本当に実際にUS-ASCII文字集合のを用いたプレーンテキストであるかは，確実ではない。これは，MIMEに先立つ以前の非標準の局所的な規約の集合を使って，他の文字集合でのを用いたテキスト，又は，例えば圧縮(compress)されてuuencodeされたUNIX tarファイルのようななどの，自動的には認識できない方法によって表現されたテキストでないデータを含むメッセージであるかもしれないからであることによる。

It is impossible to be certain that a non-MIME mail message is actually plain text in the US-ASCII character set since it might well be a message that, using some set of nonstandard local conventions that predate MIME, includes text in another character set or non- textual data presented in a manner that cannot be automatically recognized (e.g., a uuencoded compressed UNIX tar file).

5. Content-Type(内容型)ヘッダフィールド

5. Content-Type Header Field

Content-Typeフィールドの目的は，受信した受信側の利用者エージェントが，利用者にデータを表示するために，適当な適切なエージェント又は若しくは機構を選ぶこと，若しくは，又は適当な適切な方法でデータを扱うのに十分なようにことができるほど十分に，本体に含まれるデータを記述する。このフィールドに含まれる値は，メディア型と呼ばれる。

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ヘッダフィールドは，はじめは最初，RFC 1049で定義された。RFC 1049では，より単純で非力な強力ではない構文を使っていたが，その多くは，この標準仕様書(TS)((追加)及び原規定のRFC 2045)で与える機構と互換性がある。

HISTORICAL NOTE: The Content-Type header field was first defined in RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one that is largely compatible with the mechanism given here.

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.

一般に，最上位のメディア型は，データの一般的な型を指定し，下位型は，そのデータの型に対する特定のフォーマットを指定する。ゆえにそこで，メディア型“image/xyz”は，利用者エージェントが“xyz”という特定の画像フォーマットを知らなかったとしても，データが画像であることを知らせるのに十分である。このようなこれら情報は，例えば，認識できないされない下位型から，の生のデータを利用者に見せるかどうかを決定するのに使うことができる。このようなこれら動作は，テキストの認識できないされない下位型に対しては意味がある理にかなっているかもしれないが，画像又は音声の認識できないされない下位型に対しては意味がないそうでないかもしれない。この理由から，テキスト，画像，音声及び映像の登録された下位型には，実質的に実際には異なる型をとなる組込む組込み情報はを含まないほうがよい。このようなこれら複合フォーマットは，“multipart”型又は“application”型を使用して表したほうがよい。

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.

パラメタは，メディア下位型の修飾子でありあって，内容の性質には，基本的には影響しない。意味のあるパラメタ(抜け)の集合は，メディア型と及び下位型に依存する。ほとんどのパラメタは，単一の特定の下位型に関連する。ただし，与えられた最上位のメディア型が，その型のどの下位型へも適用できうる可能なパラメタを定義してもよい。内容型又は下位型の定義によって，パラメタを要求するは必須であってもよいし，又は，それらはオプションあるであってもよい。MIME実装は，認識しない名前のパラメタはを無視しなければならない。

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.

例えば，“charset”パラメタは，“text”のあらゆる下位型に適用できるが，“boundary”パラメタは，“multipart”メディア型の(抜け)あらゆる下位型に要求される。

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.

すべてのメディア型に適用できるされる大域的に意味のあるパラメタはない存在しない。真に大域的な機構は，MIMEモデルでは，追加の付加的なContent-*ヘッダフィールドの定義によって，(抜け)最もよく言及される。

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.

7つ七つの最上位メディア型の初期集合は，TS X 0070RFC 2046で定義される。そのうち5つ五つは，MIME処理が関係する限りにおいては，本質的に不透明であるな内容をもつ別々の型であるとする。残りの2つ二つは，MIME処理系によって追加の処理が必要な内容の複合型であるとする。

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.

この最上位レベルのメディア型のこの集合は，実際上実質的に，完全であるととなることを意図されている。一般に，より大きなサポートされる(抜け)型のより大きな集合への追加は，これらの初期の型の(抜け)新しい下位型を作ることによって，達成される。将来，この標準規定への標準化過程での手続き拡張によってのみだけ，追加のより多くの最上位レベルの型を定義してよい。もし，何らかの理由によって別の他の最上位型が使われるを使うことが望ましい場合，非標準の状況を示すため，及び将来の公式の名前と重なる衝突する可能性を避けるために，それは非標準状態であることを識別するその型には，“X-”ではじまる開始する名前でを与えなければならない。

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.

5.1 Content-Typeヘッダフィールドの構文

5.1. Syntax of the Content-Type Header Field

Content-Typeヘッダフィールドの値のは，RFC 822の強化BNF記法は次とするを用いて，次のとおりに定義される。

     content := "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ; メディア型及び下位型の合致は，
                ; 常に大文字・小文字を区別しない。

     type := discrete-type / composite-type

     discrete-type := "text" / "image" / "audio" / "video" /
                      "application" / extension-token

     composite-type := "message" / "multipart" / extension-token

     extension-token := ietf-token / x-token

     ietf-token := <標準化手続きRFCによりよって定義され，IANAで登録された拡張トークン>

     x-token := <“X-”又は“x-”の2文字で始まり，空白を含まない，任意のトークン。>

     subtype := extension-token / iana-token

     iana-token := <公式に定義された拡張トークン。
                    この形式のトークンは，TS X 0106で規定される通りとおりに
                    IANAに登録されなければならない。>

     parameter := attribute "=" value

     attribute := token
                ; 属性の合致は，
                ; 常に大文字・小文字を区別しない。

     value := token / quoted-string

     token := 1*<SPACE，CTL，tspecialsを除く，任意の(US-ASCII) CHAR>

     tspecials :=  "(" / ")" / "<" / "gt;" / "@" /
                   "," / ";" / ":" / "\" / <"gt;
                   "/" / "[" / "]" / "?" / "="
                   ; パラメタ値内で使うため，
                   ; quoted-stringでなければならない。
In the Augmented BNF notation of RFC 822, a Content-Type header field value is defined as follows: content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive. type := discrete-type / composite-type discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token composite-type := "message" / "multipart" / extension-token extension-token := ietf-token / x-token ietf-token := <An extension token defined by a standards-track RFC and registered with IANA.> x-token := <The two characters "X-" or "x-" followed, with no intervening white space, by any token> subtype := extension-token / iana-token iana-token := <A publicly-defined extension token. Tokens of this form must be registered with IANA as specified in RFC 2048.> parameter := attribute "=" value attribute := token ; Matching of attributes ; is ALWAYS case-insensitive. value := token / quoted-string token := 1*<any (US-ASCII) CHAR except SPACE, CTLs, or tspecials> tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; Must be in quoted-string, ; to use within parameter values

tspecialsの定義は，“/”，“?”及び“=”の3文字を追加したこと，並びに“.”を削除したこと以外は，RFC 822のspecialの定義と同等同じであることに注意する。

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

下位型の指定は必須であることにも注意する。すなわち，下位型の指定は，Content-Typeヘッダフィールドから省いてはならない。それゆえこのように，デフォルトの下位型はない存在しない。

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.

型名，下位型名及びパラメタ名は，大文字・小文字を区別しない。例えば，TEXT，Text及びTeXtは，同一の等価な最上位のメディア型であるとする。パラメタ値は，通常，大文字・小文字を区別するが，意図される使用によっては，大文字・小文字を区別しないように解釈されることがある。例えば，マルチパート境界は大文字・小文字を区別するが，message/External-bodyの“access-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.)

引用文字列(quoted string)パラメタの値は引用符を含まないことに注意する。すなわち，quoted-stringの中の引用符はパラメタ値の一部ではないがなく，単にパラメタ値を区切るのに使われる。さらに，構造化ヘッダフィールドに関するRFC 822規則に従う注釈は許される。ゆえにそこで，次の2つ二つの形式は完全に同一である等価とする。

     Content-type: text/plain; charset=us-ascii (Plain text)

     Content-type: text/plain; charset="us-ascii"
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 Content-type: text/plain; charset=us-ascii (Plain text) Content-type: text/plain; charset="us-ascii" are completely equivalent.

この構文を超えて以外の，下位型名の定義における構文上の唯一の制約は，それらの使用は重複してはならないという希望である要求とする。すなわち，2つ二つの異なる意味の“Content-Type: application/foobar”を使う，2つ二つの異なるコミュニティがあることは望ましくない。そこで，新しいメディア下位型を定義する過程は，制限をもうける課すための機構を想定する意図しているのでなく，単純にそれらの定義と及び使い方を公にする機構であるとする。それゆえそのために，新しいメディア下位型を定義するための受け入れ可能な次の二つの機構は次の2つであるが存在する。

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:
  1. “X-”で始まる私的な値は，外部での登録又は標準化なしに2つ二つの協力的エージェントの間で双対的に双方で(合意して)定義してよい。このようなこれら値は，登録又は標準化することはできない。
  2. 新しい標準の値は，TS X 0106RFC 2048に記述されるとおりに(抜け)IANAで登録するほうがよい。
(1) Private values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or standardized. (2) New standard values should be registered with IANA as described in RFC 2048.

MIMEを規定する2番目の標準仕様書(TS)（TS X 0070）RFC 2046を原規定とする標準仕様書(TS)では，MIMEのメディア型の初期集合を定義する。

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

5.2 Content-Typeデフォルト

5.2. Content-Type Defaults

MIMEのContent-TypeヘッダなしのデフォルトのRFC 822メッセージは，このプロトコルによって，明示的には次に示される，US-ASCII文字集合によるプレーンテキストとみなすUS-ASCII文字集合によるプレーンテキストとされ，明示的に次のとおりに指定できる。

     Content-type: text/plain; charset=us-ascii
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: Content-type: text/plain; charset=us-ascii

このデフォルトは，Content-Typeヘッダフィールドが指定されなかった場合を想定するしている。構文的に有効でないContent-Typeヘッダフィールドに遭遇したときにも，このデフォルトを想定することが推奨される望ましい。MIME-Versionヘッダフィールドが存在し，Content-Typeヘッダフィールドが何も存在しないとき場合，受け取った受信側の利用者エージェントは，プレーンUS-ASCIIテキストが送信者の想定であることも想定できる意図であったと想定することもできる。MIME-Versionの不在が存在しない，又は構文上有効でないなContent-Typeヘッダフィールドが存在する場合であって，送信者の想定意図がそれ以外であっても違っていたかもしれない場合であっても，プレーン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.

6. Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド

6. Content-Transfer-Encoding Header Field

電子メールによって便利に転送でき得る多くのメディア型は，8ビット文字又は2進2値データとして，“自然な”フォーマットで表現される。このようなこれらデータは，幾つかの転送プロトコルでは伝送することができない。例えば，RFC 821 (SMTP) は，メールメッセージはを，末尾のCRLF行分離子を含んで含む1000文字以下の行のをもった7ビットUS-ASCIIデータに制限されるする。

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.

したがって，このようなこれらデータを7ビットの短い行のフォーマットに符号化する標準的な機構を定義する必要がある。制限の少ないトランスポート上での直接使用のためのに，制限の少ないフォーマットの中では，の符号化されていないデータの適切なラベル付けを適切にラベル付けすることも望まれる。この標準仕様書(TS)は，このようなこれら符号化が新しい“Content-Transfer-Encoding”ヘッダフィールドによりよって指示されることを，規定する。このフィールドは，以前の標準今までのいかなる規定によっても定義されていない。

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.

6.1 Content-Transfer-Encoding構文

6.1. Content-Transfer-Encoding Syntax

Content-Transfer-Encodingフィールド値は，次に列挙されるとおり，符号化の型を指定する単一トークンとする。形式文法は次とするによる。

     encoding := "Content-Transfer-Encoding" ":" mechanism

     mechanism := "7bit" / "8bit" / "binary" /
                  "quoted-printable" / "base64" /
                  ietf-token / x-token
The Content-Transfer-Encoding field's value is a single token specifying the type of encoding, as enumerated below. Formally: encoding := "Content-Transfer-Encoding" ":" mechanism mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token

これらの値は大文字・小文字を区別しない。Base64，BASE64及びbAsE64はすべて同等である等価とする。7BITの符号化型は，本体が既に7ビットメールに使える表現でなければならないであることを要求する。これは，デフォルト値(抜け)とする。すなわち，Content-Transfer-Encodingフィールドがない場合は，“Content-Transfer-Encoding: 7BIT”が仮定される。

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.

6.2 Content-Transfer-Encodingセマンティクス

6.2. Content-Transfer-Encodings Semantics

この単一のContent-Transfer-Encodingトークンは，実際には，2つ二つの情報を提供する。これは，本体がどんな種類の符号化変換をされてに従っているか，したがってそのために，それを元の形式に戻すために何の複号操作どの復号操作が使わなければならないか，そして，及び何の結果の領域であるかが何になるかを指定する。

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.

どんなContent-Transfer-Encodingの変換部もは，どんな符号化されたオクテット列ものいかなる列に対しても，符号化される前の元のオクテット列に変換するか，又は，符号化列として不正であることを示すかをのいずれかを行なう，明示的に又は暗黙的に，単一のよく明確に定義された複号復号アルゴリズムを，明示的に又は暗黙的に，指定する。Content-Transfer-Encodingは，適切な操作のために追加のされる外部のプロファイル情報に依存してはならないすることはない。復号器は，有効な符号化に対して，単一の，よく明確に定義された出力を出力生成しなければならないが，符号化器にはこのような制限はないことに注意する。すなわち，与えれたオクテット列に対してを，異なっているが同等の等価な符号化列へと符号化することは完全に正しい。

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.

同一(符号化変換)，“quoted-printable”(印字可能引用)符号化及び“base64”符号化の3つ三つの変換が，現在定義されている。その(変換の)領域定義域？は，“binary”，“8bit”及び“7bit”とする。

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

Content-Transfer-Encoding(抜け)値の“7bit”，“8bit”及び“binary”は，すべて同一符号化変換が成されること，すなわち，いかなる符号化変換も成されないことを意味する。このように，それらは単に本体データの領域の指示子として提供し役に立ち，与えられたトランスポートシステムにおいて転送のために必要なかもしれない符号化の種類についての有用な情報を提供する。用語“7ビットデータ”，“8ビットデータ”及び“2値データ”は，すべて２章2.で定義されている。

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.

quoted-printable符号化及びbase64符号化は，任意の領域からの入力を“７7ビット”範囲のデータへと変換するので，制限のあるトランスポート上で運ぶことを安全にする。変換の特定の定義は，次とする次のとおり。

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.

正しいContent-Transfer-Encodingラベルがいつでも常に使われなければならない。８8ビット文字を含む符号化されていないデータを“7bit”とラベル付けしてはなずならず，行に基づかない符号化されていないデータを“binary”以外にラベル付けしてはならない。

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.

メディア下位型と違って，Content-Transfer-Encoding値の増加は好ましくない(抜け)し不必要でもある。しかし，“7bit”領域への単一の変換(抜け)だけを制定することはできそうにない。多くのバイナリデータのコンパクト小規模で効率的な符号化の望みに対する要望と，ほとんどが７7ビットであるけれどもだがすべてではないデータの(抜け)ある程度可読性のある符号化に対する要望との間のにはトレードオフが存在する。この理由によりよって，少なくとも２つ二つの符号化機構，すなわち，おおよそ多かれ少なかれ可読性のある符号化(quoted-printable)及び／又は“密な”又は“一様な”符号化(base64)が，必要であるになる。

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

uuencodeされた符号化されていない８8ビットデータのメールトランスポート？転送は，RFC 1652で定義されている。この規定この標準仕様書(TS)の原規定の初期の出版公開のときには，メール本体にuuencodeされた符号化されていないバイナリデータを含めるのに有効な適正な，標準化されたインターネットメールトランスポートはなかった存在しなかった。ゆえにそこで，インターネットメールにおいて“binary”Content-Transfer-Encodingが実際に有効である状況はなかった存在しなかった。しかし，2値メールトランスポートは事実になりがインターネットメールで現実のものとなるか，又は，MIMEが他の2値可能なメールトランスポート機構と一緒に使われるとき場合には，2値の本体は，この機構のようにを使うものとしてラベル付けされなければなならいならない。

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.

備考 Content-Transfer-Encodingフィールドのために定義される５つ五つの値は，(抜け)そのフィールドが符号化されたアルゴリズム，又は復号されるときの符号化されない場合には転送？トランスポートシステム要件以外は，メディア型について何も想定しない示唆しない。

NOTE: The five values defined for the Content-Transfer-Encoding field imply nothing about the media type other than the algorithm by which it was encoded or the transport system requirements if unencoded.

6.3 新しいContent-Transfer-Encoding

6.3. New Content-Transfer-Encodings

実装者は，必要ならば，私的Content-Transfer-Encoding値を定義してよいが，例えば，“Content-Transfer-Encoding: x-my-new-encoding”のようになど，非標準の状態を示す“X-”で始まる(抜け)名前の，x-トークンx-tokenを使わなければならない。追加の標準化されたContent-Transfer-Encoding値は標準化手続？によるRFCによって規定されなければならない。このようなこれら規定が適合し満たさなければならない要求事項要件は，TS X 0106RFC 2048で与えられる。このようにして，“X-”で始まるものを除き，すべての内容転送符号化の名前空間は，IETFで将来の使用のために明示的に予約されている。

参考 Content-Transfer-Encoding値は大文字・小文字を区別しないので，“X-”と“x-”とは同等である。

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.

メディア型及び下位型と異なり，新しいContent-Transfer-Encoding値(抜け)の生成は，少しの利益の可能性のためにほとんど可能性のない利益のために互換性を妨げる(抜け)ことが多いと考えられるので，強く非推奨とする。

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

6.4 解釈と及び使用

6.4. Interpretation and Use

Content-Transfer-Encodingヘッダフィールドが，メッセージヘッダの一部として現れるとき場合，そのメッセージの本体全体に適用される。Content-Transfer-Encodingヘッダフィールドが，実体ヘッダの一部として現れるとき場合，その実体全体に適用される。実体が“multipart”の型であるとき場合，Content-Transfer-Encodingは，“7bit”，“8bit”又は“binary”以外の値を持ってもってはならない。“message”型の(抜け)幾つかの下位型へは，さらにきつい厳しい制限を適用する。

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.

ほとんどのメディア型は，ビットでなくオクテットとしてを用いて定義されていいて，ここで記述される示される機構は，ビットストリームではなく，任意のオクテットストリームを符号化するための機構であるとなっていることに注意することほうがよい。これらの機構のうちのひとつ一つを通してビットストリームが符号化されるとき場合，ネットワークで標準のビット順(big-endian)，すなわち，ストリームの中ではじめ最初の方のビットが，8ビットバイトの中の高位ビットになるように，まずはじめに最初にビットストリームが(抜け)8ビットバイトストリームに変換されなければならない。8ビット境界で終わらないビットストリームは，ゼロが0を用いてパディングされなければならない。TS X 0070RFC 2046を翻訳した原規定とする標準仕様書(TS)は，“padding”パラメタをもつapplication/octet-streamメディア型の場合に，このようなそれらパディングの追加に言及する機構を提供する。

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.

ここで定義する符号化機構は，US-ASCIIのすべてのデータを明示的に符号化する。ゆえにそこで，例えば，次のようなヘッダフィールドをもつ実体を想定する。

     Content-Type: text/plain; charset=ISO-8859-1
     Content-transfer-encoding: base64
The encoding mechanisms defined here explicitly encode all data in US-ASCII. Thus, for example, suppose an entity has header fields such as: Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64

これは，本体が，もとは元はISO-8859-1だったデータのbase64 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.

あるContent-Transfer-Encoding値は，あるメディア型だけに使われてもよい。特に，複合的なメディア型，すなわち，他のContent-Typeフィールドを再帰的に含むメディア型をもつ，“7bit”，“8bit”又は“binary”以外の複合的なメディア型を含む符号化を使用すること，すなわち，他のContent-Typeフィールドを再帰的に含むことは，明確に禁止される。現在，複合的なメディア型は，“multipart”及び“message”だけであるとする。multipart又はmessageの型の本体のために望まれるすべての符号化は，符号化されることが必要な実際の本体を符号化することによって，最も内側のレベルでなされなければならない。

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.

定義ではによって，もし複合的な実体が“7bit”のようなといった転送符号化値をもつのにが，入れられたそれに取り囲まれた実体のひとつ一つが“8bit”のようなといったより制限のゆるい値をもつなら場合，外側の“7bit”というラベル付けは，8ビットデータが含まれているので，エラーであるか，又は，内側の“8bit”というラベル付けは，実際に(抜け)含まれているデータが実は7ビット安全であるからなデータだったので，(抜け)トランスポートシステムに不必要な高い要求をおく課すことになる，ということに(抜け)も注意する。

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.

備考 複合的な本体データに内容転送符号化(content-transfer-encoding)？を使うことに反する禁止を禁止するのは過度に制限的であると見える思われるかもしれないが，これは，データが複数回の一つの符号化アルゴリズムを複数回通して渡され通過し，適切に見るために複数回の復号をしなければならない場合のという，入れ子になった符号化を防ぐために必要であるとする。入れ子になった符号化は，利用者(抜け)エージェントに相当な複雑さを加える。このようなこれら複数の複数回？符号化の明白な効率の問題は別としてとは別に，入れ子になった符号化は？，メッセージの基本構造を不明瞭にすることがありうる。とりわけ特に，それら入れ子になった符号化は，メッセージが本体のどんな型の本体を(抜け)含むかを単に見つけるために，いくともの逆符号化何回もの復号操作が必要であるになることを示唆しうるする。入れ子のになった符号化を禁止することは，特定のメールゲートウェイの仕事を複雑にするかもしれないが，入れ子のになった符号化が利用者エージェントへ及ぼす影響に比べれば，問題が少ないように見える思われる。

NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using content-transfer-encodings on composite body data may seem overly restrictive, it is necessary to prevent nested encodings, in which data are passed through an encoding algorithm multiple times, and must be decoded multiple times in order to be properly viewed. Nested encodings add considerable complexity to user agents: Aside from the obvious efficiency problems with such multiple encodings, they can obscure the basic structure of a message. In particular, they can imply that several decoding operations are necessary simply to find out what types of bodies a message contains. Banning nested encodings may complicate the job of certain mail gateways, but this seems less of a problem than the effect of nested encodings on user agents.

認識されないContent-Transfer-Encodingをもつ実体は，Content-Typeヘッダフィールドに実際に何と書いてあるかにかかわらず，“application/octet-stream”のContent-Typeをもつものとして取り扱われなければならない。

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-Transfer-Encodingは，符号化されるメディアの特性特質から推測されうるように見えるかできるか，又は，少なくとも，あるContent-Transfer-Encodingはを特定のメディア型とともに使用されるためにするのが必須であるように見えるとなるものと思われるかもしれない。これが事実でない幾つもの理由がある。はじめにまず，メールに使われる多種のトランスポートでトランスポートの様々な型を与えられた場合，ある符号化はメディア型とトランスポートとの幾つかの組み合わせある組合せに対して適当であるが適切だが，他の組み合わせでは組合せには適当適切でないなくともよい。例えば，8ビットトランスポートででは，特定の文字集合ではによるテキストのためのに対して符号化は必要でないが，7ビットSMTPでは，それら符号化が明白に必要とされる。

NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER- ENCODING: It may seem that the Content-Transfer-Encoding could be inferred from the characteristics of the media that is to be encoded, or, at the very least, that certain Content-Transfer-Encodings could be mandated for use with specific media types. There are several reasons why this is not the case. First, given the varying types of transports used for mail, some encodings may be appropriate for some combinations of media types and transports but not for others. (For example, in an 8bit transport, no encoding would be required for text in certain character sets, while such encodings are clearly required for 7bit SMTP.) Uchiyama:次は，備考の一部と思われるので，段落を分けるのが妥当か？

2つめに次に，特定のメディア型は，異なる状況では異なる型の転送符号化を要求することがある。例えば，多くのPostScriptの本体は，全体が的には7ビットデータのの短い行からなりうる構成されるかもしれないので，その場合，符号化は必要でない。他のPostScriptの本体，とりわけ特に，レベル2 PostScriptの2値符号化機構を使った本体は，2値トランスポート符号化を使って使った場合にだけ適切に表現されることのみが妥当であろうてよい。最後に，Content-Typeフィールドが，は拡張可能な指定の機構であるとなることを想定意図しているので，メディア型と符号化との間の関連の厳密な規定指定が，特定の下位トランスポートを用いる応用プロトコルの規定と指定と特定の下位トランスポートとを効果的に対をなす結びつけることになる。このことは，メディア型の開発者が，使われている全てすべてのトランスポートと及びそれらの制限について，意識しなければならないので，好ましくない。

Second, certain media types may require different types of transfer encoding under different circumstances. For example, many PostScript bodies might consist entirely of short lines of 7bit data and hence require no encoding at all. Other PostScript bodies (especially those using Level 2 PostScript's binary encoding mechanism) may only be reasonably represented using a binary transport encoding. Finally, since the Content-Type field is intended to be an open-ended specification mechanism, strict specification of an association between media types and encodings effectively couples the specification of an application protocol with a specific lower-level transport. This is not desirable since the developers of a media type should not have to be aware of all the transports in use and what their limitations are.

6.5 翻訳符号化符号化の変換

6.5. Translating Encodings quoted-printable符号化及びbase64符号化は，それらの間の変換が可能なように設計されている。このようなこれら変換についてのただひとつの論点おいて生じる唯一の課題は，quoted-printable符号化出力での指定(hard)行区切りの扱いである。quoted-printableからbase64に変換するとき，quoted-printable形式の指定(hard)行区切りは，データの正準形式でのCRLF列で表現される。それゆえそこで，その行区切りは，データのbase64形式での対応する符号化されたCRLFへ変換しなけらばされなければならない。同様に，base64復号後に得られるデータの正準形式でのCRLF列は，テキストデータを変換するときにだけ，quoted-printableでの指定(hard)行区切りに変換されなければならない。

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.

6.6 正準符号化モデル

6.6. Canonical Encoding Model この標準仕様書(TS)の原規定のであるRFCの以前の版では，電子メールデータが正準形式に変換され符号化されるときのモデルについて，特に，この処理が，システムごとに改行の表現が多様である非常に異なっているときに，この(変換)処理が，CRLFの振舞い振る舞いにどう影響するかについて，そして，及び内容転送符号化と文字集合との間の関係にどう影響するかについて，いくらかの多少の混乱があった。この理由から，符号化のための正準モデルについてが，TS X 0107RFC 2049で提示される。

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.

6.7 Quoted-Printable(印字可能引用)Content-Transfer-Encoding

6.7. Quoted-Printable Content-Transfer-Encoding

Quoted-Printable符号化は，大部分がUS-ASCII文字集合の中の印字可能文字に対応するオクテットから大部分はなる構成されるデータを表現することを想定意図している。このような方法でデータが符号化され，結果のオクテットはメールトランスポートによって意図に反して修正される。この符号化は，結果として生じるオクテットがメールトランスポートによって修正されることはまずないといった方法で，データを符号化する。符号化されるデータがほとんどUS-ASCIIテキストならばの場合，データの符号化された形式は，人によって(抜け)大部分認識可能なままであるになっている。全体がUS-ASCIIである本体であっても，文字翻訳？変換及び/又は行折返しを行うゲートウェイをメッセージが通る通過するメッセージの場合に，(抜け)データの完全さ性を保証するために，Quoted-Printableによって符号化してもよい。

The Quoted-Printable encoding is intended to represent data that largely consists of octets that correspond to printable characters in the US-ASCII character set. It encodes the data in such a way that the resulting octets are unlikely to be modified by mail transport. If the data being encoded are mostly US-ASCII text, the encoded form of the data remains largely recognizable by humans. A body which is entirely US-ASCII may also be encoded in Quoted-Printable to ensure the integrity of the data should the message pass through a character-translating, and/or line-wrapping gateway.

この符号化では，オクテットは，次の規則によって決定されるものとしてとおりに表現される(抜け)のが望ましい。

In this encoding, octets are to be represented as determined by the following rules:
1. 一般？的な8ビット表現
符号化されるデータの正準(標準)形式(標準形式)のCRLF改行行区切りの一部である，CR又はLFを除く任意のあらゆるオクテットは，一つの“=”に続くそのオクテットの値の16進表現で2数字16進表現の二つの数字(2桁の16進数)を続けたもので表してよい。この目的のために使う16進の数字で使うアルファベットは，“0123456789ABCDEF”とする。大文字が使われを使わなくてはならず，小文字は使ってはならない。例えば，10進値の10進の値が12(US-ASCIIの改ページ form feed)は“=0C”で表現でき，10進値の10進の値が16(US-ASCIIの等号 EQUAL SIGN)は“=3D”で表現できる。後続の規則が代替的なの符号化を許す場合を除き，この規則には従わなければならない。
(1) (General 8bit representation) Any octet, except a CR or LF that is part of a CRLF line break of the canonical (standard) form of the data being encoded, may be represented by an "=" followed by a two digit hexadecimal representation of the octet's value. The digits of the hexadecimal alphabet, for this purpose, are "0123456789ABCDEF". Uppercase letters must be used; lowercase letters are not allowed. Thus, for example, the decimal value 12 (US-ASCII form feed) can be represented by "=0C", and the decimal value 61 (US- ASCII EQUAL SIGN) can be represented by "=3D". This rule must be followed except when the following rules allow an alternative encoding.
2. 文字？リテラル表現
10進の値が33以上60以下及び62以上126以下の10進数値のオクテットは，それらのオクテットに対応するUS-ASCII文字，それぞれ，感嘆符EXCLAMATION POINTから不等号(より小さい)LESS THANまで及び不等号(より大きい)GREATER THANからチルダTILDEまで，でとして表現してよい。
(2) (Literal representation) Octets with decimal values of 33 through 60 inclusive, and 62 through 126, inclusive, MAY be represented as the US-ASCII characters which correspond to those octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN through TILDE, respectively).
3. 空白
10進の値が9及び32の10進数値のオクテットは，US-ASCIIのTAB(HT)文字及びSPACE文字として表現してよい。ただしが，符号化された行の末尾で表現してはならない。ゆえにそこで，符号化された行でのTAB(HT)文字及びSPACE文字には，その行で印字可能文字がその行で後続しなければならない。特に，符号化された行の末尾の“=”は，5番目の規則で，無指定(soft)行区切り(5番目の規則を参照)を示しているが，1つ一つ以上のTAB(HT)文字又はSPACE文字に続くかもしれないことを表す続いてもよい。これは，符号化された行の末尾で10進値の10進の値が9又は32のオクテットがは，1番目の規則にしたがってよって表現されなければならないことにしたがっている従っている。この規則は，幾つかのMTA[Message Transport Agent(メッセージ転送エージェント)，すなわち，1人一人の利用者から他の利用者へのメッセージを転送するプログラム又はこのような転送のプラットフォーム部分，又はそれら転送の一部を実行するプログラム]の中にはが，テキストの行にをSPACEをでパディングする(追加)ものがあることが知られていて，又，さらに他のMTAが行末から“空白”文字を取り除くことがものも知られているので，この規則が必要であるになる。それゆえそのために，中間の転送エージェントによって空白が加えられることが避けがたいので，Quoted-Printable本体を逆符号化復号するとき，行の末尾についているすべての空白が削除されを削除しなければならない。
(3) (White Space) Octets with values of 9 and 32 MAY be represented as US-ASCII TAB (HT) and SPACE characters, respectively, but MUST NOT be so represented at the end of an encoded line. Any TAB (HT) or SPACE characters on an encoded line MUST thus be followed on that line by a printable character. In particular, an "=" at the end of an encoded line, indicating a soft line break (see rule #5) may follow one or more TAB (HT) or SPACE characters. It follows that an octet with decimal value 9 or 32 appearing at the end of an encoded line must be represented according to Rule #1. This rule is necessary because some MTAs (Message Transport Agents, programs which transport messages from one user to another, or perform a portion of such transfers) are known to pad lines of text with SPACEs, and others are known to remove "white space" characters from the end of a line. Therefore, when decoding a Quoted-Printable body, any trailing white space on a line must be deleted, as it will necessarily have been added by intermediate transport agents.
4. 改行
テキストの正準形式ではCRLF列として表現される，テキスト本体中の改行行区切りは，Quoted-Printable符号化では，やはりCRLF列であるRFC 822の改行行区切りによって表現されなければならない。テキスト以外のメディア型の正準表現は一般的にはCRLF列としての改行行区切りの表現を含まないので，ハード改行指定(hard)行区切り(すなわち，意味があり，利用者に表示される改行ことを意図している行区切り)は，このようなこれらの型のquoted-printableには，現れない出現できない。もちろん，quoted-printableので表現されたテキストでないデータには，“=0D”,“=0A”,“=0A=0D”及び“=0D=0A”のようなといった列は，よく現れる機械的に現れることがある。

(4) (Line Breaks) A line break in a text body, represented as a CRLF sequence in the text canonical form, must be represented by a (RFC 822) line break, which is also a CRLF sequence, in the Quoted-Printable encoding. Since the canonical representation of media types other than text do not generally include the representation of line breaks as CRLF sequences, no hard line breaks (i.e. line breaks that are intended to be meaningful and to be displayed to the user) can occur in the quoted-printable encoding of such types. Sequences like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely appear in non-text data represented in quoted- printable, of course. 多くの実装は，まず正準形式に変換してから，符号化して，そしてそれからローカル局所的な表現に戻すのではなく，直接に多くの様々な内容型の局所的な表現を符号化することを選んでもよい(抜け)ことに注意する。特に，これはこのことを，CRLF終了終端子列ではない改行規約を使うシステムで，プレーンテキストのデータに適用してもよい。このような実装の最適化は差しつかえない許されるが，(それと)組み合わされた正準(抜け)化符号化の段階が，3つ三つの段階を別々に実施するのと等価な場合のみだけに限る。
Note that many implementations may elect to encode the local representation of various content types directly rather than converting to canonical form first, encoding, and then converting back to local representation. In particular, this may apply to plain text material on systems that use newline conventions other than a CRLF terminator sequence. Such an implementation optimization is permissible, but only when the combined canonicalization-encoding step is equivalent to performing the three steps separately.
5. 無指定(soft)行区切り
Quoted-Printable符号化では，符号化された行が76文字を超えてはならない。Quoted-Printable符号化でそれより長い行が符号化されるとき場合，“無指定(soft)”行区切りが使われなければならない。符号化された行の最後の文字としての等号は，符号化されたテキストの中で意味がない“無指定(soft)”行区切りを示す。
(5) (Soft Line Breaks) The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long. If longer lines are to be encoded with the Quoted-Printable encoding, "soft" line breaks must be used. An equal sign as the last character on a encoded line indicates such a non-significant ("soft") line break in the encoded text.

ゆえにそこで，行の“raw元の(raw)”形式が，次の，復号された符号化されていない単一の行であるときの場合を考える。

     Now's the time for all folk to come to the aid of their country.
Thus if the "raw" form of the line is a single unencoded line that says: Now's the time for all folk to come to the aid of their country.

Quoted-Printable符号化では，次のようにこれを次のとおりに表せる。

     Now's the time =
     for all folk to come=
      to the aid of their country.
This can be represented, in the Quoted-Printable encoding, as: Now's the time = for all folk to come= to the aid of their country.

これは，利用者エージェントによって元に戻すとして，このような戻されるといった方法で，長い行がを符号化する機構を提供する。76文字制限は，末尾のCRLFを数えないが，等号を含め含めた他の全てすべての文字を数える。

This provides a mechanism with which long lines are encoded in such a way as to be restored by the user agent. The 76 character limit does not count the trailing CRLF, but counts all other characters, including any equal signs.

ハイフン文字(“-”)は，それ自身自体，Quoted-Printable符号化としてで表現してよいがので，境界区切り子が符号化された本体のどこにも現れないことを保証するために，ひとつ一つ以上のマルチパート実体の中の内部にquoted-printableで符号化された本体をカプセル化するときには，その境界区切り子(1)が，符号化された本体のどこにも現れないことを保証するために，注意が必要であるをしなければならない。よい戦略としては，quoted-printable(で符号化された)本体には現れることのない“=”のようなといった文字列を境界に選ぶことでがある。TS X 0070RFC 2046のマルチパートメッセージの定義を参照すること(1)。

注1　TS X 0070RFC 2046において，境界区切り子は，ハイフン文字を使って定義されている。

Since the hyphen character ("-") may be represented as itself in the Quoted-Printable encoding, care must be taken, when encapsulating a quoted-printable encoded body inside one or more multipart entities, to ensure that the boundary delimiter does not appear anywhere in the encoded body. (A good strategy is to choose a boundary that includes a character sequence such as "=_" which can never appear in a quoted-printable body. See the definition of multipart messages in RFC 2046.)

備考 quoted-printable符号化は，転送での可読性と転送における信頼性との折衷的なものであるを表現している。quoted-printable符号化で符号化された本体は，ほとんどのメールゲートウェイで信頼度が高く働くにおいて高い信頼性で動作するが，少数のゲートウェイ，特に，EBCDICへの翻訳変換を伴うものでは完全には動かないかもしれない。より高いレベルの信頼性は，base64 Content-Transfer-Encodingでによって提供される。EBCDICゲートウェイを通る妥当な信頼性のある転送を得る方法は，1番目の規則に従って，次のUS-ASCII文字も，quoted-printable符号化することである。

     !"#$@[\]^`{|}~
NOTE: The quoted-printable encoding represents something of a compromise between readability and reliability in transport. Bodies encoded with the quoted-printable encoding will work reliably over most mail gateways, but may not work perfectly over a few gateways, notably those involving translation into EBCDIC. A higher level of confidence is offered by the base64 Content-Transfer-Encoding. A way to get reasonably reliable transport through EBCDIC gateways is to also quote the US-ASCII characters !"#$@[\]^`{|}~ according to rule #1.

なぜならば，quoted-printableデータは一般に行に基づくことを仮定していているので，改行規約の異なるシステム間で渡されるときの，インターネットメールでにおいてプレーンテキストメールがいつでも常に変更されるてきたのと同じ様に，quoted-printableデータの行の間の改行区切りの表現がは，転送中に変更されるかもしれないことを期待していると予想される。もし，このようなこれら変更が，データの変造？を構成しそうならば引き起こす可能性がある場合，quoted-printable符号化ではなく，base64符号化を使うことが多分賢いことである恐らくより賢明といえる。

Because quoted-printable data is generally assumed to be line- oriented, it is to be expected that the representation of the breaks between the lines of quoted-printable data may be altered in transport, in the same manner that plain text mail has always been altered in Internet mail when passing between systems with differing newline conventions. If such alterations are likely to constitute a corruption of the data, it is probably more sensible to use the base64 encoding rather than the quoted-printable encoding.

備考 quoted-printable内容転送符号化のための符号化規則に従って，文字列の多くの種類をある種の部分文字列を生成することはできない。したがって，quoted-printable符号化器の出力にそれらが現れれば公式には不正である出現する場合は，形式的には不正とする。この備考は，これらの場合を列挙し，復号されるquoted-printableデータの中でが復号されるとき，次のどれかに遭遇した出会う場合，このようなそれら不正な(抜け)部分文字列を取り扱う方法を薦める示す。

NOTE: Several kinds of substrings cannot be generated according to the encoding rules for the quoted-printable content-transfer- encoding, and hence are formally illegal if they appear in the output of a quoted-printable encoder. This note enumerates these cases and suggests ways to handle such illegal substrings if any are encountered in quoted-printable data that is to be decoded.
  1. 1つ一つ又は両方の文字が小文字の“abcdef”のうちのいずれかの小文字であるとなっている2つ二つの16進数字に後続される“=”は，公式には不正である形式的には不正とする。エラー強さのある頑健な実装は，それらを対応する大文字として認識しうるするとよいかもしれない。
    2. (1) An "=" followed by two hexadecimal digits, one or both of which are lowercase letters in "abcdef", is formally illegal. A robust implementation might choose to recognize them as the corresponding uppercase letters.
  2. “abcdef”の場合を含めてむ16進の数字でなく，CRLF対のCR文字でもない文字に後続される“=”は，不正であるとする。この場合は，それ自身自体がquoted-printable符号化されずにに従っていない，メッセージのquoted-printable部分に含まれた含まれている，US-ASCIIテキストの結果でありうるの可能性がある。頑健な実装のによる妥当な理にかなった方針は，復号されたデータに，“=”文字及び後続の1文字それに後続する(一つの)文字を変換せずに含ませ，可能ならば可能な場合には，利用者に，データのこの地点箇所で適切な復号ができないできなかったことを利用者に示すとよい示すことかもしれない。 (2) An "=" followed by a character that is neither a hexadecimal digit (including "abcdef") nor the CR character of a CRLF pair is illegal. This case can be the result of US-ASCII text having been included in a quoted-printable part of a message without itself having been subjected to quoted-printable encoding. A reasonable approach by a robust implementation might be to include the "=" character and the following character in the decoded data without any transformation and, if possible, indicate to the user that proper decoding was not possible at this point in the data.
  3. “=”は，符号化されたオブジェクトの中で最後又は最後から2番目の文字となりえないなることはできない。これは，上記前項の2番目の場合として取り扱えよう取り扱ってよい。
    4. (3) An "=" cannot be the ultimate or penultimate character in an encoded object. This could be handled as in case (2) above.
  4. TAB，又はCRLF対の部分一部としてのCR及びLF，以外の制御文字は現れてはならない。10進の値が126より大きい値のオクテットでも同じであるに対しても同じとする。もし，(追加)それら文字が，復号器によって，到着したquoted-printableデータの中に発見されたならば場合，頑健な実装は，復号されたデータから(抜け)それら文字を除外し，利用者に不正データ文字が発見されたことを警告するとよいとよいかもしれない。
    5. (4) Control characters other than TAB, or CR and LF as parts of CRLF pairs, must not appear. The same is true for octets with decimal values greater than 126. If found in incoming quoted-printable data by a decoder, a robust implementation might exclude them from the decoded data and warn the user that illegal characters were discovered.
  5. 符号化した行は，末尾のCRLFを数えずに，76文字より長くてはならない。もし，より長い(抜け)行が符号化されたデータが来たら到着した符号化されたデータの中に発見された場合，頑健な実装は，その行を復号するかにかかわらずエラーではあるがその行を復号し，利用者にエラーのある符号化であることを報告するとよい(追加)かもしれない。
(5) Encoded lines must not be longer than 76 characters, not counting the trailing CRLF. If longer lines are found in incoming, encoded data, a robust implementation might nevertheless decode the lines, and might report the erroneous encoding to the user.

備考 2値データがquoted-printableにで符号化されるとき場合，CR(抜け)文字及びLF文字をそれぞれ“=0D”及び“=0A”として符号化することに注意しなければならない。特に，2値データでのCRLF列は，“=0D=0A”と符号化したほうがよいするのがよい。そうでなければそうでない場合であって，もしCRLFが指定(hard)行区切りとして表現されるとき場合，異なった行区切り規約のをもつプラットホームでは，正しくなく復号されるされないかもしれない。

WARNING TO IMPLEMENTORS: If binary data is encoded in quoted- printable, care must be taken to encode CR and LF characters as "=0D" and "=0A", respectively. In particular, a CRLF sequence in binary data should be encoded as "=0D=0A". Otherwise, if CRLF were represented as a hard line break, it might be incorrectly decoded on platforms with different line break conventions.

quoted-printableデータの構文は，次の形式文法で記述される。

For formalists, the syntax of quoted-printable data is described by the following grammar: 
     quoted-printable := qp-line *(CRLF qp-line)

     qp-line := *(qp-segment transport-padding CRLF)
                qp-part transport-padding

     qp-part := qp-section
                ; 最大長76文字。

     qp-segment := qp-section *(SPACE / TAB) "="
                   ; 最大長76文字。

     qp-section := [*(ptext / SPACE / TAB) ptext]

     ptext := hex-octet / safe-char


     safe-char := <any octet with decimal value of 33 through
                  60 inclusive, and 62 through 126>

     safe-char := <10進の値が33〜60及び62〜126をもつ任意のオクテット>
                  ; さらに，TS X 0107RFC 2049の“mail-safe”の一覧にない
                  ; 文字はも推奨しない。

     hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
                  ; 127より大きな文字，=，又は行末のスペースSPACE又は若しくはタブTABには
                  ; オクテットが使われなければならなず，
                  ; TS X 0107RFC 2049で“mail-safe”の一覧にない文字のためには
                  ; オクテットが推奨される。

     transport-padding := *LWSP-char
                          ; 送信者は，ゼロ長？長さが0の？長さが0ではないトランスポート
                          ; パディングを生成してはならないが，
                          ; 受信者は，メッセージトランスポート
                          ; によって追加されたパディングを
                          ; 処理できなければならない。
quoted-printable := qp-line *(CRLF qp-line) qp-line := *(qp-segment transport-padding CRLF) qp-part transport-padding qp-part := qp-section ; Maximum length of 76 characters qp-segment := qp-section *(SPACE / TAB) "=" ; Maximum length of 76 characters qp-section := [*(ptext / SPACE / TAB) ptext] ptext := hex-octet / safe-char safe-char := <any octet with decimal value of 33 through 60 inclusive, and 62 through 126> ; Characters not listed as "mail-safe" in ; RFC 2049 are also not recommended. hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") ; Octet must be used for characters > 127, =, ; SPACEs or TABs at the ends of lines, and is ; recommended for any character not listed in ; RFC 2049 as "mail-safe". 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.

このBNFでは構造化ヘッダフィールドを規定していないので，このBNFに示される要素間でのLWSPの追加は許されないことは，。このことは，重要である。

IMPORTANT: The addition of LWSP between the elements shown in this BNF is NOT allowed since this BNF does not specify a structured header field.

6.8 Base64 Content-Transfer-Encoding

6.8. Base64 Content-Transfer-Encoding

Base64 Content-Transfer-Encodingは，任意のオクテット列を，人が読める必要がない読めなくともよい形式で，表現するために設計された。符号化と逆符号化及び復号のアルゴリズムは単純であるだが，符号化されたデータは，符号化されていないデータに比べ，いつでも一貫しておよそ33パーセントほど大きい。この符号化は，実質的に，RFC 1421で定義されている，Privacy Enhanced Mail (PEM) アプリケーションと同一である同等になっている。

The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable. The encoding and decoding algorithms are simple, but the encoded data are consistently only about 33 percent larger than the unencoded data. This encoding is virtually identical to the one used in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.

65文字のUS-ASCIIの65文字のサブセット部分集合が使われることによってを使用し，印字可能な1一つの文字あたりごとに6ビットをあらわすことが可能である表現可能とする。65番目の文字“=”は，特別な処理機能を意味するのに使われるために使用する。

A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.)

備考 このサブセット部分集合は，US-ASCIIを含んだ含むISO 646のすべての版で同一に表現されるという，重要な特性を持ち，そして，このサブセットのすべての文字は，EBCDICのすべての版で(抜け)も，同一に表現される。uuencodeユーティリティユティリティ，Macintoshのbinhex 4.0 [RFC-1741]及びLevel 2 PostScriptの一部として規定されるbase85(抜け)符号化のようなといった，他の一般的なよく利用される符号化は，この特性を共有せず，そのために，メールのための用の2値転送符号化が適合し満たさなければならない可搬性の要求要件を満たさ満足しない。

NOTE: This subset has the important property that it is represented identically in all versions of ISO 646, including US-ASCII, and all characters in the subset are also represented identically in all versions of EBCDIC. Other popular encodings, such as the encoding used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741], and the base85 encoding specified as part of Level 2 PostScript, do not share these properties, and thus do not fulfill the portability requirements a binary transport encoding for mail must meet.

符号化処理は，4四つの符号化文字の出力列として，入力ビットの24ビット群24ビット(単位の)群(24-bit group)を表現する。左から右へと進めて，(抜け)一つの24ビットの入力群が，3つ三つの8ビット入力群を連結することによりよって，形作られる形成される。そして次に，これらの24ビットはを，4つ四つの(抜け)連結された6ビット群として取り扱われ取り扱い，それぞれは，をbase64アルファベット(base64の構成単位)のにおける単一の数字へと翻訳される変換する。base64符号化を通した通じてビットストリームのを符号化のときする場合，ビットストリームは，最上位ビットが先のになる順番と仮定されていなければならない。すなわち，ビットストリームの最初のビットは，最初の8ビット(単位の)バイトのうちの中の上位ビットでありとなり，8番目のビットは，最初の8ビット(単位の)バイトのうちの中の下位ビットでありとなる，など，以下同様であるとする。

The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single digit in the base64 alphabet. When encoding a bit stream via the base64 encoding, the bit stream must be presumed to be ordered with the most-significant-bit first. That is, the first bit in the stream will be the high-order bit in the first 8bit byte, and the eighth bit will be the low-order bit in the first 8bit byte, and so on.

それぞれの6ビット群は，64個の印字可能文字の行列配列へのインデクスとして使われる。インデクスにより参照される文字はが，出力列(追加)の中に置かれる。次の表1に示すで識別されるこれらの文字は，広く広い範囲で表現可能なように選ばれ，例えば，“.”，CR及び，LFなどの，SMTPへに対して特定の意味をもつ文字，並びに，及び例えば“-”などのTS X 0070RFC 2046で定義されるマルチパート境界区切り子へ，に対して特定の意味を持つもつ文字を除外してある。

Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. These characters, identified in Table 1, below, are selected so as to be universally representable, and the set excludes characters with particular significance to SMTP (e.g., ".", CR, LF) and to the multipart boundary delimiters defined in RFC 2046 (e.g., "-").
表1 Base64アルファベット
 値  符号  値  符号  値  符号  値  符号 
 0  A  17  R  34  i  51  z 
 1  B  18  S  35  j  52  0 
 2  C  19  T  36  k  53  1 
 3  D  20  U  37  l  54  2 
 4  E  21  V  38  m  55  3 
 5  F  22  W  39  n  56  4 
 6  G  23  X  40  o  57  5 
 7  H  24  Y  41  p  58  6 
 8  I  25  Z  42  q  59  7 
 9  J  26  a  43  r  60  8 
 10  K  27  b  44  s  61  9 
 11  L  28  c  45  t  62  + 
 12  M  29  d  46  u  63  / 
 13  N  30  e  47  v     
 14  O  31  f  48  w (pad) = 
 15  P  32  g  49  x     
 16  Q  33  h  50  y     
Table 1: The Base64 Alphabet Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y

符号化された出力ストリームは，それぞれ76文字を超えない行で表現されなくてはなければならない。すべての改行行区切り又は表1にない他の文字は，復号ソフトウェアによりよって，無視されなければならない。base64データの中の，表1以外の文字，改行行区切り及びその他の空白は，大抵おそらく，ある状況では警告メッセージ又はメッセージ棄却拒否が適切なかもしれない，転送誤りを示す。

The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other characters not found in Table 1 must be ignored by decoding software. In base64 data, characters other than those in Table 1, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances.

符号化されるデータの末尾において，24ビットに満たないときは場合には，特別な処理が実行される。本体の末尾ではいつでも常に完全な欠けることのない符号化の量が完成するの分量で完結する。入力グループ群の中で，24入力ビットより少ないときよりも少ない入力ビットが存在する場合，ゼロビット値0のビットが右に加えられ追加され，6ビットグループ群を単位とする整数値整数倍の数へと形付けられる整形される。データの末尾へのパディングは“=”文字を使って実行される。すべてのbase64入力はオクテットの整数倍の数であるからなので，次の場合だけがありえる発生する。

  1. 符号化入力の最後の符号化量は分量が，24ビットの整数倍であるになっている。つまりこの場合，符号化出力の最後の単位(かたまり)は，“=”パディングなしで4文字の整数倍となる。
  2. 符号化入力の最後の符号化量は分量が，ちょうど8ビットであるになっている。つまりこの場合，符号化出力の最後の単位(かたまり)は，2二つの文字に，二つの“=”パディング文字が2つ後続したものとなる。
  3. 符号化入力の最後の符号化量は分量が，ちょうど16ビットであるになっている。つまりこの場合，符号化出力の最後の単位(かたまり)は，3三つの文字に，一つの“=”パディング文字が1つ後続したものとなる。

Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a body. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the "=" character. Since all base64 input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.

(追加)“=”文字はデータの最後のパディングのためだけに用いられるので，途中で？転送中で？切り取られなかった場合には，“=”文字の出現はデータがの最後に到達した証拠ととられるみなしてもよい。しかし，伝送されたオクテットの数が3の倍数であって“=”文字が(追加)存在しないときは，このような保証は可能ではない。

Because it is used only for padding at the end of the data, the occurrence of any "=" characters may be taken as evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible, however, when the number of octets transmitted was a multiple of three and no "=" characters are present.

base64アルファベット以外の文字は，base64符号化データの中では，無視されるするのが望ましい。

Any characters outside of the base64 alphabet are to be ignored in base64-encoded data. base64符号化を正準形式に変換されていないテキストデータへに対してbase64符号化を直接に適用する場合には，改行行区切りのためのに適切なオクテットがを使うよう，に注意しなければならない。特に，テキスト改行の行区切りは，base64符号化の前に，CRLF列に変換されなければならない。注意すべき重要なことは，幾つかの実装おいての中には，これはこの変換を，前段階の先行する正準化段階ではなく，符号化器によって直接行われてよいということであるに行なうものもあるという点に注意することが重要である。

Care must be taken to use the proper octets for line breaks if base64 encoding is applied directly to text material that has not been converted to canonical form. In particular, text line breaks must be converted into CRLF sequences prior to base64 encoding. The important thing to note is that this may be done directly by the encoder rather than in a prior canonicalization step in some implementations.

備考 マルチパート実体の中のの内部のbase64符号化本体の中内で，可能な存在する可能性のある境界区切り子を引用する(quote)ことにについては，心配する必要はない。これは，base64符号化では“-”(ハイフン)文字は使用されないので，心配する必要はないことによる。

NOTE: There is no need to worry about quoting potential boundary delimiters within base64-encoded bodies within multipart entities because no hyphen characters are used in the base64 encoding.

7. Content-ID(内容識別子)ヘッダフィールド

7. Content-ID Header Field

高機能の利用者エージェントを作成する際，ある本体が別の他の本体への参照を作成すること行なうのを許す可能にすることが望まれる場合がある。従ってそれに従って，本体は，構文的にはMessage-IDヘッダフィールドと同一の，Content-IDヘッダフィールドを使ってラベル付けしてよい。

	id := "Content-ID" ":" msg-id
In constructing a high-level user agent, it may be desirable to allow one body to make reference to another. Accordingly, bodies may be labelled using the "Content-ID" header field, which is syntactically identical to the "Message-ID" header field: id := "Content-ID" ":" msg-id

Message-ID値と同様に，Content-ID値は，世界で一意にとなるように生成されなければならない。

Like the Message-ID values, Content-ID values must be generated to be world-unique.

Content-ID値は，多数のコンテキスト中で幾つかの文脈においてMIME実体を一意に識別するために，とりわに特に，message/external-body機構によりよって参照されるキャッシュデータを識別するキャッシュするために使ってよい。Content-IDは一般的にオプションであるだが，オプションのMIMEメディア型である“message/external-body”のデータを生成する実装では(抜け)，その使用は必須とする。すなわち，それぞれのmessage/external-body実体は，このようなこれらデータのキャッシングキャッシュ化を許すためにContent-IDフィールドをもたなければならない。

The Content-ID value may be used for uniquely identifying MIME entities in several contexts, particularly for caching data referenced by the message/external-body mechanism. Although the Content-ID header is generally optional, its use is MANDATORY in implementations which generate data of the optional MIME media type "message/external-body". That is, each message/external-body entity must have a Content-ID field to permit caching of such data.

Content-ID値は，multipart/alternativeメディア型(抜け)の場合には特別なセマンティクスをもつContent-ID値ことに注意することは有用であるも重要である。このことは，TS X 0070RFC 2046を翻訳した原規定とする標準仕様書(TS)において，multipart/alternativeについて扱う章箇条で説明される示される。

It is also worth noting that the Content-ID value has special semantics in the case of the multipart/alternative media type. This is explained in the section of RFC 2046 dealing with multipart/alternative.

8. Content-Description(内容記述)ヘッダフィールド

8. Content-Description Header Field

与えられた本体とともにいくらかの記述的情報に説明的な情報を与えられた本体と関連付ける能力は，しばしば好ましいが，望まれることが多い。例えば，“image”の本体に“スペースシャトルエンデバーの写真”といった印をつけることは便利でろう役に立つかもしれない。このようなそれらテキストは，Content-Descriptionヘッダフィールドに入れての中に置いてよい。このヘッダフィールドはいつでも，常にオプションであるとする。

	description := "Content-Description" ":" *text
The ability to associate some descriptive information with a given body is often desirable. For example, it may be useful to mark an "image" body as "a picture of the Space Shuttle Endeavor." Such text may be placed in the Content-Description header field. This header field is always optional. description := "Content-Description" ":" *text

この記述(description)は，US-ASCII文字集合によりで与えられることを想定するが，。ただし，TS X 0071RFC 2047で規定される機構を使って，非US-ASCII文字をContent-Descriptionフィールドの値としてもよい。

The description is presumed to be given in the US-ASCII character set, although the mechanism specified in RFC 2047 may be used for non-US-ASCII Content-Description values.

9. 追加のMIMEヘッダフィールド

9. Additional MIME Header Fields

将来の規定では，種々の目的のために追加のMIMEヘッダフィールドを定義することを選択してよい決定してもよい。メッセージの内容をさらに記述する全ての新しいヘッダフィールドは，メッセージヘッダに現れるこのようなそれらフィールドを通常のRFC 822ヘッダフィールドと区別するために，(抜け)文字列“Content-”で始まったほうがよい始めることが望ましい。

	MIME-extension-field := <文字列“Content-”文字列で始まる
	                          任意のRFC 822ヘッダフィールド>
Future documents may elect to define additional MIME header fields for various purposes. Any new header field that further describes the content of a message should begin with the string "Content-" to allow such fields which appear in a message header to be distinguished from ordinary RFC 822 message header fields. MIME-extension-field := <Any RFC 822 header field which begins with the string "Content-">

10. まとめ

10. Summary

MIME-Versionヘッダフィールド，Content-Typeヘッダフィールド及びContent-Transfer-Encodingヘッダーフィールドを使って，標準化された方法で，RFC 822に適合するメールメッセージに任意の型のデータを含む含ませることを可能としたが可能になる。これらは，RFC 821又はRFC 822のどちらかによって課される制約にも違反しない。そして幾つかのインターネットメール転送機構の特徴によって追加で追加的に課される制約(抜け)が引き起こす問題を避けるための注意がなされている行なわれた。これについては，RFC 2049を翻訳した原規定とするTS X 0107を参照すること。

Using the MIME-Version, Content-Type, and Content-Transfer-Encoding header fields, it is possible to include, in a standardized way, arbitrary types of data with RFC 822 conformant mail messages. No restrictions imposed by either RFC 821 or RFC 822 are violated, and care has been taken to avoid problems caused by additional restrictions imposed by the characteristics of some Internet mail transport mechanisms (see RFC 2049).

MIMEを規定する次の一連の標準仕様書(TS)であるの中のRFC 2046を翻訳した原規定とするTS X 0070では，これらのヘッダを使ってラベル付けされ及び転送されることができるメディア型の初期集合を規定する。

The next document in this set, RFC 2046, specifies the initial set of media types that can be labelled and transported using these headers.

11. セキュリティへの考慮

11. Security Considerations

セキュリティに関しては，MIMEを規定する2番目の一連の標準仕様書(TS)であるの中のRFC 2046を翻訳した原規定とするTS X 0070で論じられる。

Security issues are discussed in the second document in this set, RFC 2046.

12．原規定の著者の連絡先(参考)

12. Authors' Addresses

原規定(RFC 2045)についての追加的な情報のために原規定(RFC 2045)の著者に連絡をとる場合には，インターネットメールを使うほうがよい。

   Ned Freed
   Innosoft International, Inc.
   1050 East Garvey Avenue South
   West Covina, CA 91790
   USA

   Phone: +1 818 919 3600
   Fax:   +1 818 919 3614
   EMail: ned@innosoft.com


   Nathaniel S. Borenstein
   First Virtual Holdings
   25 Washington Avenue
   Morristown, NJ 07960
   USA

   Phone: +1 201 540 8967
   Fax:   +1 201 993 3032
   EMail: nsb@nsb.fv.com

MIMEは，Internet Engineering Task ForceのRFC 822の拡張に関する作業グループの作業の結果である。作業グループ議長のGreg Vaudreuilには，次の連絡先によって連絡できるかもしれない。

   Gregory M. Vaudreuil
   Octel Network Services
   17080 Dallas Parkway
   Dallas, TX 75248-1905
   USA

   EMail: Greg.Vaudreuil@Octel.Com
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 Phone: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com Nathaniel S. Borenstein First Virtual Holdings 25 Washington Avenue Morristown, NJ 07960 USA Phone: +1 201 540 8967 Fax: +1 201 993 3032 EMail: 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: Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA EMail: Greg.Vaudreuil@Octel.Com