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
を含むメッセージヘッダ行の１行の長さは、 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
一覧
スポンサーリンク
