UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 翻訳 1999年 5月 1日 / translation 1 May 1999 修正 2003年12月16日 / correction 16 December 2003 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2047 を訳者(marimo@wdic.org)が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 翻訳内容に関してご指摘を頂いた東 大亮(dais@aso.ecei.tohoku.ac.jp)様 に深く感謝いたします。 Network Working Group K. Moore Request for Comments: 2047 University of Tennessee Obsoletes: 1521, 1522, 1590 November 1996 Category: Standards Track MIME (Multipurpose Internet Mail Extensions) パート3: [多目的インターネットメール拡張] 非ASCIIテクストのためのメッセージヘッダ拡張 このメモの位置づけ この文書は、インターネットコミュニティのための Internet standards track protocol(インターネット標準運用プロトコル)を定義し、改良のため の議論と提案を求めている。標準化についての情報とこのプロトコルの状態 については最新の "Internet Official Protocol Standards" (STD 1) (イ ンターネット公的プロトコル標準) を参照のこと。このメモの配布は無制限 である。 摘要 STD 11 すなわち RFC 822 は、US-ASCII メッセージヘッダについてのか なりの詳細を記述するメッセージ表現のためのプロトコルを定義しており、 メッセージの内容あるいはメッセージボディはフラットな US-ASCII テクス トとしたままである。 正式には Multipurpose Internet Mail Extensions または MIME と呼ば れるこの一連の文書は、次のことを可能にするためにメッセージのフォー マットを再定義する。 (1) US-ASCII 以外の文字集合によるテクストメッセージボディ、 (2) 非テクストのメッセージボディのための種々のフォーマットの拡張 性のセット、 (3) マルチパート(多部分的)なメッセージボディ、そして (4) US-ASCII 以外の文字集合におけるテクストのヘッダ情報 これらの文書は RFC 934, STD 11 および RFC 1049 に述べられている初期 の作業に基づいているが、それらをさらに拡張し、改訂するものである。 RFC 822 はメッセージボディに関してほとんど述べていないので、これらの 文書は RFC 822 に対する改訂というよりも、むしろ、RFC 822 と概ね直交し たものとなっている。 この口やかましい文書はシリーズの3番目である。それは、インターネッ トメールヘッダフィールドにおいて 非 US-ASCII テクストデータを可能に するための RFC 822 への拡張である。 このシリーズの他の文書は以下を含む: + RFC 2045 は、MIMEメッセージの構造を記述するためのさまざまなヘッダ を定義する。 + RFC 2046 は、MIMEメディアタイピングシステムの一般的な構造を定義し、 そしてメディアタイプの初期セットを定義する。 + RFC 2048 は、MIMEに関する事柄のIANAの様々な登録手続きを述べ、更に + RFC 2049 は、MIME適合性の基準と MIMEメッセージフォーマットのいく つかの実例、および、謝辞(acknowledgements)と文献を示す。 これらの文書は RFC 1521、1522 および 1590 の改訂版である。それはさ らに RFC 1341 と 1342 の改訂版である。RFC 2049 の付録は、以前の版との 変更点を述べている。 1. はじめに RFC 2045 は、様々な文字集合で符号化されたテクストのボディパートを 表現するためのメカニズムのほかに、そのようなボディパートを表示可能な US-ASCII 文字として符号化するための方法も述べている。このメモは、 メッセージを扱うための現存するソフトウェアを混乱させることがないよう な方法で、RFC 822 [2] メッセージヘッダの様々な部分における非ASCIIテ クストの符号化を許す同様の手法を述べる。 RFC 2045 で説明されている符号化法と同様に、この手法では既存のイン ターネットで使われているメール取り扱いプログラムを混乱させることなく メッセージヘッダにおける非ASCII文字を使えるように設計されている。特 に、いくつかのメール転送プログラムでは、次のような現象が起きることが あることが知られている。 (a) ヘッダ中にある特定のフィールドがあると関連する別のフィールドを 破棄する。 (b) To: フィールドや Cc: フィールドのアドレスの順番を入れ換える。 (c) フィールドの出現順序を入れ換える。 (d) 本来とは異なる場所のメッセージのヘッダをオリジナルのメッセージ ヘッダを、オリジナルのメッセージヘッダで「包装」する。 さらに、幾つかのメールリーダでは、RFC 822 に従い "<"、","、":" な どの特殊文字を「隠蔽」するためにバックスラッシュを利用した引用、また はその他の使用頻度が低い機能を指定した場合、正しくメッセージヘッダを 解析することが出来ないおそれがある。 これらのプログラムが RFC 822 ヘッダを正しく解釈しないことが不運で あると同時に、これらのプログラムを「破壊」することは、インターネット メールシステムのための厳しい操作上の問題をもたらすだろう。従って、こ のメモにおいて説明された拡張は、RFC 822 の殆ど使われない仕様には依存 していない。 その代わり、特定の「ごく普通に」表示可能な ("encoded-word" と呼ば れる) ASCII 文字の集合が符号化されたデータの表現用に予約されている。 その代わりに、"ordinary" 印刷可能な ASCII文字("encoded-word" (符 号化された言葉) として知られている)の一定のシーケンスは、符号化され たデータとして使用するために確保される。encoded-word の構文は、通常 のメッセージヘッダのテクスト中に「偶然」には出現しにくいものになって いる。しかも、encoded-word に使われる文字は、encoded-word が出現する 文脈で特別な意味を持たないそれらに限定されている。 一般に、"encoded-word" (符号化された単語) は、表示可能な ASCII 文 字からなる文字列で、"=?" で始まり、"?=" で終わる。そしてその間に二つ の "?" がある。この文字列には、もとのテクストで使われている文字集合 と符号化方式、そしてテクストを表示可能な ASCII テクストに符号化した ものを挿入する。 この仕様を実装するメイル編集プログラムはヘッダフィールドへ 非ASCII テクストの入力方法を提供するだろうが、これらのフィールド(またはこれ らのフィールドの適切な部分)を encoded-word に変換してからメッセージ ヘッダに挿入するだろう。 それらがメッセージヘッダのある部分に現れる時、この仕様を満たすメー ルリーダは encoded-word を認識するだろう。encoded-word をありのまま 表示するのではなく、それは復号して、そして示されたキャラクタセットに おいてオリジナルのテクストを表示するだろう。 注意事項 このメモは、RFC 822 と RFC 2045 で定義される表記法と用語に強く依存 している。特に、このメモで使われている ABNF の文法が RFC 822 で定義 されているだけでなく、RFC 822 で示される終端記号や非終端記号も、ここ で定義するヘッダ拡張のための文法で使われている。 このメモで参照されている、RFC 822 の記号はつぎの通りである: 'addr-spec', 'atom', 'CHAR', 'comment', 'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair', 'quoted-string', 'SPACE', そして 'word'。 このプロトコルの正しい実装のためには、これらの用語の定義について特 に注意することが必要である。 このメモに用語 "ASCII" が出現する時、それは、「7ビット情報交換用米 国標準コード」、ANSI X3.4-1986 を参照する。このキャラクタセットにつ いての MIME charset 名は "US-ASCII" である。簡潔さ、そして RFC 822 を持つ一貫性のために、明確に MIME charset 名を参照しないとき、このド キュメントは用語 "ASCII" を使う。しかし、実装者は、MIMEのメッセージ やボディパートのヘッダで指定する文字集合名に必ず "US-ASCII" と表記し なければならないことに注意せよ。 このメモはメッセージヘッダーの非ASCIIテクストの表現のためのプロト コルを指定する。特に、"8ビットヘッダ" と純粋な ASCIIヘッダとの間の 翻訳は定義【せず】、そのようなどんな翻訳も可能とは仮定しない。 2. encoded-word の構文 'encoded-word' は、次の ABNF 文法によって定義される。空白文字が 'encoded-word' のコンポーネントの間に【現れてはいけない】ことを除い て、RFC 822 の表記法は使われる。 encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token ; 第3章を見よ encoding = token ; 第4章を見よ token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1*<"?" を除いたどのような印刷可能な ASCII 文字 または SPACE> ; (「メッセージヘッダの encoded-word の使用」、 ; 第5章を見よ) 'encoding' と 'charset' 名共に大文字小文字を問わない。このように、 文字コード表名 "ISO-8859-1" は、"iso-8859-1" に相当し、そして "Q" と 指定されたエンコーディングは、"Q" または "q" と同様につづられるかも しれない。 一つの 'encoded-word' は、'charset'、'encoding'、'encoded-text'、 そして、区切り記号(delimiter) を含め 75文字を超えてはならない。 もし75文字の 'encoded-word' に収まりきらない、より多くのテクストを 符号化する必要がある場合は、(CRLF または SPACE で区切られた) 複数の 'encoded-word' を使用する。 複数の行からなるヘッダフィールドの長さに制限はないが、1つ以上の 'encoded-word' を含むそれぞれの行は、76文字に制限される。 この長さ制限は、ネットワーク間のメイルゲートウェイの相互運用を容易 にするためと、token が "encoded-word" かそれ以外かをヘッダ解析器が決 めることができる前に(最後の「?=」区切り記号を探す間)しなければならな い先読みの量を制限するためにある。 重要: 'encoded-word' は、 RFC 822 パーザによって 'atom' であると承認さ れるように設計されている。結果として、符号化されない空白キャラクタ (SPACE、及び HTAB のような) は、'encoded-word' の中で禁じられる。 例えば、キャラクタシーケンス =?iso-8859-1?q?this is some text?= は、4つの 'atom' として解析され、1つの 'atom' (RFC 822解析器) ある いは 'encoded-word' ('encoded-word' を認識する解析器)として認識され ない。 文字列 "this is some text" を符号化する正しい方法は、 SPACE 文字も 符号化することである。例えば、 =?iso-8859-1?q?this=20is=20some=20text?= 'encoded-text' に出現できるキャラクタは、第5章における規則によって 更に制限される。 3. 文字集合 'encoded-word' の 'charset' パートは、符号化前のテクストの文字集合 を指定する。 'charset'は、"text/plain" ボディパートの MIME "charset" パラメータ に許された任意の文字集合名か、MIME text/plain content-type とともに 使うために IANA に登録された任意の文字集合名が可能である。 いくつかの文字集合は "ASCIIモード" と他のモードとの間を切り替える コード切り替えの手法を用いている。もし一つの 'encoded-word' 中の符号 化前のテクストが文字集合解釈器に対して ASCIIモードから他のモードへの 切り替えるを指示するようなシーケンスを含むなら、'encoded-word' の最 後で ASCIIモードが選択されるような制御文字を【含まなければならない】 (このルールは、単独のヘッダフィールド内部の隣接する 'encoded-word' を含む、それぞれの 'encoded-word' に対して独立に適用される)。 'encoded-word' 中のテクストを表現するために、1つ以上の文字集合を使 う可能性があるときは、送信者と受信者の間の合意がない場合、他の文字集 合を使うよりも、ISO-8859-* シリーズを用いることが推奨される。 4. 符号化 はじめに、"encoding" の正しい値は、"Q" と "B" である。これらの符号 化は後述する。"Q" 符号化法は、符号化されるほとんどの文字が ASCII文字 集合にあるものであるとき使うことが推奨される; そのほかの場合は、"B" 符号化が使われるべきである。それでも、'encoded-word' を認識するとす るメイルリーダは、サポートするいかなる文字集合に対しても両方の符号化 法を受け入れることができなければならない。 印刷可能な ASCII キャラクタのサブセットのみが、'encoded-text' に使 われるかもしれない。'encoded-word' の初め、及び終わりが明白であるよ うに、スペース、及びタブキャラクタは、許されない。"?" キャラクタは、 他から 'encoded-word' の様々な部分を分離するために、'encoded-word' 内で用いられ、従って、'encoded-text' パートに出現できない。他の文字 も、ある文脈においてはまた違法である。例えば、Fromヘッダフィールド中 における、メールアドレスの前にある 'phrase' の中の 'encoded-word' に は、RFC 822 で定義される、どの "specials" も含まないだろう。最後に、 ネットワーク間メールゲートウェイを通過するメッセージの信頼性を保証す るために、ある他のキャラクタは、いくらかの文脈において許されない。 "B" 符号化は、これらの要求を自動的に満たす。"Q" 符号化は、メッセージ ヘッダ(例えばサブジェクト)の重要でない位置で様々な印刷可能な文字が 他の位置での使用で利用可能なより少ない文字によって使われることを可能 にする。 4.1. "B" 符号化 "B" 符号化は、RFC 2045 により定義される "BASE64" 符号化と同一であ る。 4.2. "Q" 符号化 "Q" 符号化は、RFC 2045 において定義される "Quoted-Printable" (引用 印刷可能) content-transfer-encoding と似ている。それは、復号しないで も ASCII の端末で判読できるようにするために、ほとんどの ASCII 文字を テクストに含めることを可能にするようにデザインされている。 (1) あらゆる 8ビット値は、 "=" に続く2桁の16進数で表現される。例え ば、使われている文字集合が ISO-8859-1 なら、"=" 文字は "=30"、 SPACE は "=20" のように符号化される(16進数の数値 "A" から "F" までの桁は、大文字にするべきである)。 (2) 8ビット16進法値 20(例えば、ISO-8859-1 SPACE)が "_" として表現 されるかもしれない(下線、ASCII 95)。(この文字はいくつかのネッ トワーク間のメイルゲートウェイを通過しないかもしれないが、この 文字を使うことによって、"Q" 符号化法をサポートしないメールリー ダにおいて、"Q" 符号化が施されたデータの可読性を大幅に向上させ るだろう)。使用する文字集合の中で、16進数20 とは違うコードポジ ションを空白文字(SPACE)が占有しているとしても、"_" は常に16進数 20を表すことに注意せよ。 (3) "="、"?"、及び "_" (下線) 以外の印刷できる ASCII 文字と一致する 8 ビット値は、それらの文字として表明される【かもしれない】(制 限については第5章を見よ)。特に SPACE 及び TAB は、コード化され たワード中で、それら自身として表現【されてはいけない】。 5. メッセージヘッダの encoded-word の使用 'encoded-word' は、次のルールに従ってメッセージヘッダ、あるいはボ ディパードヘッダに現れる: (1) 任意の Subject、Comment ヘッダフィールド、任意の拡張メッセージヘッ ダフィールド、あるいはフィールドボディが '*text' と定義されている MIME ボディパートフィールドでは、'text' トークン(RFC 822 で定義)は 一つの 'encoded-word' に置き換えられる。'encoded-word' は、あらゆ るユーザー定義された ("X-") メッセージ、または、ボディパートヘッダ フィールドに同様に現れるかもしれない。 普通の ASCII テクストや encoded-word は、同じヘッダフィールドに共 に出現するかもしれない。しかし、'*text' と定義されるヘッダフィール ドに現れる 'encoded-word' は、'linear-white-space' によりあらゆる 隣接した 'encoded-word' か 'text' から分離されなければならない。 (2) "(" そして ")" によって区切られた 'comment' 内、すなわち、'ctext' が許される所どこでも 'encoded-word' が出現できる。さらに正確には、 'comment' のための RFC 822 ABNF 定義は次の通り改正される: comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" 'comment' に現れる "Q" 符号化された 'encoded-word' は、キャラクタ "("、")" または " を【含んではならない】。 'comment' において出現する 'encoded-word' は、'linear-white-space' によってあらゆる隣接の 'encoded-word' または 'ctext' から分離され なければならない。 'comment' が、"structured" フィールドボディの中でだけ認められてい ることに注意することは重要である。ボディが '*text' と定義される フィールドでは、"(" および ")" はコメント区切り記号ではなく普通の 文字として扱われ、この章の規則(1)が適用される(RFC822 の第3.1.2章 と第3.1.3章を見よ)。 (3) 'phrase'、例えば、ものの中の 'word' エンティティの置換として、それ は、From、To、または Cc ヘッダにおいてアドレスに先行する。従って、 RFC 822 からの 'phrase' のための ABNF 定義は以下のようになる: phrase = 1*( encoded-word / word ) この場合 "Q" 符号化 'encoded-word' に使われうるキャラクタセットは、 以下のように制限される: <大文字および小文字の ASCII 文字, 数字, "!", "*", "+", "-", "/", "=", そして "_" (下線, ASCII 95)>。 'phrase' 内で出現する 'encoded-word' は、いかなる隣接した 'word'、 'text'、または 'special' からとも、'linear-white-space' により分離 【されなければならない】。 これらは、'encoded-word' が出現できる【唯一の】位置である。特に: + 'encoded-word' は、'addr-spec' のどの位置にも出現【してはならな い】。 + 'encoded-word' は、'quoted-string' 内で出現【してはならない】。 + Received ヘッダフィールドで、'encoded-word' を【使ってはならな い】。 + 'encoded-word' は、MIME Content-Type または Content-Disposition フィールドのパラメータ、または 'comment'、'phrase' 以外のどのよ うな構造化されたフィールドボディにも【出現してはならない】。 'encoded-word' の 'encoded-text' は自己完結型でなければならない; 'encoded-text' を、1回の 'encoded-word' から別のものに【続けてはなら ない】。 これは、"B" 'encoded-word' の 'encoded-text' パートが、4文字長の倍 数であろうと意味する; "Q" 'encoded-word' の 'encoded-text' パートに 現れるあらゆる "=" 文字には、2つの 16進文字が続くだろう。 それぞれの 'encoded-word' は整数個のオクテットを符号化して【いなけ ればならない】。それぞれの 'encoded-word' の中の 'encoded-text' は、 符号化法の指定に従い正しい形式でなければならない; 'encoded-text' は 次の 'encoded-word' の中で続かないだろう。(例えば、"=?charset?Q?=?= =?charset?Q?AB?=" は正しくない。なぜなら、2つの16進数 "AB" は、同じ 'encoded-word' の "=" に続かなければならないからである)。 それぞれの 'encoded-word' は、文字の整数個を表して【いなければなら ない】。マルチオクテット文字は、隣接する 'encoded-word' 間で分割され ないだろう。 印刷可能な文字と空白文字データのみがこのスキームによって符号化され るべきである。しかしながら、これら符号化スキームは任意のオクテット値 の符号化を許すために、この符号の復号機能を実装するメールリーダは、解 読されたデータの表示によって、受信者の端末に対して予期しない副作用を 起こさないように保証するべきである。 非テクストのデータ(例えば、写真または音)を符号化するこれらの方法 の使用は、このメモにより定義されない。純粋な ASCII 文字列を表現する ための 'encoded-word' の使用は可能だが、推奨されない。まれなケースで 'encoded-word' のように見える普通のテクストを符号化するためにそれが 必要なことはあるだろう。 6. メールリーダによる 'encoded-word' のサポート 6.1. メッセージヘッダにおける 'encoded-word' の認識 メールリーダは、正しく 'encoded-word' を認識するために、RFC 822 の ルールに従ってメッセージヘッダおよびボディパートヘッダを解析しなけれ ばならない。 'encoded-word' は、次のとおりに認識されるべきである: (1) '*text' と定義される任意のメッセージヘッダあるいはボディパート ヘッダフィールド、またはユーザが定義したヘッダフィールドは次の ように解析されなければならない: フィールドボディの開始点、およびそれぞれの 'linear-white-space' の直後の最高75文字まで表示可能な文字(どの 'linear-white-space' も含まない) のシーケンスは、第2章の文法に従い 'encoded-word' か どうかをテストするべきである。表示可能文字以外のシーケンスは、 普通の ASCII テクストとして扱われるべきである。 (2) '*text' と定義されていないヘッダフィールドは、そのヘッダフィー ルドの文法に従って解析されるべきである。もし 'phrase' に含まれ るどの 'word' も、第2章の文法に合致した場合 'encoded-word' とし て扱われるべきである。 (3) 'comment' の中では、第2章の文法に合致する、最高75文字までの表示 可能な文字('linear-white-space' を含まないこと)のシーケンスは、 'encoded-word' として扱われるべきである。そうでない場合、それは 普通のコメントテクストとして扱われるべきである。 (4) この仕様に従って解析されるべき 'encoded-word' の出現にあたって MIME-Version ヘッダフィールドは【不要】である。その理由の一つは メールリーダは 'encoded-word' を含むかもしれない行の表示に先立ち メッセージヘッダを解析することは期待されていないからである。 6.2. 'encoded-word' のディスプレイ このように認識された 'encoded-word' は復号され、もし可能なら、結果 は元の文字集合を用いて表示される。 注意事項: encoded-word の復号と表示は、構造化されたフィールドボディをトー クンへ解析した【後】に行なわれる。それゆえ、表示時に周辺のテクスト の 'special' から区別できなくなる encoded-word の中の 'special' を 隠すことが可能になる。これと、他の理由のために、'encoded-word' を 含むメッセージヘッダから RFC 822 に従ったメールリーダによって解析 することができる復号化された形式へ翻訳することは、一般には不可能で ある。 複数の 'encoded-word' を含むある特定のヘッダフィールドを表示する時 は、隣接する 'encoded-word' を分離するあらゆる 'linear-white-space' は無視される(これによって、復号化されたテクストの空白が出現するとこ ろで 'encoded-word' を分離する必要なく、長い文字列を表現するための複 数の 'encoded-word' の使用が可能になる)。 将来、他の符号化法が定義され、メールリーダがその使われている符号化 法をサポートしない場合は、(a) 'encoded-word' を普通のテクストとして 表示するか、(b) テキストが復号できなかった旨の適切なメッセージを表示 するだろう。 メールリーダがその使われている文字集合をサポートしていない場合、 (a) 'encoded-word' を普通のテキストとして表示(ヘッダに現れているとし て)するか、(b) 利用可能な文字を使って "best effort" (最善の努力) を して表示するか、(c) 表示できなかった旨の適切なメッセージを表示する。 もし使われている文字がコードスイッチング技術を使うなら、符号化され たテクストの表示は暗黙の了解として "ASCII mode" から始まる。さらに、 メールリーダは、'encoded-word' が表示された後にもう一度出力デバイス が "ASCII mode" にあることを保証しなければならない。 6.3. 不正確に形成された 'encoded-word' のメールリーダでの扱い 第2章に定義される文法に従う 'encoded-word' が、使われている符号化 法のルールに従っていない形式である可能性がある。例えば: (1) 特定の符号化法では正しくない文字を含む 'encoded-word' (例えば "B" 符号化における "-"、あるいは "B"、"Q" 符号化における空白 (SPACE) や タブ(HTAB)文字)は正しくない形式である。 (2) 符号化する文字の数が整数でない 'encoded-word' は正しくない形式 である。 メールリーダは、正しくない形式の 'encoded-word' から生成されるテク ストを表示しようと試みる必要はない。しかし、'encoded-word' が正しく ない形式だからといって、メッセージの表示や取り扱いを【止めてはならな い】。 7. 適合性 この仕様への準拠を主張するメール作成プログラムは、'*text' や '*ctext' の内部の、"=?" で始まり "?=" で終わる空白文字以外の表示可能 ASCII 文字列を、正しい 'encoded-word' となるように、保証【しなければ ならない】。(「開始」方法: フィールドボディの開始時、直ちに 'linear-white-space' に続くか、または直ちに '*ctext' 内の 'encoded-word' のための "(" に続く; 「終了」の方法: フィールドボディ の終了時、直ちに'linear-white-space' に先行するか、もしくは '*ctext' の中の 'encoded-word' のための ")" の直前に先行する。付け加えると、 'phrase' 内部の "=?" から始まり "?=" で終わるいかなる 'word' も正し い 'encoded-word' でなければならない。この仕様への準拠を主張するメー ルリーダは、それがメッセージヘッダの適切な位置に現れた場合はいつでも 第6章のルールに従って 'text' や 'ctext'、'word' から、'encoded-word' を区別できなければならない。それらは、メッセージヘッダにおける適切な 場所に現れる。 サポートするどの文字集合についても、"B" および "Q" 符号化法の両方 をサポートしなければならない。文字集合が "US-ASCII" の場合、復号化し て表示できなければならない。ISO-8859-* については、少なくとも ASCII にある文字を表示できなければならない。 8. 例 以下は、'encoded-word' を含んでいるメッセージヘッダの例である: 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==?= 注意事項: 上の Subject フィールドのはじめの 'encoded-word' において、 'encoded-word' は自己完結でなければならないため、'encoded-text' の最後の "=" が必要である(この "=" は、2つのオクテットを表現す る 4つの base64 文字のグループを完全なものにする)。 二つめの 'encoded-word' が、はじめの 'encoded-word' と違う 'charset' を用いる場合以外では、付加的なオクテットが、はじめの 'encoded-word' で符号化されていたかもしれない(encoded-word は、 正確に3の倍数の数の符号化されたオクテットを含むため)。 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 このルールは、'*text' と定義されるフィールドとは少し違う。"(" と ")" が 'comment' の区切り記号としては認識されないからである[第5章(1) を見よ]。 次のそれぞれの例では、もし同じシーケンスが '*text' フィールドに存 在するとしたら、"displayed as" (表示されるがままの) の形式は符号化さ れた語としては【見なされず】、"encoded form" (符号化されたフォーム) と同等になるだろう。 これは、次の例における encoded-words の各々が ( もしくは ) 文字に 隣接するからである。 encoded form displayed as --------------------------------------------------------------------- (=?ISO-8859-1?Q?a?=) (a) (=?ISO-8859-1?Q?a?= b) (a b) 'comment' 内では、空白文字は、'encoded-word' と周囲のテ クストの間に出現【しなければならない】。[セクション 5, 章 (2)]。しかし空白文字は 'comment' を始める最初の "("、 及び 'encoded-word' の間で必要とされない。 (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) 隣接した 'encoded-word' 間の空白文字は表示されない。 (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) 'encoded-word' の間の複数の SPACE も表示されない。 (=?ISO-8859-1?Q?a?= (ab) =?ISO-8859-1?Q?b?=) 'encoded-word' の間のあらゆる量の linear-space-white は、1つ以上の SPACE が続くような CRLF が含まれていた としても、表示されない。 (=?ISO-8859-1?Q?a_b?=) (a b) SPACE に符号化されたテクストの部分の中で表示されるため に、 SPACE は 'encoded-word' の一部として符号化【されな ければならない】。 (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b) SPACE に符号化されたテクストの 2つの文字列の間で表示さ れるために、SPACE は 'encoded-word' のうちの 1つのパー トとして符号化【できる】。 9. 参考文献 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [RFC 2049] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. 10. セキュリティ対策 セキュリティ問題については、このメモでは論じていない。 11. 確認 役に立つアドバイス、洞察力のあるコメント、及び、この仕様の初期の バージョンに応じてなされた啓発されるような質問のために、著者は、 Nathaniel Borenstein, Issac Chan, Lutz Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, そして Kazuhiko Yamamoto に感謝する ことを望む。 12. 奥付 Keith Moore University of Tennessee 107 Ayres Hall Knoxville TN 37996-1301 EMail: moore@cs.utk.edu 付録 - RFC 1522 からの変更 (順不同) + 'encoded-word' を使うために、MIME-Version が不要であることの明文 化。 + 正確であるために 'encoded-word' が RFC822 parser.values に 'atom' のようでなければならないと説明し、SPACE と TAB が 'encoded-word' の中で与えられない明白なノートを加える。 + 隣接する linear-white-space と encoded-word がどのように表示され るかの Olle Jarnefors (感謝!) による実例を追加。 + RFC 822 において定義され、そして、このメモにおいて参照を付けられ た用語を明示的にリストする。 + nroff の気まぐれによる、1、2行、及び 2つの文字が消滅するというこ とに起因する誤植を修正。 + RFC822 ヘッダと、MIME ボディパートヘッダにおける '*text' フィール ドでは、encoded-word が許されるが、パラメータ値としては【許されな い】ことを明示。 + コード切り換えシーケンスを使う文字集合では、'encoded-word' の符号 化されたパート中で、ASCII に戻さなければならないことを明確化。 + encoded-word は comment の中で "(" 及び ")" により区切られるが、 *text では区切られないことについて注を加えた(なんと奇怪な!)。 + =E9 に続く "_" を取り除くために、Andre Pirard 例を修正(post-1342 はもはや必要なくなった)。 + 明確化: 'encoded-word' は *ctext の中の "(" 及び ")" に単に【隣 接】するのではなく、コメントを区切る最後の "(" の直後か、もしくは 最後の ")" の直前に現れるだろう。 + "B" 'encoded-word' が 'encoded-text' 部分に 4文字の倍数を常に持つ のを説明するために注を加えた。 + 例における "=" についての注を加える。 + 'encoded-word' の処理がそれについてパージング、及び、いくらかの含 意の【後】で発生することを注意。 + あなたが 1522、及び、バニラ 822、またはいわゆる "8 ビットヘッダ" のいずれかの間で翻訳を期待できないことを明白に表明する。 + 'encoded-word' が 'quoted-string' の中で有効ではないことを明白に 表明した。 Moore Standards Track [Page 1]