Network Working Group R. Gellens
Request for Comments: 3676 Qualcomm
Obsoletes: 2646 February 2004
Category: Standards Track
Network Working Group R. Gellens
Request for Comments: 3676 Qualcomm
Obsoletes: 2646 February 2004
Category: Standards Track
The Text/Plain Format and DelSp Parameters
Text/Plain格式和DelSp参数
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting.
本规范规定了两个用于文本/普通媒体类型的参数（Format和DelSP）。在存在这些参数的情况下，尾随空格用于指示流线，而规范引号指示符用于指示带引号的线。这导致在旧的实现中显示为普通文本/普通的编码，因为它实际上是普通文本/普通的，但提供了更好的包装/流动和引用。
This document supersedes the one specified in RFC 2646, "The Text/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely.
本文档取代RFC 2646“文本/纯格式参数”中指定的参数，并添加了DelSp参数，以适应不使用或很少出现ASCII空格的语言/编码字符集。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Paragraph Text. . . . . . . . . . . . . . . . . . . . . 3
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 3
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
4. The Format and DelSp Parameters . . . . . . . . . . . . . . . 5
4.1. Interpreting Format=Flowed. . . . . . . . . . . . . . . 6
4.2. Generating Format=Flowed . . . . . . . . . . . . . . . 7
4.3. Usenet Signature Convention . . . . . . . . . . . . . . 9
4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . 9
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Paragraph Text. . . . . . . . . . . . . . . . . . . . . 3
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 3
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
4. The Format and DelSp Parameters . . . . . . . . . . . . . . . 5
4.1. Interpreting Format=Flowed. . . . . . . . . . . . . . . 6
4.2. Generating Format=Flowed . . . . . . . . . . . . . . . 7
4.3. Usenet Signature Convention . . . . . . . . . . . . . . 9
4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . 9
4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Digital Signatures and Encryption . . . . . . . . . . . 11
4.7. Examples. . . . . . . . . . . . . . . . . . . . . . . . 12
5. Interoperability. . . . . . . . . . . . . . . . . . . . . . . 12
6. ABNF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Trailing White Space Corruption . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Internationalization Considerations . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Normative References. . . . . . . . . . . . . . . . . . . . . 16
13. Informative References. . . . . . . . . . . . . . . . . . . . 16
Appendix A: Changes from RFC 2646 . . . . . . . . . . . . . . . . 18
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 20
4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Digital Signatures and Encryption . . . . . . . . . . . 11
4.7. Examples. . . . . . . . . . . . . . . . . . . . . . . . 12
5. Interoperability. . . . . . . . . . . . . . . . . . . . . . . 12
6. ABNF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Trailing White Space Corruption . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Internationalization Considerations . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Normative References. . . . . . . . . . . . . . . . . . . . . 16
13. Informative References. . . . . . . . . . . . . . . . . . . . 16
Appendix A: Changes from RFC 2646 . . . . . . . . . . . . . . . . 18
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 20
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 are quoted and which lines are considered a logical paragraph, and thus eligible to be flowed (wrapped and joined) as appropriate.
所需要的格式在所有重要方面都是文本/普通格式，因此非常适合显示为文本/普通格式，并且允许发送方向接收方表示哪些行被引用，哪些行被视为逻辑段落，因此有资格根据需要流动（包装和连接）。
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 term "paragraph" is used here to mean a series of lines which are logically to be treated as a unit for display purposes and eligible to be flowed (wrapped and joined) as appropriate to fit in the display window and when creating text for replies, forwarding, etc.
这里使用的术语“段落”是指一系列行，这些行在逻辑上被视为一个用于显示目的的单元，并且在创建用于回复、转发等的文本时，可以适当地流动（包装和连接）以适合显示窗口。
The Text/Plain media type is the lowest common denominator of Internet email, with lines of no more than 998 characters (by convention usually no more than 78), and where the carriage-return and line-feed (CRLF) sequence represents a line break (see [MIME-IMT] and [MSG-FMT]).
文本/普通媒体类型是互联网电子邮件的最低公分母，行数不超过998个字符（按照惯例，通常不超过78个），其中回车和换行（CRLF）序列表示换行符（请参见[MIME-IMT]和[MSG-FMT]）。
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 format:
观察到使用此格式存在一些互操作性问题：
Many modern programs use a proportional-spaced font, and use 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 format as Text/Plain, resulting in much user discomfort.
许多软件产品错误地将此格式标记为文本/普通格式，导致用户不适。
As Text/Plain messages are quoted in replies or forwarded messages, each line gradually increases in length, eventually being arbitrarily hard wrapped, resulting in "embarrassing line wrap". This produces 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 79 or 80 characters become more popular, embarrassing line wrap has become even more prevalent, even with unquoted text.
此外，随着显示宽度小于79或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 specification defines two MIME parameters for use with Text/Plain:
本规范定义了两个用于Text/Plain的MIME参数：
Name: Format Value: Fixed, Flowed
名称：格式值：固定，流动
Name: DelSp Value: Yes, No
名称：DelSp值：是，否
(Neither the parameter names nor values are case sensitive.)
（参数名称和值都不区分大小写。）
If Format is not specified, or if the value is not recognized, 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 Format 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文本的定义（如本备忘录中所述），并且可以在接收时使用。
Note that because Format is a parameter of the Text/Plain content-type, any content-transfer-encoding used is irrelevant to the processing of flowed text.
请注意，因为格式是文本/普通内容类型的参数，所以使用的任何内容传输编码都与流式文本的处理无关。
If DelSp is not specified, or if its value is not recognized, a value of No is assumed. The use of DelSp without a Format value of Flowed is undefined. When creating messages, DelSp SHOULD NOT be specified in Text content types other than Text/Plain with Format = Flowed. When receiving messages, DelSp SHOULD be ignored if used in a Text content type other than Text/Plain with Format = Flowed.
如果未指定DelSp，或者未识别其值，则假定值为“否”。未定义没有格式值Flowed的DelSp的使用。创建消息时，不应在文本内容类型中指定DelSp，而应在格式为Flowed的文本/纯文本类型中指定。接收消息时，如果在文本内容类型中使用DelSp，而不是在Format=Flowed的Text/Plain中使用，则应忽略DelSp。
This section discusses flowed text; section 6 provides a formal definition.
本节讨论流动文本；第6节提供了一个正式的定义。
Section 5 discusses interoperability.
第5节讨论互操作性。
Note that this memo describes an on-the-wire format. It does not address formats for local file storage.
请注意，本备忘录描述了在线格式。它不处理本地文件存储的格式。
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 a space, the line is flowed. Otherwise it is fixed. The exception to this rule is a signature separator line, described in Section 4.3. Such lines end in a space but are neither flowed nor fixed.
如果该行在空间中结束，则该行将流动。否则它是固定的。此规则的例外情况是第4.3节中描述的签名分隔行。这些线在空间中结束，但既不流动也不固定。
If the line is flowed and DelSp is "yes", the trailing space immediately prior to the line's CRLF is logically deleted. If the DelSp parameter is "no" (or not specified, or set to an unrecognized value), the trailing space is not deleted.
如果该行流动且DelSp为“是”，则该行CRLF之前的尾随空格将被逻辑删除。如果DelSp参数为“否”（或未指定，或设置为无法识别的值），则不会删除尾随空格。
Any remaining 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节）。
An interpreting agent SHOULD allow for three exceptions to the rule that paragraphs end with a fixed line. These exceptions are improperly constructed messages: a flowed line SHOULD be considered to end the paragraph if it is followed by a line of a different quote depth (see 4.5) or by a signature separator (see 4.3); the end of the body also ends the paragraph.
对于段落以固定行结尾的规则，口译代理应允许三种例外情况。这些例外情况是构造不正确的消息：如果一条流线后面有一行不同的引用深度（见4.5）或一个签名分隔符（见4.3），则应将其视为段落的结尾；正文的结尾也是段落的结尾。
A line consisting of one or more spaces (after deleting a space acting as stuffing) is considered a flowed line.
由一个或多个空格组成的线（删除用作填充的空格后）被视为流线。
An empty line (just a CRLF) is a fixed line.
空行（仅为CRLF）是固定行。
Note that, for Unicode text, [Annex-14] provides guidance for choosing at which characters to wrap a line.
注意，对于Unicode文本，[附件14]提供了选择换行字符的指南。
When generating Format=Flowed text, lines SHOULD be 78 characters or shorter, including any trailing white space and also including any space added as part of stuffing (see Section 4.4). As suggested values, any paragraph longer than 78 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.)
生成格式=流动文本时，行应为78个字符或更短，包括任何尾随空格，也包括作为填充的一部分添加的任何空格（见第4.4节）。根据建议值，总长度超过78个字符的任何段落都可以使用72个或更少字符的行进行包装。虽然所使用的特定行长度是一个美观和偏好的问题，但较长的行更可能需要重新包装，并且与较老的邮件发送人遇到困难。（有人认为66个字符行是最可读的。）
The restriction to 78 or fewer characters between CRLFs on the wire is to conform to [MSG-FMT].
导线上CRLF之间的字符限制为78个或更少，以符合[MSG-FMT]。
(In addition to conformance to [MSG-FMT], there is a historical need that all lines, even when displayed by a non-flowed-aware program, will fit in a standard 79- or 80-column screen without having to be wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit on a line, the last column is often reserved for a line-wrap indicator.)
（除了符合[MSG-FMT]的要求外，历史上还需要所有行，即使由非流动感知程序显示，也能在标准79或80列屏幕中显示，而无需包装。限制为78，而不是79或80，因为79或80适合一行，最后一列通常保留为换行指示器。）
When creating flowed text, the generating agent wraps, that is, inserts 'soft' line breaks as needed. Soft line breaks are added at natural wrapping points, such as between words. A soft line break is a SP CRLF sequence.
在创建流动文本时，生成代理会进行换行，即根据需要插入“软”换行符。在自然换行点（如单词之间）添加软换行符。软换行是SP CRLF序列。
There are two techniques for inserting soft line breaks. The older technique, established by RFC 2646, creates a soft line break by inserting a CRLF after the occurrence of a space. With this technique, soft line breaks are only possible where spaces already occur. When this technique is used, the DelSp parameter SHOULD be used; if used it MUST be set to "no".
插入软换行符有两种方法。由RFC 2646建立的旧技术通过在空格出现后插入CRLF来创建软换行。使用此技术，只有在已出现空格的情况下才可能出现软换行。使用此技术时，应使用DelSp参数；如果使用，则必须将其设置为“否”。
The newer technique, suitable for use even with languages/coded character sets in which the ASCII space character is rare or not used, creates a soft line break by inserting a SP CRLF sequence. When this technique is used, the DelSp parameter MUST be used and MUST be set to "yes". Note that because of space-stuffing (see Section 4.4), when this technique is used and a soft line break is inserted at a point where a SP already exists (such as between words), if the SP CRLF sequence is added immediately before the SP, the pre-existing SP becomes leading and thus requires stuffing. It is RECOMMENDED that agents avoid this by inserting the SP CRLF sequence following the existing SP.
新技术甚至适用于ASCII空格字符很少或未使用的语言/编码字符集，通过插入SP CRLF序列创建软换行符。使用此技术时，必须使用DelSp参数，并且必须将其设置为“是”。请注意，由于空格填充（参见第4.4节），当使用此技术并在SP已存在的点（如字之间）插入软换行符时，如果SP CRLF序列在SP之前添加，则先前存在的SP变为前导，因此需要填充。建议代理通过在现有SP之后插入SP CRLF序列来避免这种情况。
Generating agents MAY use either method within each Text/Plain body part.
生成代理可以在每个文本/纯正文部分中使用任一方法。
Regardless of which technique is used, a generating agent SHOULD NOT insert a space in an unnatural location, such as into a word (a sequence of printable characters, not containing spaces, in a language/coded character set in which spaces are common). If faced with such a word which exceeds 78 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 78-character limit on line length.
无论使用哪种技术，生成代理都不应在不自然的位置插入空格，例如在单词中插入空格（在常用空格的语言/编码字符集中，不包含空格的可打印字符序列）。如果遇到超过78个字符（但小于998个字符，即[SMTP]行长限制）的单词，代理应按原样发送该单词，并超过78个字符的行长限制。
A generating agent SHOULD:
生成代理应：
o Ensure all lines (fixed and flowed) are 78 characters or fewer in length, counting any trailing space as well as a space added as stuffing, but not counting the CRLF, unless a word by itself exceeds 78 characters.
o 确保所有行（固定和流动）的长度不超过78个字符，包括任何尾随空格以及作为填充添加的空格，但不包括CRLF，除非单词本身超过78个字符。
o Trim spaces before user-inserted hard line breaks.
o 在用户插入硬线打断之前修剪空间。
A generating agent MUST:
生成代理必须：
o Space-stuff lines which start with a space, "From ", or ">".
o 以空格“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.
段落之间可以出现任意数量的固定行。
When placing soft line breaks in a paragraph, generating agents MUST NOT place them in a way that causes any line of the paragraph to be a signature separator line, because paragraphs cannot contain signature separator lines (see Sections 4.3 and 6).
当在段落中放置软换行符时，生成代理放置软换行符的方式不得使段落的任何一行成为签名分隔符行，因为段落不能包含签名分隔符行（见第4.3和6节）。
[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。
There is a long-standing convention in Usenet news which also commonly appears in Internet mail 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 or quoted and stuffed) line consisting of DASH DASH SP is neither fixed nor flowed.
Usenet新闻中有一个长期存在的惯例，它也经常出现在互联网邮件中，使用“-”作为邮件正文和签名之间的分隔线。在签名之前生成包含Usenet样式分隔符的Format=Flowed消息时，分隔符行按原样发送。这是一个特例；由破折号SP组成的（可选引用或引用并填充）行既不是固定的，也不是流动的。
Generating agents MUST NOT end a paragraph with such a signature line.
生成代理不得以这样的签名行结束段落。
A receiving agent needs to test for a signature line both before the test for a quoted line (see Section 4.5) and also after logically counting and deleting quote marks and stuffing (see Section 4.4) from a quoted line.
接收代理需要在对引用行进行测试之前（见第4.5节），以及在对引用行进行逻辑计数和删除引用标记和填充（见第4.4节）之后，对签名行进行测试。
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 (which logically counts and deletes any quote marks), 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 " MUST be space-stuffed. Other lines MAY be space-stuffed as desired.
在生成时，任何以“>”开头的不带引号的行以及任何以空格或“From”开头的行都必须填充空格。其他行可以根据需要填充空间。
(Note that space-stuffing is conceptually similar to dot-stuffing as specified in [SMTP].)
（请注意，空格填充在概念上类似于[SMTP]中指定的点填充。）
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 ">"
在Format=Flowed中，规范引号指示器（或引号）是一个或多个闭角括号（“>”）字符。以quote指示符开头的行被视为quote。“>”的数目
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.
行首的字符指定引号深度。也被引用的流线在显示和复制到新消息时可能需要特殊处理。
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. All lines of a paragraph MUST be unquoted, or else they MUST all be quoted and have the same quote depth. Therefore, whenever there is a change in quote depth, or a change from quoted to unquoted, or change from unquoted to quoted, the line immediately preceding the change MUST NOT be a flowed line.
在生成报价流线时，代理需要注意报价深度的变化。段落的所有行都必须是不带引号的，否则它们都必须被引用，并且具有相同的引用深度。因此，每当引号深度发生变化，或从引号变为无引号，或从无引号变为有引号时，紧跟在变化前的一行不得为流线。
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. To re-quote after reformatting, a quote indicator containing the same number of close angle brackets originally present are prefixed to each line.
如果接收代理希望在显示时或生成新消息时重新格式化流动的引用行（连接和/或包装它们），则应取消引用、重新格式化这些行，然后重新引用。要取消报价，将计算每行开头的报价指示器中的闭合尖括号数。若要在重新格式化后重新引用，请在每一行的前面加上一个引号指示符，该指示符包含原来存在的相同数量的右尖括号。
On reception, if a change in quote 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 consider the paragraph to end with the flowed line immediately preceding the change in quote depth.
接收时，如果流线上的报价深度发生变化，则这是一条格式不正确的消息。接收方应该通过使用“引用深度WINS”规则来处理这个错误，该规则考虑段落结束于引用深度变化之前的流线。
In other words, whenever two adjacent lines have different quote depths, senders MUST ensure that the earlier line is not flowed (does not end in a space), and receivers finding a flowed line there SHOULD treat it as the last line of a 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 is to 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 MUST NOT create this situation; a receiving agent SHOULD handle it by giving preference to the quote depth.
生成代理不能造成这种情况；接收代理应优先处理报价深度。
If a message is digitally signed or encrypted it is important that cryptographic processing use the same text for signature verification and/or decryption as was used for signature generation and/or encryption. Since the use of format=flowed allows text to be altered (by adding or removing line breaks and trailing spaces) between composition and transmission, and between reception and display, interoperability problems or security vulnerabilities may arise if originator and recipient do not both use the on-the-wire format for cryptographic processing.
如果对消息进行了数字签名或加密，则加密处理必须使用与生成签名和/或加密相同的文本进行签名验证和/或解密。由于format=flowed的使用允许在合成和传输之间以及在接收和显示之间更改文本（通过添加或删除换行符和尾随空格），如果发起者和接收者不同时使用在线格式进行加密处理，则可能会出现互操作性问题或安全漏洞。
The implications of the interaction between format=flowed and any specific cryptographic process depend on the details of the cryptographic processing and should be understood before using format=flowed in conjunction with signed and/or encrypted messages.
format=flowed与任何特定加密过程之间的交互影响取决于加密处理的细节，在将format=flowed与签名和/或加密消息结合使用之前，应了解其含义。
Note that [OpenPGP] specifies (in Section 7.1) that "any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated."
请注意，[OpenPGP]规定（在第7.1节中）“计算明文签名时，忽略任何行末尾的任何尾随空格（空格和制表符，0x09）。”
Thus it would be possible to add, in transit, a format=flowed header to a regular, format=fixed vanilla PGP (not [OpenPGP-MIME]) signed message and add arbitrary trailing space characters without this addition being detected. This would change the rendering of the article by a client which supported format=flowed.
因此，在传输过程中，可以将format=flowed头添加到常规、format=fixed vanilla PGP（非[OpenPGP MIME]）签名消息，并添加任意尾随空格字符，而不会检测到此添加。这将更改支持format=flowed的客户端对文章的呈现。
Therefore, the use of [OpenPGP] with format=flowed messages is strongly discouraged. [OpenPGP-MIME] is recommended instead.
因此，强烈反对使用[OpenPGP]格式=流消息。建议改为使用[OpenPGP MIME]。
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.#
Because flowed lines are all-but-indistinguishable from fixed lines, software which does not recognize Format=Flowed treats flowed lines as normal Text/Plain (which is what they are). Thus, Format=Flowed
由于流线与固定线几乎无法区分，因此不识别Format=flowed的软件将流线视为普通文本/普通文本（即它们是什么）。因此，格式=流动
interoperates with older clients, although flowed lines will have trailing white space inserted.
与旧客户端进行互操作，但流线将插入尾随空白。
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=流式消息可能在某些行上显示前导空格（那些以空格开头的消息，“>”不是引号指示符，或“From”）。由于需要填充空间的线条很少出现，且未翻转的填充空间的美学效果最小，因此预计这不会是一个重大问题。
If some lines begin with one or more spaces, the generating agent MAY space-stuff all lines, to maintain the relative indentation of the lines when viewed by clients which are not aware of Format=Flowed.
如果某些行以一个或多个空格开头，则生成代理可能会将所有行填充为空格，以在不知道Format=Flowed的客户端查看时保持行的相对缩进。
Messages generated with DelSp=yes and received by clients which are aware of Format=Flowed but are not aware of the DelSp parameter will have an extra space remaining after removal of soft line breaks. Thus, when generating text in languages/coded character sets in which spaces are common, the generating agent MAY always use the DelSp=no method.
使用DelSp=yes生成并由知道Format=Flowed但不知道DelSp参数的客户端接收的消息在删除软换行符后将有额外的剩余空间。因此，在以常用空格的语言/编码字符集生成文本时，生成代理可能始终使用DelSp=no方法。
Hand-aligned text, such as ASCII tables or art, source code, etc., SHOULD be sent as fixed, not flowed lines.
手动对齐的文本，如ASCII表格或art、源代码等，应作为固定行而不是流线发送。
The constructs used in Text/Plain; Format=Flowed body parts are described using Augmented Backus-Naur Form [ABNF], including the core rules defined in Appendix A.
文本/纯文本中使用的结构；格式=流动的车身零件使用扩展的巴科斯诺尔表格[ABNF]进行描述，包括附录A中定义的核心规则。
Note that the SP (space) and ">" characters are encoded according to the charset parameter.
请注意，SP（空格）和“>”字符是根据charset参数编码的。
flowed-body = *( paragraph / fixed-line / sig-sep )
paragraph = 1*flowed-line fixed-line
; all lines in paragraph MUST be unquoted or
; have same quote depth
flowed-line = ( flowed-line-qt / flowed-line-unqt ) flow CRLF
flowed-line-qt = quote ( ( stuffing stuffed-flowed ) /
unstuffed-flowed )
flowed-line-unqt = ( stuffing stuffed-flowed ) / unstuffed-flowed
stuffed-flowed = *text-char
unstuffed-flowed = non-sp-quote *text-char
fixed-line = fixed-line-qt / fixed-line-unqt
fixed-line-qt = quote ( ( stuffing stuffed-fixed ) /
flowed-body = *( paragraph / fixed-line / sig-sep )
paragraph = 1*flowed-line fixed-line
; all lines in paragraph MUST be unquoted or
; have same quote depth
flowed-line = ( flowed-line-qt / flowed-line-unqt ) flow CRLF
flowed-line-qt = quote ( ( stuffing stuffed-flowed ) /
unstuffed-flowed )
flowed-line-unqt = ( stuffing stuffed-flowed ) / unstuffed-flowed
stuffed-flowed = *text-char
unstuffed-flowed = non-sp-quote *text-char
fixed-line = fixed-line-qt / fixed-line-unqt
fixed-line-qt = quote ( ( stuffing stuffed-fixed ) /
unstuffed-fixed ) CRLF
fixed-line-unqt = ( stuffed-fixed / unstuffed-fixed ) CRLF
stuffed-fixed = *text-char non-sp
unstuffed-fixed = non-sp-quote [ *text-char non-sp ]
sig-sep = [ quote [stuffing] ] "--" SP CRLF
quote-mark = ">"
quote = 1*quote-mark
stuffing = SP ; space-stuffed, added on generation if
; needed, deleted on reception
flow = SP ; space before CRLF indicates flowed line,
; if DelSp=yes, space was added on generation
; and is deleted on reception
non-sp-quote = < any character except NUL, CR, LF, SP, quote-mark >
non-sp = non-sp-quote / quote-mark
text-char = non-sp / SP
unstuffed-fixed ) CRLF
fixed-line-unqt = ( stuffed-fixed / unstuffed-fixed ) CRLF
stuffed-fixed = *text-char non-sp
unstuffed-fixed = non-sp-quote [ *text-char non-sp ]
sig-sep = [ quote [stuffing] ] "--" SP CRLF
quote-mark = ">"
quote = 1*quote-mark
stuffing = SP ; space-stuffed, added on generation if
; needed, deleted on reception
flow = SP ; space before CRLF indicates flowed line,
; if DelSp=yes, space was added on generation
; and is deleted on reception
non-sp-quote = < any character except NUL, CR, LF, SP, quote-mark >
non-sp = non-sp-quote / quote-mark
text-char = non-sp / SP
That is, a Format=Flowed message body consists of any number of paragraphs and/or fixed lines and/or signature separator lines; paragraphs need at least one flowed line and are terminated by a fixed line; the fixed line terminating the paragraph is part of the paragraph. (There are some exceptions to this described in the text.)
即，格式=流式消息体由任意数量的段落和/或固定行和/或签名分隔行组成；段落需要至少一条流线，并以固定线终止；段落结尾的固定行是段落的一部分。（文本中描述了一些例外情况。）
Without at least one flowed line, there is a series of fixed lines, each independent. There is no paragraph.
如果没有至少一条流线，则有一系列固定管线，每个管线独立。没有段落。
With at least one flowed line, there is a paragraph, and the received lines can be reformed and flowed to fit the display window size. This can only be done if the lines are part of a logical grouping, the paragraph.
至少有一条流线，就有一个段落，并且可以对接收到的线条进行重组和流线化，以适应显示窗口的大小。只有当行是逻辑分组（段落）的一部分时，才能执行此操作。
Note that the definitions of flowed-line and sig-sep are potentially ambiguous: a signature separator line matches both, but is treated as a signature separator line and not a flowed line.
请注意，flowed line和sig sep的定义可能不明确：签名分隔符行与两者匹配，但被视为签名分隔符行，而不是flowed line。
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 2821 [SMTP] Section 4.5.2.
现有的一些系统可以改变通过它们的消息的尾随空格。此类系统可能会删除，或在罕见的情况下，添加尾随空格，违反RFC 2821[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=流线，使用一个或两个尾随空格字符来指示流线，从而使总线条长度为奇数。然而，考虑到今天这种系统的稀缺性，它不值得增加复杂性。
Any security considerations which apply to Text/Plain also apply to Text/Plain with Format=Flowed.
适用于Text/Plain的任何安全注意事项也适用于Format=Flowed的Text/Plain。
Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.
第4.6节讨论了格式=流与数字签名或加密之间的交互。
IANA has added 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 needs to 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与[quoted printable]编码相结合可能更合适。
The DelSp parameter was added specifically to permit Format=Flowed to be used with languages/coded character sets in which the ASCII space character is rarely used, or not used at all.
DelSp参数是专门添加的，以允许Format=Flowed与很少使用或根本不使用ASCII空格字符的语言/编码字符集一起使用。
The DelSp parameter was developed during a series of discussions among a number of people, including Harald Alvestrand, Grant Baillie, Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned Freed, Alexey Melnikov, John Myers, and Pete Resnick.
DelSp参数是在哈拉尔·阿尔韦斯特朗、格兰特·贝利、伊恩·贝尔、史蒂夫·多纳、帕特里克·法茨特罗姆、埃里克·费舍尔、内德·弗里德、阿列克谢·梅尔尼科夫、约翰·迈尔斯和皮特·雷斯尼克等一系列人的讨论中确定的。
Corrections and clarifications to RFC 2646 and early versions of this document were pointed out by several people, including Adam Costello, Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn, Ragho Mahalingam, Keith Moore, Greg Troxel, and Dan Wing.
一些人指出了对RFC 2646和本文件早期版本的更正和澄清，包括亚当·科斯特洛、尤塔·德杰纳、托尼·汉森、西蒙·约瑟夫森、丹·科恩、拉乔·马哈林根、基思·摩尔、格雷格·特罗塞尔和丹·温。
I'm told that NeXT's mail application used a very similar mechanism (without support for non-Western languages) in 1992.
我听说NeXT的邮件应用程序在1992年使用了非常类似的机制（不支持非西方语言）。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[Annex-14] Unicode Standard Annex #14, "Line Breaking
Properties"
<URL:http://www.unicode.org/unicode/reports/tr14/>
[Annex-14] Unicode Standard Annex #14, "Line Breaking
Properties"
<URL:http://www.unicode.org/unicode/reports/tr14/>
[MSG-FMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[MSG-FMT]Resnick，P.，Ed.“互联网信息格式”，RFC 2822，2001年4月。
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[OpenPGP]Callas，J.，Donnerhacke，L.，Finney，H.和R.Thayer，“OpenPGP消息格式”，RFC 24401998年11月。
[OpenPGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[OpenPGP MIME]Elkins，M.，“具有良好隐私的MIME安全性（PGP）”，RFC 2015，1996年10月。
Elkins, M., Del Torto, D., Levien, R. and J. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
Elkins，M.，Del Torto，D.，Levien，R.和J.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[Rich] Resnick, P. and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February 1996.
[Rich]Resnick，P.和A.Walker，“文本/丰富的MIME内容类型”，RFC18961996年2月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin，J.，Ed.，“简单邮件传输协议”，RFC 28212001年4月。
Appendix A: Changes from RFC 2646
附录A：RFC 2646的变更
Substantive:
实质性：
o Added DelSp parameter to handle languages and coded character sets in which space is less common or not used. o Updated text on generating and interpreting to accommodate the DelSp parameter. o Changed the limits of 79 or 80 to be 78 in conformance with RFC 2822. o Added text on generating to clarify that the 78-character limit includes trailing white space and stuffing. o Changed sig-sep in ABNF to allow stuffing. o Changed fixed-line to allow empty lines in ABNF. o Added explanatory text following ABNF. o Moved text from Abstract to new Introduction; rewrote Abstract. o Moved interoperability text to new section, and updated. o Clarified Security Considerations. o Text on digital signatures now discusses that OpenPGP ignores trailing white space. o Mention Unicode Annex 14. o Added mention of quoting to Abstract and Introduction. o Deleted line analysis table. o Added recommendations for OpenPGP and OpenPGP-MIME. o Rewrote ABNF rules to remove most ambiguity and note remaining case. o Added note that c-t-e is irrelevant to flowed text processing. o Added text indicating that end of data terminates a paragraph. o Moved sig-sep out of fixed-line ABNF. o Changed some SHOULDs to MUSTs (space-stuffing, quoted paragraphs). o Added note to ABNF that space and ">" are encoded according to charset. o Mentioned exceptions in section on interpreting. o Clarified and made consistent treatment of signature separator lines.
o 添加了DelSp参数以处理空间不太常见或未使用的语言和编码字符集。o更新生成和解释文本，以适应DelSp参数。o根据RFC 2822将79或80的限值更改为78。o在生成时添加文本，以澄清78个字符的限制包括尾随空格和填充。o更改ABNF中的sig sep，以允许填充。o更改固定线路，以允许ABNF中出现空行。o在ABNF之后添加解释性文本。o将文本从摘要移至新的引言；改写摘要。o将互操作性文本移至新部分，并进行更新。o澄清安全考虑。o数字签名上的文本现在讨论OpenPGP忽略尾部空白。o提及附件14。o在摘要和引言中增加了引用。o删除线分析表。o增加了对OpenPGP和OpenPGP MIME的建议。o重写ABNF规则，以消除大部分歧义，并注意剩余的情况。o补充说明c-t-e与流动文本处理无关。o添加了表示数据结尾终止段落的文本。o将sig sep移出固定线路ABNF。o将一些should改为must（空格填充、引用段落）。o在ABNF中添加了空格和“>”是根据字符集编码的注释。o在口译部分提到了例外情况。o澄清并一致处理签名分隔线。
Editorial:
社论：
o Added mention of NeXT's mail application to Acknowledgments. o Updated Acknowledgments. o Updated [SMTP] reference to 2821. o Added Notices. o Split References into Normative and Informative. o Improved text wording in some areas. o Standardize on "quote depth", not "quoting depth". o Moved section on interpreting before section on generating. o Reworded non-normative "should"s. o Noted meaning of "paragraph".
o 在致谢中增加了对NeXT邮件应用程序的提及。o更新确认。o将[SMTP]参考更新为2821。o增加通知。o将参考分为规范性参考和信息性参考。o在某些方面改进了文本措辞。o标准化“引用深度”，而不是“引用深度”。o将口译部分移到生成部分之前。o改写非规范性“应”。o注意到“款”的含义。
The DelSp parameter was added specifically to permit Format=Flowed to be used with languages/coded character sets in which the ASCII space character is rarely used, or not used at all. The DelSp mechanism was selected despite having been initially rejected as too much of a kludge, because among the many different techniques proposed, it allows for maximum interoperability among clients which support neither this specification nor RFC 2646, those which do support RFC 2646 but not this specification, and those that do support this specification; this set is multiplied by those that handle languages/coded character sets in which spaces are common, and in which they are uncommon or not used.
DelSp参数是专门添加的，以允许Format=Flowed与很少使用或根本不使用ASCII空格字符的语言/编码字符集一起使用。尽管DelSp机制最初被认为过于混乱而被拒绝，但还是选择了它，因为在提出的许多不同技术中，它允许在既不支持本规范也不支持RFC 2646的客户机之间实现最大程度的互操作性，也允许在不支持RFC 2646但不支持本规范的客户机之间实现最大程度的互操作性，以及那些支持本规范的；此集合乘以处理语言/编码字符集的集合，这些语言/编码字符集中的空格是公共的，并且不常用或不使用空格。
Author's Address
作者地址
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
美国加利福尼亚州圣地亚哥Morehouse大道5775号兰德尔盖伦高通公司，邮编92121
Phone: +1 858 651 5115
EMail: randy@qualcomm.com
Phone: +1 858 651 5115
EMail: randy@qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。