RFC1896 日本語訳
1896 The text/enriched MIME Content-type. P. Resnick, A. Walker. February 1996. (Format: TXT=45926, PS=81217 bytes) (Obsoletes RFC1523, RFC1563) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Resnick
Request for Comments: 1896 QUALCOMM
Obsoletes: 1523, 1563 A. Walker
Category: Informational InterCon
February 1996
コメントを求めるワーキンググループP.レズニックの要求をネットワークでつないでください: 1896 クアルコムは以下を時代遅れにします。 1523、1563A.ウォーカーカテゴリ: 情報のInterCon1996年2月
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-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 MIME type. 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. This document is only a minor revision to the text/enriched MIME type that was first described in [RFC-1523] and [RFC-1563], and is only intended to be used in the short term until other MIME types for text formatting in Internet mail are developed and deployed.
MIME[RFC-1521]はインターネット・メールにおける、さまざまなデータ型の表現のために書式と一般的なフレームワークを定義します。 このドキュメントは1つの特定のタイプに関するMIMEデータ、テキスト/豊かにされたMIMEの種類を定義します。 テキスト/豊かにされたMIMEの種類はさまざまなハードウェアとソフトウェアプラットホームの向こう側に簡単な豊かにされたテキストの、より広いinteroperationを容易にするつもりです。このドキュメントは最初に[RFC-1523]と[RFC-1563]で説明されて、短期で、インターネット・メールによるテキスト形式のための他のMIMEの種類が開発されて、配布されるまで使用されるつもりであるだけであるテキスト/豊かにされたMIMEの種類への小さい方の改正にすぎません。
The text/enriched MIME type
テキスト/豊かにされた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. 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 content type「テキスト」(「テキスト/豊かにされた」「副-タイプ」)の非常に簡単な「副-タイプ」を定義します。 このタイプのためのcontent type系列には、1つの任意のパラメタがあるかもしれません、"charset"パラメタ、同じ値が「テキスト/明瞭な」MIME content typeのために受入れられている状態で。
The text/enriched subtype was designed to meet the following criteria:
テキスト/豊かにされた「副-タイプ」は以下の評価基準を満たすように設計されました:
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. 構文は何らかのアプリケーションに不可欠であると考えられる新しい書式付けコマンドを考慮するのにおいて広げることができるに違いありません。
Resnick & Walker Informational [Page 1] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[1ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年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. 能力は、ユーザのプライマリワードプロセッサで「表-可能」であることがありそうであるというよりもいいえともう少し表すことができるのを保証するために非常に限らなければなりません。 これは送ることができるものを制限しますが、それは適切に送られるものを表示できる可能性を広げます。
There are other text formatting standards which meet some of these criteria. In particular, HTML and SGML have come into widespread use on the Internet. However, there are two important reasons that this document further promotes the use of text/enriched in Internet mail over other such standards:
これらの評価基準のいくつかを満たす他のテキスト形式規格があります。 特に、HTMLとSGMLはインターネットで普及使用に入りました。 しかしながら、このドキュメントがさらに他のそのような規格の上でインターネット・メールでテキスト/豊かにされることの使用を促進する2つの重要な理由があります:
1. Most MIME-aware Internet mail applications are already able to
either properly format text/enriched mail or, at the very least,
are able to strip out the formatting commands and display the
readable text. The same is not true for HTML or SGML.
1. ほとんどのMIME意識しているインターネット・メールアプリケーションが、既に適切にテキスト/豊かにされたメールをフォーマットできるか、書式付けコマンドを取り除いて、または読み込み可能なテキストを少なくとも表示できます。 HTMLかSGMLには、同じくらいは本当ではありません。
2. The current RFC on HTML [RFC-1866] and Internet Drafts on SGML
have many features which are not necessary for Internet mail, and
are missing a few capabilities that text/enriched already has.
2. HTML[RFC-1866]の現在のRFCとSGMLのインターネットDraftsには、多くのインターネット・メールに必要でない、そして、なくなった特徴があります。テキスト/が既に豊かにしたいくつかの能力はそうしました。
For these reasons, this document is promoting the use of text/enriched until other Internet standards come into more widespread use. For those who will want to use HTML, Appendix B of this document contains a very simple C program that converts text/enriched to HTML 2.0 described in [RFC-1866].
これらの理由で、他のインターネット標準が、より広範囲の使用に入るまで、このドキュメントはテキスト/豊かにされることの使用を促進しています。 HTMLを使用したくなる人に関しては、このドキュメントのAppendix Bは[RFC-1866]で説明されたHTML2.0にテキスト/豊かにされた状態で変換される非常に簡単なCプログラムを含んでいます。
Syntax
構文
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. A literal
less-than sign ("<") can be represented by a sequence of two such
characters, "<<".
「テキスト/豊かにされること」の構文は非常に簡単です。 それはただ一つの文字集合におけるテキストを表します--、米国-ASCII、異なった文字集合は指定できますが、デフォルトで、"charset"パラメタの使用で指定されてください。 (後で本書では非ASCII文字の組でテキスト/豊かにされることの意味論について議論します。) すべてのキャラクタが自分たちの代理をします、"<"キャラクタ(ASCII60)を除いて。(キャラクタは、書式付けコマンドの始まりを示すのに使用されます)。 そのような2つのキャラクタ、「<<」の系列は文字通りの不等号("<")を表すことができます。
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
書式設定命令は角ブラケット(「<>」、ASCII60と62)によって囲まれた書式付けコマンドから成ります。 各書式付けコマンドは長さが60未満のキャラクタであるかもしれません、英数字とハイフン(「-」)キャラクタに制限された米国-ASCIIで。 書式付けコマンド
Resnick & Walker Informational [Page 2] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[2ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
may be preceded by a solidus ("/", ASCII 47), making them negations,
and such negations must always exist to balance the initial opening
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.)
Formatting commands are always case-insensitive. That is, "bold" and
"BoLd" are equivalent in effect, if not in good taste.
それらを否定にして、ソリドゥス(「/」、ASCII47)が先行するかもしれなくて、そのようなものを否定にするのは、初期の初めのコマンドのバランスをとるためにいつも存在しなければなりません。 したがって、書式付けコマンド「<の大胆な>」が何らかのポイントに現れるなら、後で、それのバランスをとる「</大胆な>」があるに違いありません。 「(注意: 書式付けコマンドにおける60キャラクタ限界は、"<"、">"をNOTインクルードにするか、または」 そのようなコマンドに付けられるかもしれないキャラクタを」 /にします。) 書式付けコマンドはいつも大文字と小文字を区別しないです。 それはいて、「大胆さ」と「大胆さ」であることは、事実上、または上品で同等物です。
Line break rules
ラインブレイク規則
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.
特に、ラインブレイク(標準のネットワーク表現における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 section.
これは次のセクションです。
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 section.
これは次のセクションです。
The formatting commands, not all of which will be implemented by all implementations, are described in the following sections.
書式付けコマンド(それのすべてがすべての実装によって実装されるというわけではない)は以下のセクションで説明されます。
Resnick & Walker Informational [Page 3] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[3ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
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つのトークンの間のテキストの形式に影響して。 コマンドは、ここで説明されて、タイプに従って、分類されています。
Parameter Command
パラメタコマンド
Some of the formatting commands may require one or more associated parameters. The "param" command is a special formatting command used to include these parameters.
書式付けコマンドのいくつかが1つ以上の関連パラメタを必要とするかもしれません。 "param"コマンドはこれらのパラメタを含むのに使用される特別な書式付けコマンドです。
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 "param" command
always immediately follows some other formatting command,
and the parameter data indicates some additional
information about the formatting that is to be done. The
syntax of the parameter data (whatever appears between
the initial "<param>" and the terminating "</param>") is
defined for each command that uses it. However, it is
always required that 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
occurrence 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>」の間に現れるものなら何でも)の構文はそれを使用する各コマンドのために定義されます。 しかしながら、いつもそのようなデータの形式が入れ子にされた"param"コマンドを含んではいけなくて、"<"キャラクタを使用してはいけませんし、またテキスト/豊かにされた構文解析と互換性がある方法でそれを使用しなければならないのが必要です。 すなわち、パラメタデータの終わりは2つのアルゴリズムのどちらかで認識可能であるべきです: バランスのとれている「</param>」コマンドまで単に「</param>」の最初の発生を捜すか、または分析するのが見つけられます。 しかしながら、どちらの場合ではも、パラメタデータを人間の読者に示すべきではありません。
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.
イタリック体、イタリック体のフォントには影響を受けるテキストがあることを引き起こします。 入れ子にされたイタリック体のコマンドには、ただ一つのイタリック体のコマンドと同じ効果があります。
Resnick & Walker Informational [Page 4] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[4ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
Underline
causes the affected text to be underlined. Nested
underline commands have the same effect as a single
underline 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.
固定幅のフォントにはあるように影響を受けるテキストを原因に固定しました。 入れ子にされた固定コマンドには、ただ一つの固定コマンドと同じ効果があります。
FontFamily
causes the affected text to be displayed in a specified
typeface. The "fontfamily" command requires a parameter
that is specified by using the "param" command. The
parameter data is a case-insensitive string containing
the name of a font family. Any currently available font
family name (e.g. Times, Palatino, Courier, etc.) may be
used. This includes font families defined by commercial
type foundries such as Adobe, BitStream, or any other
such foundry. Note that implementations should only use
the general font family name, not the specific font name
(e.g. use "Times", not "TimesRoman" nor
"TimesBoldItalic"). When nested, the inner "fontfamily"
command takes precedence. Also note that the "fontfamily"
command is advisory only; it should not be expected that
other implementations will honor the typeface information
in this command since the font capabilities of systems
vary drastically.
FontFamilyは指定された活字面で影響を受けるテキストを表示させます。 "fontfamilyする"コマンドは"param"コマンドを使用することによって指定されるパラメタを必要とします。 パラメタデータはフォントファミリーの名前を含む大文字と小文字を区別しないストリングです。 どんな現在利用可能なフォント姓(例えば、タイムズ、パラティーノ、Courierなど)も使用されるかもしれません。 これはAdobe、BitStream、またはいかなる他のそのような鋳造場などの商業活字鋳造所によっても定義されたフォントファミリーを含んでいます。 実装が特定の洗礼名ではなく、一般的なフォント姓を使用するだけであるべきであることに注意してください(例えば、「回」、"TimesRoman"かどんな"TimesBoldItalic"も使用しないでください)。 入れ子にされると、内側の"fontfamilyする"コマンドは優先します。 また、"fontfamilyする"コマンドが状況報告専用であることに注意してください。 システムのフォント能力が抜本的に異なって、他の実装がこのコマンドにおける活字面情報を光栄に思わないと予想されるべきです。
Color
causes the affected text to be displayed in a specified
color. The "color" command requires a parameter that is
specified by using the "param" command. The parameter
data can be one of the following:
色で、指定された色で影響を受けるテキストを表示します。 「色」コマンドは"param"コマンドを使用することによって指定されるパラメタを必要とします。 パラメタデータは以下の1つであるかもしれません:
red
blue
green
yellow
cyan
magenta
black
white
赤い青い緑色の黄色いシアンマゼンタ黒い白
or an RGB color value in the form:
フォームでのRGB色の価値:
####,####,####
####,####,####
Resnick & Walker Informational [Page 5] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[5ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
where '#' is a hexadecimal digit '0' through '9', 'A'
through 'F', or 'a' through 'f'. The three 4-digit
hexadecimal values are the RGB values for red, green, and
blue respectively, where each component is expressed as
an unsigned value between 0 (0000) and 65535 (FFFF). The
default color for the message is unspecified, though
black is a common choice in many environments. When
nested, the inner "color" command takes precedence.
'#'が'f'を通した'9'、''から'F'、または'a'を通した16進数字'0'であるところ。 3つの4ケタの16進値が、それぞれ赤のためのRGB値と、緑色と、青です、各コンポーネントが0(0000)の間の未署名の値として言い表されるところで65535は(FFFF)です。 黒は多くの環境で一般的な選択ですが、メッセージのためのデフォルト色は不特定です。 入れ子にされると、内側の「色」コマンドは優先します。
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ポイント変えるのがお勧めですが、いくつかの環境で他の量は、より適切であるかもしれません。 入れ子にされたより大きいコマンドは、より大きいフォントを生産します、合理的にそれらを表示する実装の容量の限界に。(さらなるより大きいコマンドには、その時、どんな増加の効果もありませんでした後)。
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>".
事実上、「より大きく」て「より小さい」オペレータが逆である間、例えば、「<の、より小さい>」が「<の、より大きい>」の効果を終わらせるのに使用されることが勧められません。 「より</大きい>」で適切にこれをします。
Since the capabilities of implementations will vary, it is to be expected that some implementations will not be able to act on some of the font-alteration commands. However, an implementation should still display the text to the user in a reasonable fashion. In particular, the lack of capability to display a particular font family, color, or other text attribute does not mean that an implementation should fail to display text.
実装の能力が異なるので、いくつかの実装がフォント変更命令のいくつかに影響できないと予想されることになっています。 しかしながら、実装は合理的なファッションでまだユーザにテキストを表示しているべきです。 特に、特定のフォントファミリーを表示する能力の不足、色、または他のテキスト属性が、実装がテキストを表示するべきでないことを意味しません。
Fill/Justification/Indentation Commands
中詰め/正当化/刻み目のコマンド
Initially, text/enriched text is intended to be displayed fully filled (that is, using the rules specified for replacing CRLF pairs with spaces or removing them as appropriate) with appropriate kerning and letter-tracking, and using the maximum available margins as suits the capabilities of the receiving user agent software.
初めは、受信ユーザエージェントソフトウェアの能力に合うとき適切なカーニングと、手紙追跡と、最大の利用可能なマージンを使用することで完全にいっぱいにされた状態で(すなわち、CRLF組を空間に取り替えるか、または適宜それらを移すのに指定された規則を使用します)テキスト/豊かにされたテキストが表示されることを意図します。
Resnick & Walker Informational [Page 6] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[6ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
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は、すなわち、完全に正当化されるために滑らかな左右のマージンを作成するために影響を受けるテキストがいっぱいにされて、水増しされることを引き起こします。
ParaIndent
causes the running margins of the affected text to be
moved in. The recommended indentation change is the width
of four characters, but this may differ among
implementations. The "paraindent" command requires a
parameter that is specified by using the "param" command.
The parameter data is a comma-seperated list of one or
more of the following:
ParaIndentは影響を受けるテキストの実行している余白を入って来させます。 お勧めの刻み目の変化は4つのキャラクタの幅ですが、これは実装の中で異なるかもしれません。 "paraindent"コマンドは"param"コマンドを使用することによって指定されるパラメタを必要とします。 パラメタデータは以下の1つ以上のコンマでseperatedされたリストです:
Left
causes the running left margin to be moved to the
right.
左の右に動かされるべき実行しているマージンに原因を残しました。
Right
causes the running right margin to be moved to the
left.
権利で、実行しているライト・マージンを左に動かします。
In
causes the first line of the affected paragraph to
be indented in addition to the running margin. The
remaining lines remain flush to the running margin.
原因における、影響を受けるパラグラフの実行しているマージンに加えて入り込まれるべき最初の系列。 残っている系列は平らに実行しているマージンのままで残っています。
Out
causes all lines except for the first line of the
affected paragraph to be indented in addition to the
running margin. The first line remains flush to the
アウトで、実行しているマージンに加えて影響を受けるパラグラフの最初の系列以外のすべての系列を字下がりにします。 最初の系列は豊富なままで残っています。
Resnick & Walker Informational [Page 7] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[7ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
running margin.
マージンを実行します。
Nofill
causes the affected text to be displayed without filling.
That is, the text is displayed without using the rules
for replacing CRLF pairs with spaces or removing
consecutive sequences of CRLF pairs. However, the current
state of the margins and justification is honored; any
indentation or justification commands are still applied
to the text within the scope of the "nofill".
Nofillは充填なしで影響を受けるテキストを表示させます。 CRLF組を空間に取り替えるのに規則を使用するか、またはCRLF組の連続した系列を取り除かないで、すなわち、テキストを表示します。 しかしながら、マージンと正当化の現状は光栄に思っています。 どんな刻み目や正当化命令もまだ"nofill"の範囲の中のテキストに適用されています。
The "center", "flushleft", "flushright", and "flushboth" commands are mutually exclusive, and, when nested, the inner command takes precedence.
「センター」、"flushleft"、"flushright"、および"flushboth"コマンドは互いに排他的です、そして、入れ子にされると、内側のコマンドは優先します。
The "nofill" command is mutually exclusive with the "in" and "out" parameters of the "paraindent" command; when they occur in the same scope, their behavior is undefined.
"nofill"コマンドは"paraindent"コマンドの“in"と“out"パラメタについて互いに排他的です。 同じ範囲に起こるとき、彼らの振舞いは未定義です。
The parameter data for the "paraindent" command may contain multiple occurances of the same parameter (i.e. "left", "right", "in", or "out"). Each occurance causes the text to be further indented in the manner indicated by that parameter. Nested "paraindent" commands cause the affected text to be further indented according to the parameters. Note that the "in" and "out" parameters for "paraindent" are mutually exclusive; when they appear together or when nested "paraindent" commands contain both of them, their behavior is undefined.
"paraindent"コマンドのためのパラメタデータは同じパラメタ(すなわち、「左」の、そして、「正しい」“in"、または“out")の複数のoccurancesを含むかもしれません。 各occuranceはそのパラメタによって示された方法でテキストをさらに字下がりにさせます。 入れ子にされた"paraindent"コマンドで、パラメタによると、影響を受けるテキストをさらに字下がりにします。 "paraindent"のための“in"と“out"パラメタが互いに唯一であることに注意してください。 彼らが一緒に現れるか、または入れ子にされた"paraindent"コマンドがそれらの両方を含むとき、彼らの振舞いは未定義です。
For purposes of the "in" and "out" parameters, a paragraph is defined as text that is delimited by line breaks after applying the rules for replacing CRLF pairs with spaces or removing consecutive sequences of CRLF pairs. For example, within the scope of an "out", the line following each CRLF is made flush with the running margin, and subsequent lines are indented. Within the scope of an "in", the first line following each CRLF is indented, and subsequent lines remain flush to the running margin.
“in"と“out"パラメタの目的のために、パラグラフはCRLF組を空間に取り替えるための規則を適用するか、またはCRLF組の連続した系列を取り除いた後にラインブレイクによって区切られるテキストと定義されます。 例えば、“out"の範囲の中では、各CRLFに続く系列は平らに実行しているマージンで作られています、そして、その後の系列は字下がりにされます。 “in"の範囲の中では、各CRLFに続く最初の系列は字下がりにされます、そして、その後の系列は平らに実行しているマージンのままで残っています。
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 full justification is considered undesirable, the "flushboth" environment may be identical to the default environment. Note that full 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文字の組には、完全な正当化が基本的に不適当であるかもしれないことに注意してください。
Resnick & Walker Informational [Page 8] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[8ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
Note that [RFC-1563] defined two additional indentation commands, "Indent" and "IndentRight". These commands did not force a line break, and therefore their behavior was unpredictable since they depended on the margins and character sizes that a particular implementation used. Therefore, their use is deprecated and they should be ignored just as other unrecognized commands.
[RFC-1563]が2の追加刻み目を定義したというメモは、「インデントとIndentRight」と命令します。 これらのコマンドはラインブレイクを強制しませんでした、そして、したがって、彼らの振舞いは、特定の実装が使用したマージンとキャラクタサイズによったので、予測できませんでした。 したがって、彼らの使用は推奨しないです、そして、それらはちょうど他の認識されていないコマンドとして無視されるべきです。
Markup Commands
マーク付けコマンド
Commands in this section, unlike the other text/enriched commands are declarative markup commands. Text/enriched is not intended as a full markup language, but instead as a simple way to represent common formatting commands. Therefore, markup commands are purposely kept to a minimum. It is only because each was deemed so prevalent or necessary in an e-mail environment that these particular commands have been included at all.
このセクションのコマンドであり、もう片方と異なった、テキスト/豊かにされたコマンドは宣言的なマーク付けコマンドです。 一般的な形式を表す簡単な方法が命令するように/が豊かにしたテキストは完全なマークアップ言語として意図するのではなく、代わりに意図します。 したがって、マーク付けコマンドはわざわざ最小限に保たれます。 それは単にそれぞれが電子メール環境でこれらの特定のコマンドが全く含まれているほど一般的であるか、または必要であると考えられたからです。
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 as with the
justification commands, the excerpt command implicitly
begins and ends with a line break if one is not already
there. Nested "excerpt" commands are acceptable and
should be interpreted as meaning that the excerpted text
was excerpted from yet another source. Again, this can be
displayed using additional indentation, different colors,
etc.
原文の抜粋として抜粋で別のソースから影響を受けるテキストを解釈します、たぶんメッセージに応じて。 通常、刻み目と代替のフォントを使用することでこれを表示するだろうか、または">"で系列を字下がりにして、それらに先行することによって、そのような決定だけが実装まで達しています。 1つが既にそこにないなら、抜粋命令が正当化命令のようにそれとなく始まって、ラインブレイクで終わることに注意してください。 入れ子にされた「抜粋」コマンドは、許容できて、抜粋されたテキストがさらに別のソースから抜粋されたことを意味すると解釈されるべきです。 一方、追加刻み目、異なった色などを使用することでこれを表示できます。
Optionally, the "excerpt" command can take a parameter by
using the "param" command. The format of the data is
unspecified, but it is intended to uniquely identify the
text from which the excerpt is taken. With this
information, an implementation should be able to uniquely
identify the source of any particular excerpt, especially
if two or more excerpts in the message are from the same
source, and display it in some way that makes this
apparent to the user.
任意に、「抜粋」コマンドは、"param"コマンドを使用することによって、パラメタを取ることができます。 データの形式は不特定ですが、唯一、抜粋が取られるテキストを特定するのは意図しています。 この情報で、実装は唯一どんな特定の抜粋の源も特定できるべきです、特に、メッセージにおける2つ以上の抜粋がこれをユーザにとって明らかにする何らかの方法で同じソースから来ていて、それを表示するなら。
Lang
causes the affected text to be interpreted as belonging
to a particular language. This is most useful when two
different languages use the same character set, but may
require a different font or formatting depending on the
language. For instance, Chinese and Japanese share
ラングは特定の言語に属すと影響を受けるテキストを解釈させます。 これは、2つの異なった言語が同じ文字集合を使用するとき、最も役に立ちますが、言語に依存する異なったフォントか形式を必要とするかもしれません。 例えば、中国語と日本語は共有されます。
Resnick & Walker Informational [Page 9] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[9ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
similar character glyphs, and in some character sets like
UNICODE share common code points, but it is considered
very important that different fonts be used for the two
languages, especially if they appear together, so that
meaning is not lost. Also, language information can be
used to allow for fancier text handling, like spell
checking or hyphenation.
同様のキャラクタglyphsであり、したがって、特に一緒に現れるなら、ユニコードが一般的なコード・ポイントを共有しますが、異なったフォントが2つの言語に使用されるのが非常に重要であると考えられるようにいくつかの文字集合では、その意味は無くなっていません。 また、スペルの照合やハイフン付きのように、よりしゃれたテキスト取り扱いを考慮するのに言語情報を使用できます。
The "lang" command requires a parameter using the "param"
command. The parameter data can be any of the language
tags specified in [RFC-1766], "Tags for the
Identification of Languages". These tags are the two
letter language codes taken from [ISO-639] or can be
other language codes that are registered according to the
instructions in the Langauge Tags RFC. Consult that memo
for further information.
"lang"コマンドは、"param"コマンドを使用することでパラメタを必要とします。 パラメタデータは[RFC-1766]で指定された、言語タグのいずれ、「言語の識別のためのタグ」であることができます。 これらのタグは、[ISO-639]から取られた2つの手紙言語コードであるかLangauge Tags RFCでの指示に従って示される他の言語コードであるかもしれません。 詳細のためのそのメモを参照してください。
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.
書式付けコマンドのための巣篭もり要件は、テキスト/豊かにされたボディーの作曲家にわずかに高い負担を押しつけますが、それらがスタックベースであることを許容することによって、潜在的にテキスト/豊かにされた「不-プレーヤー」を簡素化します。 テキスト/豊かにされることの第一目的はマルチフォント、フォーマットされたメールを広く読み込み可能にするほど簡単であることになっています、したがって、それを送る能力があるそれらが信用を処理できるように。 構成ソフトウェアにおけるこのようにしてわずかに増強された複雑さは簡易型の読書ソフトウェアのための手頃な見返りであると考えられました。 それにもかかわらず、テキスト/豊かにされた読者の作成者があなたが送るもので保守的であって、あなたが受け入れるもので寛容であることの一般的なインターネットガイドラインに従うよう奨励されます。 そうできるそれらの実装が合理的に不適切に入れ子にされたテキスト/豊かにされたデータに対処するよう奨励されます。
Resnick & Walker Informational [Page 10] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[10ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
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文字の組
One of the great benefits of MIME is the ability to use different varieties of non-ASCII text in messages. To use non-ASCII text in a message, normally a charset parameter is specified in the Content- type line that indicates the character set being used. For purposes of this RFC, any legal MIME charset parameter can be used with the text/enriched Content-type. However, there are two difficulties that arise with regard to the text/enriched Content-type when non-ASCII text is desired. The first problem involves difficulties that occur when the user wishes to create text which would normally require multiple non-ASCII character sets in the same text/enriched message. The second problem is an ambiguity that arises because of the text/enriched use of the "<" character in formatting commands.
MIMEのすばらしい利益の1つはメッセージで異なったバラエティーの非ASCIIテキストを使用する能力です。 メッセージで非ASCIIテキストを使用するために、通常、charsetパラメタは使用される文字の組を示すContentタイプ線で指定されます。 このRFCの目的のために、テキスト/豊かにされた文書内容と共にどんな法的なMIME charsetパラメタも使用できます。 しかしながら、非ASCIIテキストが望まれているときテキスト/豊かにされた文書内容に関して起こる2つの困難があります。 第1の問題はユーザが通常、同じテキスト/豊かにされたメッセージの複数の非ASCII文字の組を必要とするテキストを作成したがっているとき起こる困難にかかわります。 2番目の問題は書式付けコマンドにおける"<"キャラクタのテキスト/豊かにされた使用で起こるあいまいさです。
Resnick & Walker Informational [Page 11] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[11ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
Using multiple non-ASCII character sets
複数の非ASCII文字の組を使用します。
Normally, if a user wishes to produce text which contains characters from entirely different character sets within the same MIME message (for example, using Russian Cyrillic characters from ISO 8859-5 and Hebrew characters from ISO 8859-8), a multipart message is used. Every time a new character set is desired, a new MIME body part is started with different character sets specified in the charset parameter of the Content-type line. However, using multiple character sets this way in text/enriched messages introduces problems. Since a change in the charset parameter requires a new part, text/enriched formatting commands used in the first part would not be able to apply to text that occurs in subsequent parts. It is not possible for text/enriched formatting commands to apply across MIME body part boundaries.
通常、ユーザが同じMIMEメッセージ(例えば、ISO8859-5とヘブライ人のキャラクタからISO8859-8からロシア人のキリル文字のキャラクタを使用する)の中で完全に異なった文字の組からキャラクタを含むテキストを製作したいなら、複合メッセージは使用されています。 望まれているときはいつも、新しいMIME身体の部分は文書内容線のcharsetパラメタで指定される異なった文字の組から始められます。 しかしながら、テキスト/豊かにされたメッセージでこのように複数の文字の組を使用すると、問題は紹介されます。charsetパラメタにおける変化が新しい部分を必要とするので、最初の部分で使用されるテキスト/豊かにされた書式付けコマンドはその後の部品に起こるテキストに適用できないでしょう。 テキスト/豊かにされた書式付けコマンドがMIMEボディー部分の限界の向こう側に適用されるのは、可能ではありません。
[RFC-1341] attempted to get around this problem in the now obsolete text/richtext format by introducing different character set formatting commands like "iso-8859-5" and "us-ascii". But this, or even a more general solution along the same lines, is still undesirable: It is common for a MIME application to decide, for example, what character font resources or character lookup tables it will require based on the information provided by the charset parameter of the Content-type line, before it even begins to interpret or display the data in that body part. By allowing the text/enriched interpreter to subsequently change the character set, perhaps to one completely different from the charset specified in the Content-type line (with potentially much different resource requirements), too much burden would be placed on the text/enriched interpreter itself.
そして、[RFC-1341]が、異なった文字の組形式が命令する導入するのによる現在時代遅れのテキスト/richtext形式でこの問題を逃れるのを試みた、「8859を何5インチもisoする、「私たち、-、ASCII、」、」 しかし、これ、または同じ線に沿ったより一般的な解決策さえまだ望ましくありません: 例えば、MIMEアプリケーションが、それが文書内容線のcharsetパラメタによって提供された情報に基づいてどんな文字フォントリソースかキャラクタルックアップ表を必要とするかを決めるのは、一般的です、その身体の部分にデータを解釈し始めるか、または表示し始めてさえいる前に。 テキスト/豊かにされたインタプリタが次に文字の組を恐らく文書内容線(潜在的に多くの異なったリソース要件がある)で指定されたcharsetと完全に異なった1つに変えるのを許容することによって、あまりに多くの負担がテキスト/豊かにされたインタプリタ自身にかけられるでしょう。
Therefore, if multiple types of non-ASCII characters are desired in a text/enriched document, one of the following two methods must be used:
したがって、複数のタイプの非ASCII文字がテキスト/豊かにされたドキュメントで望まれているなら、以下の2つの方法の1つを使用しなければなりません:
1. For cases where the different types of non-ASCII text can be
limited to their own paragraphs with distinct formatting, a
multipart message can be used with each part having a
Content-Type of text/enriched and a different charset parameter.
The one caveat to using this method is that each new part must
start in the initial state for a text/enriched document. That
means that all of the text/enriched commands in the preceding
part must be properly balanced with ending commands before the
next text/enriched part begins. Also, each text/enriched part
must begin a new paragraph.
1. 複合メッセージを異なった形式で異なったタイプの非ASCIIテキストをそれら自身のパラグラフに制限できて、テキストのコンテントタイプを持っている各部分と共に使用されるか、または豊かにすることができるケースと異なったcharsetパラメタのために。 この方法を使用することへの1つの警告はそれぞれの新しい部分がテキスト/豊かにされたドキュメントのために初期状態で始まらなければならないということです。 それは、次のテキスト/豊かにされた部分が始まる前に前の部分のテキスト/豊かにされたコマンドのすべてが適切に終わりのコマンドとバランスをとらなければならないことを意味します。 また、それぞれのテキスト/豊かにされた部分は行を改めなければなりません。
Resnick & Walker Informational [Page 12] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[12ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
2. If different types of non-ASCII text are to appear in the same
line or paragraph, or if text/enriched formatting (e.g. margins,
typeface, justification) is required across several different
types of non-ASCII text, a single text/enriched body part should
be used with a character set specified that contains all of the
required characters. For example, a charset parameter of
"UNICODE-1-1-UTF-7" as specified in [RFC-1642] could be used for
such purposes. Not only does UNICODE contain all of the
characters that can be represented in all of the other registered
ISO 8859 MIME character sets, but UTF-7 is fully compatible with
other aspects of the text/enriched standard, including the use of
the "<" character referred to below. Any other character sets
that are specified for use in MIME which contain different types
of non-ASCII text can also be used in these instances.
2. 非ASCIIテキストの異なったタイプが同じ線かパラグラフに現れるつもりであるか、またはテキスト/豊かにされた形式(例えば、マージン、活字面、正当化)がいくつかの異なったタイプの非ASCIIテキストの向こう側に必要であるなら、ただ一つのテキスト/豊かにされた身体の部分は必要なキャラクタのすべてを含む指定された文字の組と共に使用されるべきです。 例えば、charsetパラメタ、「ユニコード1-1UTF、7インチ、[RFC-1642]で指定されて、そのような目的に使用できた、」 UTF-7はテキスト/豊かにされた規格の他の局面と完全に互換性があります、以下に差し向けられた"<"キャラクタの使用を含んでいてユニコードは他の登録されたISO8859MIME文字の組のすべてで代理をされることができるキャラクタのすべてを含んでいるだけではなく。 MIMEにおける使用に指定されて、また、これらの例にどれが異なったタイプの非ASCIIテキストを含んでいるか使用できるということであるいかなる他の文字の組。
Use of the "<" character in formatting commands
書式付けコマンドにおける"<"キャラクタの使用
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は任意な点にいくつかのキャラクタのどれかに関してバイト列に現れるかもしれません)。
In practice, however, most multi-byte character sets address this problem internally. For example, the UNICODE character sets can use the UTF-7 encoding which preserves all of the important ASCII characters in their single byte form. The ISO-2022 family of character sets can use certain character sequences to 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.
しかしながら、実際には、ほとんどの多バイト文字セットが内部的にこのその問題を訴えます。 例えば、ユニコード文字の組は彼らのただ一つのバイトフォームに重要なASCII文字のすべてを保存するUTF-7コード化を使用できます。 文字の組の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を包括しない仮定している将来の文字の組のためにするべきことに関する質問はこのメモに記述されません。
Resnick & Walker Informational [Page 13] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[13ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
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テキスト/バージョンを発生させることによって、そのメールを作ることができます:
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バージョンを表示するでしょう。 さもなければ、テキスト/豊かにされたバージョンは示されるでしょう。
Resnick & Walker Informational [Page 14] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[14ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
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 intended to promote such extensions.
様々なメールシステム作者がテキスト/豊かにされるのに拡大を望むと予想されます。 テキスト/豊かにされることの簡単な構文、および認識されていない形式が単に無視されるべきであると命令する仕様がそのような拡大を促進することを意図します。
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
援助、それら
<color><param>red</param>beloved</color>
country.
<カラー>の<のparamの>の赤い</paramの>のいとしい</カラー>国。
By the way,
I think that <paraindent><param>left</param><<smaller>
ところで、私は、<paraindent><param>が>の<の<の、より小さい>に</paramを残したと思います。
</paraindent>should REALLY be called
</paraindent>は本当に呼ばれるべきです。
<paraindent><param>left</param><<tinier></paraindent>
<paraindent><param>は>の<の<の、より小さい></paraindent>に</paramを残しました。
Resnick & Walker Informational [Page 15] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[15ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
and that I am always right.
そして、私はいつも正しいです。
-- 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.
色に関する赤には「いとしい」という言葉があるところに、表示してください。
ti 0 Security Considerations
ti0Security Considerations
Security issues are not discussed in this memo, as the mechanism raises no security issues.
メカニズムが安全保障問題を全く提起しないのに従って、このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
For more information, the authors of this document may be contacted via Internet mail:
詳しくは、インターネット・メールでこのドキュメントの作者は連絡されるかもしれません:
Peter W. Resnick QUALCOMM Incorporated 6455 Lusk Boulevard San Diego, CA 92121-2779
ピーター・W.レズニック・クアルコムの法人組織の6455ラスク・Boulevardサンディエゴ、カリフォルニア92121-2779
Phone: +1 619 587 1121 Fax: +1 619 658 2230 EMail: presnick@qualcomm.com
以下に電話をしてください。 +1 619 587、1121Fax: +1 2230年の619 658メール: presnick@qualcomm.com
Amanda Walker InterCon Systems Corporation 950 Herndon Parkway Herndon, VA 22070
アマンダウォーカーInterCon Systems社950のハーンドンParkwayハーンドン、ヴァージニア 22070
Phone: +1 703 709 5500 Fax: +1 703 709 5555 EMail: amanda@intercon.com
以下に電話をしてください。 +1 703 709、5500Fax: +1 5555年の703 709メール: amanda@intercon.com
Resnick & Walker Informational [Page 16] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[16ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
Acknowledgements
承認
The authors gratefully acknowledge the input of many contributors, readers, and implementors of the specification in this document. Particular thanks are due to Nathaniel Borenstein, the original author of RFC 1563.
作者は感謝して本書では仕様の多くの貢献者、読者、および作成者の入力を承諾します。 特定の感謝はナザニエルBorenstein、RFC1563の原作者のためです。
References
参照
[RFC-1341]
Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
Extensions): Mechanisms for Specifying and Describing the Format
of Internet Message Bodies", 06/11/1992.
[RFC-1341]Borenstein(N.、および解放されたN.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 06/11/1992の「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム。」
[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", 09/23/1993.
解放された[RFC-1521]Borenstein、N.、およびN.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 09/23/1993の「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム。」
[RFC-1523]
Borenstein, N., "The text/enriched MIME Content-type",
09/23/1993.
[RFC-1523]Borenstein、N.、「テキスト/豊かにされたMIME文書内容」09/23/1993。
[RFC-1563]
Borenstein, N., "The text/enriched MIME Content-type",
01/10/1994.
[RFC-1563]Borenstein、N.、「テキスト/豊かにされたMIME文書内容」01/10/1994。
[RFC-1642]
Goldsmith, D., Davis, M., "UTF-7 - A Mail-Safe Transformation
Format of Unicode", 07/13/1994.
[RFC-1642]ゴールドスミス、D.、デイヴィス、M.、「UTF-7--、ユニコードのメール安全な変化形式、」、07/13/1994。
[RFC-1766]
Alvestrand, H., "Tags for the Identification of Languages",
03/02/1995.
[RFC-1766] Alvestrand、H.、「言語の識別のためのタグ」、03/02/1995。
[RFC-1866]
Berners-Lee, T., and D. Connolly, D., "Hypertext Markup Language
- 2.0", 11/03/1995.
[RFC-1866]のバーナーズ・リー、T.とD.コノリー、D.、「ハイパーテキストマークアップランゲージ--2インチと、11/03/1995」
Resnick & Walker Informational [Page 17] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[17ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
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 <ctype.h> #include <stdio.h> #include <stdlib.h> #include <string.h>
#<ctype.h>#インクルード<stdio.h>#インクルード<stdlib.h>#インクルード<string.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)
(c=getc(stdin!)=EOF)です; 等しい..ほか..象徴..象徴; 壊す..象徴..ほかに..象徴..ほか..象徴..ほかに..象徴; ほか(paramct>0)
Resnick & Walker Informational [Page 18] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[18ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
; /* ignore params */
else if (c == '\n' && nofill <= 0) {
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);
}
; '/*が(''c=\n nofill<=0)であるなら*/ほかのparamsを無視する、(+ + 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つは適切に刻み目、正当化、および他のものに関するテキスト/豊かにされた書式付けコマンドを扱うことができます。 しかしながら、上記のプログラムはダム端末の上にどんな形式人工物もユーザに見せていなくて豊かにされたテキスト/を提示するのに必要なすべてです。
Appendix B--A Simple enriched-to-HTML Translator in C
付録B--Cの純真なHTMLに豊かにされた翻訳者
It is fully expected that other text formatting standards like HTML and SGML will supplant text/enriched in Internet mail. It is also likely that as this happens, recipients of text/enriched mail will wish to view such mail with an HTML viewer. To this end, the following is a simple example of a C program to convert text/enriched to HTML. Since the current version of HTML at the time of this document's publication is HTML 2.0 defined in [RFC-1866], this program converts to that standard. There are several text/enriched commands that have no HTML 2.0 equivalent. In those cases, this program simply puts those commands into processing instructions; that is, surrounded by "<?" and ">". As in Appendix A, the local newline convention (the single character represented by "\n") is assumed by this program, but special CRLF handling might be necessary on some systems.
HTMLとSGMLのような他のテキスト形式規格がインターネット・メールで豊かにされたテキスト/に取って代わると完全に予想されます。 また、これが起こるとき、テキスト/豊かにされたメールの受取人はHTMLビューアーでそのようなメールを見たくなりそうでしょう。 このために、↓これはHTMLにテキスト/豊かにされた状態で変換するCプログラムの簡単な例です。 このドキュメントの公表時点のHTMLの最新版が[RFC-1866]で定義されたHTML2.0であるので、このプログラムはその規格に変えます。 いいえをHTML2.0同等にするいくつかのテキスト/豊かにされたコマンドがあります。 それらの場合では、このプログラムは単にそれらのコマンドを処理命令に入れます。 "<?"と">"によって囲まれて、それはそうです。 「Appendix Aのように、地方のニューラインコンベンション(」 \n」代理をされた単独のキャラクタ)はこのプログラムで想定されます、しかし、特別なCRLF取り扱いがいくつかのシステムの上で必要であるかもしれません。
#include <ctype.h> #include <stdio.h> #include <stdlib.h> #include <string.h>
#<ctype.h>#インクルード<stdio.h>#インクルード<stdlib.h>#インクルード<string.h>を含めてください。
main() {
int c, i, paramct=0, nofill=0;
メイン()、int c、i、paramct=0、nofill=0。
Resnick & Walker Informational [Page 19] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[19ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
char token[62], *p;
象徴[62]、*pを炭にしてください。
while((c=getc(stdin)) != EOF) {
if(c == '<') {
c = getc(stdin);
if(c == '<') {
fputs("<", 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--;
putc('>', stdout);
} else if(paramct > 0) {
fputs("<", stdout);
fputs(token, stdout);
fputs(">", stdout);
} else {
putc('<', stdout);
if(strcmp(token, "nofill") == 0) {
nofill++;
fputs("pre", stdout);
} else if(strcmp(token, "/nofill") == 0) {
nofill--;
fputs("/pre", stdout);
} else if(strcmp(token, "bold") == 0) {
fputs("b", stdout);
} else if(strcmp(token, "/bold") == 0) {
fputs("/b", stdout);
} else if(strcmp(token, "italic") == 0) {
fputs("i", stdout);
} else if(strcmp(token, "/italic") == 0) {
fputs("/i", stdout);
} else if(strcmp(token, "fixed") == 0) {
fputs("tt", stdout);
} else if(strcmp(token, "/fixed") == 0) {
fputs("/tt", stdout);
} else if(strcmp(token, "excerpt") == 0) {
fputs("blockquote", stdout);
} else if(strcmp(token, "/excerpt") == 0) {
fputs("/blockquote", stdout);
} else {
等しい..ほか..象徴..象徴..壊す; 「(strcmp、(象徴、」、/param、」、)、=0)、paramct--、; putc('>'、stdout);、ほか、(paramct>0)である、fputs(stdoutの"<");、fputs、(象徴、stdout) fputsします(">"はstdoutされます);、ほか、putc('<'、stdout); 「fputs("blockquote"、stdout);、ほか、(strcmp、(象徴、」、/抜粋、」、)、=0)、fputs(stdoutの「/blockquote」);、ほか
Resnick & Walker Informational [Page 20] RFC 1896 text/enriched MIME Content-type February 1996
レズニックとウォーカーInformational[20ページ]RFC1896テキスト/豊かにされたMIME文書内容1996年2月
putc('?', stdout);
fputs(token, stdout);
if(strcmp(token, "param") == 0) {
paramct++;
putc(' ', stdout);
continue;
}
}
putc('>', stdout);
}
}
} else if(c == '>') {
fputs(">", stdout);
} else if (c == '&') {
fputs("&", stdout);
} else {
if(c == '\n' && nofill <= 0 && paramct <= 0) {
while((i=getc(stdin)) == '\n') fputs("<br>", stdout);
ungetc(i, stdin);
}
putc(c, stdout);
}
}
/* The following line is only needed with line-buffering */
putc('\n', stdout);
exit(0);
}
putc('?'、stdout)。 fputs(象徴、stdout)。 (strcmp(象徴、"param")=0)である、paramct++; putcする、('、'、stdout) ; 続いてください;、putc('>'、stdout);、' } } ほか、(c='>')である、fputs(">"、stdout)。 ほか、(c='&')である、fputs("&"、stdout)。 '、ほか、(''c=\n nofill<=0、paramct<=0)、((i=getc(stdin))='\n')fputs(「<Br>」、stdout)である間。 ungetc(i、stdin)。 putc(c、stdout)。 } } 以下が裏打ちする/*が線をバッファリングする*/putc('\n'、stdout)で必要であるだけです。 出口(0)。 }
Resnick & Walker Informational [Page 21]
レズニックとウォーカーInformationalです。[21ページ]
一覧
スポンサーリンク
