RFC1522 日本語訳
1522 MIME (Multipurpose Internet Mail Extensions) Part Two: MessageHeader Extensions for Non-ASCII Text. K. Moore. September 1993. (Format: TXT=22502 bytes) (Obsoletes RFC1342) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Status: DRAFT STANDARD)
RFC一覧
英語原文
Network Working Group K. Moore Request for Comments: 1522 University of Tennessee Obsoletes: 1342 September 1993 Category: Standards Track | MIME (Multipurpose Internet Mail Extensions) Part Two: | Message Header Extensions for Non-ASCII Text MIME (Multipurpose Internet Mail Extensions)パートII: 非ASCIIテキスト対応メッセージヘッダの拡張 | Status of this Memo メモのステータス | This RFC 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" for the standardization state and status | of this protocol. Distribution of this memo is unlimited. この RFC では、インターネット社会におけるインターネット・スタンダード・ トラックとなったプロトコルの仕様を定義します。また、よりよい発展のた めに、このプロトコルについての議論、提案を広く求めます。このプロトコ ルの現在の規格化のステート、およびステータスの詳細については、最新版 の『Internet Official Protocol Standards』を参照してください。このメ モの再配布は、自由におこなってください。 | Abstract 概要 | This memo describes an extension to the message format defined in RFC | 1521 [1], to allow the representation of character sets other than | ASCII in RFC 822 (STD 11) message headers. The extensions described | were designed to be highly compatible with existing Internet mail | handling software, and to be easily implemented in mail readers that | support RFC 1521. このメモでは、 RFC822 (STD 11) でメッセージヘッダとして定められた非 ASCII の文字セットを使った表現を許す、 RFC1521 [1] で定義されたメッセー ジフォーマットへの拡張について説明します。ここで説明するヘッダへの拡 張は、現在インターネットで広く使われているメールの処理をするソフトウェ アとの共存ができるように考慮されています。またこの拡張により、 RFC1521 形式のメールリーダの実装を容易にすることを狙っています。 | 1. Introduction 1. はじめに | RFC 1521 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 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. RFC1521 では、様々な文字セットで記述されているテキストのボディパート を、表示可能な ASCII コード文字へとエンコードすることでその表現を可能 にする仕組みについて説明しました。このメモでは、非 ASCII コードのテキ ストを既存のメッセージハンドラを混乱させないようにエンコードして、 RFC822 [2] 準拠のメッセージヘッダの一部として使えるようにする方法につ いて説明します。 | Like the encoding techniques described in RFC 1521, 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. RFC1521 で説明されているエンコードの場合と同様に、この手法では既存の インターネットで使われているメールハンドルプログラムを混乱させること なく非 ASCII コードの文字を使えるように考慮されています。特に、いくつ かのメール転送プログラムでは、次のような現象が起きることがあります。 (a) ヘッダ中にある特定のフィールドがあると関連する別のフィールドを破棄 する。 (b) To: フィールドや Cc: フィールドのアドレスの順番を入れ換える。 (c) フィールドの出現順序を入れ換える。 (d) メッセージのヘッダが折り曲げられて、本来の位置とは違う場所に表示さ れる。 さらに、いくつかのメールリーダでは、「<」、「,」、「:」などの文字に対 しての RFC822 に従ったバックスラッシュを使ったクォーティングを、理解 できずにパースができなかったり、使用頻度が低い機能を指定した場合にも パースできなかったりします。 | 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. 不幸なことに、 RFC822 のヘッダを正しく解釈できないこのようなプログラ ムを破棄するということは、インターネットでのメールシステムの運用に深 刻な問題を引き起こすことになります。 このメモで説明する拡張では、このような使用頻度が低い RFC822 の特殊な 機能にも依存していません。 | 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. そのかわり、特定の「ごく普通に」表示可能な (「encoded-word」と呼ばれ る) ASCII コードの文字の集合がエンコードされたデータの表現用に予約さ れています。 encoded-word の文法は、通常のメッセージヘッダのテキスト 中に「偶然には」出現しにくいものにしてあります。 しかも、encoded-wordに使われる文字は、 encoded-word が出現する場所で 特別な意味を持たないように制限されます。 | 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. 一般に「encoded-word」は、表示可能な ASCII コードの文字からなる文字列 で、「=?」で始まり、「?=」で終ります。また、その間に2つの「?」があり ます。この文字列には、もとのテキストで使われている文字セットとエンコー ド方式、そしてテキストを表示可能な 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. メールの編集プログラムは、非 ASCII の文字セットを使ったヘッダフィール ドの入力を、 encoded-word に変換してメッセージヘッダ(フィールドの適切 な部分) に挿入します。 | 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. メールのリードプログラムは、このエンコードされたテキストが、メールヘッ ダの適切な部分に出現した場合にその記述を認識して、 encoded-word 「そ のもの」ではなくて、もとに戻したテキストを表示します。 | NOTES 注意 | This memo relies heavily on notation and terms defined STD 11, RFC | 822 and RFC 1521. In particular, the syntax for the ABNF used in | this memo is defined in STD 11, RFC 822, as well as many of the | terms used in the grammar for the header extensions defined here. | Successful implementation of this protocol extension requires | careful attention to the details of both STD 11, RFC 822 and RFC | 1521. このメモは、 STD 11、RFC 822、RFC 1521 に表記法や用語において強く 依存しています。特に、このメモで使われる ABNF の構文は、STD 11、 RFC 822 で定義されています。ヘッダの拡張に対しての文法で使われてい る用語についても同様です。このプロトコル拡張の正しい実装をするにあ たっては、STD 11、RFC 822、 RFC 1521 の詳細について理解しているこ とが要求されます。 | When the term "ASCII" appears in this memo, it refers to the "7- | Bit American Standard Code for Information Interchange", ANSI | X3.4-1986. The MIME charset name for this character set is "US- | ASCII". When not specifically referring to the MIME charset name, | this document uses the term "ASCII", both for brevity and for | consistency with STD 11, RFC 822. However, implementors are | warned that the character set name must be spelled "US-ASCII" in | MIME message and body part headers. また、このメモで「ASCII」と表記されるものは、『7-bit Ameriacan Standard Code for Information Interchange』, ANSI X3.4-1986 を暗黙 的に指すものとします。 MIME の charset 名でこの文字セットに対応す るのは、「US-ASCII」です。この文書では MIME の charset 名を指す場 合を除いて、簡潔さと STD 11、RFC 822 との一貫性のためにこの文字セッ トを表す用語として「ASCII」を使います。実装者は、 MIME のメッセー ジやボディ・パートのヘッダで指定する文字セット名には、必ず US-ASCII」と表記することに注意してください。 | 2. Syntax of encoded-words 2. encode-wordの構文 | An "encoded-word" is defined by the following ABNF grammar. The | notation of RFC 822 is used, with the exception that white space | characters MAY NOT appear between components of an encoded-word. 「encoded-word」は、 RFC822 が表記法として使っている ABNF 文法で、次 のように定義されています。この表記法は RFC 822 とほぼ同じですが、 encoded-word のコンポーネントの間に空白文字が出現しない点で異なります。 | encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" encoded-word = "=" "?" charset "?" encoding "?" encoded-text "?" "=" | charset = token ; see section 3 charset = token ; 第3章を参照のこと。 | encoding = token ; see section 4 encoding = token ; 第4章を参照のこと。 | token = 1*token = 1* <空白文字、制御文字、 especials を除いた任意の文字> | especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " | <"> / "/" / "[" / "]" / "?" / "." / "=" especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> / "/" / "[" / "]" / "?" / "." / "=" | encoded-text = 1* | ; (but see "Use of encoded-words in message | ; headers", section 5) encoded-text = 1*<表示可能な ASCII 文字で"?"、空白文字以外のいずれか> ; (第 5 章『メッセージヘッダでの encoded-word の使 ; い方』を参照のこと) | 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」と「iso-8859-1」は同じものを指し、エンコー ディング名「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-words (separated by CRLF SPACE) may be | used. encoded-word の長さは、文字セット、エンコード方式、エンコードされたテ キスト、デリミタを含めて、 75 文字以内にします。テキストをエンコード したテキストの長さが 75 文字で収まりきらない場合には、 ( CRLF または 空白文字で区切られた)複数の 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-words is limited to 76 characters. ヘッダフィールドは、複数行にわたって記述できるので、複数の encoded-word を含むメッセージヘッダ行の1行の長さは、 76 文字以内に制限されていま す。 | The length restrictions are included not only to ease | interoperability through internetwork mail gateways, but also 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. 長さの制限は、ネットワーク間を結ぶメールゲートウェイでの処理を簡単に するだけでなく、ヘッダのパーサがトークンの解析をして encoded-word を 見分ける場合に、 ( encoded-word の終了デリミタの ?= を探すために ) ス キャンしなくてはならない文字数を限定できます。 | The characters which may appear in encoded-text are further | restricted by the rules in section 5. エンコードされたテキストに出現する文字には、第 5 章で述べられている規 則で制限が加えられています。 | 3. Character sets 3. 文字セット | 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 RFC 1521 "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 [3]. (See section | 7.1.1 of RFC 1521 for a list of charsets defined in that document). encoded-word の「charset」の部分には、エンコード前のテキストの文字セッ トを指定しています。この charset には、 RFC 1521 での「text/plain」ボ ディ・パートのパラメータ「charset」に使える文字セット名、もしくは IANA で MIME の text/plain コンテントタイプ用に登録されている文字セットを 使うことができます [3] (RFC 1521 の 7.1.1 節にある charsets を定義し たリストを参照してください)。 | Some character sets use code-switching techniques to switch between | "ASCII mode" and other modes. If unencoded text in an encoded-word | contains control codes to switch out of ASCII mode, it must also | 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-words | within a single header field.) 文字セットには、「ASCII モード」とそれ以外のモードとの間でモードを切 り替えるコード切り替えのテクニックを使っているものもあります。このよ うな文字セットのテキストをエンコードした場合に、 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 にエンコードされる可能性が ある場合で、かつ送信者と受信者との間に個人的なとりきめがなされていな い場合には、これらすべての文字セットを包含する ISO-8859-* シリーズの 上位文字セットを選択するようにします。 | 4. Encodings 4. エンコーディング | 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-words | MUST be able to accept either encoding for any character set which it | supports. 今のところ「エンコード方式」として使えるのは、「Q」、「B」のみです。 これらのエンコード方式については、後で説明します。「Q」エンコード方式 を適用できるのは、エンコードした文字列のほとんどが ASCII 文字セットに なる場合のみです。それ以外の場合には、「B」エンコード方式を適用すべき です。しかしながら、 encoded-word の対応しているメールリーダでは、任 意の文字セットの 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. encoded-word として使えるのは、表示可能な ASCII 文字のサブセットのみ です。 encoded-word の区切りを明らかにするために、空白文字とタブ文字 は encoded-word 内では使えません。「?」文字は、encoded-word 内のパー トの区切りとして使われます。したがって、エンコードされたテキスト内で は使えません。その他にも、いくつかの文字が encoded-word 内で使うこと ができなくなっています。たとえば、 From ヘッダでアドレスの記述の前に ある「phrase」の部分には、 RFC822 で規定されている「specials」に属す る文字は、使うことができません。さらに、インターネットでメールゲート ウェイ経由のメッセージの安全性のために使うことのできない文字もありま す。 | 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」 エンコード方式では、メッセージヘッダのなかでも影響を受けにくい場所 (たとえば、 Subject フィールド)では、様々な表示可能な文字が使えますが、 それ以外の場所では、ごく限られた文字のみが使えます。 | 4.1. The "B" encoding 4.1. Bエンコード方式 | The "B" encoding is identical to the "BASE64" encoding defined by RFC | 1521. B エンコード方式では、 RFC1521 で規定されている「BASE64」エンコード方 式と同じです。 | 4.2. The "Q" encoding 4.2. Qエンコード方式 | The "Q" encoding is similar to the "Quoted-Printable" content- | transfer-encoding defined in RFC 1521. It is designed to allow text | containing mostly ASCII characters to be decipherable on an ASCII | terminal without decoding. Q エンコード方式は、 RFC1521 で content-transfer-encoding として規定 されている「Quoted-Printable」とほぼ同じです。このエンコード方式は、 ASCII 文字を多く含めることで ASCII 端末上でデコードしなくてもある程度 解読できるようなテキストを生成するために考案されました。 | (1) Any 8-bit value may be represented by a "=" followed by two | hexadecimal digits. For example, if the character set in use | were ISO-8859-1, the "=" character would thus be encoded as | "=3D", and a SPACE by "=20". (Upper case should be used for | hexadecimal digits "A" through "F".) (1) 8 ビット値は、「=」で始まる 2 桁の 16 進数で表現されます。たとえ ば、``ISO-8859-1''文字セットにおいて、「=」は「=3D」、空白文字は 「=20」としてエンコードされます。 ( 16 進数には、アルファベットの 大文字を使います。) | (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be | represented as "_" (underscore, ASCII 95.). (This character may | not pass through some internetwork mail gateways, but its use | will greatly enhance readability of "Q" encoded data with mail | readers that do not support this encoding.) Note that the "_" | always represents hexadecimal 20, even if the SPACE character | occupies a different code position in the character set in use. (2) 8 ビットの 16 進数で 20 に相当する文字(``ISO-8859-1'' では空白文 字)は、「_」( ASCII 95 でのアンダースコア)で表現されます。 (この 文字を通さないネットワーク間メールゲートウェイも存在しますが、こ の文字を使うことで、このエンコード方式をサポートしていないメール リーダにおいて、「Q」エンコードされたデータの可読性を高めることが できます。) 「_」文字は、 16 進コード 20 に相当する文字を表現した もので、空白文字を違うコードに割り当てた文字セットでは、空白文字 を表現したものでないことに注意してください。 | (3) 8-bit values which correspond to printable ASCII characters other | than "=", "?", "_" (underscore), and SPACE may be represented as | those characters. (But see section 5 for restrictions.) (3) その文字セットに含まれる8ビット値で表現される文字のうち、「=」、 「?」、「_」(アンダースコア)、空白文字以外で、表示可能な ASCII コー ド文字に対応するものがある場合には、その対応する文字を encoded-word として使います。 (ただし、第5章にある制限について参照のこと)。 | 5. Use of encoded-words in message headers 5. メッセージヘッダでの encoded-word の使い方 | An encoded-word may appear in a message header or body part header | according to the following rules: メッセージヘッダや、ボディヘッダで使われる encoded-word は、次のよう なルールに従います。 | (1) An encoded-word may replace a "text" token (as defined by RFC | 822) in any Subject or Comments header field, any extension | message header field, or any RFC 1521 body part field for which | the field body is defined as "*text". An encoded-word may also | appear in any user-defined ("X-") message or body part header | field. (1) encoded-word は、 Subject または、 Comments ヘッダフィールド、拡 張ヘッダフィールド、フィールドボディが「*text」と定義されている RFC1521 のボディパート・フィールドの任意の場所で「text」トークン になります。 encoded-word は、ユーザ定義の(「X-」)メッセージ、ボ ディパードのヘッダフィールドでも使えます。 | Ordinary ASCII text and encoded-words may appear together in the | same header field. However, an encoded-word that appears in a | header field defined as "*text" MUST be separated from any | adjacent encoded-word or "text" by linear-white-space. 本来の ASCII からなるテキストと encoded-word は、同一のヘッダフィー ルドに共存できます。しかしながら、ヘッダフィールドに「*text」とし て出現する encoded-word は、隣接する encoded-word や「text」と連 続した空白文字列で分割しなくてはいけません。 | (2) An encoded-word may appear within a comment delimited by "(" and | ")", i.e., wherever a "ctext" is allowed. More precisely, the | RFC 822 ABNF definition for "comment" is amended as follows: (2) encoded-word は、「(」、「)」で仕切られたコメント、つまり「ctext」 中の任意の場所でも使えます。「comment」を RFC822 の ABNF 文法でよ り正確に定義すると次のようになります。 | comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" comment = "(" * (ctext / quoted-pair / comment / encoded-word) ")" | A "Q"-encoded encoded-word which appears in a comment MUST NOT | contain the characters "(", ")" or " encoded-word that appears in | a "comment" MUST be separated from any adjacent encoded-word or | "ctext" by linear-white-space. comment 中に出現する「Q」エンコードされた encoded-word には、 「(」、「)」、「\」を使えません。「comment」中の encoded-word は、 隣接する encoded-word 、「ctext」とは連続した空白文字列で仕切られ ていなくてはなりません。 | (3) As a replacement for a "word" entity within a "phrase", for | example, one that precedes an address in a From, To, or Cc | header. The ABNF definition for phrase from RFC 822 thus | becomes: (3) From 、 To 、 Cc のフィールドでアドレスの前に記述される RFC822 で の「word」のかわりに、「phrase」が定義されています。 phrase は、 ABNF で次のように定義されます。 | phrase = 1*(encoded-word / word) phrase = 1*(encoded-word / word) | In this case the set of characters that may be used in a "Q"- | encoded encoded-word is restricted to: . An encoded-word that appears | within a "phrase" MUST be separated from any adjacent "word", | "text" or "special" by linear-white-space. この使い方をする場合、「Q」エンコード方式の encoded-word は、次の ような制限を受けます。 少し抜けてる? - yotti | These are the ONLY locations where an encoded-word may appear. In | particular, an encoded-word MUST NOT appear in any portion of an | "addr-spec". In addition, an encoded-word MUST NOT be used in a | Received header field. 以上の場所でのみ encoded-word を使うことができます。特に「addr-spec」 の中では、使えません。また、 Received ヘッダフィールドでも使えません。 | Each encoded-word MUST encode an integral number of octets. The | encoded-text in each encoded-word must be well-formed according to | the encoding specified; the encoded-text may not be continued in the | next encoded-word. (For example, "=?charset?Q?=?= =?charset?Q?AB?=" | would be illegal, because the two hex digits "AB" must follow the "=" | in the same encoded-word.) 各 encoded-word は、8ビット毎で1つの数にエンコードされなければなりま せん。各 encoded-word 中の encoded-text は、エンコード規則において正 規のものでなければなりません。また次の encoded-word に続いていてはい けません。 (たとえば「=?charset?Q?=?= =?charset?Q?AB?=」は、 16 進数 を表す「AB」が「=」の直後にないので、この規則に違反しています。) | Each encoded-word MUST represent an integral number of characters. A | multi-octet character may not be split across adjacent encoded-words. 各 encoded-word は、1文字単位でエンコードされなければなりません。マル チバイト文字を使う場合には、1つの文字が隣接する encoded-word にわたっ て分割されてはいけません。 | Only printable and white space character data should be encoded using | this scheme. However, since these encoding schemes allow the | encoding of arbitrary octet values, mail readers that implement this | decoding should also ensure that display of the decoded data on the | recipient's terminal will not cause unwanted side-effects. これらのエンコード方式は、表示可能な文字と空白文字からなるテキストデー タに対してのみ適用されるべきです。しかし、これらのエンコード方式は、 8 ビットのデータをエンコードすることもできるので、デコードができるメー ルリーダを実装する場合には、受信者の端末で表示がされるときに不本意な 副作用が起きないように保証すべきです。 | Use of these methods to encode non-textual data (e.g., pictures or | sounds) is not defined by this memo. Use of encoded-words to | represent strings of purely ASCII characters is allowed, but | discouraged. In rare cases it may be necessary to encode ordinary | text that looks like an encoded-word. 非テキストのデータ(たとえば、絵や音声)をエンコードする場合の、この方 式の適用についてはこのメモで定義されていません。純粋な ASCII 文字だけ を表現する encoded-word も作ることができますが、普通はしません。 encoded-word の形式にする必要があまりないからです。 | 6. Support of encoded-words by mail readers 6. メールリーダにおけるencoded-wordのサポート | 6.1. Recognition of encoded-words in message headers 6.1. メッセージヘッダ内でのencoded-wordの認識 | A mail reader must parse the message and body part headers according | to the rules in RFC 822 to correctly recognize encoded-words. メールリーダは RFC 822 の規則に従ってメッセージとボディパート・ヘッダ をパースし、 encoded-word を正しく認識しなくてはいけません。 | Encoded-words are to be recognized as follows: encode-word は、以下のようにして認識されます。 | (1) Any message or body part header field defined as "*text", or any | user-defined header field, should be parsed as follows: Beginning | at the start of the field-body and immediately following each | occurrence of linear-white-space, each sequence of up to 75 | printable characters (not containing any linear-white-space) | should be examined to see if it is an encoded-word according to | the syntax rules in section 2. Any other sequence of printable | characters should be treated as ordinary ASCII text. (1) 「*text」として定義されるメッセージ、ボディパート・ヘッダ、ユーザ 定義のヘッダフィールドは、以下のようにパースされます。まず、フィー ルドのボディの起点直後にある連続する空白文字列を除いた最長 75 文 字の(空白文字を1つも含まない)表示可能な文字列に対して、第 2 節で 示した構文にあてはまる encoded-word があるかどうか調べます。この 構文にあてはまらない表示可能な文字列については、字面どおりの ASCII 文字列とみなされます。 | (2) Any header field not defined as "*text" should be parsed | according to the syntax rules for that header field. However, | any "word" that appears within a "phrase" should be treated as an | encoded-word if it meets the syntax rules in section 2. | Otherwise it should be treated as an ordinary "word". (2) 「*text」として定義されていないヘッダフィールドは、そのヘッダフィー ルド特有の構文規則でパースされます。しかし、「phrase」内に出現する 「word」が第2節にある構文規則に合致する場合には、これを encoded-word として扱うべきです。それ以外の場合には、本来の「word」として扱います。 | (3) Within a "comment", any sequence of up to 75 printable characters | (not containing linear-white-space), that meets the syntax rules | in section 2, should be treated as an encoded-word. Otherwise it | should be treated as normal comment text. (3) 「comment」中の、(空白を含まない)最長75文字の表示可能な文字列で 第 2 節の構文に合致するものがあれば、 encoded-word として扱います。 それ以外の場合は、通常の comment テキストとして扱います。 | 6.2. Display of encoded-words 6.2. encoded-wordsの表示 | Any encoded-words so recognized are decoded, and if possible, the | resulting unencoded text is displayed in the original character set. デコードできる任意の encoded-word は、可能なかぎり元の文字セットで表 示されます。 | When displaying a particular header field that contains multiple | encoded-words, any linear-white-space that separates a pair of | adjacent encoded-words is ignored. (This is to allow the use of | multiple encoded-words to represent long strings of unencoded text, | without having to separate encoded-words where spaces occur in the | unencoded text.) 複数の encoded-word を含むようなフィールドの表示において、 encoded-word の間にある連続する空白文字列は無視されます。 (これにより、長いテキス トをエンコードする際に、複数の encode-word 間に不必要な空白を狭むこと なしに、これを表現することができます。) | In the event other encodings are defined in the future, and the mail | reader does not support the encoding used, it may either (a) display | the encoded-word as ordinary text, or (b) substitute an appropriate | message indicating that the text could not be decoded. 将来、新たなエンコード方式が定義され、メールリーダがそのエンコーディ ングをサポートしていない場合には、次のどちらかをします。 (a) encoded-word のテキストをエンコードされたまま表示する。 (b) デコードできないことを示すメッセージを表示する。 | If the mail reader does not support the character set used, it may | (a) display the encoded-word as ordinary text (i.e., as it appears in | the header), (b) make a "best effort" to display using such | characters as are available, or (c) substitute an appropriate message | indicating that the decoded text could not be displayed. メールリーダのサポートしていない文字セットが使われている場合には、次 のどちらかが行なわれます。 (a) (ヘッダにある) encoded-word のテキストをエンコードされたまま表示する。 (b) できうる限りの「努力」をして表示できる分だけでも表示する。 (c) デコードしたテキストが表示できないことを示すメッセージを表示する。 | If the character set being used employs code-switching techniques, | display of the encoded text implicitly begins in "ASCII mode". In | addition, the mail reader must ensure that the output device is once | again in "ASCII mode" after the encoded-word is displayed. コード切り替えのテクニックを使っている文字セットでは、エンコードされ ているテキストの表示は、暗黙的に「ASCII モード」から始めます。それに 加えてメールリーダは、各 encoded-word の表示を終えたら、「ASCII モード」 に戻っていることを保証しなくてはなりません。 | 6.3. Mail reader handling of incorrectly formed encoded-words 6.3. 正しい形式でないencoded-wordのメールリーダでの取り扱い | It is possible that an encoded-word that is legal according to the | syntax defined in section 2, is incorrectly formed according to the | rules for the encoding being used. For example: 第 2 節で定義されている構文に従う encoded-word には、適用されたエンコー ド方式の規則により、形式のうえで正しくないものがありえます。 | (1) An encoded-word which contains characters which are not legal for | a particular encoding (for example, a '-' in the "B" encoding), | is incorrectly formed. (1) 特定のエンコード方式において有効でない文字 (たとえば、「B」エンコー ディングでの '-') を含んでいて正しくないもの。 | (2) Any encoded-word which encodes a non-integral number of | characters or octets is incorrectly formed. (2) encoded-word において、文字もしくは、 8 ビットのデータ毎にエンコー ドがなされていないもの。 | A mail reader need not attempt to display the text associated with an | encoded-word that is incorrectly formed. However, a mail reader MUST | NOT prevent the display or handling of a message because an encoded- | word is incorrectly formed. メールリーダは、正しい形式になっていない encoded-word を無理に表示す る必要はありません。しかし、たとえそれが正しい形式になっていなくとも、 メールリーダはそのメッセージ全体の表示や処理をやめてはいけません。 | 7. Conformance 7. 規則 | A mail composing program claiming compliance with this specification | MUST ensure that any string of non-white-space printable ASCII | characters within a "*text" or "*ctext" that begins with "=?" and | ends with "?=" be a valid encoded-word. ("begins" means: at the | start of the field-body or immediately following linear-white-space; | "ends" means: at the end of the field-body or immediately preceding | linear-white-space.) In addition, any "word" within a "phrase" that | begins with "=?" and ends with "?=" must be a valid encoded-word. この仕様書の要求をみたすメール編集プログラムは、「*text」、「*ctext」 内の文字で「=?」で始まり、「=?」で終る空白文字列でない表示可能な ASCII 文字列が、有効な encoded-word であることを保証する必要がありま す。 (ここで言う「始まる」とは、フィールドボディの起点と、空白文字列 の直後の状態をさし、「終る」とはフィールドボディの終りと、空白文字列 の直前の状態をさします。) | A mail reading program claiming compliance with this specification | must be able to distinguish encoded-words from "text", "ctext", or | "word"s, according to the rules in section 6, anytime they appear in | appropriate places in message headers. It must support both the "B" | and "Q" encodings for any character set which it supports. The | program must be able to display the unencoded text if the character | set is "US-ASCII". For the ISO-8859-* character sets, the mail | reading program must at least be able to display the characters which | are also in the ASCII set. この仕様書の要求をみたすメールを読むためのプログラムは、メッセージヘッ ダの適切な場所に出現した encoded-word を第 6 節で定義した規則により 「text」、「ctext」、「word」を区別できる必要があります。サポートする 文字セットについては、「B」と「Q」両方のエンコーディング方式をサポー トしていなければなりません。またプログラムは、デコードしたテキストの 文字セットが「US-ASCII」である場合には、表示できなくてはなりません。 メールを読むためのプログラムは、``ISO-8859-*''の文字セットについても その中で ASCII 文字に該当する文字のある文字については、すくなくとも表 示できるようになっていなくてはなりません。 | 8. Examples 8. 例 | From: =?US-ASCII?Q?Keith_Moore?=| To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= | CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard | Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= | =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= | From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= | To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se | Subject: Time for ISO 10646? | To: Dave Crocker | Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se | From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= | Subject: Re: RFC-HDR care and feeding | From: Nathaniel Borenstein | (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) | To: Greg Vaudreuil , Ned Freed | , Keith Moore | Subject: Test of new header generator | MIME-Version: 1.0 | Content-type: text/plain; charset=ISO-8859-1 | 9. References 9. 参考文献 | [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail | Extensions) Part One: Mechanisms for Specifying and Describing | the Format of Internet Message Bodies", RFC 1521, Bellcore, | Innosoft, September 1993. | [2] Crocker, D., "Standard for the Format of ARPA Internet Text | Messages", STD 11, RFC 822, UDEL, August 1982. | [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, | RFC 1340, USC/Information Sciences Institute, July 1992. | 10. Security Considerations 10. セキュリティに関する考察 | Security issues are not discussed in this memo. このメモでは、議論されていません。 | 11. Author's Address 11. 著者連絡先 | Keith Moore | University of Tennessee | 107 Ayres Hall | Knoxville TN 37996-1301 | EMail: moore@cs.utk.edu
一覧
スポンサーリンク