Network Working Group R. Gellens, Editor
Request for Comments: 2646 Qualcomm
Updates: 2046 August 1999
Category: Standards Track
Network Working Group R. Gellens, Editor
Request for Comments: 2646 Qualcomm
Updates: 2046 August 1999
Category: Standards Track
The Text/Plain Format Parameter
文本/纯格式参数
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Table of Contents
目录
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . 3
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
4. The Format Parameter to the Text/Plain Media Type . . . . . 4
4.1. Generating Format=Flowed . . . . . . . . . . . . . . . 5
4.2. Interpreting Format=Flowed . . . . . . . . . . . . . . . 6
4.3. Usenet Signature Convention . . . . . . . . . . . . . . 7
4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . . 7
4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Digital Signatures and Encryption . . . . . . . . . . . 9
4.7. Line Analysis Table . . . . . . . . . . . . . . . . . . 10
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Trailing White Space Corruption . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
9. Internationalization Considerations . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 13
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . 3
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
4. The Format Parameter to the Text/Plain Media Type . . . . . 4
4.1. Generating Format=Flowed . . . . . . . . . . . . . . . 5
4.2. Interpreting Format=Flowed . . . . . . . . . . . . . . . 6
4.3. Usenet Signature Convention . . . . . . . . . . . . . . 7
4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . . 7
4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Digital Signatures and Encryption . . . . . . . . . . . 9
4.7. Line Analysis Table . . . . . . . . . . . . . . . . . . 10
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Trailing White Space Corruption . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
9. Internationalization Considerations . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 13
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
Interoperability problems have been observed with erroneous labelling of paragraph text as Text/Plain, and with various forms of "embarrassing line wrap." (See section 3.)
在将段落文本错误地标记为文本/纯文本以及各种形式的“尴尬换行”时，发现了互操作性问题（见第3节）
Attempts to deploy new media types, such as Text/Enriched [RICH] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.
尝试部署新媒体类型，如Text/riched[RICH]和Text/HTML[HTML]时，由于缺乏向后兼容性以及接收端用户的敌意反应而受到影响。
What is required is a format which is in all significant ways Text/Plain, and therefore is quite suitable for display as Text/Plain, and yet allows the sender to express to the receiver which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate.
所需要的格式在所有重要方面都是文本/纯文本，因此非常适合显示为文本/纯文本，并且允许发送方向接收方表示哪些行可以被视为逻辑段落，从而适当地流动（包装和连接）。
This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain.
此备忘录提出了一个新参数，用于Text/Plain，并且在存在此参数时，使用尾随空格来指示流线。这导致在旧的实现中显示为普通文本/普通的编码，因为它实际上是普通文本/普通的。
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
本文件中的关键词“必需”、“必须”、“不得”、“应该”、“不应该”和“可能”应按照“RFC中用于指示需求水平的关键词”[关键词]中的描述进行解释。
The Text/Plain media type is the lowest common denominator of Internet email, with lines of no more than 997 characters (by convention usually no more than 80), and where the CRLF sequence represents a line break [MIME-IMT].
文本/普通媒体类型是互联网电子邮件的最低公分母，行数不超过997个字符（按惯例通常不超过80个），其中CRLF序列表示换行符[MIME-IMT]。
Text/Plain is usually displayed as preformatted text, often in a fixed font. That is, the characters start at the left margin of the display window, and advance to the right until a CRLF sequence is seen, at which point a new line is started, again at the left margin. When a line length exceeds the display window, some clients will wrap the line, while others invoke a horizontal scroll bar.
文本/纯文本通常显示为预格式化文本，通常采用固定字体。也就是说，字符从显示窗口的左边距开始，然后向右移动，直到看到一个CRLF序列，此时又在左边距开始一个新行。当一行长度超过显示窗口时，一些客户端将换行，而另一些客户端则调用水平滚动条。
Text which meets this description is defined by this memo as "fixed".
本备忘录将符合本说明的文本定义为“固定”。
Some interoperability problems have been observed with this media type:
观察到此媒体类型存在一些互操作性问题：
Many modern programs use a proportional-spaced font and CRLF to represent paragraph breaks. Line breaks are "soft", occurring as needed on display. That is, characters are grouped into a paragraph until a CRLF sequence is seen, at which point a new paragraph is started. Each paragraph is displayed, starting at the left margin (or paragraph indent), and continuing to the right until a word is encountered which does not fit in the remaining display width. This word is displayed at the left margin of the next line. This continues until the paragraph ends (a CRLF is seen). Extra vertical space is left between paragraphs.
许多现代程序使用等距字体和CRLF来表示段落中断。换行符是“软的”，根据需要在显示器上出现。也就是说，字符被分组到一个段落中，直到看到一个CRLF序列，此时一个新段落开始。将显示每个段落，从左边距（或段落缩进）开始，然后继续向右显示，直到遇到不适合剩余显示宽度的单词。该单词显示在下一行的左边距处。这将持续到本段结束（见CRLF）。段落之间留有额外的垂直空间。
Text which meets this description is defined by this memo as "flowed".
符合本说明的文本在本备忘录中定义为“流动”。
Numerous software products erroneously label this media type as Text/Plain, resulting in much user discomfort.
许多软件产品错误地将这种媒体类型标记为文本/纯文本，导致许多用户不适。
As Text/Plain messages get quoted in replies or forwarded messages, the length of each line gradually increases, resulting in "embarrassing line wrap." This results in text which is at best hard to read, and often confuses attributions.
当回复或转发的消息中引用文本/普通消息时，每行的长度逐渐增加，导致“尴尬的换行”。这导致文本最多难以阅读，并且常常混淆属性。
Example:
例子：
>>>>>>This is a comment from the first message to show a >quoting example. >>>>>This is a comment from the second message to show a >quoting example. >>>>This is a comment from the third message. >>>This is a comment from the fourth message.
>>>>>>这是第一条消息中的注释，显示>引用示例。>>>>这是第二条消息中的注释，用于显示>引用示例。>>>这是来自第三条消息的评论。>>这是来自第四条消息的评论。
It can be confusing to assign attribution to lines 2 and 4 above.
将属性指定给上面的第2行和第4行可能会令人困惑。
In addition, as devices with display widths smaller than 80 characters become more popular, embarrassing line wrap has become even more prevalent, even with unquoted text.
此外，随着显示宽度小于80个字符的设备变得越来越流行，尴尬的换行变得更加普遍，即使是不带引号的文本。
Example:
例子：
This is paragraph text that is meant to be flowed across several lines. However, the sending mailer is converting it to fixed text at a width of 72 characters, which causes it to look like this when shown on a PDA with only 30 character lines.
这是一个段落文本，要跨越几行。然而，发送邮件的人正在将其转换为72个字符宽的固定文本，这使得它在PDA上仅显示30个字符行时看起来像这样。
Attempts to deploy new media types, such as Text/Enriched [RICH] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.
尝试部署新媒体类型，如Text/riched[RICH]和Text/HTML[HTML]时，由于缺乏向后兼容性以及接收端用户的敌意反应而受到影响。
In particular, Text/Enriched requires that open angle brackets ("<") and hard line breaks be doubled, with resulting user unhappiness when viewed as Text/Plain. Text/HTML requires even more alteration of text, with a corresponding increase in user complaints.
特别是，Text/experiment要求将开放的尖括号（“<”）和硬线分隔符增加一倍，当用户将其视为Text/Plain时，用户会感到不快。Text/HTML需要对文本进行更多的修改，用户投诉也相应增加。
A proposal to define a new media type to explicitly represent the paragraph form suffered from a lack of interoperability with currently deployed software. Some programs treat unknown subtypes of Text as an attachment.
由于缺乏与当前部署的软件的互操作性，一项定义新媒体类型以明确表示段落形式的建议受到了影响。有些程序将未知的文本子类型视为附件。
What is desired is a format which is in all significant ways Text/Plain, and therefore is quite suitable for display as Text/Plain, and yet allows the sender to express to the receiver which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate.
所需要的格式在所有重要方面都是文本/纯文本，因此非常适合显示为文本/纯文本，并且允许发送方向接收方表示哪些行可以被视为逻辑段落，并因此适当地流动（包装和连接）。
This document defines a new MIME parameter for use with Text/Plain:
本文档定义了一个用于Text/Plain的新MIME参数：
Name: Format Value: Fixed, Flowed
名称：格式值：固定，流动
(Neither the parameter name nor its value are case sensitive.)
（参数名称及其值都不区分大小写。）
If not specified, a value of Fixed is assumed. The semantics of the Fixed value are the usual associated with Text/Plain [MIME-IMT].
如果未指定，则假定值为Fixed。固定值的语义通常与Text/Plain[MIME-IMT]关联。
A value of Flowed indicates that the definition of flowed text (as specified in this memo) was used on generation, and MAY be used on reception.
Flowed的值表示在生成时使用了Flowed文本的定义（如本备忘录中所述），并且可以在接收时使用。
This section discusses flowed text; section 5 provides a formal definition.
本节讨论流动文本；第5节提供了一个正式的定义。
Because flowed lines are all-but-indistinguishable from fixed lines, currently deployed software treats flowed lines as normal Text/Plain (which is what they are). Thus, no interoperability problems are expected.
由于流线与固定线几乎无法区分，因此当前部署的软件将流线视为普通文本/纯文本（这就是它们）。因此，不存在互操作性问题。
Note that this memo describes an on-the-wire format. It does not address formats for local file storage.
请注意，本备忘录描述了在线格式。它不处理本地文件存储的格式。
When generating Format=Flowed text, lines SHOULD be shorter than 80 characters. As suggested values, any paragraph longer than 79 characters in total length could be wrapped using lines of 72 or fewer characters. While the specific line length used is a matter of aesthetics and preference, longer lines are more likely to require rewrapping and to encounter difficulties with older mailers. It has been suggested that 66 character lines are the most readable.
生成格式=流动文本时，行应少于80个字符。根据建议值，总长度超过79个字符的任何段落都可以使用72个或更少字符的行进行包装。虽然所使用的特定行长度是一个美观和偏好的问题，但较长的行更可能需要重新包装，并且与较老的邮件发送人遇到困难。有人认为66个字符行是最可读的。
(The reason for the restriction to 79 or fewer characters between CRLFs on the wire is to ensure that all lines, even when displayed by a non-flowed-aware program, will fit in a standard 80-column screen without having to be wrapped. The limit is 79, not 80, because while 80 fit on a line, the last column is often reserved for a line-wrap indicator.)
（将线路上的CRLF之间的字符限制为79个或更少的原因是为了确保所有行，即使由非流动感知程序显示，也可以在标准的80列屏幕中显示，而不必进行换行。限制为79，而不是80，因为当80适合一行时，最后一列通常保留为换行指示符。）r、 )
When creating flowed text, the generating agent wraps, that is, inserts 'soft' line breaks as needed. Soft line breaks are added between words. Because a soft line break is a SP CRLF sequence, the generating agent creates one by inserting a CRLF after the occurance of a space.
在创建流动文本时，生成代理会进行换行，即根据需要插入“软”换行符。单词之间添加了软换行符。由于软换行符是SP CRLF序列，因此生成代理通过在出现空格后插入CRLF来创建一个序列。
A generating agent SHOULD NOT insert white space into a word (a sequence of printable characters not containing spaces). If faced with a word which exceeds 79 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 79-character limit on line length.
生成代理不应在单词中插入空格（不包含空格的可打印字符序列）。如果遇到超过79个字符（但小于998个字符，即[SMTP]行长限制）的单词，代理应按原样发送该单词，并超过79个字符的行长限制。
A generating agent SHOULD:
生成代理应：
1. Ensure all lines (fixed and flowed) are 79 characters or fewer in length, counting the trailing space but not counting the CRLF, unless a word by itself exceeds 79 characters. 2. Trim spaces before user-inserted hard line breaks. 3. Space-stuff lines which start with a space, "From ", or ">".
1. 确保所有行（固定和流动）长度不超过79个字符，计算尾随空格，但不计算CRLF，除非单词本身超过79个字符。2.在用户插入硬线打断之前修剪空间。3.以空格“From”或“>”开头的空格填充行。
In order to create messages which do not require space-stuffing, and are thus more aesthetically pleasing when viewed as Format=Fixed, a generating agent MAY avoid wrapping immediately before ">", "From ", or space.
为了创建不需要空间填充的消息，从而在被视为Format=Fixed时更美观，生成代理可以避免在“>”、“From”或space之前立即换行。
(See sections 4.4 and 4.5 for more information on space-stuffing and quoting, respectively.)
（有关空间填充和引用的更多信息，请分别参见第4.4节和第4.5节。）
A Format=Flowed message consists of zero or more paragraphs, each containing one or more flowed lines followed by one fixed line. The usual case is a series of flowed text lines with blank (empty) fixed lines between them.
格式=流程消息由零个或多个段落组成，每个段落包含一个或多个流程行，后跟一个固定行。通常情况下是一系列流动文本行，它们之间有空白（空）固定行。
Any number of fixed lines can appear between paragraphs.
段落之间可以出现任意数量的固定行。
[Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed unless absolutely necessary (for example, non-US-ASCII (8-bit) characters over a strictly 7-bit transport such as unextended SMTP). In particular, a message SHOULD NOT be encoded in Quoted-Printable for the sole purpose of protecting the trailing space on flowed lines unless the body part is cryptographically signed or encrypted (see Section 4.6).
[Quoted Printable]编码不应与Format=Flowed一起使用，除非绝对必要（例如，在严格的7位传输上使用非US ASCII（8位）字符，如未扩展的SMTP）。特别是，除非正文部分经过加密签名或加密（见第4.6节），否则不应仅出于保护流线上尾随空间的目的对消息进行带引号的可打印编码。
The intent of Format=Flowed is to allow user agents to generate flowed text which is non-obnoxious when viewed as pure, raw Text/Plain (without any decoding); use of Quoted-Printable hinders this and may cause Format=Flowed to be rejected by end users.
Format=Flowed的目的是允许用户代理生成流式文本，当被视为纯原始文本/纯文本（无任何解码）时，该文本不会令人讨厌；引用的可打印文件的使用阻碍了这一点，并可能导致最终用户拒绝Format=Flowed。
If the first character of a line is a quote mark (">"), the line is considered to be quoted (see section 4.5). Logically, all quote marks are counted and deleted, resulting in a line with a non-zero quote depth, and content. (The agent is of course free to display the content with quote marks or excerpt bars or anything else.) Logically, this test for quoted lines is done before any other tests (that is, before checking for space-stuffed and flowed).
如果一行的第一个字符是引号（“>”），则该行被视为被引用（见第4.5节）。从逻辑上讲，所有引号都会被计数和删除，从而生成一行非零引号深度和内容。（代理当然可以自由地显示带有引号或摘录栏或任何其他内容。）逻辑上，引用行的此测试在任何其他测试之前完成（即，在检查空间是否填满和流动之前）。
If the first character of a line is a space, the line has been space-stuffed (see section 4.4). Logically, this leading space is deleted before examining the line further (that is, before checking for flowed).
如果行的第一个字符是空格，则该行已填充空格（参见第4.4节）。从逻辑上讲，在进一步检查行之前（即，在检查流之前），删除该前导空格。
If the line ends in one or more spaces, the line is flowed. Otherwise it is fixed. Trailing spaces are part of the line's content, but the CRLF of a soft line break is not.
如果该行在一个或多个空间中结束，则该行将流动。否则它是固定的。尾随空格是行内容的一部分，但软换行符的CRLF不是。
A series of one or more flowed lines followed by one fixed line is considered a paragraph, and MAY be flowed (wrapped and unwrapped) as appropriate on display and in the construction of new messages (see section 4.5).
由一条或多条流线和一条固定线组成的一系列流线被视为一个段落，在显示和构建新消息时可酌情进行流线（包装和展开）（见第4.5节）。
A line consisting of one or more spaces (after deleting a stuffed space) is considered a flowed line.
由一个或多个空格组成的直线（删除填充空格后）被视为流线。
There is a convention in Usenet news of using "-- " as the separator line between the body and the signature of a message. When generating a Format=Flowed message containing a Usenet-style separator before the signature, the separator line is sent as-is. This is a special case; an (optionally quoted) line consisting of DASH DASH SP is not considered flowed.
在Usenet新闻中有一个惯例，即使用“-”作为消息正文和签名之间的分隔线。在签名之前生成包含Usenet样式分隔符的Format=Flowed消息时，分隔符行按原样发送。这是一个特例；由短划线SP组成的（可选引用）线不视为流动。
In order to allow for unquoted lines which start with ">", and to protect against systems which "From-munge" in-transit messages (modifying any line which starts with "From " to ">From "), Format=Flowed provides for space-stuffing.
为了允许以“>”开头的未加引号的行，并防止传输消息中出现“From munge”的系统（修改以“From”开头的任何行到“>From”），Format=Flowed提供了空间填充。
Space-stuffing adds a single space to the start of any line which needs protection when the message is generated. On reception, if the first character of a line is a space, it is logically deleted. This occurs after the test for a quoted line, and before the test for a flowed line.
空格填充在生成消息时需要保护的任何行的开头添加一个空格。接收时，如果行的第一个字符是空格，则逻辑上删除它。这发生在引用管线测试之后和流动管线测试之前。
On generation, any unquoted lines which start with ">", and any lines which start with a space or "From " SHOULD be space-stuffed. Other lines MAY be space-stuffed as desired.
在生成时，任何以“>”开头的不带引号的行以及任何以空格或“From”开头的行都应填充空格。其他行可以根据需要填充空间。
(Note that space-stuffing is similar to dot-stuffing as specified in [SMTP].)
（请注意，空格填充类似于[SMTP]中指定的点填充。）
If a space-stuffed message is received by an agent which handles Format=Flowed, the space-stuffing is reversed and thus the message appears unchanged. An agent which is not aware of Format=Flowed will of course not undo any space-stuffing, thus Format=Flowed messages may appear with a leading space on some lines (those which start with a space, ">" which is not a quote indicator, or "From "). Since lines which require space-stuffing rarely occur, and the aesthetic consequences of unreversed space-stuffing are minimal, this is not expected to be a significant problem.
如果处理Format=Flowed的代理接收到空间填充消息，则空间填充将被反转，因此消息显示为未更改。不知道Format=Flowed的代理当然不会撤消任何空格填充，因此Format=Flowed消息可能会在某些行上显示前导空格（那些以空格开头的消息，“>”不是引号指示符，或“From”）。由于需要填充空间的线条很少出现，且未翻转的填充空间的美学效果最小，因此预计这不会是一个重大问题。
In Format=Flowed, the canonical quote indicator (or quote mark) is one or more close angle bracket (">") characters. Lines which start with the quote indicator are considered quoted. The number of ">" characters at the start of the line specifies the quote depth. Flowed lines which are also quoted may require special handling on display and when copied to new messages.
在Format=Flowed中，规范引号指示器（或引号）是一个或多个闭角括号（“>”）字符。以quote指示符开头的行被视为quote。行首的“>”字符数指定引号深度。也被引用的流线在显示和复制到新消息时可能需要特殊处理。
When creating quoted flowed lines, each such line starts with the quote indicator.
创建带引号的流水行时，每一行都以引号指示符开始。
Note that because of space-stuffing, the lines >> Exit, Stage Left and >>Exit, Stage Left are semantically identical; both have a quote-depth of two, and a content of "Exit, Stage Left".
请注意，由于空格填充，行>>退出，Stage Left和>>退出，Stage Left在语义上是相同的；两者的引用深度均为2，内容为“退出，舞台左侧”。
However, the line > > Exit, Stage Left is different. It has a quote-depth of one, and a content of "> Exit, Stage Left".
但是，行>>退出，舞台左侧是不同的。报价深度为1，内容为“>退出，舞台左侧”。
When generating quoted flowed lines, an agent needs to pay attention to changes in quote depth. A sequence of quoted lines of the same quote depth SHOULD be encoded as a paragraph, with the last line generated as fixed and prior lines generated as flowed.
在生成报价流线时，代理需要注意报价深度的变化。相同引用深度的引用行序列应编码为段落，最后一行生成为固定行，前一行生成为流动行。
If a receiving agent wishes to reformat flowed quoted lines (joining and/or wrapping them) on display or when generating new messages, the lines SHOULD be de-quoted, reformatted, and then re-quoted. To de-quote, the number of close angle brackets in the quote indicator at the start of each line is counted. Consecutive lines with the same quoting depth are considered one paragraph and are reformatted together. To re-quote after reformatting, a quote indicator containing the same number of close angle brackets originally present is prefixed to each line.
如果接收代理希望在显示时或生成新消息时重新格式化流动的引用行（连接和/或包装它们），则应取消引用、重新格式化这些行，然后重新引用。要取消报价，将计算每行开头的报价指示器中的闭合尖括号数。具有相同引用深度的连续行被视为一个段落，并一起重新格式化。若要在重新格式化后重新引用，请在每行的前面加上一个引号指示符，该指示符包含原来存在的相同数量的右尖括号。
On reception, if a change in quoting depth occurs on a flowed line, this is an improperly formatted message. The receiver SHOULD handle this error by using the 'quote-depth-wins' rule, which is to ignore the flowed indicator and treat the line as fixed. That is, the change in quote depth ends the paragraph.
接收时，如果流线上的报价深度发生变化，则这是一条格式不正确的消息。接收方应使用“报价深度赢”规则处理此错误，即忽略流动指示器并将该行视为固定。也就是说，引用深度的变化结束了段落。
For example, consider the following sequence of lines (using '*' to indicate a soft line break, i.e., SP CRLF, and '#' to indicate a hard line break, i.e., CRLF):
例如，考虑下面的行序列（使用‘*’来指示软线断线，即sp CRLF，和‘γ’’来指示硬线断线，即CRLF）：
> Thou villainous ill-breeding spongy dizzy-eyed*
> reeky elf-skinned pigeon-egg!* <--- problem ---<
>> Thou artless swag-bellied milk-livered*
>> dismal-dreaming idle-headed scut!#
>>> Thou errant folly-fallen spleeny reeling-ripe*
>>> unmuzzled ratsbane!#
>>>> Henceforth, the coding style is to be strictly*
>>>> enforced, including the use of only upper case.#
>>>>> I've noticed a lack of adherence to the coding*
>>>>> styles, of late.#
>>>>>> Any complaints?#
> Thou villainous ill-breeding spongy dizzy-eyed*
> reeky elf-skinned pigeon-egg!* <--- problem ---<
>> Thou artless swag-bellied milk-livered*
>> dismal-dreaming idle-headed scut!#
>>> Thou errant folly-fallen spleeny reeling-ripe*
>>> unmuzzled ratsbane!#
>>>> Henceforth, the coding style is to be strictly*
>>>> enforced, including the use of only upper case.#
>>>>> I've noticed a lack of adherence to the coding*
>>>>> styles, of late.#
>>>>>> Any complaints?#
The second line ends in a soft line break, even though it is the last line of the one-deep quote block. The question then arises as to how this line should be interpreted, considering that the next line is the first line of the two-deep quote block.
第二行以软换行结束，即使它是一个深引号块的最后一行。考虑到下一行是两个深引号块的第一行，接下来的问题是如何解释这一行。
The example text above, when processed according to quote-depth wins, results in the first two lines being considered as one quoted, flowed section, with a quote depth of 1; the third and fourth lines become a quoted, flowed section, with a quote depth of 2.
当根据quote depth wins处理上述示例文本时，前两行将被视为一个引用的流动部分，quote depth为1；第三行和第四行成为引用的流动段，引用深度为2。
A generating agent SHOULD NOT create this situation; a receiving agent SHOULD handle it using quote-depth wins.
生成代理不应造成这种情况；接收代理应使用quote depth wins来处理它。
If a message is digitally signed or encrypted it is important that cryptographic processing use the on-the-wire Format=Flowed format. That is, during generation the message SHOULD be prepared for transmission, including addition of soft line breaks, space-stuffing, and [Quoted-Printable] encoding (to protect soft line breaks) before being digitally signed or encrypted; similarly, on receipt the message SHOULD have the signature verified or be decrypted before [Quoted-Printable] decoding and removal of stuffed spaces, soft line breaks and quote marks, and reflowing.
如果消息是数字签名或加密的，则加密处理必须使用在线格式=流格式。也就是说，在生成过程中，消息应准备好传输，包括在数字签名或加密之前添加软换行符、空格填充和[引用的可打印]编码（以保护软换行符）；类似地，在收到邮件时，应在[引用可打印]解码和删除填充空格、软换行符和引号以及回流之前验证或解密签名。
Lines contained in a Text/Plain body part with Format=Flowed can be analyzed by examining the start and end of the line. If the line starts with the quote indicator, it is quoted. If the line ends with one or more space characters, it is flowed. This is summarized by the following table:
可以通过检查行的开始和结束来分析Format=Flowed的文本/普通正文部分中包含的行。如果该行以quote指示符开头，则该行将被引用。如果行以一个或多个空格字符结尾，则该行将流动。下表对此进行了总结：
Starts Ends in
with One or Line
Quote More Spaces Type
------ ----------- ---------------
no no unquoted, fixed
yes no quoted, fixed
no yes unquoted, flowed
yes yes quoted, flowed
Starts Ends in
with One or Line
Quote More Spaces Type
------ ----------- ---------------
no no unquoted, fixed
yes no quoted, fixed
no yes unquoted, flowed
yes yes quoted, flowed
The following example contains three paragraphs:
以下示例包含三个段落：
`Take some more tea,' the March Hare said to Alice, very earnestly.
`“再喝点茶，”三月兔非常认真地对爱丽丝说。
`I've had nothing yet,' Alice replied in an offended tone, `so I can't take more.'
`“我还什么都没有，”爱丽丝生气地回答，“所以我再也受不了了。”
`You mean you can't take LESS,' said the Hatter: `it's very easy to take MORE than nothing.'
`“你的意思是你不能少拿，”帽匠说，“多拿总比什么都不拿容易。”
This could be encoded as follows (using '*' to indicate a soft line break, that is, SP CRLF sequence, and '#' to indicate a hard line break, that is, CRLF):
这可以按如下方式编码（使用“*”表示软线中断，即SP CRLF序列，使用“#”表示硬线中断，即CRLF序列）：
`Take some more tea,' the March Hare said to Alice, very*
earnestly.*
#
`I've had nothing yet,' Alice replied in an offended tone, `so*
I can't take more.'*
#
`You mean you can't take LESS,' said the Hatter: `it's very*
easy to take MORE than nothing.'#
`Take some more tea,' the March Hare said to Alice, very*
earnestly.*
#
`I've had nothing yet,' Alice replied in an offended tone, `so*
I can't take more.'*
#
`You mean you can't take LESS,' said the Hatter: `it's very*
easy to take MORE than nothing.'#
To show an example of quoting, here we have the same exchange, presented as a series of direct quotes:
为了展示报价的示例，这里我们使用了相同的交换，以一系列直接报价的形式呈现：
>>>Take some more tea.#
>>I've had nothing yet, so I can't take more.#
>You mean you can't take LESS, it's very easy to take*
>MORE than nothing.#
>>>Take some more tea.#
>>I've had nothing yet, so I can't take more.#
>You mean you can't take LESS, it's very easy to take*
>MORE than nothing.#
The constructs used in Text/Plain; Format=Flowed body parts are described using [ABNF], including the Core Rules:
文本/纯文本中使用的结构；格式=使用[ABNF]描述流动的身体部位，包括核心规则：
paragraph = 1*flowed-line fixed-line
fixed-line = fixed / sig-sep
fixed = [quote] [stuffing] *text-char non-sp CRLF
flowed-line = flow-qt / flow-unqt
flow-qt = quote [stuffing] *text-char 1*SP CRLF
flow-unqt = [stuffing] *text-char 1*SP CRLF
non-sp = %x01-09 / %x0B / %x0C / %x0E-1F / %x21-7F
; any 7-bit US-ASCII character, excluding
; NUL, CR, LF, and SP
quote = 1*">"
sig-sep = [quote] "--" SP CRLF
stuffing = [SP] ; space-stuffed, added on generation if
; needed, deleted on reception
text-char = non-sp / SP
paragraph = 1*flowed-line fixed-line
fixed-line = fixed / sig-sep
fixed = [quote] [stuffing] *text-char non-sp CRLF
flowed-line = flow-qt / flow-unqt
flow-qt = quote [stuffing] *text-char 1*SP CRLF
flow-unqt = [stuffing] *text-char 1*SP CRLF
non-sp = %x01-09 / %x0B / %x0C / %x0E-1F / %x21-7F
; any 7-bit US-ASCII character, excluding
; NUL, CR, LF, and SP
quote = 1*">"
sig-sep = [quote] "--" SP CRLF
stuffing = [SP] ; space-stuffed, added on generation if
; needed, deleted on reception
text-char = non-sp / SP
There are systems in existence which alter trailing whitespace on messages which pass through them. Such systems may strip, or in rarer cases, add trailing whitespace, in violation of RFC 821 [SMTP] section 4.5.2.
现有的一些系统可以改变通过它们的消息的尾随空格。此类系统可能会删除，或在罕见的情况下，添加尾随空格，违反RFC 821[SMTP]第4.5.2节。
Stripping trailing whitespace has the effect of converting flowed lines to fixed lines, which results in a message no worse than if Format=Flowed had not been used.
去除尾随空格的效果是将流水行转换为固定行，这会产生一条消息，不会比未使用Format=flowed更糟糕。
Adding trailing whitespace to a Format=Flowed message may result in a malformed display or reply.
将尾部空白添加到Format=Flow消息可能会导致格式错误的显示或回复。
Since most systems which add trailing white space do so to create a line which fills an internal record format, the result is almost always a line which contains an even number of characters (counting the added trailing white space).
由于大多数添加尾随空格的系统都是创建一行来填充内部记录格式，因此结果几乎总是一行包含偶数个字符（计入添加的尾随空格）。
One possible avoidance, therefore, would be to define Format=Flowed lines to use either one or two trailing space characters to indicate a flowed line, such that the total line length is odd. However, considering the scarcity of such systems today, it is not worth the added complexity.
因此，一种可能的避免方法是定义Format=流线，使用一个或两个尾随空格字符来指示流线，从而使总线条长度为奇数。然而，考虑到今天这种系统的稀缺性，它不值得增加复杂性。
This parameter introduces no security considerations beyond those which apply to Text/Plain.
除了适用于Text/Plain的安全注意事项外，此参数不引入其他安全注意事项。
Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.
第4.6节讨论了格式=流与数字签名或加密之间的交互。
IANA is requested to add a reference to this specification in the Text/Plain Media Type registration.
请IANA在文本/普通媒体类型注册中添加对本规范的引用。
The line wrap and quoting specifications of Format=Flowed may not be suitable for certain charsets, such as for Arabic and Hebrew characters that read from right to left. Care should be taken in applying format=flowed in these cases, as format=fixed combined with quoted-printable encoding may be more suitable.
Format=Flowed的换行和引用规范可能不适用于某些字符集，例如从右向左读取的阿拉伯语和希伯来语字符。在这些情况下，应用format=flowed时应小心，因为format=fixed与引用的可打印编码相结合可能更合适。
This proposal evolved from a discussion of Chris Newman's Text/Paragraph draft which took place on the IETF 822 mailing list. Special thanks to Ian Bell, Steve Dorner, Brian Kelley, Dan Kohn, Laurence Lundblade, and Dan Wing for their reviews, comments, suggestions, and discussions.
本提案源于在IETF 822邮件列表上讨论Chris Newman的文本/段落草案。特别感谢Ian Bell、Steve Dorner、Brian Kelley、Dan Kohn、Laurence Lundblade和Dan Wing的评论、评论、建议和讨论。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]S.Bradner，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RICH] Resnick, P. and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February 1996.
[RICH]Resnick，P.和A.Walker，“文本/丰富的MIME内容类型”，RFC18961996年2月。
[MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME-IMT]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[Quoted-Printable] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[引用可打印]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP]Postel，J.，“简单邮件传输协议”，STD 10，RFC 8211982年8月。
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -- 2.0", RFC 1866, November 1995.
[HTML]Berners Lee，T.和D.Connolly，“超文本标记语言——2.0”，RFC 18661995年11月。
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Dr. San Diego, CA 92121-2779 USA
Randall Gellens高通公司5775 Morehouse Dr.San Diego，CA 92121-2779美国
Phone: +1 619 651 5115
EMail: randy@qualcomm.com
Phone: +1 619 651 5115
EMail: randy@qualcomm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。