RFC1563 日本語訳
1563 The text/enriched MIME Content-type. N. Borenstein. January 1994. (Format: TXT=32913, PS=73543, PDF=37459 bytes) (Obsoletes RFC1523) (Obsoleted by RFC1896) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Borenstein Request for Comments: 1563 Bellcore Obsoletes: 1523 January 1994 Category: Informational
Borensteinがコメントのために要求するワーキンググループN.をネットワークでつないでください: 1563 Bellcoreは以下を時代遅れにします。 1523 1994年1月のカテゴリ: 情報
The text/enriched MIME Content-type
テキスト/豊かにされたMIME文書内容
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms.
MIME[RFC-1341、RFC-1521]はインターネット・メールにおける、さまざまなデータ型の表現のために書式と一般的な枠組みを定義します。 このドキュメントは1つの特定のタイプに関するMIMEデータを定義します、テキスト/豊かにされたタイプ、RFC1341で定義された「テキスト/richtext」タイプの気品。 テキスト/豊かにされたMIMEの種類がさまざまなハードウェアとソフトウェアプラットホームの向こう側に簡単な豊かにされたテキストの、より広いinteroperationを容易にすることを意図します。
Table of Contents
目次
The Text/enriched MIME type.............................. 2
Formatting Commands...................................... 4
Font-Alteration Commands........................... 4
Fill/Justification Commands........................ 5
Indentation Commands............................... 6
Miscellaneous Commands............................. 6
Balancing and Nesting of Formatting Commands....... 7
Unrecognized formatting commands................... 8
White Space in Text/enriched Data........................ 8
Initial State of a text/enriched interpreter............. 8
Non-ASCII character sets................................. 8
Minimal text/enriched conformance........................ 9
Notes for Implementors................................... 9
Extensions to text/enriched.............................. 10
An Example............................................... 11
Security Considerations.................................. 12
Author's Address......................................... 12
Acknowledgements......................................... 12
References............................................... 12
Appendix A -- A Simple enriched-to-plain Translator in C. 13
Appendix B -- Differences from RFC 1341 text/richtext.... 15
Text/豊かにされたMIMEの種類… 2形式は命令します… 4 字体変更は命令します… 4 中詰め/正当化は命令します… 5刻み目は命令します… 6 その他は命令します… 6 形式のバランスをとることと巣篭もりは命令します… 7の認識されていない形式は命令します… 8 テキスト/豊かにされたデータの白いスペース… 8 テキスト/豊かにされたインタプリタの州に頭文字をつけてください… 8 非ASCII文字の組… 8 最小量のテキスト/豊かにされた順応… 9 作成者によって、注意します。 テキスト/豊かにされることへの9つの拡大… 10 例… 11 セキュリティ問題… 12作者のアドレス… 12の承認… 12の参照箇所… 12 付録A--SimpleはC.13Appendix Bで平野にTranslatorを豊かにしました--RFC1341テキスト/richtextからの違い。 15
Borenstein [Page 1] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[1ページ]RFC1563Aテキスト/豊かにされたタイプ
The Text/enriched MIME type
Text/豊かにされたMIMEの種類
In order to promote the wider interoperability of simple formatted text, this document defines an extremely simple subtype of the MIME content-type "text", the "text/enriched" subtype. This subtype was designed to meet the following criteria:
簡単なフォーマット済みのテキストの、より広い相互運用性を促進するために、このドキュメントはMIME満足しているタイプ「テキスト」(「テキスト/豊かにされた」「副-タイプ」)の非常に簡単な「副-タイプ」を定義します。 この「副-タイプ」は以下の評価基準を満たすように設計されました:
1. The syntax must be extremely simple to parse,
so that even teletype-oriented mail systems can
easily strip away the formatting information and
leave only the readable text.
1. 構文は分析するのが非常に簡単でなければなりません、テレタイプ指向のメールシステムさえ容易に形式情報をはいで、読み込み可能なテキストだけを残すことができるように。
2. The syntax must be extensible to allow for new
formatting commands that are deemed essential for
some application.
2. 構文は何らかのアプリケーションに不可欠であると考えられる新しい書式付けコマンドを考慮するのにおいて広げることができるに違いありません。
3. If the character set in use is ASCII or an 8-
bit ASCII superset, then the raw form of the data
must be readable enough to be largely
unobjectionable in the event that it is displayed
on the screen of the user of a non-MIME-conformant
mail reader.
3. 使用中の文字の組がASCIIか8の噛み付いているASCIIスーパーセットであるなら、非MIMEのconformantメール読者のユーザのスクリーンにそれを表示する場合、データの生のフォームは主に「非-好ましくな」なほど読み込み可能でなければなりません。
4. The capabilities must be extremely limited, to
ensure that it can represent no more than is
likely to be representable by the user's primary
word processor. While this limits what can be
sent, it increases the likelihood that what is
sent can be properly displayed.
4. 能力は、ユーザの第一のワードプロセッサで「表-可能」であることがありそうであるというよりもいいえともう少し表すことができるのを保証するために非常に限らなければなりません。 これは送ることができるものを制限しますが、それは適切に送られるものを表示できる可能性を広げます。
This document defines a new MIME content-type, "text/enriched". The content-type line for this type may have one optional parameter, the "charset" parameter, with the same values permitted for the "text/plain" MIME content-type.
このドキュメントは満足しているタイプで、「テキスト/豊かにされた」状態で新しいMIMEを定義します。 このタイプのための満足しているタイプ線には、1つの任意のパラメタがあるかもしれません、"charset"パラメタ、同じ値が「テキスト/明瞭な」MIME満足しているタイプのために受入れられている状態で。
The syntax of "text/enriched" is very simple. It represents text in
a single character set -- US-ASCII by default, although a different
character set can be specified by the use of the "charset" parameter.
(The semantics of text/enriched in non-ASCII character sets are
discussed later in this document.) All characters represent
themselves, with the exception of the "<" character (ASCII 60), which
is used to mark the beginning of a formatting command. Formatting
instructions consist of formatting commands surrounded by angle
brackets ("<>", ASCII 60 and 62). Each formatting command may be no
more than 60 characters in length, all in US-ASCII, restricted to the
alphanumeric and hyphen ("-") characters. Formatting commands may be
preceded by a solidus ("/", ASCII 47), making them negations, and
such negations must always exist to balance the initial opening
「テキスト/豊かにされること」の構文は非常に簡単です。 それはただ一つの文字の組のテキストを表します--、米国-ASCII、異なった文字の組は指定できますが、デフォルトで、"charset"パラメタの使用で指定されてください。 (後で本書では非ASCII文字の組でテキスト/豊かにされることの意味論について議論します。) すべてのキャラクタが自分たちの代理をします、"<"キャラクタ(ASCII60)を除いて。(キャラクタは、書式付けコマンドの始まりを示すのに使用されます)。 書式設定命令は角ブラケット(「<>」、ASCII60と62)によって囲まれた書式付けコマンドから成ります。 各書式付けコマンドは長さが60未満のキャラクタであるかもしれません、英数字とハイフン(「-」)キャラクタに制限された米国-ASCIIで。 ソリドゥス(「/」、ASCII47)は書式付けコマンドに先行するかもしれなくて、作っているそれらは否定です、そして、そのような否定が、初期の始まりのバランスをとるためにいつも存在しなければなりません。
Borenstein [Page 2] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[2ページ]RFC1563Aテキスト/豊かにされたタイプ
commands. Thus, if the formatting command "<bold>" appears at some point, there must later be a "</bold>" to balance it. (NOTE: The 60 character limit on formatting commands does NOT include the "<", ">", or "/" characters that might be attached to such commands.)
コマンド。 したがって、書式付けコマンド「<の大胆な>」が何らかのポイントに現れるなら、後で、それのバランスをとる「</大胆な>」があるに違いありません。 「(注意: 書式付けコマンドにおける60キャラクタ限界は、"<"、">"をNOTインクルードにするか、または」 そのようなコマンドに付けられるかもしれないキャラクタを」 /にします。)
Formatting commands are always case-insensitive. That is, "bold" and "BoLd" are equivalent in effect, if not in good taste.
書式付けコマンドはいつも大文字と小文字を区別しないです。 それはいて、「大胆さ」と「大胆さ」であることは、事実上、または上品で同等物です。
Beyond tokens delimited by "<" and ">", there are two other special
processing rules. First, a literal less-than sign ("<") can be
represented by a sequence of two such characters, "<<". Second, line
breaks (CRLF pairs in standard network representation) are handled
specially. In particular, isolated CRLF pairs are translated into a
single SPACE character. Sequences of N consecutive CRLF pairs,
however, are translated into N-1 actual line breaks. This permits
long lines of data to be represented in a natural- looking manner
despite the frequency of line-wrapping in Internet mailers. When
preparing the data for mail transport, isolated line breaks should be
inserted wherever necessary to keep each line shorter than 80
characters. When preparing such data for presentation to the user,
isolated line breaks should be replaced by a single SPACE character,
and N consecutive CRLF pairs should be presented to the user as N-1
line breaks.
"<"と">"によって区切られた象徴を超えて、他の2つの特別な処理規則があります。 まず最初に、そのような2つのキャラクタ、「<<」の系列は文字通りの不等号("<")を表すことができます。 特に、2番目に、ラインブレイク(標準のネットワーク表現におけるCRLF組)は扱われます。 特に、孤立しているCRLF組は単独のSPACEキャラクタに翻訳されます。 しかしながら、N連続したCRLF組の系列はN-1の実際のラインブレイクに翻訳されます。 これは、インターネット郵送者の線ラッピングの頻度にもかかわらず、データの長い台詞が生まれながらの見る方法で表されることを許可します。 メール輸送のためにデータを準備するとき、孤立しているラインブレイクはどこでも、80のキャラクタより短く各線を保つのに必要であるところに挿入されるべきです。 プレゼンテーションのためにそのようなデータをユーザに準備するとき、孤立しているラインブレイクを単独のSPACEキャラクタに取り替えるべきです、そして、N-1ラインブレイクとしてN連続したCRLF組をユーザに紹介するべきです。
Thus text/enriched data that looks like this:
その結果、これに似ているテキスト/豊かにされたデータ:
This is
a single
line
これは単線です。
This is the
next line.
これは次の線です。
This is the
next paragraph.
これは次のパラグラフです。
should be displayed by a text/enriched interpreter as follows:
以下のテキスト/豊かにされたインタプリタによって表示されるはずです:
This is a single line
This is the next line.
これによる独身の線Thisが次の線であるということです。
This is the next paragraph.
これは次のパラグラフです。
The formatting commands, not all of which will be implemented by all implementations, are described in the following sections.
書式付けコマンド(それのすべてがすべての実現で実行されるというわけではない)は以下のセクションで説明されます。
Borenstein [Page 3] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[3ページ]RFC1563Aテキスト/豊かにされたタイプ
Formatting Commands
書式付けコマンド
The text/enriched formatting commands all begin with <commandname> and end with </commandname>, affecting the formatting of the text between those two tokens. The commands are described here, grouped according to type.
テキスト/豊かにされた書式付けコマンドは、<commandname>ですべて始まって、</commandname>で終わります、それらの2つの象徴の間のテキストの形式に影響して。 コマンドは、ここで説明されて、タイプに従って、分類されています。
Font-Alteration Commands
字体変更命令
The following formatting commands are intended to alter the font in which text is displayed, but not to alter the indentation or justification state of the text:
以下の書式付けコマンドがしかし、刻み目を変更しないようにどのテキストを表示するか、そして、テキストの正当化状態で字体を変更することを意図します:
Bold -- causes the affected text to be in a bold font. Nested
bold commands have the same effect as a single bold
command.
ボールド--太字フォントには影響を受けるテキストがあることを引き起こします。 入れ子にされた大胆なコマンドには、ただ一つの大胆なコマンドと同じ効果があります。
Italic -- causes the affected text to be in an italic font.
Nested italic commands have the same effect as a single
italic command.
イタリック体、--イタリック体の字体には影響を受けるテキストがあることを引き起こします。 入れ子にされたイタリック体のコマンドには、ただ一つのイタリック体のコマンドと同じ効果があります。
Fixed -- causes the affected text to be in a fixed width font.
Nested fixed commands have the same effect as a single
fixed command.
修理されました--固定幅の字体には影響を受けるテキストがあることを引き起こします。 入れ子にされた固定コマンドには、ただ一つの固定コマンドと同じ効果があります。
Smaller -- causes the affected text to be in a smaller font.
It is recommended that the font size be changed by two
points, but other amounts may be more appropriate in some
environments. Nested smaller commands produce ever-
smaller fonts, to the limits of the implementation's
capacity to reasonably display them, after which further
smaller commands have no incremental effect.
小ささ、--より小さい字体には影響を受けるテキストがあることを引き起こします。 字体サイズを2ポイント変えるのがお勧めですが、いくつかの環境で他の量は、より適切であるかもしれません。 入れ子にされたより小さいコマンドは、より絶えず小さい字体を発生させます、合理的にそれらを表示する実現の能力の限界に。(さらなるより小さいコマンドには、その時、どんな増加の効果もありませんでした後)。
Bigger -- causes the affected text to be in a bigger font. It
is recommended that the font size be changed by two
points, but other amounts may be more appropriate in some
environments. Nested bigger commands produce ever-bigger
fonts, to the limits of the implementation's capacity to
reasonably display them, after which further bigger
commands have no incremental effect.
大きさ、--より大きい字体には影響を受けるテキストがあることを引き起こします。 字体サイズを2ポイント変えるのがお勧めですが、いくつかの環境で他の量は、より適切であるかもしれません。 入れ子にされたより大きいコマンドは、より絶えず大きい字体を発生させます、合理的にそれらを表示する実現の能力の限界に。(さらなるより大きいコマンドには、その時、どんな増加の効果もありませんでした後)。
Underline -- causes the affected text to be underlined. Nested
underline commands have the same effect as a single
underline command.
アンダーライン--影響を受けるテキストがアンダーラインを引かれることを引き起こします。 入れ子にされたアンダーラインを引くコマンドには、ただ一つのアンダーラインを引くコマンドと同じ効果があります。
While the "bigger" and "smaller" operators are effectively inverses, it is not recommended, for example, that "<smaller>" be used to end the effect of "<bigger>". This is properly done with "</bigger>".
事実上、「より大きく」て「より小さい」オペレータが逆である間、例えば、「<の、より小さい>」が「<の、より大きい>」の効果を終わらせるのに使用されることが勧められません。 「より</大きい>」で適切にこれをします。
Borenstein [Page 4] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[4ページ]RFC1563Aテキスト/豊かにされたタイプ
Fill/Justification Commands
中詰め/正当化命令
Initially, text/enriched text is intended to be displayed fully filled with appropriate kerning and letter-tracking as suits the capabilities of the receiving user agent software. Actual line width is left to the discretion of the receiver, which is expected to fold lines intelligently (preferring soft line breaks) to the best of its ability.
初めは、適切なカーニングで完全に満たされて、スーツとして能力を手紙で追跡しながら受信ユーザエージェントソフトウェアについてテキスト/豊かにされたテキストが表示されることを意図します。 実際の線幅は受信機に任せます。(それは、知的(柔らかいラインブレイクを好む)にできる限り線を折り重ねると予想されます)。
The following commands alter that state. Each of these commands force a line break before and after the formatting environment if there is not otherwise a line break. For example, if one of these commands occurs anywhere other than the beginning of a line of text as presented, a new line is begun.
以下のコマンドはその状態を変更します。 そうでなければ、ラインブレイクがなければ、それぞれのこれらのコマンドは形式環境の前後にラインブレイクを強制します。 例えば、テキスト行の始まりを除いて、これらのコマンドの1つが提示されるように何処かでに起こるなら、復帰改行は始められます。
Center -- causes the affected text to be centered.
センター--影響を受けるテキストが中心に置かれることを引き起こします。
FlushLeft -- causes the affected text to be left-justified with a
ragged right margin.
FlushLeft--影響を受けるテキストが左でぼろぼろのライト・マージンで正当であることを引き起こします。
FlushRight -- causes the affected text to be right-justified with a
ragged left margin.
FlushRight--影響を受けるテキストが左のぼろぼろのマージンでまさしく正当であることを引き起こします。
FlushBoth -- causes the affected text to be filled and padded so
as to create smooth left and right margins, i.e., to be
fully justified.
FlushBoth--すなわち、完全に正当化されるために滑らかな左右のマージンを作成するために影響を受けるテキストがいっぱいにされて、水増しされることを引き起こします。
Nofill -- causes the affected text to be displayed without filling
or justification.
Nofill--影響を受けるテキストが充填も正当化なしで表示されることを引き起こします。
The center, flushleft, flushright, and flushboth commands are mutually exclusive, and, when nested, the inner command takes precedence.
センター、flushleft、flushright、およびflushbothコマンドは互いに排他的です、そして、入れ子にされると、内側のコマンドは優先します。
Whether or not text is justified by default (that is, whether the default environment is flushleft, flushright, or flushboth) is unspecified, and depends on the preferences of the user, the capabilities of the local software and hardware, and the nature of the character set in use. On systems where justification is considered undesirable, the flushboth environment may be identical to the default environment. Note that justification should never be performed inside of center, flushleft, flushright, or nofill environments. Note also that for some non-ASCII character sets, full justification may be fundamentally inappropriate.
テキストがデフォルトで正当化されるかどうかが(すなわち、デフォルト環境がflushleft、flushright、またはflushbothであることにかかわらず)、不特定であり、ユーザの好み、ローカルのソフトウェアとハードウェアの能力、および使用中の文字の組の本質に依存します。 システムでは、上、正当化が望ましくないと考えられるflushboth環境はデフォルト環境と同じであるかもしれません。 正当化が決してセンター、flushleft、flushright、またはnofill環境の実行された内部でないことに注意してください。 また、いくつかの非ASCII文字の組には、完全な正当化が基本的に不適当であるかもしれないことに注意してください。
Borenstein [Page 5] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[5ページ]RFC1563Aテキスト/豊かにされたタイプ
Indentation Commands
刻み目のコマンド
Initially, text/enriched text is displayed using the maximum available margins. Two formatting commands may be used to affect the margins.
初めは、最大の利用可能なマージンを使用することでテキスト/豊かにされたテキストを表示します。 2つの書式付けコマンドが、マージンに影響するのに使用されるかもしれません。
Indent -- causes the running left margin to be moved to the
right. The recommended indentation change is the width of
four characters, but this may differ among
implementations.
インデント--右に動かされるために左のマージンを走行に引き起こします。 お勧めの刻み目の変化は4つのキャラクタの幅ですが、これは実現の中で異なるかもしれません。
IndentRight -- causes the running right margin to be moved to
the left. The recommended indentation change is the width
of four characters, but this may differ among
implementations.
IndentRight--走行ライト・マージンが左に動かされることを引き起こします。 お勧めの刻み目の変化は4つのキャラクタの幅ですが、これは実現の中で異なるかもしれません。
A line break is NOT forced by a change of the margin, to permit the description of "hanging" text. Thus for example the following text:
ラインブレイクはマージンの変化でやむを得ず「掛かっている」テキストの記述を可能にしません。 その結果、例えば、以下のテキスト:
Now <indent> is the time for all good horses to come to the aid of their stable, assuming that </indent> any stable is really stable.
<インデント>がそれらのうまやの援助へのすべての良い馬の来たる時間であるので、その</インデント>があらゆるうまやであると仮定するのは本当に安定しています。
would be displayed in a 40-character-wide window as follows:
aに表示するだろう、40キャラクタ、広さ、以下の窓:
Now is the time for all good horses to
come to the aid of their stable,
assuming that any stable is
really stable.
現在はそれらのうまやの援助へのすべての良い馬の来たる時間です、どんなうまやも本当に安定していると仮定して。
Miscellaneous Commands
種々雑多なコマンド
Excerpt -- causes the affected text to be interpreted as a
textual excerpt from another source, probably a message
being responded to. Typically this will be displayed
using indentation and an alternate font, or by indenting
lines and preceding them with "> ", but such decisions are
up to the implementation. (Note that this is the only
truly declarative markup construct in text/enriched, and
as such doesn't fit very well with the other facilities,
but it describes a type of markup that is very commonly
used in email and has no procedural analogue.) Note that
as with the justification commands, the excerpt command
implicitly begins and ends with a line break if one is not
already there.
抜粋--影響を受けるテキストが別のソースからの原文の抜粋、たぶん応じるメッセージとして解釈されることを引き起こします。 通常、刻み目と交互の字体を使用することでこれを表示するだろうか、または">"で線にギザギザを付けさせて、それらに先行することによって、そのような決定だけが実現まで達しています。 (これが本当に叙述的なマーク付けがテキストで組み立てたか、または豊かにした唯一であり、そういうものとしてそれほど他の施設をよく与えませんが、メールで非常に一般的に使用されて、どんな手続き上のアナログも持っていない一種の値上げについて説明することに注意してください。) 1つが既にそこにないなら、抜粋命令が正当化命令のようにそれとなく始まって、ラインブレイクで終わることに注意してください。
Borenstein [Page 6] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[6ページ]RFC1563Aテキスト/豊かにされたタイプ
Param -- Marks the affected text as command parameters, to be
interpreted or ignored by the text/enriched interpreter,
but NOT to be shown to the reader. The syntax of the
parameter data (whatever appears between the initial
"<param>" and the terminating "</param>") is left
undefined by this memo, to be defined by text/enriched
extensions in the future. However, the format of such
data must NOT contain nested <param> commands, and either
must NOT use the "<" character or must use it in a way
that is compatible with text/enriched parsing. That is,
the end of the parameter data should be recognizable with
EITHER of two algorithms: simply searching for the first
occurence of "</param>" or parsing until a balanced
"</param>" command is found. In either case, however, the
parameter data should NOT be shown to the human reader.
Param--読者に示されるのではなく、テキスト/豊かにされたインタプリタによって解釈されるか、または無視されるように、コマンドパラメタとして影響を受けるテキストにマークします。 未定義の状態で、将来テキスト/豊かにされた拡大でパラメタデータ(初期の「<param>」と終わっている「</param>」の間に現れるものなら何でも)の構文が定義されるのがこのメモで残されます。 しかしながら、そのようなデータの形式は、入れ子にされた<param>コマンドを含んではいけなくて、"<"キャラクタを使用してはいけませんし、またテキスト/豊かにされた構文解析と互換性がある方法でそれを使用しなければなりません。 すなわち、パラメタデータの終わりは2つのアルゴリズムのEITHERと共に認識可能であるべきです: バランスのとれている「</param>」コマンドまで単に「</param>」の最初のoccurenceを捜すか、または分析するのが見つけられます。 しかしながら、どちらの場合ではも、パラメタデータを人間の読者に示すべきではありません。
Balancing and Nesting of Formatting Commands
書式付けコマンドのバランスをとることと巣篭もり
Pairs of formatting commands must be properly balanced and nested. Thus, a proper way to describe text in bold italics is:
書式付けコマンドのペアは適切にバランスをとっていて、入れ子にしなければなりません。 したがって、太字のイタリックでテキストについて説明する適切な方法は以下の通りです。
<bold><italic>the-text</italic></bold>
<の大胆な><イタリック体の>、-、テキストの</イタリック体の></大胆な>。
or, alternately,
または、交互に。
<italic><bold>the-text</bold></italic>
<のイタリック体の><大胆な>、-、テキストの</大胆な></イタリック体の>。
but, in particular, the following is illegal
text/enriched:
しかし、特に、以下はテキスト/豊かにされた状態で不法です:
<bold><italic>the-text</bold></italic>
<の大胆な><イタリック体の>、-、テキストの</大胆な></イタリック体の>。
The nesting requirement for formatting commands imposes a slightly higher burden upon the composers of text/enriched bodies, but potentially simplifies text/enriched displayers by allowing them to be stack-based. The main goal of text/enriched is to be simple enough to make multifont, formatted email widely readable, so that those with the capability of sending it will be able to do so with confidence. Thus slightly increased complexity in the composing software was deemed a reasonable tradeoff for simplified reading software. Nonetheless, implementors of text/enriched readers are encouraged to follow the general Internet guidelines of being conservative in what you send and liberal in what you accept. Those implementations that can do so are encouraged to deal reasonably with improperly nested text/enriched data.
書式付けコマンドのための巣篭もり要件は、テキスト/豊かにされたボディーの作曲家にわずかに高い負担を押しつけますが、それらがスタックベースであることを許容することによって、潜在的にテキスト/豊かにされた「不-プレーヤー」を簡素化します。 テキスト/豊かにされることの第一目的はマルチフォント、フォーマットされたメールを広く読み込み可能にするほど簡単であることになっています、したがって、それを送る能力があるそれらが信用を処理できるように。 構成ソフトウェアにおけるこのようにしてわずかに増加する複雑さは簡易型の読書ソフトウェアのための手頃な見返りであると考えられました。 それにもかかわらず、テキスト/豊かにされた読者の作成者があなたが送るもので保守的であって、あなたが受け入れるもので寛容であることの一般的なインターネットガイドラインに従うよう奨励されます。 そうできるそれらの実現が合理的に不適切に入れ子にされたテキスト/豊かにされたデータに対処するよう奨励されます。
Borenstein [Page 7] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[7ページ]RFC1563Aテキスト/豊かにされたタイプ
Unrecognized formatting commands
認識されていない書式付けコマンド
Implementations must regard any unrecognized formatting command as "no-op" commands, that is, as commands having no effect, thus facilitating future extensions to "text/enriched". Private extensions may be defined using formatting commands that begin with "X-", by analogy to Internet mail header field names.
実現は、どんな認識されていない書式付けコマンドも「オプアートがありません」コマンドと見なさなければなりません、すなわち、効き目がないコマンドとして、その結果、「テキスト/豊かにされること」に今後の拡大を容易にします。 個人的な拡大は、「X」と共にインターネット・メールヘッダーフィールドへの類推で始まる書式付けコマンドを使用することで定義されるかもしれません。
In order to formally define extended commands, a new Internet document should be published.
正式に拡張コマンドを定義するために、新しいインターネットドキュメントは発表されるべきです。
White Space in Text/enriched Data
テキスト/豊かにされたデータの余白
No special behavior is required for the SPACE or TAB (HT) character. It is recommended, however, that, at least when fixed-width fonts are in use, the common semantics of the TAB (HT) character should be observed, namely that it moves to the next column position that is a multiple of 8. (In other words, if a TAB (HT) occurs in column n, where the leftmost column is column 0, then that TAB (HT) should be replaced by 8-(n mod 8) SPACE characters.) It should also be noted that some mail gateways are notorious for losing (or, less commonly, adding) white space at the end of lines, so reliance on SPACE or TAB characters at the end of a line is not recommended.
どんな特別な振舞いもSPACEかTAB(HT)キャラクタに必要ではありません。 しかしながら、それがお勧めである、それ、少なくともいつ固定ピッチフォントは使用中に、TAB(HT)キャラクタの一般的な意味論が観測されるべきであり、すなわち、8の倍数である次期コラム位置に動くということであるか。 (言い換えれば、TAB(HT)が一番左コラムがコラム0である桁nに起こるなら、そのTAB(HT)を8(nモッズ風の8)SPACEキャラクタに取り替えるべきです。) また、線の端のSPACEかTABキャラクタへの信用が推薦されないで、行末の失っていて(それほど一般的にない加えません)の余白に、いくつかのメール・ゲートウェイが悪名高いことに注意されるべきです。
Initial State of a text/enriched interpreter
テキスト/豊かにされたインタプリタの初期の州
Text/enriched is assumed to begin with filled text in a variable- width font in a normal typeface and a size that is average for the current display and user. The left and right margins are assumed to be maximal, that is, at the leftmost and rightmost acceptable positions.
/が豊かにしたテキストは正常な活字面の可変幅の字体と現在の表示とユーザにとって、平均したサイズにおける初めにいっぱいにされたテキストであると思われます。 左右のマージンがすなわち、一番左の、そして、一番右の許容できる位置で最大限度であると思われます。
Non-ASCII character sets
非ASCII文字の組
If the character set specified by the charset parameter on the Content-type line is anything other than "US-ASCII", this means that the text being described by text/enriched formatting commands is in a non-ASCII character set. However, the commands themselves are still the same ASCII commands that are defined in this document. This creates an ambiguity only with reference to the "<" character, the octet with numeric value 60. In single byte character sets, such as the ISO-8859 family, this is not a problem; the octet 60 can be quoted by including it twice, just as for ASCII. The problem is more complicated, however, in the case of multi-byte character sets, where the octet 60 might appear at any point in the byte sequence for any of several characters.
文書内容線に関するcharsetパラメタによって指定された文字の組が「米国-ASCII」を除いた何か、これが非ASCII文字の組にはテキスト/豊かにされた書式付けコマンドで説明されるテキストがあることを意味するということであるなら。 しかしながら、コマンド自体は本書では定義されるまだ同じASCIIコマンドです。 これは単に"<"キャラクタ、数値60がある八重奏に関してあいまいさを作成します。 ISO-8859家などのただ一つのバイト文字の組では、これは問題ではありません。 まさしくASCIIのように二度それを含んでいることによって、八重奏60を引用できます。 しかしながら、多バイト文字セットの場合では問題は、より複雑です。(そこでは、八重奏60は任意な点にいくつかのキャラクタのどれかに関してバイト列に現れるかもしれません)。
Borenstein [Page 8] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[8ページ]RFC1563Aテキスト/豊かにされたタイプ
In practice, however, most multibyte character sets address this problem internally. For example, the ISO-2022 family of character sets can switch back into ASCII at any moment. Therefore it is specified that, before text/enriched formatting commands, the prevailing character set should be "switched back" into ASCII, and that only those characters which would be interpreted as "<" in plain text should be interpreted as token delimiters in text/enriched.
しかしながら、実際には、ほとんどの多バイト文字セットが内部的にこのその問題を訴えます。 例えば、文字の組のISO-2022家はいつ何時、ASCIIに元に戻ることができます。 したがって、"<"としてプレーンテキストで解釈されるそれらのキャラクタだけが行き渡っている文字の組はテキスト/豊かにされた書式付けコマンドの前にASCIIに「元に戻らされるべきであり」、テキストの象徴デリミタとして解釈されるべきであるか、または豊かにされるべきであると指定されます。
The question of what to do for hypothetical future character sets that do NOT subsume ASCII is not addressed in this memo.
ASCIIを包括しない仮定している将来の文字の組のためにするべきことに関する質問はこのメモに記述されません。
Minimal text/enriched conformance
最小量のテキスト/豊かにされた順応
A minimal text/enriched implementation is one that converts "<<" to "<", removes everything between a <param> command and the next balancing </param> command, removes all other formatting commands (all text enclosed in angle brackets), and, outside of <nofill> environments, converts any series of n CRLFs to n-1 CRLFs, and converts any lone CRLF pairs to SPACE.
最小量のテキスト/豊かにされた実現は<nofill>環境の外で「<<」を"<"に変換して、<param>コマンドと次のバランスをとることの</param>コマンドの間にすべてを移して、他のすべての書式付けコマンド(角ブラケットに同封されたすべてのテキスト)を移して、n CRLFsのどんなシリーズもn-1 CRLFsに変換して、どんなひとりのCRLF組もスペースに変換するものです。
Notes for Implementors
作成者への注意
It is recognized that implementors of future mail systems will want rich text functionality far beyond that currently defined for text/enriched. The intent of text/enriched is to provide a common format for expressing that functionality in a form in which much of it, at least, will be understood by interoperating software. Thus, in particular, software with a richer notion of formatted text than text/enriched can still use text/enriched as its basic representation, but can extend it with new formatting commands and by hiding information specific to that software system in text/enriched <param> constructs. As such systems evolve, it is expected that the definition of text/enriched will be further refined by future published specifications, but text/enriched as defined here provides a platform on which evolutionary refinements can be based.
将来のメールシステムの作成者が遠くにそんなに現在を超えたリッチテキストの機能性をテキストのために定義されるか、または豊かにして欲しくなると認められます。 テキスト/豊かにされることの意図はそれの多くがソフトウェアを共同利用するのに少なくとも解釈されるフォームでその機能性を言い表すための一般的な形式を提供することです。 その結果、特にフォーマット済みのテキストの、より豊かな概念があるソフトウェア、テキスト/豊かにされた<param>構造物のそのソフトウェア・システムに特定の基本的な表現としてテキスト/豊かにされた状態で缶の静かな使用を豊かにしますが、新しい書式付けコマンドでそれを広げることができる、テキスト/隠れている情報より。 そういうものとして、システムは発展して、定義されて、進化論の気品が基づくことができるプラットホームがここで提供されるので、将来の広められた仕様でさらに精製されて、テキスト/豊かにされるのを除いて、テキスト/豊かにされることの定義がそうすると予想されます。
An expected common way that sophisticated mail programs will generate text/enriched data is as part of a multipart/alternative construct. For example, a mail agent that can generate enriched mail in ODA format can generate that mail in a more widely interoperable form by generating both text/enriched and ODA versions of the same data, e.g.:
複合の、または、代替の構造物の一部として精巧なメールプログラムがテキスト/豊かにされたデータを発生させる予想された一般的な方法があります。 例えば、ODA形式における豊かにされたメールを作ることができるメールエージェントは、より広く共同利用できるフォームで例えば同じデータの両方の豊かにされるのとODAテキスト/バージョンを発生させることによって、そのメールを作ることができます:
Borenstein [Page 9] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[9ページ]RFC1563Aテキスト/豊かにされたタイプ
Content-type: multipart/alternative; boundary=foo
文書内容: 複合/代替手段。 境界=foo
--foo
Content-type: text/enriched
--foo文書内容: テキスト/豊かにされます。
[text/enriched version of data]
--foo
Content-type: application/oda
[データのテキスト/豊かにされたバージョン] --foo文書内容: アプリケーション/oda
[ODA version of data]
--foo--
[データのODAバージョン] --foo--
If such a message is read using a MIME-conformant mail reader that understands ODA, the ODA version will be displayed; otherwise, the text/enriched version will be shown.
ODAを理解しているMIME-conformantメール読者を使用することでそのようなメッセージを読むと、ODAバージョンを表示するでしょう。 さもなければ、テキスト/豊かにされたバージョンは示されるでしょう。
In some environments, it might be impossible to combine certain text/enriched formatting commands, whereas in others they might be combined easily. For example, the combination of <bold> and <italic> might produce bold italics on systems that support such fonts, but there exist systems that can make text bold or italicized, but not both. In such cases, the most recently issued (innermost) recognized formatting command should be preferred.
いくつかの環境で、あるテキスト/豊かにされた書式付けコマンドを結合するのが不可能であるかもしれませんが、他のものでは、彼らは容易に結合されるかもしれません。 例えば、<の大胆な>と<のイタリック体の>の組み合わせはそのような字体を支持するシステムに太字のイタリックを作成するかもしれませんが、テキストを大胆さかイタリック体で印刷されるようにすることができるシステムが存在していますが、ともに存在するというわけではありません。 そのような場合、最も最近発行された(最も奥深い)認識された書式付けコマンドは好まれるべきです。
One of the major goals in the design of text/enriched was to make it so simple that even text-only mailers will implement enriched-to- plain-text translators, thus increasing the likelihood that enriched text will become "safe" to use very widely. To demonstrate this simplicity, an extremely simple C program that converts text/enriched input into plain text output is included in Appendix A.
テキスト/豊かにされることのデザインにおける主要な目標の1つはそれをテキストのみ郵送者さえ豊かにされた状態で実行するほど簡単にすることでした。その結果、-プレーンテキスト翻訳者に、非常に広く使用するために「安全に」なるために望んでいて、テキストを豊かにした可能性を広げてください。 この簡単さを示すために、テキスト/豊かにされた入力をプレーンテキスト出力に変換する非常に簡単なCプログラムはAppendix Aに含まれています。
Extensions to text/enriched
テキスト/豊かにされることへの拡大
It is expected that various mail system authors will desire extensions to text/enriched. The simple syntax of text/enriched, and the specification that unrecognized formatting commands should simply be ignored, are intend to promote such extensions.
様々なメールシステム作者がテキスト/豊かにされるのに拡大を望むと予想されます。 /が豊かにしたテキストの簡単な構文、および認識されていない形式が単に無視されるべきであると命令する仕様があります。そのような拡大を促進するつもりであってください。
Beyond simply defining new formatting commands, however, it may sometimes be necessary to define formatting commands that can take arguments. This is the intended use of the <param> construct. In particular, software that wished to extend text/enriched to include colored text might define an "x-color" environment which always began with a color name parameter, to indicate the desired color for the affected text.
しかしながら、単に新しい書式付けコマンドを定義することを超えて、議論を取ることができる書式付けコマンドを定義するのが時々必要であるかもしれません。 これは<param>構造物の意図している使用です。 特に、有色のテキストを含むようにテキスト/豊かにされた状態で広がりたがっていたソフトウェアは影響を受けるテキストのための必要な色を示すためにいつも色の名前パラメタで始まった「x-色」環境を定義するかもしれません。
Borenstein [Page 10] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[10ページ]RFC1563Aテキスト/豊かにされたタイプ
An Example
例
Putting all this together, the following "text/enriched" body fragment:
このすべてをまとめる以下の「テキスト/豊かにされた」ボディー断片:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Content-type: text/enriched
From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッド Freed <ned@innosoft.com 、gt;、文書内容: テキスト/豊かにされます。
<bold>Now</bold> is the time for
<italic>all</italic> good men
<smaller>(and <<women>)</smaller> to
<ignoreme>come</ignoreme>
<の大胆な>が</大胆な>が<ignoreme>への<のイタリック体の>よりすべて</イタリック体の>良い男性<の、より小さい>(そして、<<女性>)</小さい>のための時間であるので</ignoremeになる、>。
to the aid of their
援助、それら
<x-color><param>red</param>beloved</x-color>
country.
<xカラー><param>赤い</param>いとしいx</カラー>国。
By the way, I think that <<smaller>
ところで、私は、その<<が、より小さい>であると思います。
should
should
REALLY be called
本当に電話をされてください。
<<tinier>
and that I am always right.
<の<の、より小さい>とそのIはいつも正しいです。
-- the end
-- 終わり
represents the following formatted text (which will, no doubt, look somewhat cryptic in the text-only version of this document):
以下のフォーマット済みのテキスト(間違いなくこのドキュメントのテキストのみバージョンでいくらか不可解に見える)を表します:
Now is the time for all good men (and <women>) to
come
to the aid of their
現在がすべての良い男性(そして、<女性>)が援助に来る時間である、彼女ら
beloved country.
By the way, I think that <smaller>
should
REALLY be called
<tinier>
and that I am always right.
-- the end
いとしい国。 ところで、私は<の、より小さい>が本当に<の、より小さい>と呼ばれるべきであり、いつも正当であると思います。 -- 終わり
where the word "beloved" would be in red on a color display if the receiving software implemented the "x-color" extension.
受信ソフトウェアが「x-色」拡大を実行するならカラーディスプレイに関する赤には「いとしい」という言葉があるところで。
Borenstein [Page 11] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[11ページ]RFC1563Aテキスト/豊かにされたタイプ
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo, as the mechanism raises no security issues.
メカニズムが安全保障問題を全く提起しないのに従って、このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
For more information, the author of this document may be contacted via Internet mail:
詳しくは、インターネット・メールでこのドキュメントの作者は連絡されるかもしれません:
Nathaniel S. Borenstein MRE 2D-296, Bellcore 445 South St. Morristown, NJ 07962-1910
ナザニエルS.Borenstein MRE2D-296、南聖モリスタウン、Bellcore445ニュージャージー07962-1910
Phone: +1 201 829 4270 Fax: +1 201 829 5963 EMail: nsb@bellcore.com
以下に電話をしてください。 +1 201 829、4270Fax: +1 5963年の201 829メール: nsb@bellcore.com
Acknowledgements
承認
This document reflects the input of many contributors, readers, and implementors of the original MIME specification, RFC 1341. It also reflects particular contributions and comments from Terry Crowley, Rhys Weatherley, and John LoVerso.
RFC1341、このドキュメントは当初のMIME仕様の多くの貢献者、読者、および作成者の入力を反映します。 また、それはテリー・クローリー、リスWeatherley、およびジョンLoVersoから特定の貢献とコメントを反映します。
References
参照
[RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying
and Describing the Format of Internet Message Bodies",
RFC 1341, Bellcore, Innosoft, June 1992.
[RFC-1341]Borenstein(N.、および解放されたN.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、Innosoft、1992年6月。
[RFC-1521] 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.
解放された[RFC-1521]Borenstein、N.、およびN.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。
Borenstein [Page 12] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[12ページ]RFC1563Aテキスト/豊かにされたタイプ
Appendix A -- A Simple enriched-to-plain Translator in C
付録A--SimpleはCで平野にTranslatorを豊かにしました。
One of the major goals in the design of the text/enriched subtype of the text Content-Type is to make formatted text so simple that even text-only mailers will implement enriched-to-plain-text translators, thus increasing the likelihood that multifont text will become "safe" to use very widely. To demonstrate this simplicity, what follows is a simple C program that converts text/enriched input into plain text output. Note that the local newline convention (the single character represented by "\n") is assumed by this program, but that special CRLF handling might be necessary on some systems.
テキストコンテントタイプのテキスト/豊かにされた「副-タイプ」のデザインにおける主要な目標の1つはフォーマット済みのテキストをテキストのみ郵送者さえプレーンテキストに豊かにされた翻訳者を実行するほど簡単にすることです、その結果、マルチフォントテキストが非常に広く使用するために「安全に」なる可能性を広げます。 この簡単さを示すために、続くことはテキスト/豊かにされた入力をプレーンテキスト出力に変換する簡単なCプログラムです。 「地方のニューラインコンベンション(」 \n」代理をされた単独のキャラクタ)がこのプログラムで想定されますが、特別なCRLF取り扱いがいくつかのシステムの上で必要であるかもしれないことに注意してください。
#include <stdio.h> #include <ctype.h>
#<stdio.h>#インクルード<ctype.h>を含めてください。
main() {
int c, i, paramct=0, newlinect=0, nofill=0;
char token[62], *p;
メイン()、int c、i、paramct=0、newlinect=0、nofill=0; 象徴[62]、*pを炭にしてください。
while ((c=getc(stdin)) != EOF) {
if (c == '<') {
if (newlinect == 1) putc(' ', stdout);
newlinect = 0;
c = getc(stdin);
if (c == '<') {
if (paramct <= 0) putc(c, stdout);
} else {
ungetc(c, stdin);
for (i=0, p=token; (c=getc(stdin)) != EOF && c != '>';
i++)
{ if (i < sizeof(token)-1)
*p++ = isupper(c) ? tolower(c) : c;
}
*p = '%%BODY%%';
if (c == EOF) break;
if (strcmp(token, "param") == 0)
paramct++;
else if (strcmp(token, "nofill") == 0)
nofill++;
else if (strcmp(token, "/param") == 0)
paramct--;
else if (strcmp(token, "/nofill") == 0)
nofill--;
}
} else {
if (paramct > 0)
; /* ignore params */
else if (c == '\n' && nofill <= 0) {
(c=getc(stdin!)=EOF)です; 等しい..ほか..象徴..象徴; 壊す..象徴..ほかに..象徴..ほか..象徴..ほかに..象徴; ほか、(paramct>0)であるなら; '/*は(''c=\n nofill<=0)であるなら*/ほかのparamsを無視します。
Borenstein [Page 13] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[13ページ]RFC1563Aテキスト/豊かにされたタイプ
if (++newlinect > 1) putc(c, stdout);
} else {
if (newlinect == 1) putc(' ', stdout);
newlinect = 0;
putc(c, stdout);
}
}
}
/* The following line is only needed with line-buffering */
putc('\n', stdout);
exit(0);
}
(+ + newlinect>1)putc(c、stdout)であるなら。 ほか、(newlinect=1)putcである、('、'、stdout)、;、' newlinect=0。 putc(c、stdout)。 } } } 以下が裏打ちする/*が線をバッファリングする*/putc('\n'、stdout)で必要であるだけです。 出口(0)。 }
It should be noted that one can do considerably better than this in displaying text/enriched data on a dumb terminal. In particular, one can replace font information such as "bold" with textual emphasis (like *this* or _T_H_I_S_). One can also properly handle the text/enriched formatting commands regarding indentation, justification, and others. However, the above program is all that is necessary in order to present text/enriched on a dumb terminal without showing the user any formatting artifacts.
1つがダム端末で表示におけるこれよりかなり良いテキスト/豊かにされたデータができることに注意されるべきです。 特に、1つは原文の強調(_*この*や_T_H I_S_のような)に「ボールド」などの字体情報を置き換えることができます。 また、1つは適切に刻み目、正当化、および他のものに関するテキスト/豊かにされた書式付けコマンドを扱うことができます。 しかしながら、上記のプログラムはダム端末の上にどんな形式人工物もユーザに見せていなくて豊かにされたテキスト/を提示するのに必要なすべてです。
Borenstein [Page 14] RFC 1563 A text/enriched type for MIME January 1994
MIME1994年1月のためのBorenstein[14ページ]RFC1563Aテキスト/豊かにされたタイプ
Appendix B -- Differences from RFC 1341 text/richtext
付録B--RFC1341テキスト/richtextからの違い
Text/enriched is a clarification, simplification, and refinement of the type defined as text/richtext in RFC 1341. For the benefit of those who are already familiar with text/richtext, or for those who want to exploit the similarities to be able to display text/richtext data with their text/enriched software, the differences between the two are summarized here. Note, however, that text/enriched is intended to make text/richtext obsolete, so it is not recommended that new software generate text/richtext.
/が豊かにしたテキストは、RFC1341でテキスト/richtextと定義されたタイプの明確化と、簡素化と、気品です。 既にテキスト/richtextになじみ深いそれらの利益、またはそれらのテキスト/豊かにされたソフトウェアがあるテキスト/richtextデータを表示できるように類似性を利用したがっている人に関しては、2の違いはここへまとめられます。 しかしながら、新しいソフトウェアがテキスト/richtextを発生させることが勧められないように/が豊かにしたテキストでテキスト/richtextが時代遅れになることを意図することに注意してください。
0. The name "richtext" was changed to "enriched", both to
differentiate the two versions and because "richtext"
created widespread confusion with Microsoft's Rich Text
Format (RTF).
0. ともに2つのバージョンを微分するために「豊かにされ」て、"richtext"がマイクロソフトのリッチテキストフォーマット(RTF)への広範囲の混乱を作成したので、"richtext"という名前に変えました。
1. Clarifications. Many things were ambiguous or
unspecified in the text/richtext definition, particularly
the initial state and the semantics of richtext with
multibyte character sets. However, such differences are
OPERATIONALLY irrelevant, since the clarifications offered
in this document are at least reasonable interpretations of
the text/richtext specification.
1. 明確化。 多くのものが、テキスト/richtext定義、特に初期状態、および多バイト文字セットがあるrichtextの意味論であいまいであるか、または不特定でした。 しかしながら、そのような違いはOPERATIONALLY無関係です、本書では提供された明確化が少なくともテキスト/richtext仕様の理に適った解釈であるので。
2. Newline semantics have changed. In text/richtext, all
CRLFs were mapped to spaces, and line breaks were indicated
by "<nl>". This has been replaced by the "n-1" rule for
CRLFs.
2. ニューライン意味論は変化しました。 テキスト/richtextでは、すべてのCRLFsが空間に写像されました、そして、ラインブレイクは「<nl>」によって示されました。 これを「CRLFsのためのn-1インチの規則」に取り替えました。
3. The representation of a literal "<" character was "<lt>"
in text/richtext, but is "<<" in text/enriched.
3. 文字通りの"<"キャラクタの表現は、テキスト/richtextの「<lt>」でしたが、テキスト/豊かにされるところの「<<」です。
4. The "nofill" command did not exist in text/richtext.
4. "nofill"コマンドはテキスト/richtextに存在しませんでした。
5. The "param" command did not exist in text/richtext.
5. "param"コマンドはテキスト/richtextに存在しませんでした。
6. The following commands from text/richtext have been
REMOVED from text/enriched: <COMMENT>, <OUTDENT>,
<OUTDENTRIGHT>, <SAMEPAGE>, <SUBSCRIPT>, <SUPERSCRIPT>,
<HEADING>, <FOOTING>, <ISO-8859-[1-9]>, <US-ASCII>,
<PARAGRAPH>, <SIGNATURE>, <NO-OP>, <LT>, <NL>, and <NP>.
6. テキスト/richtextからの以下のコマンドはテキスト/豊かにされるのからのREMOVEDです: <コメント>、<OUTDENT>、<OUTDENTRIGHT>、<SAMEPAGE>、<添字>、<の上付き文字の>、<見出し>、<立脚地>、<ISO-8859-[1-9]>、<米国-ASCII>、<パラグラフ>、<署名>、<ノーオプ>、<LT>、<NL>、および<Np @?br /> 7. SGMLの互換性のすべてのクレームが落とされました。 しかしながら、いいえが以下であったなら実行されて、テキスト/豊かにされて、テキスト/richtextよりCRLFと「<<」のための新しい意味論の可能な例外でSGMLに優しい状態でそうすることができます。
7. All claims of SGML compatibility have been dropped.
However, with the possible exceptions of the new semantics
for CRLF and "<<" can be implemented, text/enriched should
be no less SGML-friendly than text/richtext was.
Borenstein [Page 15] RFC 1563 A text/enriched type for MIME January 1994
8. In text/richtext, there were three commands (<NL>, <NP>,
and <LT>) that did not use balanced closing delimiters.
Since all of these have been eliminated, there are NO
exceptions to the nesting/balancing rules in text/enriched.
9. 形式象徴のサイズにおける限界は40〜60の増加するキャラクタです。
9. The limit on the size of formatting tokens has been
increased from 40 to 60 characters.
Borenstein [Page 16]
一覧
スポンサーリンク
