<http://www.imasy.or.jp/~yotti/rfc1522j.txt>


この文書は rfc1522 を藤本真吾さん(shingo@wide.ad.jp) が翻訳したものを
私(yotti@imasy.or.jp)が Plain Text に作り替えたものです。
また、私の好みから対訳の形になっています。

注: 文中、元の翻訳に抜けがあったようなので、印を付けています。

--
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 "?="

|    charset = token    ; see section 3
   charset = token    ;  第3章を参照のこと。

|    encoding = token   ; see section 4
   encoding = token   ; 第4章を参照のこと。

|    token = 1*<Any CHAR except SPACE, CTLs, and especials>
   token = 1* <空白文字、制御文字、 especials を除いた任意の文字>

|    especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
|                <"> / "/" / "[" / "]" / "?" / "." / "="

|    encoded-text = 1*<Any printable ASCII character other
|                      than "?" or SPACE>
|                      ; (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) ")"

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

|        In this case the set of characters that may be used in a "Q"-
|        encoded encoded-word is restricted to: <upper and lower case
|        ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=", and
|        "_" (underscore, ASCII 95.)>.  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 は、次の
       ような制限を受けます。
       <ASCII コードの英大小文字、数字、「!」、「*」、「+」、「-」、「/」、
       「=」、「_」(ASCII 95のアンダースコア)>
<NOTE>少し抜けてる? - yotti</NOTE>

|    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?= <moore@cs.utk.edu>
|       To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>
|       CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD@vm1.ulg.ac.be>
|       Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
|        =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

|       From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef@admin.kth.se>
|       To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
|       Subject: Time for ISO 10646?

|       To: Dave Crocker <dcrocker@mordor.stanford.edu>
|       Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
|       From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se>
|       Subject: Re: RFC-HDR care and feeding

|       From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
|             (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
|       To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed
|          <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>
|       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