MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text
MIME[多目的インターネットメール拡張] パート3:
非ASCIIテクストのためのメッセージヘッダ拡張

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.

この文書はインターネットコミュニティのためにインターネット標準トラックプロトコルを指定し、改良のために議論と提案を要求します。どうぞ、標準化状態のための「インターネット役員プロトコル標準」(STD 1)の現行版とこのプロトコルのステータスを参照してください。このメモの配布は無制限です。

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

STD 11、RFC 822はUS-ASCIIメッセージヘッダについてかなりの詳細を指定しているメッセージ表現プロトコルを平らなUS-ASCIIテキストと定義し、メッセージ中身または本文を置いていきます。多目的のインターネットメール拡張またはMIMEと集合的に呼ばれる文書のこのセットは、可能にするメッセージ形式を再定義します。

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.

これらの文書は、RFC 934、STD 11とRFC 1049において文書化されました。けれどもより早い仕事に基づき、それらを拡張し、改訂します。RFC 822が本文についてほとんどそう言わなかったので、これらの文書は主としてRFC 822(というよりも改正)に同列です。

This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields.

この特定の文書はシリーズにおいて3番目の文書です。インターネットメールヘッダーフィールドで非US-ASCIIテキストデータを許すために、それはRFC 822への拡張を説明します。

Other documents in this series include:

このシリーズにおける他の文書は以下を含みます：

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.

これらの文書は、RFC 1521、1522と1590、自身のどれがRFC 1341の改訂であった1342です。RFC 2049の中の付録は違いを説明し、前のバージョンから変わります。

RFC 2045 describes a mechanism for denoting textual body parts which are coded in various character sets, as well as methods for encoding such body parts as sequences of printable US-ASCII characters. This memo describes similar techniques to allow the encoding of non-ASCII text in various portions of a RFC 822 [2] message header, in a manner which is unlikely to confuse existing message handling software.

印刷可能US-ASCII文字のシーケンスのようなボディ部分を符号化するための方法と同様に様々なキャラクタセットの中でコード化される原文のボディ部分を示すことに、RFC 2045はメカニズムを記述します。このメモは、RFC 822[2]メッセージヘッダの様々な部分において、ソフトウェアを処理している既存のメッセージを混乱させることがありそうにない方法の中で非アスキーテキストのエンコーディングを許す同様な技術を説明します。

Like the encoding techniques described in RFC 2045, the techniques outlined here were designed to allow the use of non-ASCII characters in message headers in a way which is unlikely to be disturbed by the quirks of existing Internet mail handling programs. In particular, some mail relaying programs are known to (a) delete some message header fields while retaining others, (b) rearrange the order of addresses in To or Cc fields, (c) rearrange the (vertical) order of header fields, and/or (d) "wrap" message headers at different places than those in the original message. In addition, some mail reading programs are known to have difficulty correctly parsing message headers which, while legal according to RFC 822, make use of backslash-quoting to "hide" special characters such as "<", ",", or ":", or which exploit other infrequently-used features of that specification.

RFC 2045の中で説明された符号化技術のように、ここで概説された技術は、プログラムを処理している既存のインターネットメールの奇抜さによって妨害されることがありそうにない方法でメッセージヘッダの中の非アスキーキャラクタの使用を許すようにデザインされました。特にいくつかのメールを置き直しているプログラムが(a)に知られている 他、(b)を保有する間、いくつかのメッセージヘッダフィールドを削除し アドレスの注文を中にそれに組み替える か、または、Ccフィールド、(c)は、ヘッダーフィールドの(垂直の)注文および／または(d)「包装」メッセージヘッダを種々の場所 オリジナルのメッセージのそれら に組み替えます。さらに、いくつかのメール読取りプログラムは、RFC 822に従って正当である一方、「<」、「,」、または「：」などの特殊文字を「隠す」ために、バックスラッシュ引用を利用するか、その仕様の他のまれに使われた機能を利用するメッセージヘッダを構文解析して、苦労を正しくすると知られています。

While it is unfortunate that these programs do not correctly interpret RFC 822 headers, to "break" these programs would cause severe operational problems for the Internet mail system. The extensions described in this memo therefore do not rely on little-used features of RFC 822.

これらのプログラムが正しくRFC 822ヘッダーを解釈しないことが不運な間、これらのプログラムを「壊すこと」はインターネットメールシステムのために厳しい業務事故を起こすでしょう。従って、このメモにおいて説明された拡張はRFC 822のほとんど使われなかった機能に依存していません。

