6.7. Quoted-Printable Content-Transfer-Encoding
 エンコードタイプ 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.

Quoted-Printableエンコーディングは、主として、US-ASCII文字セットの中の印字可能文字と一致している8ビットバイトから成るデータを表すことを意図しています。 結果として生じている8ビットバイトが、メールトランスポートによって修正されることがありそうにないそのような方法で、それはデータを符号化します。 符号化されているデータがたいていUS-ASCIIテキストであるならば、データの符号化された形式は主として人によって認識可能であり続けます。 完全に、US-ASCIIであるボディは、また、メッセージが万一キャラクタ翻訳の、そして/または行包みのゲートウェイを通過するならばデータの完全性を保証するためにQuoted-Printableにおいて符号化されるかもしれません。

In this encoding, octets are to be represented as determined by the following rules:

このエンコーディングにおいて、8ビットバイトは、以下の規則によって決定されることとして見せられることになっています:

  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.

    (一般の8ビットの表現)どれでも8ビットバイトは、符号化されているデータの正規の(標準)形式のCRLF改行の一部であるCRまたはLFを除いて、8ビットバイトの値の2桁の16進の表現が後に続く「=」によって表されているかもしれません。この目的のための16進のアルファベットの数字は「0123456789ABCDEF」です。大文字が使われなければなりません。小文字は許されません。例えば、10進値12(US-ASCII書式送り)は「=0C」によって表されることができて、10進値61(US-ASCII EQUAL SIGN)は「=3D」によって表されることができます。以下の規則が代替のエンコーディングを許す時を除いて、この規則は従われなければなりません。

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

    33から包含的な60と62から126の10進値を持つ8ビットバイトは、包含的に、それらの8ビットバイト(より少なく、直通であるより大きなチルダを通しての、それぞれの感嘆符)と一致しているUS-ASCIIキャラクタとして見せられるかもしれません。(リテラル表現)

  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.

    (空白類)9と32の値を持つ8ビットバイトはそれぞれ私達アスキータブ(ht)と間隔文字として見せられるかもしれないけれども、符号化された行の終わりにそう表されていてはなりません。符号化された行の上のどのようなタブ(ht)または間隔文字にでも従ってその行の上で印字可能文字が続いていなければなりません。特に柔軟路線破壊(規則#5を見てください)が1つ以上のタブ(ht)または間隔文字に続くかもしれないのを示している符号化された行の終わりの「=」。規則#1に従って、10進を持つ8ビットバイトが9を見積もることになるか、符号化された行の終わりの32の出現が表されていなければなりません。いくつかのMTAs(メッセージトランスポート エージェント(一方のユーザからのメッセージを別のものに輸送するか、そのような転送の一部を実行するプログラム))が、スペースによってテキストの行をパディングすると知られていて、他が、「空白類」キャラクタを行の終わりから削除すると知られているので、この規則は必要です。 従って、quoted-printableボディをデコードする時に、それが必ず中間の運送業者によって追加されているであろう時に、行の上のどのような引きずる空白類でも削除されなければなりません。

  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シーケンスとして見せられたテキスト本文の中の改行は(RFC 822)改行によって表されていなければなりません(それはまたquoted-printableエンコーディングにおいてCRLFシーケンスです)。テキスト以外のメディアタイプの正規の表現以来、CRLFシーケンス、どの強硬路線破壊(すなわち、有意味で、ユーザに表示されることを意図している改行)もそのようなタイプのquoted-printableエンコーディングに存在することができる時に、一般に改行の表現を含まないでください。「=0D」、「=0A」、「=0A=0D」、「=0D=0A」のようなシーケンスはもちろん印刷可能な引用において説明された非テキストデータの中で定期的に出現するでしょう。

    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.

    多くのインプリメンテーションが、最初に符号化して、基準形式に変換し、それからローカルな表現に後ろで変換するというよりも直接様々なコンテントタイプのローカルな表現を符号化することを決定するかもしれないことに注意してください。 特に、これは、CRLFターミネータシーケンス以外の復改規定を使うシステムの上の普通テキスト素材にあてはまるかもしれません。しかし、結合された canonicalization-encoding (正規化された符号化) ステップが機能に相当する時のみ 3つのステップは別々に実行されます。

  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.

    (ソフト改行) quoted-printableエンコーディングは、符号化された行が長い間たった76文字であることを必要としています。より長い行が、quoted-printableエンコーディングによって符号化されることになっているならば、「柔らかい」改行は使われなければなりません。符号化された行の上の最後のキャラクタとしての等号は符号化されたテキストの中でそのような有意でない(「柔らかい」)改行を示します。

Thus if the "raw" form of the line is a single unencoded line that says:

従って、行の「raw」形式が、言う1本の符号化されなかった行であるならば:

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:

これは次としてQuoted-Printableエンコーディングにおいて表されることができます:

Now's the time =
for all folk to come=
 to the aid of their country.

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.

これはメカニズムに、どの長い行が、ユーザエージェントによって復元されるためのそのような方法で符号化されるかを提供します。76文字の限界は引きずるCRLFをカウントしないけれども、どのような等号でも含めて、すべての他のキャラクタをカウントします。

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エンコーディングにおいて自身として表されることができるので、注意は、バウンダリデリミタが符号化されたボディの中でどこでも出現しないと保証する印刷可能に引用された符号化されたボディが1つ以上の複数パート実体の中でカプセル化する時のために払われなければなりません。(よい戦略は、印刷可能に引用されたボディの中で決して出現することができない)「=_」(などのキャラクタシーケンスを含むバウンダリを選ぶことになっています。)(RFC 2046の中で複数パートメッセージの定義を見てください。)

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

注意事項: quoted-printableエンコーディングはトランスポートの中で読み込み可能性と信頼性の間のちょっとした妥協案を表しています。quoted-printableエンコーディングによって符号化されたボディは確かに上で最もメールゲートウェイを作動させるであろうけれども、少しのゲートウェイ(特にEBCDICへのそれらの関係翻訳)上で完全に作業しないかもしれません。より高い信頼度はBase64コンテンツ転送エンコーディングによって提供されます。EBCDICゲートウェイを通して信頼できるトランスポートのために適度に取ってくる方法は、またUS-ASCII文字を引用することです。

!"#$@[\]^`{|}~

according to rule #1.

規則#1によると。

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エンコーディングというよりもBase64エンコーディングを使うことはたぶんもっと分別があります。

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.

注意事項: いくつかの種類のサブストリングはquoted-printableコンテンツ転送エンコーディングのために符号化規則に従って生成されることができなく、それゆえ、それらがquoted-printableエンコーダの出力において出現するならば、形式上不当です。 この注はこれらのケースを列挙し、いくらかがデコードされた将来のquoted-printableデータの中で出会われるならば、そのような不当なサブストリングを処理する方法を示唆します。

  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つの16進数字、ものによって続いていたか、両方とも、どれが「abcdef」において小文字であるかのうちの、フォーマルに不当です。 頑強なインプリメンテーションは、それらを対応する大文字と認識することに決めるかもしれません。

  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.

    16進数字(含む「abcdef」)やCRLFペアのCRキャラクタのどちらでもない性格によって後に続く「=」は不当です。このケースはquoted-printableエンコーディングを受けて、自身なしでメッセージのquoted-printable一部に含められていてUS-ASCIIテキストの結果であるかもしれません。頑強なインプリメンテーションによる妥当なアプローチは、「=」キャラクタと以下のキャラクタをどのような変形ものないデコードされたデータに含めることであるかもしれず、可能ならば、適切なデコーディングがデータの中のこのポイントで可能でなかったことをユーザに示します。

  3. An "=" cannot be the ultimate or penultimate character in an encoded object. This could be handled as in case (2) above.

    「=」は符号化されたオブジェクトの中で究極の、または語尾から2番目の音節のキャラクタであるはずがありません。上の場合(2)ののように、これは処理されることができました。

  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ペアの一部としてのCRとLFまたはTAB以外の制御文字は出現してはなりません。 同じことは8ビットバイトのために126より大きい10進値にあてはまります。受信のquoted-printableデータの中でデコーダによって発見されるならば、頑強なインプリメンテーションは、それらをデコードされたデータから除外し、違法文字が発見されることをユーザに警告するかもしれません。

  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.

    符号化されたラインは、引きずるCRLFをカウントしないで76文字より長くてはなりません。 より長いラインが受信の、符号化されたデータの中で発見されるならば、頑強なインプリメンテーションはそれにもかかわらずラインをデコードするかもしれず、誤ったエンコーディングをユーザに報告するかもしれません。

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.

実装者に対する警告: 2進データがquoted-printableで符号化されるならば、それぞれ「=0D」と「=0A」としてCRとLFのキャラクタを符号化するために注意を払われなければなりません。特に、バイナリデータの中のCRLFシーケンスは「=0D=0A」として符号化されるべきです。さもなければ、CRLFが強制的な改行として見せられたならば、それは違う改行規定によってプラットホームの上で間違ってデコードされるかもしれません。

For formalists, the syntax of quoted-printable data is described by the following grammar:

形式主義者のために、quoted-printableデータのシンタックスは以下の文法によって説明されます:

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
           ; 最大長は 76文字

qp-segment := qp-section *(SPACE / TAB) "="
              ; Maximum length of 76 characters
              ; 最大長は 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>
             ; Characters not listed as "mail-safe" in
             ; RFC 2049 are also not recommended.
         ; <10 進値で 33~60、および 62~126 までのあらゆるオクテット>
         ; RFC 2049において「mail-safe」として、リストされなかったキャラクタは、
         ; 同じく勧められません。

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".
         ; 8ビットバイトはラインの終わりにキャラクタ >127、 =、スペース、
         ; またはタブのために使われなければならず、「メール金庫」として
         ; RFC 2049中でリストにされなかったどのようなキャラクタにでも推薦されます。

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.
         ; コンポーザーは0でない長さのトランスポート充てん文字を生成しては
         ; ならないけれども、レシーバは、メッセージトランスポートによって
         ; 追加された充てん文字を処理することができなければなりません。

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.

重要: このBNFが構造化されたヘッダーフィールドを指定しないので、このBNFにおいて示されたエレメントの間のLWSPの加算は許されません。

6.8. Base64 Content-Transfer-Encoding
 エンコードタイプ Base64

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.

Base64 Content-Transfer-Encodingは、人間らしく読取り可能である必要がない形式において8ビットバイトのきまぐれな順番を表すようにデザインされます。符号化し、デコーディングのアルゴリズムは単純であるけれども、符号化されたデータは符号化されなかったデータより一貫してわずか約33パーセント大きい。RFC 1421中で定義されるように、このエンコーディングは事実上Privacy Enhanced Mail(PEM)アプリケーションの中で使われたものに同一です。

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の65の文字部分集合が、6ビットが1つの印字可能文字あたり説明されることを可能にして、使われます。 (特別な65番目の文字は「=、」特殊な処理要素を意味するために使われます。)

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.

注意事項: このサブセットは、それがUS-ASCIIを含むISO646のすべてのバージョンの中で同一に表されていて、サブセットの中のすべてのキャラクタがEBCDICのすべてのバージョンの中で同一にまた表されているという重要な特性を持っています。 uuencodeユーティリティによって使われたエンコーディング(とベース85エンコーディングがレベル2PostScriptの一部として指定したマッキントッシュbinhex 4.0[RFC-1741])などの他のポピュラーなエンコーディングはこれらの特性を共有しなく、それから、メールのための2進のトランスポートエンコーディングが合わなければならないというポータビリティ必要条件を満たしません。

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.

符号化プロセスは4つの符号化されたキャラクタの出力ストリングとして入力ビットの24ビットのグループを代表します。左から右に進んで、24ビットの入力グループは、3つの8ビットの入力グループに連結することによって結成されます。これらの24ビットはその時4つの連結された6ビットのグループとして扱われます(それのそれぞれはBase64アルファベットの中の1つの数字に翻訳されます)。Base64エンコーディング経由でビットストリームを符号化する時に、ビットストリームは、最も有意なビットの一番目によって配列されると推定されなければなりません。すなわちストリームの中の最初のビットは最初の8ビットのバイトの中で最上位ビットになるであろうし、8番目のビットは最初の8ビットのバイトなどの中で最下位ビットになるでしょう。

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

各6ビットのグループは64の印字可能文字の配列の中にインデックスとして使われます。インデックスによって参照されたキャラクタは出力ストリングに置かれます。下でテーブル1中で識別されたこれらのキャラクタは、一般的に表現可能であるように選ばれて、SMTP(「.」、CR、LF)に、そしてRFC 2046(例えば「-」)RFCの中で定義された複数パートバウンダリデリミタにセットは特定の重みによってキャラクタを除きます。

               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

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.

符号化された出力ストリームはそれぞれたった76文字のラインの中で表されていなければなりません。すべての改行またはテーブル1中で発見されなかった他のキャラクタは、ソフトウェアをデコードすることによって無視されなければなりません。Base64データの中で、テーブル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.

24ビットより少しが符号化されているデータの終わりに使用可能ならば、特殊な処理は実行されます。完全な符号化量子はボディの終わりにいつも完成します。24の入力ビットより少しが入力グループで使用可能な時に、ゼロビットは、6ビットのグループの整数を成形するために追加されます(右の上)。データの終わりの充てん文字は、「=」キャラクタを使って、実行されます。すべてのBase64入力が8ビットバイトの整数であるので、以下のケースだけが生じることができます。(1)エンコーディング入力の最終的な量子は24ビットの整数倍です。ここで、符号化された出力の最終的なユニットは「=」充てん文字なしで4文字の整数倍になるでしょう。(2)エンコーディング入力の最終的な量子はちょうど8ビットです; ここで、符号化された出力の最終的なユニットはまたは2つの「=」が後に続く2文字になるでしょう。(3)エンコーディング入力の最終的な量子はちょうど16ビットです; ここで、符号化された出力の最終的なユニットは1つの「=」パディング文字が後に続く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.

それが、データの終わりに徒歩旅行するためだけに使われるので、どのような「=」キャラクタの発生でも、データの終わりが取って来られている(通過における切捨てなしで)証拠としてとられるかもしれません。転送された8ビットバイトの数が3の倍数であった時に、しかしどのそのような保証も可能でなく、どの「=」キャラクタも出現していません。

Any characters outside of the base64 alphabet are to be ignored in base64-encoded data.

Base64アルファベットの外のどのようなキャラクタでも、Base64符号化されたデータの中で無視されることになっています。

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エンコーディングが、直接、基準形式に変換されていないテキスト素材に適用されるならば、注意は、改行のために適切な8ビットバイトを使うように払われなければなりません。特に、テキスト改行はBase64エンコーディングに先がけてCRLFシーケンスに変換されなければなりません。注目する重要なものは、これがいくつかのインプリメンテーションの中の事前の正規化ステップの中というよりも直接エンコーダによってされるかもしれないことです。

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.

注意事項: どのハイフンキャラクタもBase64エンコーディングに用いられないので複数パート実体の中でBase64符号化されたボディの中で潜在的なバウンダリデリミタを引用することについて悩む必要は全然ありません。

7. Content-ID Header Field
 Content-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:

高水準のユーザエージェントを構成することにおいて、一方のボディが別のものへのリファレンスをすることを可能にすることは望ましいかもしれません。それに応じて、ボディは、「Content-ID」ヘッダーフィールドを使って、ラベルを貼られるかもしれません(それは「Message-ID」ヘッダーフィールドに統語的に同一です):

id := "Content-ID" ":" msg-id

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

Message-ID値のように、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値は、いくつかのコンテキストの中で独特にMIME実体を識別するため、特に、メッセージ/外部ボディメカニズムによって参照されたデータをキャッシュするために使われるかもしれません。Content-IDヘッダーが一般にオプションであるけれども、その使用は、オプションのMIMEメディアタイプ「message/external-body」のデータを生成するインプリメンテーションの中で義務的です。すなわち各message/external-body実体は、そのようなデータのキャッシングを許すためにContent-IDフィールドを持たなければなりません。

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.

Content-ID値がmultipart/alternativeのメディアタイプの場合に特殊な意味論を持っていることはまた注目する価値があります。これは、multipart/alternativeを扱って、RFC 2046のセクションの中で説明されます。

8. Content-Description Header Field
 Content-Description ヘッダフィールド

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

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.

RFC 2047の中で指定されたメカニズムが非US-ASCII Content-Description値のために使われるかもしれないけれども、説明は、US-ASCII文字セットの中で与えられると推定されます。

9. Additional MIME Header Fields
 付加的な MIME ヘッダフィールド

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ヘッダーフィールドを定義することを決定するかもしれません。さらに、メッセージの内容を説明するどのような新しいヘッダーフィールドでも、メッセージヘッダの中で、通常のRFC 822メッセージヘッダフィールドと区別されるようなそのようなフィールドを許すためにストリング「Content-」から始まるべきです。

MIME-extension-field := <Any RFC 822 header field which
                         begins with the string
                         "Content-">
         ; <「Content-」という文字列で始まる
         ;  あらゆる RFC 822 ヘッダフィールド>

10. Summary
 要約

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バージョン、Content-Type、およびContent-Transfer-Encodingのヘッダーフィールドを使って、標準化された方法でデータの任意のタイプをRFC822に準じた私信メッセージに含めることは可能です。RFC 821またはRFC 822のどちらかによって課されたどの制限も違反されなく、注意は、いくつかのインターネットメール移送機構(RFC 2049を見てください)の特徴によって課された追加の制限によって起こされた問題を避けるために払われています。

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

このセットにおける次の文書、RFC 2046は、これらのヘッダーを使って、ラベルを貼られて、輸送されることができるメディアタイプの初期のセットを指定します。

11. Security Considerations
 セキュリティ対策

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

セキュリティ問題はこのセットにおける2番目の文書、RFC 2046の中で議論されます。

12. Authors' Addresses
 奥付

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:

MIMEはRFC 822拡張の上のインターネット技術特別調査委員会作業グループの作業の結果です。そのグループの会長、Greg Vaudreuilに以下から連絡することができます:

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

EMail: Greg.Vaudreuil@Octel.Com

Appendix A -- Collected Grammar
 付録 A -- 収集された文法

This appendix contains the complete BNF grammar for all the syntax specified by this document.

この文書によって指定されたすべての構文のためにこの付録は完全なBNF文法を含んでいます。

By itself, however, this grammar is incomplete. It refers by name to several syntax rules that are defined by RFC 822. Rather than reproduce those definitions here, and risk unintentional differences between the two, this document simply refers the reader to RFC 822 for the remaining definitions. Wherever a term is undefined, it refers to the RFC 822 definition.

しかし、単独で、この文法は不完全です。RFC 822によって定義されるいくつかの構文規則に、それは名前によって差し向けます。ここでそれらの定義を複写し、両者の故意でない違いを思い切ってやってみるというよりも、この文書は単に残存定義のためにリーダをRFC 822に差し向けます。 たとえ、項がどこで不確定でも、それはRFC 822定義を参照します。


attribute := token
             ; Matching of attributes
             ; is ALWAYS case-insensitive.
             ; 属性の照合はいつも大文字小文字を区別しません。

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

content := "Content-Type" ":" type "/" subtype
           *(";" parameter)
           ; Matching of media type and subtype
           ; is ALWAYS case-insensitive.
    ; メディアタイプとサブタイプの照合はいつも大文字小文字を区別しません。

description := "Content-Description" ":" *text

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

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

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

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

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".
    ; 127 を超える文字、行末の =、空白、または TAB、そしてRFC 2049において
    ;「mail-safe」として、リストされなかったあらゆるキャラクタが推薦されます。

iana-token := <A publicly-defined extension token. Tokens
               of this form must be registered with IANA
               as specified in RFC 2048.>
    ; <公然と定義された拡張トークン。RFC 2048の中で指定されるように、
    ; この形式のトークンはIANAに登録されなければなりません。>

ietf-token := <An extension token defined by a
               standards-track RFC and registered
               with IANA.>
    ; <拡張トークンは標準トラックRFCによって定義し、IANAに登録しました。>

id := "Content-ID" ":" msg-id

mechanism := "7bit" / "8bit" / "binary" /
             "quoted-printable" / "base64" /
             ietf-token / x-token

MIME-extension-field := <Any RFC 822 header field which
                         begins with the string
                         "Content-">
    ; <「Content-」から始まるどのようなRFC 822ヘッダーフィールド>

MIME-message-headers := entity-headers
                        fields
                        version CRLF
                        ; The ordering of the header
                        ; fields implied by this BNF
                        ; definition should be ignored.
    ; このBNF定義によって暗示されているヘッダーフィールドの
    ; 記述は無視されるべきです。

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.
    ; 「content-」から始まっていないどのようなフィールドでも定義された
    ; 意味を全然持つことができなく、無視されるかもしれません。
    ; このBNF定義によって暗示されているヘッダーフィールドの記述は
    ; 無視されるべきです

parameter := attribute "=" value

ptext := hex-octet / safe-char

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

qp-part := qp-section
           ; Maximum length of 76 characters

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

qp-segment := qp-section *(SPACE / TAB) "="
              ; Maximum length of 76 characters
              ; 最大長は 76文字

quoted-printable := qp-line *(CRLF qp-line)

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.
    ; <33から包含的な60と62から126の10進値を持つどのような
    ;  8ビットバイトでも>
    ; RFC 2049の中の「mail-safe」としてリストにされなかった
    ; キャラクタはまた勧められません。

subtype := extension-token / iana-token

token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
            or tspecials>

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.
    ; コンポーザーは非0の長さトランスポート充てん文字を生成しては
    ; ならないけれども、レシーバは、メッセージトランスポートによって
    ; 追加された充てん文字を処理することができなければなりません

tspecials :=  "(" / ")" / "<" / ">" / "@" /
              "," / ";" / ":" / "\" / <">
              "/" / "[" / "]" / "?" / "="
              ; Must be in quoted-string,
              ; to use within parameter values
    ; 引用符で囲まれる文字列でなければなりません。

type := discrete-type / composite-type

value := token / quoted-string

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

x-token := <The two characters "X-" or "x-" followed, with
            no  intervening white space, by any token>
    ; <2文字「X-」または「x-」はどのようなトークンによってでも
    ;  介在空白類なしで続いていました。>