標準仕様書(TS) TS X 0069:2005
多目的インターネットメール拡張(MIME)−
第1部:インターネットメッセージ本体のフォーマット
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 適用範囲
Abstract
インターネット公式プロトコル規定STD 11であるRFC 822では,US-ASCIIメッセージヘッダについて多くの詳細を規定したメッセージ表現プロトコルを定義しているが,メッセージ内容又は,すなわちメッセージ本体については,構造のないUS-ASCIIテキストだけとしている。この標準仕様書(TS)を含む一連の標準仕様書(TS)は,多目的インターネットメール拡張又はMIMEと総称され,次のことを可能とするために,メッセージのフォーマットを再定義する。
- US-ASCII以外の文字集合でのテキストのメッセージ本体。
- 非テキストのメッセージ本体のための
種々の異なるフォーマットの拡張集合。
- マルチパートのメッセージ本体。
- 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. 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
用語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. Character Set
用語“文字集合”は,MIMEでは,オクテット列を文字列をに変換する方法として参照されるものとする。無条件であいまいでないあいまい性のない逆方向への変換は要求されないことに注意すること。すなわち,与えられた一つの与えられた文字集合によってはが,必ずしもすべての文字が表現可能でなくともよくを表現できないともよいし,特定の文字列を表現するのに2通り二つ以上のオクテット列を提供してもよい。
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. 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. 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. Body Part
用語“本体部分”は,マルチパート実体の中の内部の実体とする。
The term "body part" refers to an entity inside of a multipart
entity.
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.
“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. 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. Binary Data
“2値データ”は,どのようなオクテットの列も含むことができるデータとする。
"Binary data" refers to data where any sequence of octets whatsoever
is allowed.
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 Header Fields
MIMEは,MIME実体の内容を記述するために使用される幾つかの多くの新しいRFC 822ヘッダフィールドを定義する。これらのヘッダフィールドは,少なくとも次の二つの文脈で生じる出現する。
- 通常のRFC 822メッセージヘッダの一部として。
- マルチパート構成内で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 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 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. 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 :=
x-token :=
subtype := extension-token / iana-token
iana-token :=
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*
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:
- “X-”で始まる私的な値は,外部での登録又は標準化なしに
2つ二つの協力的エージェントの間で双対的に双方で(合意して)定義してよい。このようなこれら値は,登録又は標準化することはできない。
- 新しい標準の値は,TS X 0106
RFC 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 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 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 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-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章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符号化は,任意の領域からの入力を“77ビット”範囲のデータへと変換するので,制限のあるトランスポート上で運ぶことを安全にする。変換の特定の定義は,次とする次のとおり。
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ラベルがいつでも常に使われなければならない。88ビット文字を含む符号化されていないデータを“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”領域への単一の変換(抜け)だけを制定することはできそうにない。多くのバイナリデータのコンパクト小規模で効率的な符号化の望みに対する要望と,ほとんどが77ビットであるけれどもだがすべてではないデータの(抜け)ある程度可読性のある符号化に対する要望との間のにはトレードオフが存在する。この理由によりよって,少なくとも2つ二つの符号化機構,すなわち,おおよそ多かれ少なかれ可読性のある符号化(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された符号化されていない88ビットデータのメールトランスポート?転送は,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フィールドのために定義される5つ五つの値は,(抜け)そのフィールドが符号化されたアルゴリズム,又は復号されるときの符号化されない場合には転送?トランスポートシステム要件以外は,メディア型について何も想定しない示唆しない。
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. 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. 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. 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. 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
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つ一つ又は両方の文字が小文字の“abcdef”のうちのいずれかの小文字であるとなっている2つ二つの16進数字に後続される“=”は,公式には不正である形式的には不正とする。エラー強さのある頑健な実装は,それらを対応する大文字として認識しうるするとよいかもしれない。
(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.
- “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.
- “=”は,符号化されたオブジェクトの中で最後又は最後から2番目の文字と
なりえないなることはできない。これは,上記前項の2番目の場合として取り扱えよう取り扱ってよい。
(3) An "=" cannot be the ultimate or penultimate character
in an encoded object. This could be handled as in case
(2) above.
- TAB,又はCRLF対の
部分一部としてのCR及びLF,以外の制御文字は現れてはならない。10進の値が126より大きい値のオクテットでも同じであるに対しても同じとする。もし,(追加)それら文字が,復号器によって,到着したquoted-printableデータの中に発見されたならば場合,頑健な実装は,復号されたデータから(抜け)それら文字を除外し,利用者に不正データ文字が発見されたことを警告するとよいとよいかもしれない。
(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.
- 符号化した行は,末尾の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 :=
; 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
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入力はオクテットの整数倍の数であるからなので,次の場合だけがありえる発生する。
- 符号化入力の最後の
符号化量は分量が,24ビットの整数倍であるになっている。つまりこの場合,符号化出力の最後の単位(かたまり)は,“=”パディングなしで4文字の整数倍となる。
- 符号化入力の最後の
符号化量は分量が,ちょうど8ビットであるになっている。つまりこの場合,符号化出力の最後の単位(かたまり)は,2二つの文字に,二つの“=”パディング文字が2つ後続したものとなる。
- 符号化入力の最後の
符号化量は分量が,ちょうど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 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 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. 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 :=
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. Security Considerations
セキュリティに関しては,MIMEを規定する2番目の一連の標準仕様書(TS)であるの中のRFC 2046を翻訳した原規定とするTS X 0070で論じられる。
Security issues are discussed in the second document in this set, RFC
2046.
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