Instead, certain sequences of "ordinary" printable ASCII characters (known as "encoded-words") are reserved for use as encoded data. The syntax of encoded-words is such that they are unlikely to "accidentally" appear as normal text in message headers. Furthermore, the characters used in encoded-words are restricted to those which do not have special meanings in the context in which the encoded-word appears.

代わりに、「通常の」印刷可能なASCII文字(「符号化されたワード」として知られています)の一定のシーケンスは符号化されたデータとして使用のために確保されます。符号化されるワードのシンタックスは、それらが、メッセージヘッダの中の標準テキストとして「偶然」出現することがありそうにないほどです。さらに、符号化されるワードの中で使われたキャラクタは、符号化されたワードが出るコンテキストの中に特殊な意味を持っていないそれらに限定されます。

Generally, an "encoded-word" is a sequence of printable ASCII characters that begins with "=?", ends with "?=", and has two "?"s in between. It specifies a character set and an encoding method, and also includes the original text encoded as graphic ASCII characters, according to the rules for that encoding method.

一般に、「符号化されたワード」は、「=?」から始まり、「?=」によって終わり、間で2つの「？」をためている印刷可能なASCII文字のシーケンスです。それは文字セットと符号化方法を指定し、また、グラフィックのASCII文字として符号化された原本をその符号化方法のための規則によると含みます。

A mail composer that implements this specification will provide a means of inputting non-ASCII text in header fields, but will translate these fields (or appropriate portions of these fields) into encoded-words before inserting them into the message header.

この仕様を実施するメール作曲者は、ヘッダーフィールドで非アスキーテキストを入力する方法を提供するであろうけれども、それらをメッセージヘッダに挿入する前に、これらのフィールド(または、これらのフィールドの一部を計上してください)を符号化されるワードに翻訳するでしょう。

A mail reader that implements this specification will recognize encoded-words when they appear in certain portions of the message header. Instead of displaying the encoded-word "as is", it will reverse the encoding and display the original text in the designated character set.

それらがメッセージヘッダの一定の部分において出現する時に、この仕様を実施するメールリーダは符号化されるワードを認識するでしょう。符号化ワード 「として」 を表示し、「である」代わりに、それはエンコーディングをリバースし、明示された文字セットの原本を表示します。

An 'encoded-word' is defined by the following ABNF grammar. The notation of RFC 822 is used, with the exception that white space characters MUST NOT appear between components of an 'encoded-word'.

『encoded-word』は以下のABNF文法によって定義されます。RFC 822の表記法は、空白類キャラクタが‘符号化されたワード’のコンポーネントの間で表れてはならないのを除いて使われます。

Both 'encoding' and 'charset' names are case-independent. Thus the charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the encoding named "Q" may be spelled either "Q" or "q".

『encoding』と『charset』名共に大文字小文字を区別しません。従って、「ISO-8859-1」というcharset名は、「iso-8859-1」と等しく、符号化名付けられた「Q」は「Q」または「q」と綴られえます 。

An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used.

一つの『encoded-word』は、『charset』、『encoding』、『encoded-text』そして、区切り記号(delimiter) を含め 75文字を超えてはいけません。もし75文字の『encoded-word』に収まりきらない、より多くのテクストを符号化する必要がある場合は、(CRLF または SPACE で区切られた) 複数の『encoded-word』を使用してください。

While there is no limit to the length of a multiple-line header field, each line of a header field that contains one or more 'encoded-word's is limited to 76 characters.

複数の行からなるヘッダフィールドの長さに制限はありませんが、1つ以上の『encoded-word』を含むそれぞれの行は、76文字に制限されます。

The length restrictions are included both to ease interoperability through internetwork mail gateways, and to impose a limit on the amount of lookahead a header parser must employ (while looking for a final ?= delimiter) before it can decide whether a token is an "encoded-word" or something else.

この長さ制限は、ネットワーク間のメイルゲートウェイの相互運用を容易にするためと、token が 「encoded-word」 かそれ以外かをヘッダ解析器が決めることができる前に(最後の「?=」区切り記号を探す間)しなければならない先読みの量を制限するためにあります。

The 'charset' portion of an 'encoded-word' specifies the character set associated with the unencoded text. A 'charset' can be any of the character set names allowed in an MIME "charset" parameter of a "text/plain" body part, or any character set name registered with IANA for use with the MIME text/plain content-type.

『encoded-word』の『charset』パートは、符号化前のテクストの文字集合を指定します。『charset』は、『text/plain』ボディパートの MIME『charset』パラメータに許された任意の文字集合名か、MIME text/plain content-type とともに使うために IANA に登録された任意の文字集合名が可能です。

