RFC2047 日本語訳
2047 MIME (Multipurpose Internet Mail Extensions) Part Three: MessageHeader Extensions for Non-ASCII Text. K. Moore. November 1996. (Format: TXT=33262 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Moore Request for Comments: 2047 University of Tennessee Obsoletes: 1521, 1522, 1590 November 1996 Category: Standards Track
コメントを求めるワーキンググループK.ムーア要求をネットワークでつないでください: 2047年のテネシー大学は以下を時代遅れにします。 1522、1590 1521、年1996年11月のカテゴリ: 標準化過程
MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text
パートThreeをまねてください(マルチパーパスインターネットメールエクステンション): 非ASCIIテキストのためのメッセージヘッダー拡張子
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for
STD11(RFC822)は米国-ASCIIメッセージヘッダーに関するかなりの詳細を指定するメッセージ表現プロトコルを定義して、メッセージ内容、またはメッセージ本体を残します、平坦な米国-ASCIIテキストとして。 このセットのまとめてマルチパーパスインターネットメールエクステンションと呼ばれるドキュメント、またはMIMEが考慮するメッセージの書式を再定義します。
(1) textual message bodies in character sets other than US-ASCII,
(1) 米国-ASCIIを除いた文字の組の原文のメッセージ本体
(2) an extensible set of different formats for non-textual message
bodies,
(2) 非原文のメッセージ本体のための広げることができる異なった形式
(3) multi-part message bodies, and
そして(3) 複合メッセージ本体。
(4) textual header information in character sets other than US-ASCII.
(4) 米国-ASCIIを除いて、原文のヘッダー情報はぴったりしたセットします。
These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
これらのドキュメントは、それらをRFC934、STD11、およびRFC1049に記録された以前の仕事に基づいていますが、広げていて、改訂します。 RFC822が、メッセージ本体に関してこれらのドキュメントが主にそうであると直交していた状態でそれほど少ししか言わなかった、(改正よりむしろ、)、RFC822
This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields.
この特定のドキュメントはシリーズで3番目のドキュメントです。 それは、インターネット・メール・ヘッダー分野に非米国のASCIIテキストデータを許容するためにRFC822に拡大について説明します。
Moore Standards Track [Page 1] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[1ページ]。
Other documents in this series include:
このシリーズにおける他のドキュメントは:
+ RFC 2045, which specifies the various headers used to describe
the structure of MIME messages.
+ RFC2045、どれが様々なヘッダーを指定するかが以前はよくMIMEメッセージの構造について説明していました。
+ RFC 2046, which defines the general structure of the MIME media
typing system and defines an initial set of media types,
+ RFC2046、どれがMIMEメディアタイピングシステムの一般構造体を定義して、1人の始発のメディアを定義するかはタイプされます。
+ RFC 2048, which specifies various IANA registration procedures
for MIME-related facilities, and
そして+ RFC2048。(RFCは様々なIANA登録手順をMIME関連の施設に指定します)。
+ RFC 2049, which describes MIME conformance criteria and
provides some illustrative examples of MIME message formats,
acknowledgements, and the bibliography.
+ RFC2049。(そのRFCはMIME順応評価基準について説明して、MIMEメッセージ・フォーマット、承認、および図書目録に関するいくつかの説明に役立つ実例を提供します)。
These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.
これらのドキュメントはRFCs1521、1522、および1590年の改正です。(その改正は自分たちでRFCs1341と1342年の改正でした)。 RFC2049の付録は旧バージョンからの違いと変化について説明します。
1. Introduction
1. 序論
RFC 2045 describes a mechanism for denoting textual body parts which are coded in various character sets, as well as methods for encoding such body parts as sequences of printable US-ASCII characters. This memo describes similar techniques to allow the encoding of non-ASCII text in various portions of a RFC 822 [2] message header, in a manner which is unlikely to confuse existing message handling software.
RFC2045は様々な文字の組でコード化される原文の身体の部分を指示するためにメカニズムについて説明します、印刷可能な米国-ASCII文字の系列のような身体の部分をコード化するための方法と同様に。 このメモはRFC822[2]メッセージヘッダーの様々な部分での非ASCIIテキストのコード化を許すために同様のテクニックについて説明します、既存のメッセージハンドリングソフトウェアを混乱させそうにない方法で。
Like the encoding techniques described in RFC 2045, the techniques outlined here were designed to allow the use of non-ASCII characters in message headers in a way which is unlikely to be disturbed by the quirks of existing Internet mail handling programs. In particular, some mail relaying programs are known to (a) delete some message header fields while retaining others, (b) rearrange the order of addresses in To or Cc fields, (c) rearrange the (vertical) order of header fields, and/or (d) "wrap" message headers at different places than those in the original message. In addition, some mail reading programs are known to have difficulty correctly parsing message headers which, while legal according to RFC 822, make use of backslash-quoting to "hide" special characters such as "<", ",", or ":", or which exploit other infrequently-used features of that specification.
RFC2045で説明されたコード化のテクニックのように、ここに概説されたテクニックは、既存のインターネット・メール取り扱いプログラムの気まぐれによって擾乱されそうにない方法でメッセージヘッダーにおける非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.
これらのプログラムが正しく822個のヘッダーの、そして、これらのプログラムがそうする「中断」原因に厳しいRFCを解釈しないのが、不幸である間、インターネットへの運転上の問題はシステムを郵送します。 したがって、このメモで説明された拡張子はRFC822の小さい中古の特徴を当てにしません。
Moore Standards Track [Page 2] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[2ページ]。
Instead, certain sequences of "ordinary" printable ASCII characters (known as "encoded-words") are reserved for use as encoded data. The syntax of encoded-words is such that they are unlikely to "accidentally" appear as normal text in message headers. Furthermore, the characters used in encoded-words are restricted to those which do not have special meanings in the context in which the encoded-word appears.
代わりに、印刷可能な「普通」のASCII文字(「コード化された単語」として、知られています)のある系列は使用のためにコード化されたデータとして予約されます。 コード化された単語の構文がそのようなものであるので、それらは正常なテキストとしてメッセージヘッダーに「偶然」現れそうにはありません。 その上、コード化された単語で使用されるキャラクタはコード化された単語が現れる文脈での特別な意味を持っていないものに制限されます。
Generally, an "encoded-word" is a sequence of printable ASCII characters that begins with "=?", ends with "?=", and has two "?"s in between. It specifies a character set and an encoding method, and also includes the original text encoded as graphic ASCII characters, according to the rules for that encoding method.
一般に「コード化された単語」は「=?」で始まる印刷可能なASCII文字の系列です、」 =がある終わり。「」 中間で2“?"sを持っています。 それは、文字の組とコード化方法を指定して、また、グラフィック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テキストを入力する手段をヘッダーフィールドに提供しますが、メッセージヘッダーにそれらを挿入する前に、これらの分野(または、これらの分野の適切な部分)をコード化された単語に翻訳するでしょう。
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.
メッセージヘッダーのある部分に現れると、この仕様を履行するメール読者はコード化された単語を認めるでしょう。 「そのままで」というコード化された言葉を表示することの代わりに、それは、指定された文字の組でコード化を逆にして、原本を表示するでしょう。
NOTES
注意
This memo relies heavily on notation and terms defined RFC 822 and RFC 2045. In particular, the syntax for the ABNF used in this memo is defined in RFC 822, as well as many of the terminal or nonterminal symbols from RFC 822 are used in the grammar for the header extensions defined here. Among the symbols defined in RFC 822 and referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 'comment', 'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair'. 'quoted-string', 'SPACE', and 'word'. Successful implementation of this protocol extension requires careful attention to the RFC 822 definitions of these terms.
このメモは大いに記法を当てにします、そして、用語はRFC822とRFC2045を定義しました。 特に、このメモで使用されるABNFのための構文がRFC822、および端末の多くで定義されるか、またはRFC822からの非終端記号はここで定義されたヘッダー拡大に文法に使用されます。 RFC822で定義されて、このメモで参照をつけられるシンボルの中に、以下があります。 'addr-仕様'、'原子'、'炭'、'コメント'、'CTLs''ctext'、'直線的な余白'、'句'、'引用された組'。 '引用文字列'、'スペース'、および'単語'。 このプロトコル拡大のうまくいっている実現はこれらの用語のRFC822定義に関する慎重な注意を必要とします。
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 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ビットの情報交換用米国標準コード」(ANSI X3.4-1986)について言及します。 この文字の組のためのMIME charset名は「米国-ASCII」です。 明確にMIME charset名を示さないとき、このドキュメントは「ASCII」という用語(簡潔さと一貫性のためのRFC822がある両方)を使用します。 しかしながら、作成者は文字の組名がMIMEメッセージとボディー部分ヘッダーのつづられた「米国-ASCII」であるに違いないのに注意されます。
Moore Standards Track [Page 3] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[3ページ]。
This memo specifies a protocol for the representation of non-ASCII text in message headers. It specifically DOES NOT define any translation between "8-bit headers" and pure ASCII headers, nor is any such translation assumed to be possible.
このメモはメッセージヘッダーの非ASCIIテキストの表現にプロトコルを指定します。 それ、明確にDOES NOTは「8ビットのヘッダー」と純粋なASCIIヘッダーの間のどんな翻訳も定義して、少しのそのような翻訳も可能であると思われません。
2. Syntax of encoded-words
2. コード化された単語の構文
An 'encoded-word' is defined by the following ABNF grammar. The notation of RFC 822 is used, with the exception that white space characters MUST NOT appear between components of an 'encoded-word'.
'コード化された単語'は以下のABNF文法によって定義されます。RFC822の記法は余白キャラクタが'コード化された単語'のコンポーネントの間で見えてはいけない例外と共に使用されます。
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
「コード化された単語は「=? 」 “?"のコード化されたテキストをコード化するcharset “?"」と等しいです--=」
charset = token ; see section 3
charsetは象徴と等しいです。 セクション3を見てください。
encoding = token ; see section 4
コード化は象徴と等しいです。 セクション4を見てください。
token = 1*<Any CHAR except SPACE, CTLs, and especials>
SPACE、CTLs、およびespecials>以外の象徴=1*<Any CHAR
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
「especialsは「」 (「/」)」 /「<」 /">"/"@"/」、/」と等しいです」 / ":" /「<「>/」/」/「[「/」]」/“?" / "." / "="
encoded-text = 1*<Any printable ASCII character other than "?"
or SPACE>
; (but see "Use of encoded-words in message
; headers", section 5)
“?"かスペース>以外の1*<のAnyの印刷可能なコード化されたテキスト=ASCII文字。 (「メッセージ;ヘッダーにおけるコード化された単語の使用」を見てください、そして、5を区分してください)
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".
'コード化'と'charset'名の両方がケースから独立しています。 その結果、charset名、「ISO、8859、1インチ、相当する、「8859を何1インチもisoしている、「Q」というコード化は「Q」か「q」。」というつづられて、ことであるかもしれません。
An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used.
'charset'、'コード化'、'コード化されたテキスト'、およびデリミタを含んでいて、長い間、'コード化された単語'は75以上のキャラクタでないかもしれません。 より多くのテキストをコード化するのが''75のキャラクタに、複数の'が単語のコード化されたもの(CRLF SPACEによって切り離される)使用されるかもしれないというコード化された単語'をうまくはめ込むより望ましいなら。
While there is no limit to the length of a multiple-line header field, each line of a header field that contains one or more 'encoded-word's is limited to 76 characters.
長さへの限界が全くない間、複数の線ヘッダーフィールド、1つ以上を含むヘッダーフィールドの各線では、'コード化された単語のものは76のキャラクタに制限されます'。
The length restrictions are included both to ease interoperability through internetwork mail gateways, and to impose a limit on the amount of lookahead a header parser must employ (while looking for a final ?= delimiter) before it can decide whether a token is an "encoded-word" or something else.
長さの制限はともにインターネットワークメール・ゲートウェイを通して相互運用性を緩和するために含まれていて、ヘッダーパーサが以前使わなければならない(決勝--デリミタと等しいのを探している間)先読みの量で指し値するように、それは、象徴が「コード化された単語」か他の何かであるかを決めることができます。
Moore Standards Track [Page 4] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[4ページ]。
IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's by an RFC 822 parser. As a consequence, unencoded white space characters (such as SPACE and HTAB) are FORBIDDEN within an 'encoded-word'. For example, the character sequence
重要: ''原子'がRFC822パーサであるので、コード化された単語のものは認識されるように設計されています。' 結果として、暗号化されていない余白キャラクタ(SPACEやHTABなどの)は'コード化された単語'の中のFORBIDDENです。 例えば、キャラクタシーケンス
=?iso-8859-1?q?this is some text?=
=これが何らかのテキストであるという--iso-8859-1--qは等しいです。
would be parsed as four 'atom's, rather than as a single 'atom' (by an RFC 822 parser) or 'encoded-word' (by a parser which understands 'encoded-words'). The correct way to encode the string "this is some text" is to encode the SPACE characters as well, e.g.
こと'単一の同じくらい'原子'(RFC822パーサによる)か同じくらい'コード化された単語'('コード化された単語'を理解しているパーサによる)よりむしろ原子。'4として分析されて、でしょう。 適度の方法で、「これは何らかのテキストです」は、ストリングをコード化するためには、例えばまた、SPACEキャラクタをコード化することです。
=?iso-8859-1?q?this=20is=20some=20text?=
=q?iso-8859-1?この=20is=20some=20text=?
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 MIME "charset" parameter of a "text/plain" body part, or any character set name registered with IANA for use with the MIME text/plain content-type.
'コード化された単語'の'charset'部分は暗号化されていないテキストに関連している文字の組を指定します。 'charset'は名前が「テキスト/明瞭な」身体の部分のMIME"charset"パラメタに許容したか、またはどんな文字の組名も使用のためにMIMEの明瞭な満足しているテキスト/タイプでIANAに登録した文字の組のいずれであることができますも。
Some character sets use code-switching techniques to switch between "ASCII mode" and other modes. If unencoded text in an 'encoded-word' contains a sequence which causes the charset interpreter to switch out of ASCII mode, it MUST contain additional control codes such that ASCII mode is again selected at the end of the 'encoded-word'. (This rule applies separately to each 'encoded-word', including adjacent 'encoded-word's within a single header field.)
いくつかの文字の組が、「ASCIIモード」と他のモードを切り換えるのにコードを切り換えるテクニックを使用します。 'コード化された単語'による暗号化されていないテキストがcharsetインタプリタがASCIIモードから切り替わる系列を含んでいるなら、追加制御コードを含まなければならないので、ASCIIモードは再び'コード化された単語'の終わりで選択されます。 (この規則は別々に各'コード化された単語'、'ただ一つのヘッダーフィールドの中のコード化された単語'に隣接した包含に適用されます。)、'
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.
1つ以上の文字の組を使用するとテキストが'コード化された単語'、メッセージの送付者と受取人との個人的な協定およびがないとき表される可能性があるとき、ISO8859*シリーズのメンバーが他の文字の組に優先して使用されるのは、お勧めです。
4. Encodings
4. Encodings
Initially, the legal values for "encoding" are "Q" and "B". These encodings are described below. The "Q" encoding is recommended for use when most of the characters to be encoded are in the ASCII character set; otherwise, the "B" encoding should be used. Nevertheless, a mail reader which claims to recognize 'encoded-word's MUST be able to accept either encoding for any character set which it supports.
初めは、「コード化」のための法定価格は、「Q」と「B」です。 これらのencodingsは以下で説明されます。 ASCII文字の組にコード化されるべきキャラクタの大部分があるとき、「Q」コード化は使用のために推薦されます。 さもなければ、「B」コード化は使用されるべきです。 それにもかかわらず、'コード化された単語のものはそれがサポートするどんな文字の組のためのコード化も受け入れることができなければなりません'と認めると主張するメール読者。
Moore Standards Track [Page 5] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[5ページ]。
Only a subset of the printable ASCII characters may be used in 'encoded-text'. Space and tab characters are not allowed, so that the beginning and end of an 'encoded-word' are obvious. The "?" character is used within an 'encoded-word' to separate the various portions of the 'encoded-word' from one another, and thus cannot appear in the 'encoded-text' portion. Other characters are also illegal in certain contexts. For example, an 'encoded-word' in a 'phrase' preceding an address in a From header field may not contain any of the "specials" defined in RFC 822. Finally, certain other characters are disallowed in some contexts, to ensure reliability for messages that pass through internetwork mail gateways.
'コード化されたテキスト'で印刷可能なASCII文字の部分集合だけを使用してもよいです。 スペースとタブキャラクタが許容されていないので、'コード化された単語'の始めと終わりは明白です。 “?"キャラクタは、お互いと'コード化された単語'の様々な部分を切り離すのに'コード化された単語'の中で使用されて、その結果、'コード化されたテキスト'部分に現れることができません。 また、他のキャラクタもある文脈で不法です。 例えば、Fromヘッダーフィールドにおけるアドレスに先行する'句'の'コード化された単語'はRFC822で定義された「特別番組」のいずれも含まないかもしれません。 最終的に、他の確信しているキャラクタは、インターネットワークメール・ゲートウェイを通り抜けるメッセージのために信頼性を確実にするためにいくつかの文脈で禁じられます。
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」コード化は、さまざまな印刷可能なキャラクタがメッセージヘッダー(例えば、対象)で非臨界位置で使用されるのを許容します、他の位置での使用に手があいているより少ないキャラクタと共に。
4.1. The "B" encoding
4.1. 「B」コード化
The "B" encoding is identical to the "BASE64" encoding defined by RFC 2045.
「B」コード化は「RFC2045によって定義されたBASE64"コード化」と同じです。
4.2. The "Q" encoding
4.2. 「Q」コード化
The "Q" encoding is similar to the "Quoted-Printable" content- transfer-encoding defined in RFC 2045. It is designed to allow text containing mostly ASCII characters to be decipherable on an ASCII terminal without decoding.
「Q」コード化はRFC2045で定義された「引用されて印刷可能な」内容転送コード化と同様です。 それは、ほとんど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進数字「A」に「F」を通して使用されるべきです。)
(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 SPACE)は"_"(強調、ASCII95)として表されるかもしれません。 (このキャラクタはいくつかのインターネットワークメール・ゲートウェイを通り抜けないかもしれませんが、使用はこのコード化を支持しないメール読者と共に「Q」コード化されたデータの読み易さを大いに高めるでしょう。) "_"がいつも16進20を表すことに注意してください、間隔文字が使用中の文字の組の異なったコード位置を占めても。
(3) 8-bit values which correspond to printable ASCII characters other
than "=", "?", and "_" (underscore), MAY be represented as those
characters. (But see section 5 for restrictions.) In
particular, SPACE and TAB MUST NOT be represented as themselves
within encoded words.
(3) 「=」を除いた印刷可能なASCII文字に文通される8ビット値“?"、および"_"(強調)は、それらのキャラクタとして表されるかもしれません。 (しかし、制限に関してセクション5を見てください。) 事項、SPACE、およびTAB MUST NOTでは、自分たちとしてコード化された単語の中に表されてください。
Moore Standards Track [Page 6] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[6ページ]。
5. Use of encoded-words in message headers
5. メッセージヘッダーにおけるコード化された単語の使用
An 'encoded-word' may appear in a message header or body part header according to the following rules:
以下の規則に従って、'コード化された単語'はメッセージヘッダーかボディー部分ヘッダーに現れるかもしれません:
(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 MIME 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) ''コード化された単語'はどんなSubject、Commentsヘッダーフィールド、どんな拡大メッセージヘッダーフィールド、または分野本体が'*テキスト'と定義されるどんなMIMEボディー部分分野でも'テキスト'象徴(RFC822によって定義されるように)を取り替えるかもしれません。 また、'コード化された単語'はどんなユーザによって定義された(「X」)メッセージやボディー部分ヘッダーフィールドにも現れるかもしれません。
Ordinary ASCII text and 'encoded-word's 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テキストと'コード化された単語のものは同じヘッダーフィールドに一緒に現れるかもしれません'普通の。 'しかしながら、どんな隣接している'コード化された単語'や'テキスト'とも'直線的な余白'で'*テキスト'と定義されたヘッダーフィールドに現れる'コード化された単語'を切り離さなければなりません。
(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) そして、'コード化された単語'が区切られた'コメント'の中に現れるかもしれない、「(「」、)、」、すなわち、'ctext'が許容されているどこ?。 より正確に、'コメント'のためのRFC822ABNF定義は以下の通り修正されます:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
「(「*(コード化された引用されたctext/組の/コメント/単語の)」)」というコメント=
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'.
「Q」がどれが'コメント'に現れるかがキャラクタを含んではいけないという'コード化された単語'をコード化した、「(「」、)、」 「どんな隣接している'コード化された単語'や'ctext'とも'直線的な余白'で'コメント'に現れる'コード化された単語'を切り離さなければなりません」。
It is important to note that 'comment's are only recognized inside
"structured" field bodies. In fields whose bodies are defined as
'*text', "(" and ")" are treated as ordinary characters rather than
comment delimiters, and rule (1) of this section applies. (See RFC
822, sections 3.1.2 and 3.1.3)
'コメントは「構造化された」分野本体の中で認識されるだけでした'に注意するのは重要です。 そして、'分野では、だれの身体が'*テキスト'と定義されるか、「(「」、)、」 コメントよりむしろ普通のキャラクタとして扱われたデリミタ、およびこのセクションの規則(1)が適用されます。 (セクション3.1 RFC822、.2、および3.1を見てください、.3)
(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からの'句'のためのABNF定義はなります:
phrase = 1*( encoded-word / word )
句の=1*(コード化された単語/単語)
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」コード化された'コード化された単語'で使用されるかもしれないキャラクタのセットは以下のことのために制限されます。 「<大文字と小文字ASCII手紙、10進数字、“!"「*」、「+」、「-」」、/、」、「=」、および"_"(強調、ASCII95)>。 '句'の中に現れる'コード化された単語'は、どんな隣接している'単語'、'テキスト'とも切り離されるか'直線的な余白'で'特別でなければなりません'。
Moore Standards Track [Page 7] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[7ページ]。
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'.
+ 'コード化された単語'は'addr-仕様'のどんな部分にも現れてはいけません。
+ An 'encoded-word' MUST NOT appear within a 'quoted-string'.
+ 'コード化された単語'は'引用文字列'の中に現れてはいけません。
+ An 'encoded-word' MUST NOT be used in a Received header field.
Receivedヘッダーフィールドに+ 'コード化された単語'を使用してはいけません。
+ An 'encoded-word' MUST NOT be used in parameter of a MIME
Content-Type or Content-Disposition field, or in any structured
field body except within a 'comment' or 'phrase'.
MIMEコンテントタイプかContent-気質分野のパラメタ、または'コメント'か'句'以外のどんな構造化された分野本体でも+ 'コード化された単語'を使用してはいけません。
The 'encoded-text' in an 'encoded-word' must be self-contained; 'encoded-text' MUST NOT be continued from one 'encoded-word' to another. This implies that the 'encoded-text' portion of a "B" 'encoded-word' will be a multiple of 4 characters long; for a "Q" 'encoded-word', any "=" character that appears in the 'encoded-text' portion will be followed by two hexadecimal characters.
'コード化された単語'による'コード化されたテキスト'は自己充足的であるに違いありません。 1'コード化された単語'から別のものまで'コード化されたテキスト'を続けてはいけません。 これは、「B」'コード化された単語'の'コード化されたテキスト'部分が長い間4つのキャラクタの倍数になるのを含意します。 「Q」'コード化された単語'に関しては、'コード化されたテキスト'部分に現れるどんな「=」キャラクタも2つの16進キャラクタによってついて来られるでしょう。
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'.)
各'コード化された単語'は整数の八重奏をコード化しなければなりません。 指定されたコード化に従って、各'コード化された単語'による'コード化されたテキスト'はよく形成していなければなりません。 'コード化されたテキスト'は次の'コード化された単語'で続けられないかもしれません。 (例えば、「=--charset--Q(=)は=--charset--Q--AB--=と等しいこと」は不法でしょう、2十六進法ケタ「AB」が同じ'コード化された単語'による「=」に続かなければならないので。)
Each 'encoded-word' MUST represent an integral number of characters. A multi-octet character may not be split across adjacent 'encoded- word's.
各'コード化された単語'は整数のキャラクタの代理をしなければなりません。 マルチ八重奏キャラクタは横切って'コード化された単語のもの'に隣接して分けられないかもしれません。
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.
印刷可能で白い間隔文字データだけが、この計画を使用することでコード化されるべきです。 しかしながら、計画をコード化するこれらが任意の八重奏値のコード化を許すので、また、この解読を実行するメール読者は、受取人の端末における解読されたデータの表示が求められていない副作用を引き起こさないのを保証するべきです。
Use of these methods to encode non-textual data (e.g., pictures or sounds) is not defined by this memo. Use of 'encoded-word's 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文字のストリングを表すコード化された言葉のものは、許容されていますが、がっかりしていること'の使用。 たまにはそれが、'コード化された単語'に似ている普通のテキストをコード化するのに必要であるかもしれません。
Moore Standards Track [Page 8] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[8ページ]。
6. Support of 'encoded-word's by mail readers
6. 'メールによるコード化された単語の読者'のサポート
6.1. Recognition of 'encoded-word's in message headers
6.1. 'コード化された単語がメッセージヘッダーにある'認識
A mail reader must parse the message and body part headers according to the rules in RFC 822 to correctly recognize 'encoded-word's.
RFC822の規則に従って、メール読者は、正しく'コード化された単語のもの'を認識するためにメッセージとボディー部分ヘッダーを分析しなければなりません。
'encoded-word's are to be recognized as follows:
'コード化された単語のものは以下の通り認識されることです'
(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) どんなメッセージ、'*テキスト'と定義されたボディー部分ヘッダーフィールド、またはどんなユーザによって定義されたヘッダーフィールドも以下の通り分析されるべきです: 分野本体の始めにおいてすぐに'直線的な余白'の各発生に続き始めて、最大75の印刷可能なキャラクタ(どんな'直線的な余白'も含んでいない)の各系列は、シンタックス・ルールによると、それがセクション2の'コード化された単語'であるかどうか確認するために調べられるべきです。 印刷可能なキャラクタのいかなる他の系列も普通の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)はそのヘッダーフィールドのために統治されます。 しかしながら、セクション2でシンタックス・ルールを満たすなら、'句'の中に現れるどんな'単語'も'コード化された単語'として扱われるべきです。 さもなければ、それは普通の'単語'として扱われるべきです。
(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) 中では、'コメント'、セクション2でシンタックス・ルールを満たす最大75の印刷可能なキャラクタのどんな系列('直線的な余白'を含んでいない)も'コード化された単語'として扱われるべきです。 さもなければ、それは正常なコメントテキストとして扱われるべきです。
(4) A MIME-Version header field is NOT required to be present for
'encoded-word's to be interpreted according to this
specification. One reason for this is that the mail reader is
not expected to parse the entire message header before displaying
lines that may contain 'encoded-word's.
(4) MIMEバージョンヘッダーフィールドは、'この仕様通りに解釈されるべき単語のコード化されたもの'のために存在しているのに必要ではありません。 この1つの理由は'コード化された単語のもの'を含むかもしれない台詞を表示する前にメール読者が全体のメッセージヘッダーを分析しないと予想されるということです。
6.2. Display of 'encoded-word's
6.2. 'コード化された単語のもの'の表示
Any 'encoded-word's so recognized are decoded, and if possible, the resulting unencoded text is displayed in the original character set.
いずれによる'解読されて、可能であるなら、オリジナルの文字の組で結果として起こる暗号化されていないテキストを表示するというしたがって、コード化された単語のものが、認めたことです'。
NOTE: Decoding and display of encoded-words occurs *after* a structured field body is parsed into tokens. It is therefore possible to hide 'special' characters in encoded-words which, when displayed, will be indistinguishable from 'special' characters in the surrounding text. For this and other reasons, it is NOT generally possible to translate a message header containing 'encoded-word's to an unencoded form which can be parsed by an RFC 822 mail reader.
以下に注意してください。 **構造化された分野本体が象徴に分析された後にコード化された単語の解読と表示は起こります。 したがって、表示すると周囲のテキストの'特別な'キャラクタから区別がつかなくなるコード化された単語に'特別な'キャラクタを隠すのは可能です。 これと他の理由で、一般に、'RFC822が分析できる暗号化されていないフォームへの単語のコード化されたもののメール読者'を含むメッセージヘッダーを翻訳するのは可能ではありません。
Moore Standards Track [Page 9] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[9ページ]。
When displaying a particular header field that contains multiple 'encoded-word's, any 'linear-white-space' that separates a pair of adjacent 'encoded-word's is ignored. (This is to allow the use of multiple 'encoded-word's to represent long strings of unencoded text, without having to separate 'encoded-word's where spaces occur in the unencoded text.)
複数の'を単語のコード化されたもの含む特定のヘッダーフィールドを表示するとき、いくらか、''単語のコード化されたものに隣接して'それが1組を切り離す直線的な余白は無視されます'。 (これは空間が暗号化されていないテキストに起こるところで'暗号化されていないテキストのロング・ストリングを表すためにはコード化された単語のもの別々の状態でそうする必要はなくて'コード化された単語の複数のものの使用を許すためのものです。)、'
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.
出来事では、他のencodingsは将来定義されます、そして、メール読者は使用されるコード化を支持しません、そして、それはテキストが適切なメッセージ表示であるかもしれませんが、解読されて、表示普通であるとしての'コード化された単語'テキスト、または(b)が代入する(a)を定義されるかもしれません。
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.
メール読者がそうしないなら、使用される文字の組をサポートしてください、それ。普通のテキスト(すなわち、ヘッダーに現れるように)、(b)が利用可能であるようなキャラクタを使用することで表示するためには「ベストエフォート型」か(c)代用品を解読されたテキストを表示できなかったのを示す適切なメッセージにするとき、(a)が'コード化された単語'を表示しますように。
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モード」でそれとなく始まります。 さらに、メール読者は、出力装置がもう一度「ASCIIモード」で'コード化された単語'を表示する後であることを保証しなければなりません。
6.3. Mail reader handling of incorrectly formed 'encoded-word's
6.3. 不当に形成された'コード化された単語のもの'の取り扱いを読者に郵送してください。
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で定義された構文によると、法的な'コード化された単語'が不当に形成されるのは、可能です。 例えば:
(1) An 'encoded-word' which contains characters which are not legal
for a particular encoding (for example, a "-" in the "B"
encoding, or a SPACE or HTAB in either the "B" or "Q" encoding),
is incorrectly formed.
(1) 特定のコード化(「B」か「Q」のどちらかコード化における例えば、「B」コード化における「-」、スペースまたはHTAB)には、法的でないキャラクタを含む'コード化された単語'は不当に形成されます。
(2) Any 'encoded-word' which encodes a non-integral number of
characters or octets is incorrectly formed.
(2) 非整数のキャラクタか八重奏をコード化するどんな'コード化された単語'も不当に形成されます。
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.
メール読者は、不当に形成される'コード化された単語'に関連しているテキストを表示するのを試みる必要はありません。 しかしながら、'コード化された単語'が不当に形成されるので、メール読者はメッセージの表示か取り扱いを防いではいけません。
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
'「この仕様へのコンプライアンスを要求するメール構成プログラムは、'*テキストの中の非余白の印刷可能なASCII文字と'」 =がある「=?」で始まる'*ctext'と終わり」のどんなストリングも有効な'コード化された単語であることを確実にしなければなりません。' (「始まり」は以下を意味します。
Moore Standards Track [Page 10] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[10ページ]。
start of the field-body, immediately following 'linear-white-space',
or immediately following a "(" for an 'encoded-word' within '*ctext';
"ends" means: at the end of the field-body, immediately preceding
'linear-white-space', or immediately preceding a ")" for an
'encoded-word' within '*ctext'.) In addition, any 'word' within a
'phrase' that begins with "=?" and ends with "?=" must be a valid
'encoded-word'.
'すぐに'直線的な余白'、または'*ctext'の中の'コード化された単語'のための「(「'*ctext'の中の'コード化された単語'のために; 「終わり」は分野本体の先で以下を意味します、すぐに'直線的な余白'に先行するか、またはすぐにaに先行して」)」というすぐに次のaに続く分野本体の始まり 「添加、「=?」で始まって、」 =で終わる'句'の中のどんな'単語'も」は有効な'コード化された単語'であるに違いありません。
A mail reading program claiming compliance with this specification must be able to distinguish 'encoded-word's 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.
この仕様への承諾が'テキスト'、'ctext'と'を単語のコード化されたもの区別できなければならないと主張するメール読み込みプログラムか'単語のもの、セクション6の規則に従って、いつでも、メッセージヘッダーの適切な場所に現れます'。 それはサポートするどんな文字の組のためにも「B」と「Q」encodingsの両方を支持しなければなりません。 プログラムは文字の組が「米国-ASCII」であるなら暗号化されていないテキストを表示できなければなりません。 ISO8859*文字の組において、メール読み込みプログラムはASCIIセットにもあるキャラクタを少なくとも見せることができなければなりません。
8. Examples
8. 例
The following are examples of message headers containing 'encoded- word's:
↓これは'コード化された単語によるである:'というメッセージヘッダー含有に関する例です。
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: =--、米国-ASCII?Q(キース_ムーア)が <moore@cs.utk.edu と等しいgt;、To: =--、ISO-8859-1?Q(Keld_J=F8rn_シモンセン)が <keld@dkuug.dk と等しいgt;、CC: =--、ISO-8859-1--Q(9Andr=E)が Pirard <PIRARD@vm1.ulg.ac.be と等しいgt;、Subject: =--ISO-8859-1--B(SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=)は=--ISO-8859-2--B--dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg=--=と等しいです。
Note: In the first 'encoded-word' of the Subject field above, the
last "=" at the end of the 'encoded-text' is necessary because each
'encoded-word' must be self-contained (the "=" character completes a
group of 4 base64 characters representing 2 octets). An additional
octet could have been encoded in the first 'encoded-word' (so that
the encoded-word would contain an exact multiple of 3 encoded
octets), except that the second 'encoded-word' uses a different
'charset' than the first one.
以下に注意してください。 Subject分野の最初の'コード化された単語'で、それぞれの'コード化された単語'が自己充足的であるに違いないので(「=」キャラクタは2つの八重奏を表す4つのbase64キャラクタのグループを完成します)、上では、'コード化されたテキスト'の終わりの最後の「=」が必要です。 追加八重奏は最初の'コード化された単語'でコード化されたかもしれません(コード化された単語が3つのコード化された八重奏の正確な倍数を含むように)、2番目の'コード化された単語'が最初のものと異なった'charset'を使用するのを除いて。
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?
From: =--、ISO-8859-1--Q--オッレ_JはE4rneforsと等しいです-- <ojarnef@admin.kth.se と等しいgt;、To: ietf-822@dimacs.rutgers.edu 、ojarnef@admin.kth.se Subject: ISO10646のための時間?
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
To: デーヴ Crocker <dcrocker@mordor.stanford.edu 、gt;、Cc: ietf-822@dimacs.rutgers.edu 、paf@comsol.se From: =--、ISO-8859-1--Q--パトリク_FはE4ltstr=F6mと等しいです-- <paf@nada.kth.se と等しいgt;、Subject: Re: RFC-HDR注意と食べること
Moore Standards Track [Page 11] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[11ページ]。
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
From: ナザニエル Borenstein <nsb@thumper.bellcore.com 、gt;、(=--iso-8859-8--b--7eXs+SDv4SDp7Oj08A=--=)To: グレッグ Vaudreuil <gvaudre@NRI.Reston.VA.US 、gt;、ネッドが<ned@innosoft.com>、キース Moore <moore@cs.utk.edu を解放した、gt;、Subject: 新しいヘッダージェネレータMIMEバージョンのテスト: 1.0文書内容: テキスト/平野。 charset=ISO-8859-1
The following examples illustrate how text containing 'encoded-word's
which appear in a structured field body. The rules are slightly
different for fields defined as '*text' because "(" and ")" are not
recognized as 'comment' delimiters. [Section 5, paragraph (1)].
以下の例はその方法を例証します。'構造化された分野本体に現れるコード化された単語のもの'を含むテキスト。 そして、''*テキスト'と定義された分野において、規則がわずかに異なっている、「(「」、)、」 'コメント'デリミタとして、認識されません。 [セクション5、パラグラフ(1)]。
In each of the following examples, if the same sequence were to occur
in a '*text' field, the "displayed as" form would NOT be treated as
encoded words, but be identical to the "encoded form". This is
because each of the encoded-words in the following examples is
adjacent to a "(" or ")" character.
'それぞれ以下の例のコネ、同じ系列が'*テキスト'分野に起こるつもりであったならフォームは「コード化されたフォーム」と同じである以外に、コード化された単語として扱われないだろう、そうし「表示しました」。 または、これが以下の例のそれぞれのコード化された単語がaに隣接しているからである「(「」、)、」 キャラクタ。
encoded form displayed as --------------------------------------------------------------------- (=?ISO-8859-1?Q?a?=) (a)
表示されたコード化された書式--------------------------------------------------------------------- (=? ISO-8859-1Q?--a--=) (a)
(=?ISO-8859-1?Q?a?= b) (a b)
(=? ISO-8859-1Q?--a--=b)(a b)
Within a 'comment', white space MUST appear between an
'encoded-word' and surrounding text. [Section 5,
paragraph (2)]. However, white space is not needed between
the initial "(" that begins the 'comment', and the
'encoded-word'.
'コメント'の中では、余白は'コード化された単語'と周囲のテキストの間に現れなければなりません。 [セクション5、パラグラフ(2)]。 しかしながら、余白はイニシャルの間で必要でない、「(「それは'コメント'、および'コード化された単語'を始めます」。
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab)
(=? ISO-8859-1Q?----==--ISO-8859-1--Q--b--=)(腹筋)
White space between adjacent 'encoded-word's is not
displayed.
'コード化された言葉のものは表示されないこと'の隣接している間の余白。
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab)
(=? ISO-8859-1Q?----==--ISO-8859-1--Q--b--=)(腹筋)
Even multiple SPACEs between 'encoded-word's are ignored
for the purpose of display.
'コード化された単語のものは表示の目的のために無視されること'の間の複数のSPACEsさえ。
(=?ISO-8859-1?Q?a?= (ab)
=?ISO-8859-1?Q?b?=)
(=? ISO-8859-1Q?----=(腹筋)=--ISO-8859-1--Q--b--=)
Any amount of linear-space-white between 'encoded-word's,
even if it includes a CRLF followed by one or more SPACEs,
is ignored for the purposes of display.
'1SPACEsによって続かれたCRLFを含んでも、コード化された単語のものは表示の目的のために無視されること'の間の直線的なスペース白についてエニィ・アマウント。
Moore Standards Track [Page 12] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[12ページ]。
(=?ISO-8859-1?Q?a_b?=) (a b)
(=? ISO-8859-1Q?--_b--=)(a b)
In order to cause a SPACE to be displayed within a portion
of encoded text, the SPACE MUST be encoded as part of the
'encoded-word'.
SPACEを引き起こして、コード化されたテキスト、SPACE MUSTの一部の中に表示するために、'コード化された単語'の一部としてコード化されてください。
(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b)
(=? ISO-8859-1Q?----==--ISO-8859-2--Q--_b--=)(a b)
In order to cause a SPACE to be displayed between two strings
of encoded text, the SPACE MAY be encoded as part of one of
the 'encoded-word's.
SPACEを引き起こして、コード化されたテキスト、SPACE MAYの2個のストリングの間に表示するために、'コード化された単語のもの'の1つの一部としてコード化されてください。
9. References
9. 参照
[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[RFC 2049] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples",
RFC 2049, November 1996.
[RFC2049] Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は5を分けます」。 「順応評価基準と例」、RFC2049、11月1996日
[RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[RFC2045] Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2046] Borenstein N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
解放された[RFC2048]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、1996年11月。
Moore Standards Track [Page 13] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[13ページ]。
10. Security Considerations
10. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
11. Acknowledgements
11. 承認
The author wishes to thank Nathaniel Borenstein, Issac Chan, Lutz Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, and Kazuhiko Yamamoto, for their helpful advice, insightful comments, and illuminating questions in response to earlier versions of this specification.
この仕様の以前のバージョンに対応したナザニエルBorensteinに感謝するという作者願望、アイザック・チェン、ルッツDonnerhacke、ポール・エッゲルト、ネッド・フリード、アンドレアスM.Kirchwitz、オッレJarnefors、マイクRosin、ユタカの佐藤、バードSchaefer、彼らの有益な助言を求めるKazuhiko山本、洞察に満ちたコメント、および啓発的な問題。
12. Author's Address
12. 作者のアドレス
Keith Moore University of Tennessee 107 Ayres Hall Knoxville TN 37996-1301
キース・ムーア・テネシー大学107アリエス・ホールノクスビルテネシー37996-1301
EMail: moore@cs.utk.edu
メール: moore@cs.utk.edu
Moore Standards Track [Page 14] RFC 2047 Message Header Extensions November 1996
ムーアStandardsはメッセージヘッダー拡大1996年11月にRFC2047を追跡します[14ページ]。
Appendix - changes since RFC 1522 (in no particular order)
付録--RFC1522以来の変化(特に決まった順番でなく)
+ explicitly state that the MIME-Version is not requried to use
'encoded-word's.
+は、MIMEバージョンが'コード化された単語のもの'を使用するためにrequriedされないと明らかに述べます。
+ add explicit note that SPACEs and TABs are not allowed within
'encoded-word's, explaining that an 'encoded-word' must look like an
'atom' to an RFC822 parser.values, to be precise).
+はSPACEsとTABsが'の単語のコード化されたもの中に許容されていないという明白なメモを加えます、'コード化された単語'が'原子'にRFC822 parser.valuesに似なければならないと説明して、正確に言うと)、'
+ add examples from Olle Jarnefors (thanks!) which illustrate how
encoded-words with adjacent linear-white-space are displayed.
+はどう隣接している直線的な余白があるコード化された言葉を表示するかを例証するオッレJarnefors(ありがとうございます!)から例を加えます。
+ explicitly list terms defined in RFC822 and referenced in this memo
+は明らかにRFC822で定義されて、このメモで参照をつけられる用語をリストアップします。
+ fix transcription typos that caused one or two lines and a couple of
characters to disappear in the resulting text, due to nroff quirks.
+ 1か2つの線と2、3のキャラクタがnroff気まぐれのため結果として起こるテキストで姿を消したフィックス転写誤植。
+ clarify that encoded-words are allowed in '*text' fields in both
RFC822 headers and MIME body part headers, but NOT as parameter
values.
'コード化された単語が許容されている+ははっきりさせる'という*テキスト'分野は、RFC822ヘッダーとMIME本体の両方でヘッダーを分けますが、パラメタ値として分けるというわけではありません。
+ clarify the requirement to switch back to ASCII within the encoded
portion of an 'encoded-word', for any charset that uses code switching
sequences.
+は'コード化された単語'のコード化された部分の中のASCIIに元に戻るという要件をはっきりさせます、コード切り換え系列を使用するどんなcharsetのためにも。
+ add a note about 'encoded-word's being delimited by "(" and ")"
within a comment, but not in a *text (how bizarre!).
そして、+が区切られる'コード化された単語'に関する注を加える、「(「」、)、」 中ではなくコメントの中で*テキスト(何と奇妙な!)、'
+ fix the Andre Pirard example to get rid of the trailing "_" after
the =E9. (no longer needed post-1342).
+は、9=Eの後に引きずっている"_"を取り除くためにアンドレPirardの例を修理します。 (もう、ポスト-1342を必要としません。)
+ clarification: an 'encoded-word' may appear immediately following
the initial "(" or immediately before the final ")" that delimits a
comment, not just adjacent to "(" and ")" *within* *ctext.
+ 明確化: そして、に隣接してすぐに初期に続いて、'コード化された単語'が現れるかもしれない、「(「決勝の直前」、)、」 それはコメントを区切ります、正当でない、「(「」、)、」 **ctextの中の*。
+ add a note to explain that a "B" 'encoded-word' will always have a
multiple of 4 characters in the 'encoded-text' portion.
+は、「B」'コード化された単語'には'コード化されたテキスト'部分の4つのキャラクタの倍数がいつもあると説明するために注意を加えます。
+ add note about the "=" in the examples
+は例の「=」に関する注を加えます。
+ note that processing of 'encoded-word's occurs *after* parsing, and
some of the implications thereof.
+は'コード化された単語のものはそれの含意を**構文解析の、後といくつか生じる'その処理に注意します。
+ explicitly state that you can't expect to translate between
1522 and either vanilla 822 or so-called "8-bit headers".
+は、あなたが、1522とバニラ822かいわゆる「8ビットのヘッダー」のどちらかの間で翻訳することを期待できないと明らかに述べます。
+ explicitly state that 'encoded-word's are not valid within a
'quoted-string'.
+は、'コード化された単語のものは'引用文字列'の中で有効ではありません'と明らかに述べます。
Moore Standards Track [Page 15]
ムーア標準化過程[15ページ]
一覧
スポンサーリンク