Some character sets use code-switching techniques to switch between "ASCII mode" and other modes. If unencoded text in an 'encoded-word' contains a sequence which causes the charset interpreter to switch out of ASCII mode, it MUST contain additional control codes such that ASCII mode is again selected at the end of the 'encoded-word'. (This rule applies separately to each 'encoded-word', including adjacent 'encoded-word's within a single header field.)

いくつかの文字集合は「ASCIIモード」と他のモードとの間を切り替えるコード切り替えの手法を用いています。もし一つの『encoded-word』中の符号化前のテクストが文字集合解釈器に対して ASCIIモードから他のモードへの切り替えるを指示するようなシーケンスを含むなら、『encoded-word』の最後でASCIIモードが選択されるような制御文字を含まなければなりません。(このルールは、単独のヘッダフィールド内部の隣接する『encoded-word』を含む、それぞれの『encoded-word』に対して独立に適用されます)。

When there is a possibility of using more than one character set to represent the text in an 'encoded-word', and in the absence of private agreements between sender and recipients of a message, it is recommended that members of the ISO-8859-* series be used in preference to other character sets.

『encoded-word』中のテクストを表現するために、1つ以上の文字集合を使う可能性があるときは、送信者と受信者の間の合意がない場合、他の文字集合を使うよりも、ISO-8859-* シリーズを用いることが推奨されます。

Initially, the legal values for "encoding" are "Q" and "B". These encodings are described below. The "Q" encoding is recommended for use when most of the characters to be encoded are in the ASCII character set; otherwise, the "B" encoding should be used. Nevertheless, a mail reader which claims to recognize 'encoded-word's MUST be able to accept either encoding for any character set which it supports.

はじめに、「encoding」の正しい値は、「Q」と「B」である。これらの符号化は後述する。「Q」符号化法は、符号化されるほとんどの文字が ASCII文字集合にあるものであるとき使うことが推奨されます。そのほかの場合は、「B」符号化が使われるべきです。それでも、『encoded-word』を認識するとするメールリーダは、サポートするいかなる文字集合に対しても両方の符号化法を受け入れることができなければなりません。

Only a subset of the printable ASCII characters may be used in 'encoded-text'. Space and tab characters are not allowed, so that the beginning and end of an 'encoded-word' are obvious. The "?" character is used within an 'encoded-word' to separate the various portions of the 'encoded-word' from one another, and thus cannot appear in the 'encoded-text' portion. Other characters are also illegal in certain contexts. For example, an 'encoded-word' in a 'phrase' preceding an address in a From header field may not contain any of the "specials" defined in RFC 822. Finally, certain other characters are disallowed in some contexts, to ensure reliability for messages that pass through internetwork mail gateways.

印刷可能なASCII文字のサブセットだけが『encoded-text』において使われるかもしれません。最初と『encoded-word』の終わりが明らかであるように、スペースとタブ文字は許されません。「？」キャラクタは、互いから『encoded-word』の様々な部分を分離する『encoded-word』中で使われて、それから、『encoded-text』部分において表れることができません。他のキャラクタは一定のコンテキストの中でまた不当です。例えば、Fromヘッダーフィールドにアドレスに先行している『フレーズ』において『encoded-word』はRFC 822中で定義された「スペシャル」の少しも含まないかもしれません。最終的に、ある他の登場人物は、インターネットワークメールゲートウェイを通過するメッセージに信頼性を保証するためにいくつかのコンテキストの中で却下されます。

The "B" encoding automatically meets these requirements. The "Q" encoding allows a wide range of printable characters to be used in non-critical locations in the message header (e.g., Subject), with fewer characters available for use in other locations.

「B」エンコーディングは自動的にこれらの必要条件を満たしています。「Q」エンコーディングは、様々な印字可能文字が他の位置での使用のために使用可能なより少ないキャラクタによってメッセージヘッダ(例えばサブジェクト)中の臨界でない位置で使われることを可能にします。

The "B" encoding is identical to the "BASE64" encoding defined by RFC 2045.

「B」エンコーディングはRFC 2045によって定義された「BASE64」エンコーディングに同一です。

The "Q" encoding is similar to the "Quoted-Printable" content-transfer-encoding defined in RFC 2045. It is designed to allow text containing mostly ASCII characters to be decipherable on an ASCII terminal without decoding.

「Q」エンコーディングはRFC 2045の中で定義された「Quoted-Printable」コンテンツ転送エンコーディングに類似しています。それは、たいていASCII文字を含んでいるテキストがデコーディングなしでASCII端末の上で判読できることを可能にするようにデザインされます。