Network Working Group P. Hethmon
Request for Comments: 3659 Hethmon Software
Updates: 959 March 2007
Category: Standards Track
Network Working Group P. Hethmon
Request for Comments: 3659 Hethmon Software
Updates: 959 March 2007
Category: Standards Track
Extensions to FTP
FTP的扩展
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure.
本文档指定了新的FTP命令，用于以定义的格式获取远程目录列表，并允许以流模式重新启动中断的数据传输。它允许使用US-ASCII以外的字符集，还定义了可选的虚拟文件存储结构。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pathnames. . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Times. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Server Replies . . . . . . . . . . . . . . . . . . . . . 7
2.5. Interpreting Examples. . . . . . . . . . . . . . . . . . 8
3. File Modification Time (MDTM). . . . . . . . . . . . . . . . . 8
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Error Responses. . . . . . . . . . . . . . . . . . . . . 9
3.3. FEAT Response for MDTM . . . . . . . . . . . . . . . . . 10
3.4. MDTM Examples. . . . . . . . . . . . . . . . . . . . . . 10
4. File SIZE. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Error Responses. . . . . . . . . . . . . . . . . . . . . 12
4.3. FEAT Response for SIZE . . . . . . . . . . . . . . . . . 12
4.4. Size Examples. . . . . . . . . . . . . . . . . . . . . . 12
5. Restart of Interrupted Transfer (REST) . . . . . . . . . . . . 13
5.1. Restarting in STREAM Mode. . . . . . . . . . . . . . . . 14
5.2. Error Recovery and Restart . . . . . . . . . . . . . . . 14
5.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. FEAT Response for REST . . . . . . . . . . . . . . . . . 16
5.5. REST Example . . . . . . . . . . . . . . . . . . . . . . 17
6. A Trivial Virtual File Store (TVFS). . . . . . . . . . . . . . 17
6.1. TVFS File Names. . . . . . . . . . . . . . . . . . . . . 18
6.2. TVFS Pathnames . . . . . . . . . . . . . . . . . . . . . 18
6.3. FEAT Response for TVFS . . . . . . . . . . . . . . . . . 20
6.4. OPTS for TVFS. . . . . . . . . . . . . . . . . . . . . . 21
6.5. TVFS Examples. . . . . . . . . . . . . . . . . . . . . . 21
7. Listings for Machine Processing (MLST and MLSD). . . . . . . . 23
7.1. Format of MLSx Requests. . . . . . . . . . . . . . . . . 23
7.2. Format of MLSx Response. . . . . . . . . . . . . . . . . 24
7.3. File Name Encoding . . . . . . . . . . . . . . . . . . . 26
7.4. Format of Facts. . . . . . . . . . . . . . . . . . . . . 28
7.5. Standard Facts . . . . . . . . . . . . . . . . . . . . . 28
7.6. System Dependent and Local Facts . . . . . . . . . . . . 36
7.7. MLSx Examples. . . . . . . . . . . . . . . . . . . . . . 37
7.8. FEAT Response for MLSx . . . . . . . . . . . . . . . . . 49
7.9. OPTS Parameters for MLST . . . . . . . . . . . . . . . . 51
8. Impact on Other FTP Commands . . . . . . . . . . . . . . . . . 54
9. Character Sets and Internationalization. . . . . . . . . . . . 55
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 55
10.1. The OS Specific Fact Registry. . . . . . . . . . . . . . 56
10.2. The OS Specific Filetype Registry. . . . . . . . . . . . 56
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pathnames. . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Times. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Server Replies . . . . . . . . . . . . . . . . . . . . . 7
2.5. Interpreting Examples. . . . . . . . . . . . . . . . . . 8
3. File Modification Time (MDTM). . . . . . . . . . . . . . . . . 8
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Error Responses. . . . . . . . . . . . . . . . . . . . . 9
3.3. FEAT Response for MDTM . . . . . . . . . . . . . . . . . 10
3.4. MDTM Examples. . . . . . . . . . . . . . . . . . . . . . 10
4. File SIZE. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Error Responses. . . . . . . . . . . . . . . . . . . . . 12
4.3. FEAT Response for SIZE . . . . . . . . . . . . . . . . . 12
4.4. Size Examples. . . . . . . . . . . . . . . . . . . . . . 12
5. Restart of Interrupted Transfer (REST) . . . . . . . . . . . . 13
5.1. Restarting in STREAM Mode. . . . . . . . . . . . . . . . 14
5.2. Error Recovery and Restart . . . . . . . . . . . . . . . 14
5.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. FEAT Response for REST . . . . . . . . . . . . . . . . . 16
5.5. REST Example . . . . . . . . . . . . . . . . . . . . . . 17
6. A Trivial Virtual File Store (TVFS). . . . . . . . . . . . . . 17
6.1. TVFS File Names. . . . . . . . . . . . . . . . . . . . . 18
6.2. TVFS Pathnames . . . . . . . . . . . . . . . . . . . . . 18
6.3. FEAT Response for TVFS . . . . . . . . . . . . . . . . . 20
6.4. OPTS for TVFS. . . . . . . . . . . . . . . . . . . . . . 21
6.5. TVFS Examples. . . . . . . . . . . . . . . . . . . . . . 21
7. Listings for Machine Processing (MLST and MLSD). . . . . . . . 23
7.1. Format of MLSx Requests. . . . . . . . . . . . . . . . . 23
7.2. Format of MLSx Response. . . . . . . . . . . . . . . . . 24
7.3. File Name Encoding . . . . . . . . . . . . . . . . . . . 26
7.4. Format of Facts. . . . . . . . . . . . . . . . . . . . . 28
7.5. Standard Facts . . . . . . . . . . . . . . . . . . . . . 28
7.6. System Dependent and Local Facts . . . . . . . . . . . . 36
7.7. MLSx Examples. . . . . . . . . . . . . . . . . . . . . . 37
7.8. FEAT Response for MLSx . . . . . . . . . . . . . . . . . 49
7.9. OPTS Parameters for MLST . . . . . . . . . . . . . . . . 51
8. Impact on Other FTP Commands . . . . . . . . . . . . . . . . . 54
9. Character Sets and Internationalization. . . . . . . . . . . . 55
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 55
10.1. The OS Specific Fact Registry. . . . . . . . . . . . . . 56
10.2. The OS Specific Filetype Registry. . . . . . . . . . . . 56
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 57
12. Normative References . . . . . . . . . . . . . . . . . . . . . 58
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 59
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 57
12. Normative References . . . . . . . . . . . . . . . . . . . . . 58
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 59
This document updates the File Transfer Protocol (FTP) [3]. Four new commands are added: "SIZE", "MDTM", "MLST", and "MLSD". The existing command "REST" is modified. Of those, the "SIZE" and "MDTM" commands, and the modifications to "REST" have been in wide use for many years. The others are new.
本文档更新了文件传输协议（FTP）[3]。添加了四个新命令：“SIZE”、“MDTM”、“MLST”和“MLSD”。现有命令“REST”已修改。其中，“SIZE”和“MDTM”命令以及对“REST”的修改已广泛使用多年。其他的都是新的。
These commands allow a client to restart an interrupted transfer in transfer modes not previously supported in any documented way, and to obtain a directory listing in a machine friendly, predictable, format.
这些命令允许客户端以以前不支持的任何文档化方式以传输模式重新启动中断传输，并以机器友好、可预测的格式获取目录列表。
An optional structure for the server's file store (NVFS) is also defined, allowing servers that support such a structure to convey that information to clients in a standard way, thus allowing clients more certainty in constructing and interpreting pathnames.
还定义了服务器文件存储（NVFS）的可选结构，允许支持这种结构的服务器以标准方式将该信息传递给客户端，从而使客户端在构建和解释路径名时更加确定。
This document makes use of the document conventions defined in BCP 14, RFC 2119 [4]. That provides the interpretation of capitalized imperative words like MUST, SHOULD, etc.
本文件使用了BCP 14、RFC 2119[4]中定义的文件约定。它提供了诸如必须、应该等大写祈使词的解释。
This document also uses notation defined in STD 9, RFC 959 [3]. In particular, the terms "reply", "user", "NVFS" (Network Virtual File System), "file", "pathname", "FTP commands", "DTP" (data transfer process), "user-FTP process", "user-PI" (user protocol interpreter), "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "type", "NVT" (Network Virtual Terminal), "control connection", "data connection", and "ASCII", are all used here as defined there.
本文件还使用了STD 9、RFC 959[3]中定义的符号。尤其是术语“回复”、“用户”、“NVFS”（网络虚拟文件系统）、“文件”、“路径名”、“FTP命令”、“DTP”（数据传输过程）、“用户FTP过程”、“用户PI”（用户协议解释器）、“用户DTP”、“服务器FTP过程”、“服务器PI”、“服务器DTP”、“模式”、“类型”、“NVT”（网络虚拟终端）、“控制连接”，“数据连接”和“ASCII”在这里都是按照这里的定义使用的。
Syntax required is defined using the Augmented BNF defined in [5]. Some general ABNF definitions that are required throughout the document will be defined later in this section. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section.
所需语法是使用[5]中定义的扩充BNF定义的。本节后面将定义本文件中要求的一些通用ABNF定义。在第一次阅读时，明智的做法是简单地回忆一下这里存在这些定义，然后跳到下一节。
This document imports the core ABNF definitions given in Appendix A of [5]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, SP, etc. The following terms are added for use in this document.
本文件引入了[5]附录A中给出的核心ABNF定义。可以找到基本ABNF元素的定义，如ALPHA、DIGIT、SP等。本文档中添加了以下术语。
TCHAR = VCHAR / SP / HTAB ; visible plus white space
RCHAR = ALPHA / DIGIT / "," / "." / ":" / "!" /
"@" / "#" / "$" / "%" / "^" /
"&" / "(" / ")" / "-" / "_" /
"+" / "?" / "/" / "\" / "'" /
DQUOTE ; <"> -- double quote character (%x22)
SCHAR = RCHAR / "=" ;
TCHAR = VCHAR / SP / HTAB ; visible plus white space
RCHAR = ALPHA / DIGIT / "," / "." / ":" / "!" /
"@" / "#" / "$" / "%" / "^" /
"&" / "(" / ")" / "-" / "_" /
"+" / "?" / "/" / "\" / "'" /
DQUOTE ; <"> -- double quote character (%x22)
SCHAR = RCHAR / "=" ;
The VCHAR (from [5]), RCHAR, SCHAR, and TCHAR types give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses.
VCHAR（来自[5]）、RCHAR、SCHAR和TCHAR类型提供了ASCII字符集不同子集的基本字符类型，用于各种命令和响应。
token = 1*RCHAR
token = 1*RCHAR
A "token" is a string whose precise meaning depends upon the context in which it is used. In some cases it will be a value from a set of possible values maintained elsewhere. In others it might be a string invented by one party to an FTP conversation from whatever sources it finds relevant.
“标记”是一个字符串，其确切含义取决于使用它的上下文。在某些情况下，它将是其他地方维护的一组可能值中的一个值。在其他情况下，它可能是FTP会话的一方从其认为相关的任何来源发明的字符串。
Note that in ABNF, string literals are case insensitive. That convention is preserved in this document, and implies that FTP commands added by this specification have names that can be represented in any case. That is, "MDTM" is the same as "mdtm", "Mdtm" and "MdTm" etc. However note that ALPHA, in particular, is case sensitive. That implies that a "token" is a case sensitive value. That implication is correct, except where explicitly stated to the contrary in this document, or in some other specification that defines the values this document specifies be used in a particular context.
请注意，在ABNF中，字符串文字不区分大小写。该约定保留在本文档中，这意味着由本规范添加的FTP命令具有在任何情况下都可以表示的名称。也就是说，“MDTM”与“MDTM”、“MDTM”和“MDTM”等相同。但是请注意，尤其是ALPHA是区分大小写的。这意味着“令牌”是区分大小写的值。该含义是正确的，除非在本文件中明确规定相反，或在其他一些规范中定义了本文件指定在特定上下文中使用的值。
Various FTP commands take pathnames as arguments, or return pathnames in responses. When the MLST command is supported, as indicated in the response to the FEAT command [6], pathnames are to be transferred in one of the following two formats.
各种FTP命令将路径名作为参数，或在响应中返回路径名。当支持MLST命令时，如对FEAT命令[6]的响应中所示，路径名将以以下两种格式之一传输。
pathname = utf-8-name / raw
utf-8-name = <a UTF-8 encoded Unicode string>
raw = <any string that is not a valid UTF-8 encoding>
pathname = utf-8-name / raw
utf-8-name = <a UTF-8 encoded Unicode string>
raw = <any string that is not a valid UTF-8 encoding>
Which format is used is at the option of the user-PI or server-PI sending the pathname. UTF-8 encodings [2] contain enough internal structure that it is always, in practice, possible to determine whether a UTF-8 or raw encoding has been used, in those cases where it matters. While it is useful for the user-PI to be able to correctly display a pathname received from the server-PI to the user, it is far more important for the user-PI to be able to retain and retransmit the identical pathname when required. Implementations are advised against converting a UTF-8 pathname to a local charset that isn't capable of representing the full Unicode character repertoire, and then attempting to invert the charset translation later. Note that ASCII is a subset of UTF-8. See also [1].
使用哪种格式取决于发送路径名的用户PI或服务器PI。UTF-8编码[2]包含足够的内部结构，因此在实际中，在重要的情况下，始终可以确定是否使用了UTF-8编码或原始编码。虽然用户PI能够正确地向用户显示从服务器PI接收到的路径名是有用的，但用户PI能够在需要时保留并重新传输相同的路径名则更为重要。建议实现不要将UTF-8路径名转换为无法表示完整Unicode字符集的本地字符集，然后稍后尝试反转字符集转换。请注意，ASCII是UTF-8的子集。另见[1]。
Unless otherwise specified, the pathname is terminated by the CRLF that terminates the FTP command, or by the CRLF that ends a reply. Any trailing spaces preceding that CRLF form part of the name. Exactly one space will precede the pathname and serve as a separator from the preceding syntax element. Any additional spaces form part of the pathname. See [7] for a fuller explanation of the character encoding issues. All implementations supporting MLST MUST support [7].
除非另有规定，否则路径名由终止FTP命令的CRLF或结束回复的CRLF终止。该CRLF前面的任何尾随空格构成名称的一部分。路径名前面正好有一个空格，用作前面语法元素的分隔符。任何其他空格构成路径名的一部分。有关字符编码问题的更全面解释，请参见[7]。所有支持MLST的实现都必须支持[7]。
Note: for pathnames transferred over a data connection, there is no way to represent a pathname containing the characters CR and LF in sequence, and distinguish that from the end of line indication. Hence, pathnames containing the CRLF pair of characters cannot be transmitted over a data connection. Data connections only contain file names transmitted from server-FTP to user-FTP as the result of one of the directory listing commands. Files with names containing the CRLF sequence must either have that sequence converted to some other form, such that the other form can be recognised and be correctly converted back to CRLF, or be omitted from the listing.
注意：对于通过数据连接传输的路径名，无法表示顺序包含字符CR和LF的路径名，也无法将其与行尾指示区分开来。因此，包含CRLF字符对的路径名不能通过数据连接传输。数据连接仅包含作为目录列表命令之一的结果从服务器FTP传输到用户FTP的文件名。名称包含CRLF序列的文件必须将该序列转换为其他形式，以便识别其他形式并正确转换回CRLF，或者从列表中删除。
Implementations should also beware that the FTP control connection uses Telnet NVT conventions [8], and that the Telnet IAC character, if part of a pathname sent over the control connection, MUST be correctly escaped as defined by the Telnet protocol.
实现还应注意FTP控制连接使用Telnet NVT约定[8]，并且Telnet IAC字符（如果是通过控制连接发送的路径名的一部分）必须按照Telnet协议的定义正确转义。
NVT also distinguishes between CR, LF, and the end of line CRLF, and so would permit pathnames containing the pair of characters CR and LF to be correctly transmitted. However, because such a sequence cannot be transmitted over a data connection (as part of the result of a LIST, NLST, or MLSD command), such pathnames are best avoided.
NVT还区分CR、LF和行尾CRLF，因此允许正确传输包含CR和LF字符对的路径名。但是，由于这样的序列不能通过数据连接传输（作为LIST、NLST或MLSD命令结果的一部分），因此最好避免使用这样的路径名。
Implementors should also be aware that, although Telnet NVT conventions are used over the control connections, Telnet option negotiation MUST NOT be attempted. See section 4.1.2.12 of [9].
实现者还应该意识到，尽管在控制连接上使用了Telnet NVT约定，但不能尝试Telnet选项协商。见[9]第4.1.2.12节。
Except where TVFS is supported (see section 6), this specification imposes no syntax upon pathnames. Nor does it restrict the character set from which pathnames are created. This does not imply that the NVFS is required to make sense of all possible pathnames. Server-PIs may restrict the syntax of valid pathnames in their NVFS in any manner appropriate to their implementation or underlying file system. Similarly, a server-PI may parse the pathname and assign meaning to the components detected.
除非支持TVFS（参见第6节），否则本规范不对路径名施加语法。它也不限制从中创建路径名的字符集。这并不意味着需要NVFS来理解所有可能的路径名。服务器PIs可以根据其实现或底层文件系统的适当方式限制其NVF中有效路径名的语法。类似地，服务器PI可以解析路径名并为检测到的组件分配意义。
For the commands defined in this specification, all pathnames are to be treated literally. That is, for a pathname given as a parameter to a command, the file whose name is identical to the pathname given is implied. No characters from the pathname may be treated as special or "magic", thus no pattern matching (other than for exact equality) between the pathname given and the files present in the NVFS of the server-FTP is permitted.
对于本规范中定义的命令，所有路径名都将按字面处理。也就是说，对于作为命令参数给定的路径名，将暗示其名称与给定路径名相同的文件。路径名中的任何字符都不能被视为特殊字符或“魔法”，因此不允许在给定的路径名和服务器FTP的NVFS中存在的文件之间进行模式匹配（完全相等的情况除外）。
Clients that desire some form of pattern matching functionality must obtain a listing of the relevant directory, or directories, and implement their own file name selection procedures.
需要某种形式的模式匹配功能的客户机必须获得相关目录的列表，并实现自己的文件名选择过程。
The syntax of a time value is:
时间值的语法为：
time-val = 14DIGIT [ "." 1*DIGIT ]
时间值=14位[“”1*位]
The leading, mandatory, fourteen digits are to be interpreted as, in order from the leftmost, four digits giving the year, with a range of 1000--9999, two digits giving the month of the year, with a range of 01--12, two digits giving the day of the month, with a range of 01--31, two digits giving the hour of the day, with a range of 00--23, two digits giving minutes past the hour, with a range of 00--59, and finally, two digits giving seconds past the minute, with a range of 00--60 (with 60 being used only at a leap second). Years in the tenth century, and earlier, cannot be expressed. This is not considered a serious defect of the protocol.
前导的、必须的十四位数字按最左边的顺序解释为四位数字表示年份，范围为1000-9999，两位数字表示月份，范围为01-12，两位数字表示月份的日期，范围为01-31，两位数字表示一天中的小时，范围为00-23，两位数字表示小时后的分钟数，范围为00-59，最后两位数字表示分钟后的秒数，范围为00-60（60仅在闰秒使用）。十世纪或更早的年份是无法表达的。这不被认为是协议的严重缺陷。
The optional digits, which are preceded by a period, give decimal fractions of a second. These may be given to whatever precision is appropriate to the circumstance, however implementations MUST NOT add precision to time-vals where that precision does not exist in the underlying value being transmitted.
可选数字前加句点，表示小数点为秒。这些精度可适用于任何适合环境的精度，但是，如果传输的基础值中不存在精度，则实现不得向时间VAL添加精度。
Symbolically, a time-val may be viewed as
从象征意义上讲，时间值可以被视为
YYYYMMDDHHMMSS.sss
YYYYMMDDHHMMSS.sss
The "." and subsequent digits ("sss") are optional. However the "." MUST NOT appear unless at least one following digit also appears.
“.”和后续数字（“sss”）是可选的。但是，除非下面至少出现一个数字，否则不得出现“.”。
Time values are always represented in UTC (GMT), and in the Gregorian calendar regardless of what calendar may have been in use at the date and time indicated at the location of the server-PI.
时间值始终以UTC（GMT）和公历表示，无论在服务器PI位置指示的日期和时间使用的是哪种日历。
The technical differences among GMT, TAI, UTC, UT1, UT2, etc., are not considered here. A server-FTP process should always use the same time reference, so the times it returns will be consistent. Clients are not expected to be time synchronized with the server, so the possible difference in times that might be reported by the different time standards is not considered important.
此处不考虑GMT、TAI、UTC、UT1、UT2等之间的技术差异。服务器FTP进程应始终使用相同的时间引用，以便返回的时间保持一致。客户端不希望与服务器进行时间同步，因此不同时间标准可能报告的时间差异并不重要。
Section 4.2 of [3] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change.
[3]的第4.2节定义了服务器PI对来自用户PI的FTP命令的回复的格式和含义。这些回复约定在这里使用，没有任何更改。
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
Implementors should note that the ABNF syntax used in this document and in other FTP related documents (but not used in [3]), sometimes shows replies using the one-line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementors should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) may use the multi-line format described in [3].
实施者应注意，本文档和其他FTP相关文档（但未在[3]中使用）中使用的ABNF语法有时显示使用单行格式的回复。除非另有明确说明，否则这并不意味着不允许多行响应。实施者应假设，除非另有说明，对任何FTP命令（包括QUIT）的任何回复都可以使用[3]中描述的多行格式。
Throughout this document, replies will be identified by the three digit code that is their first element. Thus the term "500 reply" means a reply from the server-PI using the three digit code "500".
在本文件中，答复将以三位数代码标识，这是答复的第一个要素。因此，术语“500应答”是指来自服务器PI的使用三位数代码“500”的应答。
In the examples of FTP dialogs presented in this document, lines that begin "C> " were sent over the control connection from the user-PI to the server-PI, lines that begin "S> " were sent over the control connection from the server-PI to the user-PI, and each sequence of lines that begin "D> " was sent from the server-PI to the user-PI over a data connection created just to send those lines and closed immediately after. No examples here show data transferred over a data connection from the client to the server. In all cases, the prefixes shown above, including the one space, have been added for the purposes of this document, and are not a part of the data exchanged between client and server.
在本文档中介绍的FTP对话框示例中，以“C>开头的行通过控制连接从用户PI发送到服务器PI，以“S>开头的行通过控制连接从服务器PI发送到用户PI，以及以“D>开头的每一行序列通过数据连接从服务器PI发送到用户PI，该数据连接仅为发送这些行而创建，并在之后立即关闭。这里没有示例显示通过数据连接从客户端传输到服务器的数据。在所有情况下，上面显示的前缀（包括一个空格）都是为了本文档的目的而添加的，并且不是客户端和服务器之间交换的数据的一部分。
The FTP command, MODIFICATION TIME (MDTM), can be used to determine when a file in the server NVFS was last modified. This command has existed in many FTP servers for many years, as an adjunct to the REST command for STREAM mode, thus is widely available. However, where supported, the "modify" fact that can be provided in the result from the new MLST command is recommended as a superior alternative.
FTP命令修改时间（MDTM）可用于确定服务器NVFS中的文件上次修改的时间。此命令在许多FTP服务器中已经存在多年，作为流模式REST命令的附件，因此广泛可用。但是，在支持的情况下，建议在新MLST命令的结果中提供“修改”事实作为更好的替代方案。
When attempting to restart a RETRieve, the user-FTP can use the MDTM command or the "modify" fact to check if the modification time of the source file is more recent than the modification time of the partially transferred file. If it is, then most likely the source file has changed, and it would be unsafe to restart the previously incomplete file transfer.
尝试重新启动检索时，用户FTP可以使用MDTM命令或“修改”事实来检查源文件的修改时间是否比部分传输文件的修改时间更晚。如果是，则很可能源文件已更改，重新启动以前未完成的文件传输是不安全的。
Because the user- and server-FTPs' clocks are not necessarily synchronised, user-FTPs intending to use this method should usually obtain the modification time of the file from the server before the initial RETRieval, and compare that with the modification time before a RESTart. If they differ, the files may have changed, and RESTart would be inadvisable. Where this is not possible, the user-FTP should make sure to allow for possible clock skew when comparing times.
由于用户和服务器FTP的时钟不一定同步，因此打算使用此方法的用户FTP通常应在初始检索之前从服务器获取文件的修改时间，并将其与重新启动之前的修改时间进行比较。如果它们不同，则文件可能已更改，不建议重新启动。在不可能的情况下，用户FTP应确保在比较时间时考虑可能的时钟偏移。
When attempting to restart a STORe, the User FTP can use the MDTM command to discover the modification time of the partially transferred file. If it is older than the modification time of the file that is about to be STORed, then most likely the source file has changed, and it would be unsafe to restart the file transfer.
尝试重新启动存储时，用户FTP可以使用MDTM命令来发现部分传输文件的修改时间。如果该时间早于即将存储的文件的修改时间，则很可能源文件已更改，重新启动文件传输将不安全。
Note that using MLST (described below), where available, can provide this information and much more, thus giving an even better indication that a file has changed and that restarting a transfer would not give valid results.
请注意，在可用的情况下，使用MLST（如下所述）可以提供此信息以及更多信息，从而更好地指示文件已更改，并且重新启动传输不会产生有效结果。
Note that this is applicable to any RESTart attempt, regardless of the mode of the file transfer.
请注意，这适用于任何重新启动尝试，无论文件传输的模式如何。
The syntax for the MDTM command is:
MDTM命令的语法为：
mdtm = "MdTm" SP pathname CRLF
mdtm=“mdtm”SP路径名CRLF
As with all FTP commands, the "MDTM" command label is interpreted in a case-insensitive manner.
与所有FTP命令一样，“MDTM”命令标签以不区分大小写的方式解释。
The "pathname" specifies an object in the NVFS that may be the object of a RETR command. Attempts to query the modification time of files that exist but are unable to be retrieved may generate an error-response, or can result in a positive response carrying a time-val with an unspecified value, the choice being made by the server-PI.
“路径名”指定NVFS中可能是RETR命令对象的对象。尝试查询已存在但无法检索的文件的修改时间可能会生成错误响应，或者可能导致带有未指定值的时间val的肯定响应，由服务器PI进行选择。
The server-PI will respond to the MDTM command with a 213 reply giving the last modification time of the file whose pathname was supplied, or a 550 reply if the file does not exist, the modification time is unavailable, or some other error has occurred.
服务器PI将以213回复MDTM命令，给出提供路径名的文件的最后修改时间；如果文件不存在、修改时间不可用或发生其他错误，则以550回复MDTM命令。
mdtm-response = "213" SP time-val CRLF / error-response
mdtm response=“213”SP时间值CRLF/错误响应
Note that when the 213 response is issued, that is, when there is no error, the format MUST be exactly as specified. Multi-line responses are not permitted.
请注意，当发出213响应时，即当没有错误时，格式必须与指定的格式完全相同。不允许多行响应。
Where the command is correctly parsed but the modification time is not available, either because the pathname identifies no existing entity or because the information is not available for the entity named, then a 550 reply should be sent. Where the command cannot be correctly parsed, a 500 or 501 reply should be sent, as specified in [3]. Various 4xy replies are also possible in appropriate circumstances.
如果命令已正确解析，但修改时间不可用，或者是因为路径名未标识任何现有实体，或者是因为指定实体的信息不可用，则应发送550回复。如果无法正确解析命令，则应发送500或501回复，如[3]中所述。在适当的情况下，也可以进行各种4xy回复。
When replying to the FEAT command [6], a server-FTP process that supports the MDTM command MUST include a line containing the single word "MDTM". This MAY be sent in upper or lower case or a mixture of both (it is case insensitive), but SHOULD be transmitted in upper case only. That is, the response SHOULD be:
在回复FEAT命令[6]时，支持MDTM命令的服务器FTP进程必须包含一行，其中包含单个单词“MDTM”。可以用大写或小写或两者的混合形式发送（不区分大小写），但只能用大写发送。也就是说，答案应该是：
C> Feat
S> 211- <any descriptive text>
S> ...
S> MDTM
S> ...
S> 211 End
C> Feat
S> 211- <any descriptive text>
S> ...
S> MDTM
S> ...
S> 211 End
The ellipses indicate place holders where other features may be included, but are not required. The one-space indentation of the feature lines is mandatory [6].
省略号表示可能包括但不需要其他功能的占位符。要素线的单空间缩进是强制性的[6]。
If we assume the existence of three files, A B and C, a directory D, two files with names that end with the string "ile6", and no other files at all, then the MDTM command may behave as indicated. The "C>" lines are commands from user-PI to server-PI, the "S>" lines are server-PI replies.
如果我们假设存在三个文件，一个B和C、一个目录D、两个名称以字符串“ile6”结尾的文件，并且根本没有其他文件，那么MDTM命令的行为可能如图所示。“C>行是从用户PI到服务器PI的命令，“S>行是服务器PI应答。
C> MDTM A S> 213 19980615100045.014 C> MDTM B S> 213 19980615100045.014 C> MDTM C S> 213 19980705132316 C> MDTM D S> 550 D is not retrievable C> MDTM E S> 550 No file named "E" C> mdtm file6 S> 213 19990929003355 C> MdTm 19990929043300 File6 S> 213 19991005213102 C> MdTm 19990929043300 file6 S> 550 19990929043300 file6: No such file or directory.
C> MDTM A S>213 1998061510045.014 C>MDTM B S>213 1998061510045.014 C>MDTM C S>213 19980705132316 C>MDTM D S>550 D不可检索C>MDTM E S>550没有名为“E”C>MDTM文件6 S>213 19990929003355 C>MDTM 19990929043300文件6 S>213 19991005213102 C>MDTM 19990929043300文件6 S>550 19990929043300文件6：没有这样的文件或目录。
From that we can conclude that both A and B were last modified at the same time (to the nearest millisecond), and that C was modified 20 days and several hours later.
由此我们可以得出结论，A和B最后一次被修改是在同一时间（精确到毫秒），而C在20天和几个小时后被修改。
The times are in GMT, so file A was modified on the 15th of June, 1998, at approximately 11am in London (summer time was then in effect), or perhaps at 8pm in Melbourne, Australia, or at 6am in New York. All of those represent the same absolute time, of course. The location where the file was modified, and consequently the local wall clock time at that location, is not available.
时间以格林尼治标准时间为单位，因此文件A于1998年6月15日伦敦上午11点左右（当时是夏季时间）或澳大利亚墨尔本晚上8点或纽约早上6点修改。当然，所有这些都代表相同的绝对时间。文件被修改的位置以及该位置的本地挂钟时间不可用。
There is no file named "E" in the current directory, but there are files named both "file6" and "19990929043300 File6". The modification times of those files were obtained. There is no file named "19990929043300 file6".
当前目录中没有名为“E”的文件，但有名为“file6”和“19990929043300 file6”的文件。获得了这些文件的修改次数。没有名为“19990929043300 file6”的文件。
The FTP command, SIZE OF FILE (SIZE), is used to obtain the transfer size of a file from the server-FTP process. This is the exact number of octets (8 bit bytes) that would be transmitted over the data connection should that file be transmitted. This value will change depending on the current STRUcture, MODE, and TYPE of the data connection or of a data connection that would be created were one created now. Thus, the result of the SIZE command is dependent on the currently established STRU, MODE, and TYPE parameters.
FTP命令SIZE OF FILE（SIZE）用于从服务器FTP进程获取文件的传输大小。这是在传输该文件时通过数据连接传输的八位字节（8位字节）的确切数量。此值将根据当前数据连接或当前创建的数据连接的结构、模式和类型而更改。因此，SIZE命令的结果取决于当前建立的STRU、模式和类型参数。
The SIZE command returns how many octets would be transferred if the file were to be transferred using the current transfer structure, mode, and type. This command is normally used in conjunction with the RESTART (REST) command when STORing a file to a remote server in STREAM mode, to determine the restart point. The server-PI might need to read the partially transferred file, do any appropriate conversion, and count the number of octets that would be generated when sending the file in order to correctly respond to this command. Estimates of the file transfer size MUST NOT be returned; only precise information is acceptable.
SIZE命令返回使用当前传输结构、模式和类型传输文件时将传输多少个八位字节。当以流模式将文件存储到远程服务器时，此命令通常与RESTART（REST）命令一起使用，以确定重新启动点。服务器PI可能需要读取部分传输的文件，执行任何适当的转换，并计算发送文件时生成的八位字节数，以便正确响应此命令。不得返回文件传输大小的估计值；只有准确的信息是可以接受的。
The syntax of the SIZE command is:
SIZE命令的语法为：
size = "Size" SP pathname CRLF
size=“size”SP路径名CRLF
The server-PI will respond to the SIZE command with a 213 reply giving the transfer size of the file whose pathname was supplied, or an error response if the file does not exist, the size is unavailable, or some other error has occurred. The value returned is in a format suitable for use with the RESTART (REST) command for mode STREAM, provided the transfer mode and type are not altered.
服务器PI将以213回复SIZE命令，给出提供路径名的文件的传输大小；如果文件不存在、大小不可用或发生了其他错误，则会发出错误响应。如果传输模式和类型没有改变，则返回的值的格式适合与模式流的RESTART（REST）命令一起使用。
size-response = "213" SP 1*DIGIT CRLF / error-response
大小响应=“213”SP 1*数字CRLF/错误响应
Note that when the 213 response is issued, that is, when there is no error, the format MUST be exactly as specified. Multi-line responses are not permitted.
请注意，当发出213响应时，即当没有错误时，格式必须与指定的格式完全相同。不允许多行响应。
Where the command is correctly parsed but the size is not available, perhaps because the pathname identifies no existing entity or because the entity named cannot be transferred in the current MODE and TYPE (or at all), then a 550 reply should be sent. Where the command cannot be correctly parsed, a 500 or 501 reply should be sent, as specified in [3]. The presence of the 550 error response to a SIZE command MUST NOT be taken by the client as an indication that the file cannot be transferred in the current MODE and TYPE. A server may generate this error for other reasons -- for instance if the processing overhead is considered too great. Various 4xy replies are also possible in appropriate circumstances.
如果命令已正确解析，但大小不可用，可能是因为路径名未标识任何现有实体，或者因为名为的实体无法在当前模式和类型下传输（或根本无法传输），则应发送550回复。如果无法正确解析命令，则应发送500或501回复，如[3]中所述。客户端不得将存在对SIZE命令的550错误响应视为文件无法在当前模式和类型下传输的指示。服务器可能会因为其他原因生成此错误——例如，如果认为处理开销太大。在适当的情况下，也可以进行各种4xy回复。
When replying to the FEAT command [6], a server-FTP process that supports the SIZE command MUST include a line containing the single word "SIZE". This word is case insensitive, and MAY be sent in any mixture of upper or lower case, however it SHOULD be sent in upper case. That is, the response SHOULD be:
在回复FEAT命令[6]时，支持SIZE命令的服务器FTP进程必须包含一行，其中包含单个单词“SIZE”。这个词不区分大小写，可以用大写或小写的任意混合形式发送，但应该用大写。也就是说，答案应该是：
C> FEAT
S> 211- <any descriptive text>
S> ...
S> SIZE
S> ...
S> 211 END
C> FEAT
S> 211- <any descriptive text>
S> ...
S> SIZE
S> ...
S> 211 END
The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory [6].
省略号表示可能包含其他功能且不需要的占位符。要素线的单空间缩进是强制性的[6]。
Consider a text file "Example" stored on a Unix(TM) server where each end of line is represented by a single octet. Assume the file contains 112 lines, and 1830 octets total. Then the SIZE command would produce:
考虑在UNIX（TM）服务器上存储的文本文件“示例”，其中每一行的末端由单个八位字节表示。假设该文件包含112行，总共1830个八位字节。然后，“大小”命令将生成：
C> TYPE I S> 200 Type set to I. C> size Example S> 213 1830 C> TYPE A S> 200 Type set to A. C> Size Example S> 213 1942
C> I型S>200型设置为I.C>尺寸示例S>213 1830 C>A型S>200型设置为A.C>尺寸示例S>213 1942
Notice that with TYPE=A the SIZE command reports an extra 112 octets. Those are the extra octets that need to be inserted, one at the end of each line, to provide correct end-of-line semantics for a transfer using TYPE=A. Other systems might need to make other changes to the transfer format of files when converting between TYPEs and MODEs. The SIZE command takes all of that into account.
请注意，对于TYPE=A，SIZE命令报告额外的112个八位字节。这些是需要插入的额外八位字节，每行末尾一个，以便为使用TYPE=a的传输提供正确的行尾语义。在类型和模式之间转换时，其他系统可能需要对文件的传输格式进行其他更改。SIZE命令考虑了所有这些因素。
Since calculating the size of a file with this degree of precision may take considerable effort on the part of the server-PI, user-PIs should not used this command unless this precision is essential (such as when about to restart an interrupted transfer). For other uses, the "Size" fact of the MLST command (see section 7.5.7) ought be requested.
由于计算具有此精度的文件大小可能需要服务器PI付出相当大的努力，因此用户PI不应使用此命令，除非此精度至关重要（例如，当即将重新启动中断传输时）。对于其他用途，应要求提供MLST命令的“大小”事实（见第7.5.7节）。
To avoid having to resend the entire file if the file is only partially transferred, both sides need some way to agree on where in the data stream to restart the data transfer.
为了避免在文件仅部分传输的情况下必须重新发送整个文件，双方需要以某种方式就数据流中的何处重新启动数据传输达成一致。
The FTP specification [3] includes three modes of data transfer, STREAM, Block, and Compressed. In Block and Compressed modes, the data stream that is transferred over the data connection is formatted, allowing the embedding of restart markers into the stream. The sending DTP can include a restart marker with whatever information it needs to be able to restart a file transfer at that point. The receiving DTP can keep a list of these restart markers, and correlate them with how the file is being saved. To restart the file transfer, the receiver just sends back that last restart marker, and both sides know how to resume the data transfer. Note that there are some flaws in the description of the restart mechanism in STD 9, RFC 959 [3]. See section 4.1.3.4 of RFC 1123 [9] for the corrections.
FTP规范[3]包括数据传输、流、块和压缩三种模式。在块模式和压缩模式下，通过数据连接传输的数据流被格式化，允许在流中嵌入重启标记。发送DTP可以包含一个重新启动标记，其中包含在该点重新启动文件传输所需的任何信息。接收DTP可以保留这些重新启动标记的列表，并将它们与文件的保存方式相关联。要重新启动文件传输，接收方只需发送回上次重新启动标记，双方都知道如何恢复数据传输。请注意，STD 9 RFC 959[3]中对重启机制的描述存在一些缺陷。有关更正，请参见RFC 1123[9]第4.1.3.4节。
In STREAM mode, the data connection contains just a stream of unformatted octets of data. Explicit restart markers thus cannot be inserted into the data stream, they would be indistinguishable from data. For this reason, the FTP specification [3] did not provide the ability to do restarts in stream mode. However, there is not really a need to have explicit restart markers in this case, as restart markers can be implied by the octet offset into the data stream.
在流模式下，数据连接仅包含未格式化的八位字节数据流。因此，无法将显式重启标记插入到数据流中，因为它们与数据无法区分。因此，FTP规范[3]没有提供以流模式重新启动的功能。然而，在这种情况下，实际上并不需要显式的重启标记，因为重启标记可以由数据流中的八位组偏移量暗示。
Because the data stream defines the file in STREAM mode, a different data stream would represent a different file. Thus, an offset will always represent the same position within a file. On the other hand, in other modes than STREAM, the same file can be transferred using quite different octet sequences and yet be reconstructed into the one identical file. Thus an offset into the data stream in transfer modes other than STREAM would not give an unambiguous restart point.
因为数据流以流模式定义文件，所以不同的数据流将表示不同的文件。因此，偏移量将始终表示文件中的相同位置。另一方面，在流以外的其他模式中，相同的文件可以使用完全不同的八位组序列进行传输，并且还可以重建为一个相同的文件。因此，在数据流以外的传输模式下，数据流中的偏移量不会给出明确的重新启动点。
If the data representation TYPE is IMAGE and the STRUcture is File, for many systems the file will be stored exactly in the same format as it is sent across the data connection. It is then usually very easy for the receiver to determine how much data was previously received, and notify the sender of the offset where the transfer should be restarted. In other representation types and structures more effort will be required, but it remains always possible to determine the offset with finite, but perhaps non-negligible, effort. In the worst case, an FTP process may need to open a data connection to itself, set the appropriate transfer type and structure, and actually transmit the file, counting the transmitted octets.
如果数据表示类型为图像，结构为文件，则对于许多系统，文件的存储格式将与通过数据连接发送的格式完全相同。然后，接收方通常很容易确定以前接收到多少数据，并通知发送方应该在哪里重新开始传输的偏移量。在其他表示类型和结构中，需要付出更多的努力，但始终可以通过有限但可能不可忽略的努力来确定偏移量。在最坏的情况下，FTP进程可能需要打开与自身的数据连接，设置适当的传输类型和结构，并实际传输文件，计算传输的八位字节数。
If the user-FTP process is intending to restart a retrieve, it will directly calculate the restart marker and send that information in the RESTart command. However, if the user-FTP process is intending to restart sending the file, it needs to be able to determine how much data was previously sent, and correctly received and saved. A new FTP command is needed to get this information. This is the purpose of the SIZE command, as documented in section 4.
如果用户FTP进程打算重新启动检索，它将直接计算重新启动标记，并在restart命令中发送该信息。但是，如果用户FTP进程打算重新发送文件，则需要能够确定以前发送了多少数据，以及正确接收和保存了多少数据。需要一个新的FTP命令来获取此信息。这是SIZE命令的目的，如第4节所述。
STREAM mode transfers with FILE STRUcture may be restarted even though no restart marker has been transferred in addition to the data itself. This is done by using the SIZE command, if needed, in combination with the RESTART (REST) command, and one of the standard file transfer commands.
具有文件结构的流模式传输可以重新启动，即使除了数据本身之外，没有传输重新启动标记。如果需要，可以使用SIZE命令、RESTART（REST）命令和一个标准文件传输命令来完成此操作。
When using TYPE ASCII or IMAGE, the SIZE command will return the number of octets that would actually be transferred if the file were
当使用ASCII或IMAGE类型时，SIZE命令将返回实际传输的八位字节数（如果文件被删除）
to be sent between the two systems, i.e., with type IMAGE, the SIZE normally would be the number of octets in the file. With type ASCII, the SIZE would be the number of octets in the file including any modifications required to satisfy the TYPE ASCII CR-LF end-of-line convention.
要在两个系统之间发送，即使用类型IMAGE，大小通常为文件中的八位字节数。对于ASCII类型，大小将是文件中的八位字节数，包括满足ASCII CR-LF类型行尾约定所需的任何修改。
The syntax for the REST command when the current transfer mode is STREAM is:
当前传输模式为STREAM时，REST命令的语法为：
rest = "Rest" SP 1*DIGIT CRLF
rest=“rest”SP 1*数字CRLF
The numeric value gives the number of octets of the immediately-following transfer to not actually send, effectively causing the transmission to be restarted at a later point. A value of zero effectively disables restart, causing the entire file to be transmitted. The server-PI will respond to the REST command with a 350 reply, indicating that the REST parameter has been saved, and that another command, which should be either RETR or STOR, should then follow to complete the restart.
该数值给出了紧接着传输的未实际发送的八位字节数，有效地导致传输在稍后重新启动。值为零将有效禁用重新启动，从而导致传输整个文件。服务器PI将以350的回复响应REST命令，指示REST参数已保存，然后应跟随另一个命令（应为RETR或STOR）完成重启。
rest-response = "350" SP *TCHAR CRLF / error-response
rest response=“350”SP*TCHAR CRLF/错误响应
Server-FTP processes may permit transfer commands other than RETR and STOR, such as APPE and STOU, to complete a restart; however, this is not recommended. STOU (store unique) is undefined in this usage, as storing the remainder of a file into a unique file name is rarely going to be useful. If APPE (append) is permitted, it MUST act identically to STOR when a restart marker has been set. That is, in both cases, octets from the data connection are placed into the file at the location indicated by the restart marker value.
服务器FTP进程可能允许传输RETR和STOR以外的命令，如APPE和STOU，以完成重启；但是，不建议这样做。STOU（store unique）在这种用法中没有定义，因为将文件的其余部分存储到唯一的文件名中很少有用。如果允许APPE（append），则在设置重启标记时，它必须与STOR相同。也就是说，在这两种情况下，数据连接中的八位字节都被放置到文件中由重新启动标记值指示的位置。
The REST command is intended to complete a failed transfer. Use with RETR is comparatively well defined in all cases, as the client bears the responsibility of merging the retrieved data with the partially retrieved file. It may choose to use the data obtained other than to complete an earlier transfer, or to re-retrieve data that had been retrieved before. With STOR, however, the server must insert the data into the file named. The results are undefined if a client uses REST to do other than restart to complete a transfer of a file that had previously failed to completely transfer. In particular, if the restart marker set with a REST command is not at the end of the data currently stored at the server, as reported by the server, or if insufficient data are provided in a STOR that follows a REST to extend the destination file to at least its previous size, then the effects are undefined.
REST命令用于完成失败的传输。在所有情况下，与RETR一起使用的定义都比较明确，因为客户机负责将检索到的数据与部分检索到的文件合并。它可以选择使用获得的数据，而不是完成先前的传输，或者重新检索以前检索过的数据。但是，对于STOR，服务器必须将数据插入名为的文件中。如果客户机使用REST而不是重新启动来完成以前无法完全传输的文件的传输，则结果是未定义的。特别是，如果使用REST命令设置的重新启动标记不是服务器报告的当前存储在服务器上的数据的末尾，或者如果REST之后的STOR中提供的数据不足，无法将目标文件扩展到至少以前的大小，则效果未定义。
The REST command must be the last command issued before the data transfer command that is to cause a restarted, rather than a complete, file transfer. The effect of issuing a REST command at any other time is undefined. The server-PI may react to a badly positioned REST command by issuing an error response to the following command, not being a restartable data transfer command, or it may save the restart value and apply it to the next data transfer command, or it may silently ignore the inappropriate restart attempt. Because of this, a user-PI that has issued a REST command, but that has not successfully transmitted the following data transfer command for any reason, should send another REST command before the next data transfer command. If that transfer is not to be restarted, then "REST 0" should be issued.
REST命令必须是在数据传输命令之前发出的最后一个命令，该命令将导致重新启动而不是完成文件传输。在任何其他时间发出REST命令的效果都是未定义的。服务器PI可能会对位置错误的REST命令作出反应，对以下命令发出错误响应，而不是可重启的数据传输命令，或者它可能会保存重启值并将其应用于下一个数据传输命令，或者它可能会默默地忽略不适当的重启尝试。因此，发出REST命令但由于任何原因未成功传输以下数据传输命令的用户PI应在下一个数据传输命令之前发送另一个REST命令。如果不重新启动该传输，则应发出“REST 0”。
An error response will follow a REST command only when the server does not implement the command, or when the restart marker value is syntactically invalid for the current transfer mode (e.g., in STREAM mode, something other than one or more digits appears in the parameter to the REST command). Any other errors, including such problems as restart marker out of range, should be reported when the following transfer command is issued. Such errors will cause that transfer request to be rejected with an error indicating the invalid restart attempt.
只有当服务器未执行REST命令时，或者当重新启动标记值在语法上对当前传输模式无效时（例如，在流模式下，REST命令的参数中出现一个或多个数字以外的内容），错误响应才会跟随REST命令。发出以下传输命令时，应报告任何其他错误，包括重新启动标记超出范围等问题。此类错误将导致传输请求被拒绝，并出现一个错误，指示重新启动尝试无效。
Where a server-FTP process supports RESTart in STREAM mode, as specified here, it MUST include, in the response to the FEAT command [6], a line containing exactly the string "REST STREAM". This string is not case sensitive, but it SHOULD be transmitted in upper case. Where REST is not supported at all or supported only in block or compressed modes, the REST line MUST NOT be included in the FEAT response. Where required, the response SHOULD be:
如果服务器FTP进程支持以流模式重新启动（如此处所述），则它必须在对FEAT命令[6]的响应中包含一行，该行正好包含字符串“REST STREAM”。此字符串不区分大小写，但应以大写形式传输。如果完全不支持REST，或仅在块或压缩模式下支持REST，则FEAT响应中不得包含REST行。如有需要，答复应为：
C> feat
S> 211- <any descriptive text>
S> ...
S> REST STREAM
S> ...
S> 211 end
C> feat
S> 211- <any descriptive text>
S> ...
S> REST STREAM
S> ...
S> 211 end
The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory [6].
省略号表示可能包含其他功能且不需要的占位符。要素线的单空间缩进是强制性的[6]。
Assume that the transfer of a largish file has previously been interrupted after 802816 octets had been received, that the previous transfer was with TYPE=I, and that it has been verified that the file on the server has not since changed.
假设较大文件的传输在收到802816个八位字节后被中断，之前的传输类型为I，并且已验证服务器上的文件此后没有更改。
C> TYPE I S> 200 Type set to I. C> PORT 127,0,0,1,15,107 S> 200 PORT command successful. C> REST 802816 S> 350 Restarting at 802816. Send STORE or RETRIEVE C> RETR cap60.pl198.tar S> 150 Opening BINARY mode data connection [...] S> 226 Transfer complete.
C> 类型I S>200类型设置为I.C>端口127,0,0,1,15107 S>200端口命令成功。C> 其余802816 S>350在802816重新启动。发送存储或检索C>RETR cap60.pl198.tar S>150打开二进制模式数据连接[…]S>226传输完成。
Traditionally, FTP has placed almost no constraints upon the file store (NVFS) provided by a server. This specification does not alter that. However, it has become common for servers to attempt to provide at least file system naming conventions modeled loosely upon those of the UNIX(TM) file system. This is a tree-structured file system, built of directories, each of which can contain other directories, or other kinds of files, or both. Each file and directory has a name relative to the directory that contains it, except for the directory at the root of the tree, which is contained in no other directory, and hence has no name of its own.
传统上，FTP对服务器提供的文件存储（NVFS）几乎没有任何限制。本规范不会改变这一点。然而，对于服务器来说，尝试至少提供松散地模仿UNIX（TM）文件系统的文件系统命名约定已经变得很常见。这是一个树状结构的文件系统，由目录组成，每个目录可以包含其他目录，或其他类型的文件，或两者兼而有之。每个文件和目录都有一个相对于包含它的目录的名称，除了树的根目录，它不包含在其他目录中，因此没有自己的名称。
That which has so far been described is perfectly consistent with the standard FTP NVFS and access mechanisms. The "CWD" command is used to move from one directory to an embedded directory. "CDUP" may be provided to return to the parent directory, and the various file manipulation commands ("RETR", "STOR", the rename commands, etc.) are used to manipulate files within the current directory.
到目前为止所描述的内容与标准FTP NVFS和访问机制完全一致。“CWD”命令用于从一个目录移动到嵌入式目录。可以提供“CDUP”以返回到父目录，并且各种文件操作命令（“RETR”、“STOR”、重命名命令等）用于操作当前目录中的文件。
However, it is often useful to be able to reference files other than by changing directories, especially as FTP provides no guaranteed mechanism to return to a previous directory. The Trivial Virtual File Store (TVFS), if implemented, provides that mechanism.
但是，能够通过更改目录以外的方式引用文件通常很有用，特别是在FTP没有提供返回到以前目录的保证机制的情况下。普通虚拟文件存储（TVFS）如果实现，就提供了这种机制。
Where a server implements the TVFS, no elementary file name shall contain the character "/". Where the underlying natural file store permits files, or directories, to contain the "/" character in their names, a server-PI implementing TVFS must encode that character in some manner whenever file or directory names are being returned to the user-PI, and reverse that encoding whenever such names are being accepted from the user-PI.
如果服务器实现TVFS，则基本文件名不得包含字符“/”。当底层自然文件存储允许文件或目录在其名称中包含“/”字符时，实现TVFS的服务器PI必须在文件或目录名称返回给用户PI时以某种方式对该字符进行编码，并在从用户PI接受该名称时反转该编码。
The encoding method to be used is not specified here. Where some other character is illegal in file and directory names in the underlying file store, a simple transliteration may be sufficient. Where there is no suitable substitute character a more complex encoding scheme, possibly using an escape character, is likely to be required.
此处未指定要使用的编码方法。如果底层文件存储中的文件名和目录名中的其他字符是非法的，那么简单的音译就足够了。如果没有合适的替代字符，则可能需要更复杂的编码方案，可能使用转义字符。
With the one exception of the unnamed root directory, a TVFS file name may not be empty. That is, all other file names contain at least one character.
除了未命名的根目录之外，TVFS文件名不能为空。也就是说，所有其他文件名至少包含一个字符。
With the sole exception of the "/" character, any valid IS10646 character [10] may be used in a TVFS file name. When transmitted, file name characters are encoded using the UTF-8 encoding [2]. Note that the two-character sequence CR LF occurring in a file name will make that name impossible to transmit over a data connection. Consequently, it should be avoided, or if that is impossible to achieve, it MUST be encoded in some reversible way.
除了“/”字符外，TVFS文件名中可以使用任何有效的IS10646字符[10]。传输时，使用UTF-8编码对文件名字符进行编码[2]。请注意，文件名中出现的两个字符序列CR LF将使该名称无法通过数据连接传输。因此，应该避免，或者如果不可能实现，则必须以某种可逆的方式对其进行编码。
A TVFS "Pathname" combines the file or directory name of a target file or directory, with the directory names of zero or more enclosing directories, so as to allow the target file or directory to be referenced other than when the server's "current working directory" is the directory directly containing the target file or directory.
TVFS“路径名”将目标文件或目录的文件或目录名与零个或多个封闭目录的目录名相结合，以便允许引用目标文件或目录，而不是在服务器的“当前工作目录”是直接包含目标文件或目录的目录时引用。
By definition, every TVFS file or directory name is also a TVFS pathname. Such a pathname is valid to reference the file from the directory containing the name, that is, when that directory is the server-FTP's current working directory.
根据定义，每个TVFS文件或目录名也是一个TVFS路径名。这样的路径名对于从包含该名称的目录引用文件是有效的，也就是说，当该目录是服务器FTP的当前工作目录时。
Other TVFS pathnames are constructed by prefixing a pathname by a name of a directory from which the path is valid, and separating the two with the "/" character. Such a pathname is valid to reference the file or directory from the directory containing the newly added directory name.
其他TVFS路径名是通过在路径名前面加上路径有效的目录名，并用“/”字符分隔这两个路径名来构造的。这样的路径名对于从包含新添加的目录名的目录中引用文件或目录是有效的。
Where a pathname has been extended to the point where the directory added is the unnamed root directory, the pathname will begin with the "/" character. Such a path is known as a fully qualified pathname. Fully qualified paths may, obviously, not be further extended, as, by definition, no directory contains the root directory. Being unnamed, it cannot be represented in any other directory. A fully qualified pathname is valid to reference the named file or directory from any location (that is, regardless of what the current working directory may be) in the virtual file store.
如果路径名已扩展到添加的目录是未命名的根目录，则路径名将以“/”字符开头。这样的路径称为完全限定路径名。显然，完全限定路径可能不会进一步扩展，因为根据定义，没有目录包含根目录。由于未命名，它不能在任何其他目录中表示。完全限定路径名对于从虚拟文件存储中的任何位置（即，无论当前工作目录是什么）引用命名文件或目录都是有效的。
Any pathname that is not a fully qualified pathname may be referred to as a "relative pathname" and will only correctly reference the intended file when the current working directory of the server-FTP is a directory from which the relative pathname is valid.
任何不是完全限定路径名的路径名都可以称为“相对路径名”，并且只有当服务器FTP的当前工作目录是相对路径名有效的目录时，才会正确引用所需文件。
As a special case, the pathname "/" is defined to be a fully qualified pathname referring to the root directory. That is, the root directory does not have a directory (or file) name, but does have a pathname. This special pathname may be used only as is as a reference to the root directory. It may not be combined with other pathnames using the rules above, as doing so would lead to a pathname containing two consecutive "/" characters, which is an undefined sequence.
作为特例，路径名“/”被定义为引用根目录的完全限定路径名。也就是说，根目录没有目录（或文件）名，但有路径名。此特殊路径名只能用作对根目录的引用。不能使用上述规则将其与其他路径名组合，因为这样做会导致路径名包含两个连续的“/”字符，这是一个未定义的序列。
+ It is not required, or expected, that there be only one fully qualified pathname that will reference any particular file or directory.
+ 只有一个完全限定的路径名将引用任何特定的文件或目录不是必需的，也不是期望的。
+ As a caveat, though the TVFS file store is basically tree structured, there is no requirement that any file or directory have only one parent directory.
+ 需要注意的是，尽管TVFS文件存储基本上是树结构的，但不要求任何文件或目录只有一个父目录。
+ As defined, no TVFS pathname will ever contain two consecutive "/" characters. Such a name is not illegal however, and may be defined by the server for any purpose that suits it. Clients implementing this specification should not assume any semantics for such names.
+ 根据定义，任何TVFS路径名都不会包含两个连续的“/”字符。但是，这样的名称并不非法，服务器可以为适合它的任何目的定义该名称。实现此规范的客户机不应假定此类名称具有任何语义。
+ Similarly, other than the special case path that refers to the root directory, no TVFS pathname constructed as defined here will ever end with the "/" character. Such names are also not illegal, but are undefined.
+ 类似地，除了引用根目录的特殊情况路径外，按照此处定义构造的TVFS路径名都不会以“/”字符结尾。这些名称也不是非法的，但没有定义。
+ While any legal IS10646 character is permitted to occur in a TVFS file or directory name, other than "/", server FTP implementations are not required to support all possible IS10646 characters. The
+ 虽然允许在TVFS文件或目录名中出现除“/”以外的任何合法IS10646字符，但服务器FTP实现不需要支持所有可能的IS10646字符。这个
subset supported is entirely at the discretion of the server. The case (where it exists) of the characters that make up file, directory, and pathnames may be significant. Unless determined otherwise by means unspecified here, clients should assume that all such names are comprised of characters whose case is significant. Servers are free to treat case (or any other attribute) of a name as irrelevant, and hence map two names that appear to be distinct onto the same underlying file.
支持的子集完全由服务器决定。组成文件、目录和路径名的字符的大小写（如果存在）可能很重要。除非通过此处未指定的方式另行确定，否则客户端应假定所有此类名称都由大小写重要的字符组成。服务器可以自由地将名称的大小写（或任何其他属性）视为不相关，从而将两个看起来不同的名称映射到同一基础文件上。
+ There are no defined "magic" names, like ".", ".." or "C:". Servers may implement such names, with any semantics they choose, but are not required to do so.
+ 没有定义的“魔法”名称，如“.”、“…”或“C:”。服务器可以使用它们选择的任何语义实现这样的名称，但不需要这样做。
+ TVFS imposes no particular semantics or properties upon files, guarantees no access control schemes, or any of the other common properties of a file store. Only the naming scheme is defined.
+ TVFS不对文件施加特定的语义或属性，不保证访问控制方案或文件存储的任何其他公共属性。只定义了命名方案。
In response to the FEAT command [6] a server that wishes to indicate support for the TVFS as defined here will include a line that begins with the four characters "TVFS" (in any case, or mixture of cases, upper case is not required). Servers SHOULD send upper case.
为了响应FEAT命令[6]，希望表示支持此处定义的TVFS的服务器将包括一行，该行以四个字符“TVFS”开头（在任何情况下或混合情况下，不需要大写）。服务器应发送大写字母。
Such a response to the FEAT command MUST NOT be returned unless the server implements TVFS as defined here.
除非服务器实现此处定义的TVFS，否则不得返回对FEAT命令的此类响应。
Later specifications may add to the TVFS definition. Such additions should be notified by means of additional text appended to the TVFS feature line. Such specifications, if any, will define the extra text.
以后的规范可能会添加到TVFS定义中。此类添加应通过附加到TVFS功能线的附加文本进行通知。此类规范（如有）将定义额外的文本。
Until such a specification is defined, servers should not include anything after "TVFS" in the TVFS feature line. Clients, however, should be prepared to deal with arbitrary text following the four defined characters, and simply ignore it if unrecognized.
在定义此类规范之前，服务器不应在TVFS功能行中的“TVFS”之后包含任何内容。但是，客户端应该准备好处理四个已定义字符后面的任意文本，如果无法识别，则直接忽略它。
A typical response to the FEAT command issued by a server implementing only this specification would be:
对仅实现此规范的服务器发出的FEAT命令的典型响应是：
C> feat
S> 211- <any descriptive text>
S> ...
S> TVFS
S> ...
S> 211 end
C> feat
S> 211- <any descriptive text>
S> ...
S> TVFS
S> ...
S> 211 end
The ellipses indicate place holders where other features may be included, but are not required. The one-space indentation of the feature lines is mandatory [6] and is not counted as one of the first four characters for the purposes of this feature listing.
省略号表示可能包括但不需要其他功能的占位符。要素行的一个空格缩进是强制性的[6]，在本要素列表中不算作前四个字符之一。
The TVFS feature adds no new commands to the FTP command repertoire.
TVFS功能不向FTP命令库添加新命令。
There are no options in this TVFS specification, and hence there is no OPTS command defined.
此TVFS规范中没有选项，因此没有定义OPTS命令。
Assume a TVFS file store is comprised of a root directory, which contains two directories (A and B) and two non-directory files (X and Y). The A directory contains two directories (C and D) and one other file (Z). The B directory contains just two non-directory files (P and Q) and the C directory also two non-directory files (also named P and Q, by chance). The D directory is empty, that is, contains no files or directories. This structure may depicted graphically as...
假设TVFS文件存储由根目录组成，根目录包含两个目录（a和B）和两个非目录文件（X和Y）。A目录包含两个目录（C和D）和另一个文件（Z）。B目录只包含两个非目录文件（P和Q），C目录也包含两个非目录文件（碰巧也称为P和Q）。D目录为空，即不包含任何文件或目录。这种结构可以用图形表示为。。。
(unnamed root)
/ | \ \
/ | \ \
A X B Y
/|\ / \
/ | \ / \
C D Z P Q
/ \
/ \
P Q
(unnamed root)
/ | \ \
/ | \ \
A X B Y
/|\ / \
/ | \ / \
C D Z P Q
/ \
/ \
P Q
Given this structure, the following fully qualified pathnames exist.
给定此结构，存在以下完全限定的路径名。
/
/A
/B
/X
/Y
/A/C
/A/D
/A/Z
/A/C/P
/A/C/Q
/B/P
/B/Q
/
/A
/B
/X
/Y
/A/C
/A/D
/A/Z
/A/C/P
/A/C/Q
/B/P
/B/Q
It is clear that none of the paths / /A /B or /A/D refer to the same
directory, as the contents of each is different. Nor do any of / /A
/A/C or /A/D. However /A/C and /B might be the same directory, there
is insufficient information given to tell. Any of the other
pathnames (/X /Y /A/Z /A/C/P /A/C/Q /B/P and /B/Q) may refer to the
same underlying files, in almost any combination.
It is clear that none of the paths / /A /B or /A/D refer to the same
directory, as the contents of each is different. Nor do any of / /A
/A/C or /A/D. However /A/C and /B might be the same directory, there
is insufficient information given to tell. Any of the other
pathnames (/X /Y /A/Z /A/C/P /A/C/Q /B/P and /B/Q) may refer to the
same underlying files, in almost any combination.
If the current working directory of the server-FTP is /A then the following pathnames, in addition to all the fully qualified pathnames, are valid
如果服务器FTP的当前工作目录为/A，则除了所有完全限定的路径名之外，以下路径名也是有效的
C D Z C/P C/Q
C D Z C/P C/Q
These all refer to the same files or directories as the corresponding fully qualified path with "/A/" prepended.
这些文件或目录都引用了与前面带有“/A/”的相应完全限定路径相同的文件或目录。
That those pathnames all exist does not imply that the TVFS sever will necessarily grant any kind of access rights to the named paths, or that access to the same file via different pathnames will necessarily be granted equal rights.
这些路径名都存在并不意味着TVFS服务器将必须向命名路径授予任何类型的访问权限，或者通过不同路径名访问同一文件将必须获得同等的权限。
None of the following relative paths are valid when the current directory is /A
当当前目录为/A时，下列相对路径均无效
A B X Y B/P B/Q P Q
A B X Y B/P B/Q P Q
Any of those could be made valid by changing the server-FTP's current working directory to the appropriate directory. Note that the paths "P" and "Q" might refer to different files depending upon which directory is selected to cause those to become valid TVFS relative paths.
通过将服务器FTP的当前工作目录更改为适当的目录，可以使这些目录中的任何一个生效。请注意，路径“P”和“Q”可能指的是不同的文件，具体取决于选择哪个目录以使这些文件成为有效的TVFS相对路径。
The MLST and MLSD commands are intended to standardize the file and directory information returned by the server-FTP process. These commands differ from the LIST command in that the format of the replies is strictly defined although extensible.
MLST和MLSD命令用于标准化服务器FTP进程返回的文件和目录信息。这些命令与LIST命令的不同之处在于，回复的格式是严格定义的，尽管可以扩展。
Two commands are defined, MLST and MLSD. MLST provides data about exactly the object named on its command line, and no others. MLSD, on the other, lists the contents of a directory if a directory is named, otherwise a 501 reply is returned. In either case, if no object is named, the current directory is assumed. That will cause MLST to send a one-line response, describing the current directory itself, and MLSD to list the contents of the current directory.
定义了两个命令：MLST和MLSD。MLST只提供有关其命令行上命名的对象的数据，而不提供其他数据。另一方面，如果目录被命名，MLSD将列出目录的内容，否则将返回501回复。在这两种情况下，如果没有命名对象，则假定当前目录。这将导致MLST发送一行响应，描述当前目录本身，并使MLSD列出当前目录的内容。
In the following, the term MLSx will be used wherever either MLST or MLSD may be inserted.
在下文中，术语MLSx将用于插入MLST或MLSD的任何地方。
The MLST and MLSD commands also extend the FTP protocol as presented in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow that transmission of 8-bit data over the control connection. Note this is not specifying character sets which are 8-bit, but specifying that FTP implementations are to specifically allow the transmission and reception of 8-bit bytes, with all bits significant, over the control connection. That is, all 256 possible octet values are permitted. The MLSx command allows both UTF-8/Unicode and "raw" forms as arguments, and in responses both to the MLST and MLSD commands, and all other FTP commands which take pathnames as arguments.
MLST和MLSD命令还扩展了STD 9、RFC 959[3]和STD 3、RFC 1123[9]中所述的FTP协议，以允许通过控制连接传输8位数据。注意：这不是指定8位字符集，而是指定FTP实现特别允许通过控制连接传输和接收8位字节，所有位都有效。也就是说，允许所有256个可能的八位组值。MLSx命令允许UTF-8/Unicode和“raw”形式作为参数，并响应MLST和MLSD命令，以及所有其他以路径名作为参数的FTP命令。
The MLST and MLSD commands each allow a single optional argument. This argument may be either a directory name or, for MLST only, a file name. For these purposes, a "file name" is the name of any entity in the server NVFS which is not a directory. Where TVFS is supported, any TVFS relative pathname valid in the current working directory, or any TVFS fully qualified pathname, may be given. If a directory name is given then MLSD must return a listing of the contents of the named directory, otherwise it issues a 501 reply, and does not open a data connection. In all cases for MLST, a single set of fact lines (usually a single fact line) containing the information about the named file or directory shall be returned over the control connection, without opening a data connection.
MLST和MLSD命令都允许一个可选参数。此参数可以是目录名，也可以是文件名（仅限MLST）。出于这些目的，“文件名”是服务器NVFS中非目录的任何实体的名称。在支持TVFS的情况下，可以提供当前工作目录中有效的任何TVFS相对路径名或任何TVFS完全限定路径名。如果给定了目录名，则MLSD必须返回命名目录的内容列表，否则它将发出501回复，并且不会打开数据连接。在所有情况下，对于MLST，应通过控制连接返回包含命名文件或目录信息的一组事实行（通常为一个事实行），而无需打开数据连接。
If no argument is given then MLSD must return a listing of the contents of the current working directory, and MLST must return a listing giving information about the current working directory itself. For these purposes, the contents of a directory are whatever
如果没有给出参数，那么MLSD必须返回当前工作目录的内容列表，MLST必须返回给出当前工作目录本身信息的列表。出于这些目的，目录的内容是任意的
file or directory names (not pathnames) the server-PI will allow to be referenced when the current working directory is the directory named, and which the server-PI desires to reveal to the user-PI. Note that omitting the argument is the only defined way to obtain a listing of the current directory, unless a pathname that represents the directory happens to be known. In particular, there is no defined shorthand name for the current directory. This does not prohibit any particular server-PI implementing such a shorthand.
当当前工作目录是指定的目录时，服务器PI允许引用的文件或目录名（不是路径名），并且服务器PI希望向用户PI显示该目录。请注意，省略参数是获取当前目录列表的唯一定义方法，除非表示目录的路径名碰巧是已知的。特别是，当前目录没有定义的速记名称。这并不禁止任何特定的服务器PI实现这种速记。
No title, header, or summary, lines, or any other formatting, other than as is specified below, is ever returned in the output of an MLST or MLSD command.
MLST或MLSD命令的输出中不会返回标题、标题、摘要、行或任何其他格式（以下指定的格式除外）。
If the Client-FTP sends an invalid argument, the server-FTP MUST reply with an error code of 501.
如果客户端FTP发送无效参数，服务器FTP必须回复错误代码501。
The syntax for the MLSx command is:
MLSx命令的语法为：
mlst = "MLst" [ SP pathname ] CRLF mlsd = "MLsD" [ SP pathname ] CRLF
mlst=“mlst”[SP pathname]CRLF mlsd=“mlsd”[SP pathname]CRLF
The format of a response to an MLSx command is as follows:
对MLSx命令的响应格式如下：
mlst-response = control-response / error-response
mlsd-response = ( initial-response final-response ) /
error-response
mlst-response = control-response / error-response
mlsd-response = ( initial-response final-response ) /
error-response
control-response = "250-" [ response-message ] CRLF 1*( SP entry CRLF ) "250" [ SP response-message ] CRLF
控制响应=“250-”[响应消息]CRLF 1*（SP条目CRLF）“250”[SP响应消息]CRLF
initial-response = "150" [ SP response-message ] CRLF final-response = "226" SP response-message CRLF
初始响应=“150”[SP响应消息]CRLF最终响应=“226”SP响应消息CRLF
response-message = *TCHAR
response-message = *TCHAR
data-response = *( entry CRLF )
data-response = *( entry CRLF )
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
factname = "Size" / "Modify" / "Create" /
"Type" / "Unique" / "Perm" /
"Lang" / "Media-Type" / "CharSet" /
os-depend-fact / local-fact
os-depend-fact = <IANA assigned OS name> "." token
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
factname = "Size" / "Modify" / "Create" /
"Type" / "Unique" / "Perm" /
"Lang" / "Media-Type" / "CharSet" /
os-depend-fact / local-fact
os-depend-fact = <IANA assigned OS name> "." token
local-fact = "X." token
value = *SCHAR
local-fact = "X." token
value = *SCHAR
Upon receipt of an MLSx command, the server will verify the parameter, and if invalid return an error-response. For this purpose, the parameter should be considered to be invalid if the client issuing the command does not have permission to perform the requested operation.
收到MLSx命令后，服务器将验证参数，如果无效，则返回错误响应。为此，如果发出命令的客户端没有执行请求操作的权限，则该参数应视为无效。
If the parameter is valid, then for an MLST command, the server-PI will send the first (leading) line of the control response, the entry for the pathname given, or the current directory if no pathname was provided, and the terminating line. Normally exactly one entry would be returned, more entries are permitted only when required to represent a file that is to have multiple "Type" facts returned. In this case, the pathname component of every response MUST be identical.
如果参数有效，则对于MLST命令，服务器PI将发送控制响应的第一行（前导行）、给定路径名的条目或当前目录（如果未提供路径名）以及终止行。通常只返回一个条目，只有当需要表示要返回多个“类型”事实的文件时，才允许返回更多条目。在这种情况下，每个响应的路径名组件必须相同。
Note that for MLST the fact set is preceded by a space. That is provided to guarantee that the fact set cannot be accidentally interpreted as the terminating line of the control response, but is required even when that would not be possible. Exactly one space exists between the set of facts and the pathname. Where no facts are present, there will be exactly two leading spaces before the pathname. No spaces are permitted in the facts, any other spaces in the response are to be treated as being a part of the pathname.
请注意，对于MLST，事实集前面有一个空格。这是为了保证事实集不会被意外地解释为控制响应的终止行，但即使在不可能的情况下，也需要这样做。事实集和路径名之间只存在一个空格。如果不存在事实，则路径名前将正好有两个前导空格。事实中不允许使用空格，响应中的任何其他空格都将被视为路径名的一部分。
If the command was an MLSD command, the server will open a data connection as indicated in section 3.2 of STD 9, RFC 959 [3]. If that fails, the server will return an error-response. If all is OK, the server will return the initial-response, send the appropriate data-response over the new data connection, close that connection, and then send the final-response over the control connection. The grammar above defines the format for the data-response, which defines the format of the data returned over the data connection established.
如果该命令是MLSD命令，则服务器将按照STD 9 RFC 959[3]第3.2节的指示打开数据连接。如果失败，服务器将返回错误响应。如果一切正常，服务器将返回初始响应，通过新数据连接发送适当的数据响应，关闭该连接，然后通过控制连接发送最终响应。上面的语法定义了数据响应的格式，它定义了通过建立的数据连接返回的数据的格式。
The data connection opened for a MLSD response shall be a connection as if the "TYPE L 8", "MODE S", and "STRU F" commands had been given, whatever FTP transfer type, mode and structure had actually been set, and without causing those settings to be altered for future commands. That is, this transfer type shall be set for the duration of the data connection established for this command only. While the content of the data sent can be viewed as a series of lines, implementations should note that there is no maximum line length defined. Implementations should be prepared to deal with arbitrarily long lines.
为MLSD响应打开的数据连接应是一个连接，如同已发出“L 8型”、“S型”和“STRU F”命令一样，无论实际设置了何种FTP传输类型、模式和结构，并且不会导致为将来的命令更改这些设置。也就是说，该传输类型应仅在为该命令建立的数据连接期间设置。虽然发送的数据的内容可以看作是一系列行，但实现应该注意，没有定义最大行长度。实现应该准备好处理任意长的行。
The facts part of the specification would contain a series of "file facts" about the file or directory named on the same line. Typical information to be presented would include file size, last modification time, creation time, a unique identifier, and a file/directory flag.
规范的事实部分将包含一系列关于同一行中命名的文件或目录的“文件事实”。要显示的典型信息包括文件大小、上次修改时间、创建时间、唯一标识符和文件/目录标志。
The complete format for a successful reply to the MLSD command would be:
成功回复MLSD命令的完整格式为：
facts SP pathname CRLF facts SP pathname CRLF facts SP pathname CRLF ...
事实SP路径名CRLF事实SP路径名CRLF事实SP路径名CRLF。。。
Note that the format is intended for machine processing, not human viewing, and as such the format is very rigid. Implementations MUST NOT vary the format by, for example, inserting extra spaces for readability, replacing spaces by tabs, including header or title lines, or inserting blank lines, or in any other way alter this format. Exactly one space is always required after the set of facts (which may be empty). More spaces may be present on a line if, and only if, the pathname presented contains significant spaces. The set of facts must not contain any spaces anywhere inside it. Facts should be provided in each output line only if they both provide relevant information about the file named on the same line, and they are in the set requested by the user-PI. See section 7.9 (page 51). There is no requirement that the same set of facts be provided for each file, or that the facts presented occur in the same order for each file.
请注意，该格式用于机器处理，而不是人工查看，因此格式非常严格。实现不能改变格式，例如，插入额外的空格以提高可读性，用制表符（包括标题行或标题行）替换空格，或插入空行，或以任何其他方式改变此格式。事实集（可能为空）后始终需要正好一个空格。当且仅当显示的路径名包含有效空格时，一行上可能会出现更多空格。事实集不得包含任何空格。只有当事实都提供了关于同一行上命名的文件的相关信息，并且它们在用户PI请求的集合中时，才应该在每个输出行中提供事实。见第7.9节（第51页）。不要求为每个文件提供相同的事实集，也不要求为每个文件提供相同顺序的事实。
Many of the 4xy and 5xy responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. In particular, syntax errors can generate 500 or 501 replies. Giving a pathname that exists but is not a directory as the argument to a MLSD command generates a 501 reply. Giving a name that does not exist, or for which access permission (to obtain directory information as requested) is not granted will elicit a 550 reply. Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances.
STD 9 RFC 959[3]第4.2节中定义的许多4xy和5xy响应可响应MLST和MLSD命令。特别是，语法错误可以生成500或501个回复。将存在但不是目录的路径名作为MLSD命令的参数，将生成501回复。给出一个不存在的名称，或未授予访问权限（根据请求获取目录信息）的名称将得到550回复。在适当的情况下，也可以进行其他回复（530、553、503、504和任何4xy回复）。
An FTP implementation supporting the MLSx commands must be 8-bit clean. This is necessary in order to transmit UTF-8 encoded file names. This specification recommends the use of UTF-8 encoded file
支持MLSx命令的FTP实现必须是8位干净的。这是传输UTF-8编码文件名所必需的。本规范建议使用UTF-8编码文件
names. FTP implementations SHOULD use UTF-8 whenever possible to encourage the maximum inter-operability.
名字。FTP实施应尽可能使用UTF-8，以鼓励最大程度的互操作性。
File names are not restricted to UTF-8, however treatment of arbitrary character encodings is not specified by this standard. Applications are encouraged to treat non-UTF-8 encodings of file names as octet sequences.
文件名不限于UTF-8，但本标准未规定对任意字符编码的处理。鼓励应用程序将文件名的非UTF-8编码视为八位字节序列。
Note that this encoding is unrelated to that of the contents of the file, even if the file contains character data.
请注意，此编码与文件内容的编码无关，即使文件包含字符数据。
Further information about file name encoding for FTP may be found in "Internationalization of the File Transfer Protocol" [7].
有关FTP文件名编码的更多信息，请参见“文件传输协议的国际化”[7]。
The file name returned in the MLST response should be the same name as was specified in the MLST command, or, where TVFS is supported, a fully qualified TVFS path naming the same file. Where no argument was given to the MLST command, the server-PI may either include an empty file name in the response, or it may supply a name that refers to the current directory, if such a name is available. Where TVFS is supported, a fully qualified pathname of the current directory SHOULD be returned.
MLST响应中返回的文件名应与MLST命令中指定的名称相同，或者在支持TVFS的情况下，为同一文件命名的完全限定TVFS路径。如果没有为MLST命令提供参数，则服务器PI可以在响应中包含空文件名，或者提供引用当前目录的名称（如果该名称可用）。如果支持TVFS，则应返回当前目录的完全限定路径名。
File names returned in the output from an MLSD command SHOULD be unqualified names within the directory named, or the current directory if no argument was given. That is, the directory named in the MLSD command SHOULD NOT appear as a component of the file names returned.
MLSD命令输出中返回的文件名应该是名为的目录中的非限定名称，如果没有提供参数，则应该是当前目录中的非限定名称。也就是说，在MLSD命令中命名的目录不应显示为返回的文件名的组成部分。
If the server-FTP process is able, and the "type" fact is being returned, it MAY return in the MLSD response, an entry whose type is "cdir", which names the directory from which the contents of the listing were obtained. Where TVFS is supported, the name MAY be the fully qualified pathname of the directory, or MAY be any other pathname that is valid to refer to that directory from the current working directory of the server-FTP. Where more than one name exists, multiple of these entries may be returned. In a sense, the "cdir" entry can be viewed as a heading for the MLSD output. However, it is not required to be the first entry returned, and may occur anywhere within the listing.
如果服务器FTP进程是可启动的，并且正在返回“type”事实，则它可能会在MLSD响应中返回一个类型为“cdir”的条目，该条目命名从中获取列表内容的目录。在支持TVFS的情况下，该名称可以是目录的完全限定路径名，也可以是FTP服务器当前工作目录中有效引用该目录的任何其他路径名。如果存在多个名称，则可能会返回多个条目。在某种意义上，“cdir”条目可以被视为MLSD输出的标题。但是，它不需要是返回的第一个条目，并且可能出现在列表中的任何位置。
When TVFS is supported, a user-PI can refer to any file or directory in the listing by combining a type "cdir" name, with the appropriate name from the directory listing using the procedure defined in section 6.2.
当支持TVFS时，用户PI可以通过使用第6.2节中定义的过程，将类型“cdir”名称与目录列表中的适当名称组合，引用列表中的任何文件或目录。
Alternatively, whether TVFS is supported or not, the user-PI can issue a CWD command ([3]) giving a name of type "cdir" from the listing returned, and from that point reference the files returned in the MLSD response from which the cdir was obtained by using the file name components of the listing.
或者，无论是否支持TVFS，用户PI都可以发出CWD命令（[3]），给出返回列表中类型为“cdir”的名称，并从该点引用MLSD响应中返回的文件，通过使用列表的文件名组件从中获得cdir。
The "facts" for a file in a reply to a MLSx command consist of information about that file. The facts are a series of keyword=value pairs each followed by semi-colon (";") characters. An individual fact may not contain a semi-colon in its name or value. The complete series of facts may not contain the space character. See the definition or "RCHAR" in section 2.1 for a list of the characters that can occur in a fact value. Not all are applicable to all facts.
MLSx命令回复中文件的“事实”包括有关该文件的信息。事实是一系列关键字=值对，每对后面都跟有分号（；）字符。单个事实的名称或值中不得包含分号。完整的事实系列可能不包含空格字符。有关事实值中可能出现的字符列表，请参见第2.1节中的定义或“RCHAR”。并非所有这些都适用于所有事实。
A sample of a typical series of facts would be: (spread over two lines for presentation here only)
一系列典型事实的一个样本是：（在这里仅用于陈述的两行中展开）
size=4161;lang=en-US;modify=19970214165800;create=19961001124534;
type=file;x.myfact=foo,bar;
size=4161;lang=en-US;modify=19970214165800;create=19961001124534;
type=file;x.myfact=foo,bar;
This document defines a standard set of facts as follows:
本文件定义了一组标准事实，如下所示：
size -- Size in octets modify -- Last modification time create -- Creation time type -- Entry type unique -- Unique id of file/directory perm -- File permissions, whether read, write, execute is allowed for the login id. lang -- Language of the file name per IANA [11] registry. media-type -- MIME media-type of file contents per IANA registry. charset -- Character set per IANA registry (if not UTF-8)
大小--大小（以八位字节为单位）修改--上次修改时间创建--创建时间类型--条目类型唯一--文件/目录perm的唯一id--文件权限，登录id是否允许读、写、执行。lang--每个IANA[11]注册表文件名的语言。媒体类型--每个IANA注册表中文件内容的MIME媒体类型。字符集--每个IANA注册表的字符集（如果不是UTF-8）
Fact names are case-insensitive. Size, size, SIZE, and SiZe are the same fact.
事实名称不区分大小写。大小、大小、大小和大小是相同的事实。
Further operating system specific keywords could be specified by using the IANA operating system name as a prefix (examples only):
可以使用IANA操作系统名称作为前缀来指定更多操作系统特定的关键字（仅示例）：
OS/2.ea -- OS/2 extended attributes
MACOS.rf -- MacIntosh resource forks
UNIX.mode -- Unix file modes (permissions)
OS/2.ea -- OS/2 extended attributes
MACOS.rf -- MacIntosh resource forks
UNIX.mode -- Unix file modes (permissions)
Implementations may define keywords for experimental, or private use. All such keywords MUST begin with the two character sequence "x.". As type names are case independent, "x." and "X." are equivalent. For example:
实现可以定义用于实验或私人用途的关键字。所有这些关键字必须以两个字符序列“x”开头。由于类型名是独立于大小写的，“x.”和“x.”是等价的。例如：
x.ver -- Version information x.desc -- File description x.type -- File type
x、 版本信息x.desc文件描述x.type文件类型
The type fact needs a special description. Part of the problem with current practices is deciding when a file is a directory. If it is a directory, is it the current directory, a regular directory, or a parent directory? The MLST specification makes this unambiguous using the type fact. The type fact given specifies information about the object listed on the same line of the MLST response.
类型事实需要特殊描述。当前做法的部分问题在于决定文件何时为目录。如果是目录，它是当前目录、常规目录还是父目录？MLST规范使用类型事实明确了这一点。给定的类型事实指定有关MLST响应的同一行上列出的对象的信息。
Five values are possible for the type fact:
类型事实可能有五个值：
file -- a file entry cdir -- the listed directory pdir -- a parent directory dir -- a directory or sub-directory OS.name=type -- an OS or file system dependent file type
file--文件条目cdir--列出的目录pdir--父目录dir--目录或子目录OS.name=type--依赖于OS或文件系统的文件类型
The syntax is defined to be:
语法定义为：
type-fact = type-label "=" type-val
type-label = "Type"
type-val = "File" / "cdir" / "pdir" / "dir" /
os-type
type-fact = type-label "=" type-val
type-label = "Type"
type-val = "File" / "cdir" / "pdir" / "dir" /
os-type
The value of the type fact (the "type-val") is a case independent string.
类型事实（“类型val”）的值是一个大小写无关的字符串。
The presence of the type=file fact indicates the listed entry is a file containing non-system data. That is, it may be transferred from one system to another of quite different characteristics, and perhaps still be meaningful.
type=file事实表示列出的条目是包含非系统数据的文件。也就是说，它可以从一个系统转移到另一个具有完全不同特征的系统，并且可能仍然有意义。
The type=cdir fact indicates the listed entry contains a pathname of the directory whose contents are listed. An entry of this type will only be returned as a part of the result of an MLSD command when the
type=cdir事实表示列出的条目包含列出其内容的目录的路径名。当
type fact is included, and provides a name for the listed directory, and facts about that directory. In a sense, it can be viewed as representing the title of the listing, in a machine friendly format. It may appear at any point of the listing, it is not restricted to appearing at the start, though frequently may do so, and may occur multiple times. It MUST NOT be included if the type fact is not included, or there would be no way for the user-PI to distinguish the name of the directory from an entry in the directory.
包含类型fact，并提供所列目录的名称以及有关该目录的事实。在某种意义上，它可以被视为以机器友好的格式表示列表的标题。它可能出现在列表的任何一点上，但并不局限于出现在开始处，尽管可能经常出现，并且可能出现多次。如果没有包含类型事实，则不能包含它，否则用户PI将无法区分目录名称和目录中的条目。
Where TVFS is supported by the server-FTP, this name may be used to construct pathnames with which to refer to the files and directories returned in the same MLSD output (see section 6.2). These pathnames are only expected to work when the server-PI's position in the NVFS file tree is the same as its position when the MLSD command was issued, unless a fully qualified pathname results.
当服务器FTP支持TVFS时，此名称可用于构造路径名，用于引用同一MLSD输出中返回的文件和目录（请参阅第6.2节）。只有当服务器PI在NVFS文件树中的位置与其在发出MLSD命令时的位置相同时，这些路径名才能工作，除非产生完全限定的路径名。
Where TVFS is not supported, the only defined semantics associated with a "type=cdir" entry are that, provided the current working directory of the server-PI has not been changed, a pathname of type "cdir" may be used as an argument to a CWD command, which will cause the current directory of the server-PI to change so that the directory that was listed in its current working directory.
在不支持TVFS的情况下，与“type=cdir”项关联的唯一定义语义是，如果服务器PI的当前工作目录未更改，则可以将“cdir”类型的路径名用作CWD命令的参数，这将导致服务器PI的当前目录发生更改，从而使其当前工作目录中列出的目录发生更改。
If present, the type=dir entry gives the name of a directory. Such an entry typically cannot be transferred from one system to another using RETR, etc., but should (permissions permitting) be able to be the object of an MLSD command.
如果存在，type=dir条目给出目录的名称。这样的条目通常不能使用RETR等从一个系统传输到另一个系统，但应该（权限允许）能够成为MLSD命令的对象。
If present, which will occur only in the response to a MLSD command when the type fact is included, the type=pdir entry represents a pathname of the parent directory of the listed directory. As well as having the properties of a type=dir, a CWD command that uses the pathname from this entry should change the user to a parent directory of the listed directory. If the listed directory is the current directory, a CDUP command may also have the effect of changing to the named directory. User-FTP processes should note not all responses will include this information, and that some systems may provide multiple type=pdir responses.
如果存在，则type=pdir条目表示所列目录的父目录的路径名，该条目仅在包含type事实时响应MLSD命令时出现。除了具有type=dir的属性外，使用此条目中的路径名的CWD命令还应将用户更改为列出目录的父目录。如果列出的目录是当前目录，CDUP命令也可能具有更改为命名目录的效果。用户FTP进程应注意，并非所有响应都包含此信息，而且某些系统可能会提供多个type=pdir响应。
Where TVFS is supported, a "type=pdir" name may be a relative pathname, or a fully qualified pathname. A relative pathname will be relative to the directory being listed, not to the current directory of the server-PI at the time.
在支持TVFS的情况下，“type=pdir”名称可以是相对路径名，也可以是完全限定的路径名。相对路径名将与列出的目录相对，而不是与当时服务器PI的当前目录相对。
For the purposes of this type value, a "parent directory" is any directory in which there is an entry of type=dir that refers to the directory in which the type=pdir entity was found. Thus it is not required that all entities with type=pdir refer to the same directory. The "unique" fact (if supported and supplied) can be used to determine whether there is a relationship between the type=pdir entries or not.
出于此类型值的目的，“父目录”是任何目录，其中有一个type=dir条目，该条目引用了在其中找到type=pdir实体的目录。因此，不要求type=pdir的所有实体都引用同一目录。“唯一”事实（如果支持并提供）可用于确定type=pdir条目之间是否存在关系。
Files types that are specific to a specific operating system, or file system, can be encoded using the "OS." type names. The format is:
特定于特定操作系统或文件系统的文件类型可以使用“OS.”类型名称进行编码。格式为：
os-type = "OS." os-name "=" os-kind
os-name = <an IANA registered operating system name>
os-kind = token
os-type = "OS." os-name "=" os-kind
os-name = <an IANA registered operating system name>
os-kind = token
The "os-name" indicates the specific system type that supports the particular localtype. OS specific types are registered by the IANA using the procedures specified in section 10. The "os-kind" provides the system dependent information as to the type of the file listed. The os-name and os-kind strings in an os-type are case independent. "OS.unix=block" and "OS.Unix=BLOCK" represent the same type (or would, if such a type were registered.)
“os名称”表示支持特定localtype的特定系统类型。IANA使用第10节规定的程序注册特定于操作系统的类型。“os种类”提供与所列文件类型相关的系统相关信息。os类型中的os名称和os种类字符串与大小写无关。“OS.unix=block”和“OS.unix=block”表示相同的类型（如果注册了此类类型，则表示相同的类型）
Note: Where the underlying system supports a file type that is essentially an indirect pointer to another file, the NVFS representation of that type should normally be to represent the file that the reference indicates. That is, the underlying basic file will appear more than once in the NVFS, each time with the "unique" fact (see immediately following section) containing the same value, indicating that the same file is represented by all such names. User-PIs transferring the file need then transfer it only once, and then insert their own form of indirect reference to construct alternate names where desired, or perhaps even copy the local file if that is the only way to provide two names with the same content. A file which would be a reference to another file, if only the other file actually existed, may be represented in any OS dependent manner appropriate, or not represented at all.
注意：如果基础系统支持的文件类型本质上是指向另一个文件的间接指针，则该类型的NVFS表示通常应表示引用所指示的文件。也就是说，基础基本文件将在NVFS中多次出现，每次都带有包含相同值的“唯一”事实（请参见下一节），这表示相同的文件由所有此类名称表示。传输文件的用户PI只需传输一次文件，然后插入他们自己的间接引用形式，在需要的地方构造备用名称，或者甚至复制本地文件，如果这是提供两个具有相同内容的名称的唯一方法。如果只有另一个文件实际存在，则作为对另一个文件的引用的文件可以以任何适当的依赖于操作系统的方式表示，或者根本不表示。
Where a file is such that it may validly, and sensibly, treated by the server-PI as being of more than one of the above types, then multiple entries should be returned, each with its own "Type" fact of the appropriate type, and each containing the same pathname. This may occur, for example, with a structured file, which may contain sub-files, and where the server-PI permits the structured file to be
如果一个文件可以被服务器PI有效地、合理地视为上述类型中的一种以上，那么应该返回多个条目，每个条目都有其自己的适当类型的“类型”事实，并且每个条目都包含相同的路径名。例如，这可能发生在结构化文件中，该结构化文件可能包含子文件，并且服务器PI允许该结构化文件被保存
treated as a unit, or treated as a directory allowing the sub-files within it to be referenced. When this is done, the pathname returned with each entry MUST be identical to the others representing the same file.
视为一个单元，或视为一个目录，允许引用其中的子文件。完成此操作后，随每个条目返回的路径名必须与代表同一文件的其他条目相同。
The unique fact is used to present a unique identifier for a file or directory in the NVFS accessed via a server-FTP process. The value of this fact should be the same for any number of pathnames that refer to the same underlying file. The fact should have different values for names that reference distinct files. The mapping between files, and unique fact tokens should be maintained, and remain consistent, for at least the lifetime of the control connection from user-PI to server-PI.
唯一事实用于表示通过服务器FTP进程访问的NVFS中的文件或目录的唯一标识符。对于引用同一基础文件的任意数量的路径名，此事实的值应相同。对于引用不同文件的名称，事实应具有不同的值。至少在从用户PI到服务器PI的控制连接的生命周期内，应该维护文件和唯一事实标记之间的映射，并保持一致。
unique-fact = "Unique" "=" token
唯一事实=“唯一”“=”标记
This fact would be expected to be used by server-FTPs whose host system allows things such as symbolic links so that the same file may be represented in more than one directory on the server. The only conclusion that should be drawn is that if two different names each have the same value for the unique fact, they refer to the same underlying object. The value of the unique fact (the token) should be considered an opaque string for comparison purposes, and is a case dependent value. The tokens "A" and "a" do not represent the same underlying object.
这一事实预计将被服务器FTP使用，因为服务器FTP的主机系统允许诸如符号链接之类的东西，以便同一文件可以在服务器上的多个目录中表示。应该得出的唯一结论是，如果两个不同的名称对唯一事实都具有相同的值，则它们引用相同的基础对象。出于比较目的，唯一事实（标记）的值应被视为不透明字符串，并且是大小写相关的值。标记“A”和“A”不代表相同的底层对象。
The modify fact is used to determine the last time the content of the file (or directory) indicated was modified. Any change of substance to the file should cause this value to alter. That is, if a change is made to a file such that the results of a RETR command would differ, then the value of the modify fact should alter. User-PIs should not assume that a different modify fact value indicates that the file contents are necessarily different than when last retrieved. Some systems may alter the value of the modify fact for other reasons, though this is discouraged wherever possible. Also a file may alter, and then be returned to its previous content, which would often be indicated as two incremental alterations to the value of the modify fact.
修改事实用于确定上次修改指定文件（或目录）内容的时间。对文件内容的任何更改都会导致该值发生更改。也就是说，如果对文件进行更改，使得RETR命令的结果不同，那么修改事实的值应该改变。用户PI不应假定不同的修改事实值表示文件内容必然与上次检索时不同。有些系统可能会出于其他原因更改修改事实的值，尽管在可能的情况下不鼓励这样做。此外，文件可能会更改，然后返回到其以前的内容，这通常表示为对修改事实值的两次增量更改。
For directories, this value should alter whenever a change occurs to the directory such that different file names would (or might) be included in MLSD output of that directory.
对于目录，每当目录发生更改时，该值都应该更改，以便不同的文件名将（或可能）包含在该目录的MLSD输出中。
modify-fact = "Modify" "=" time-val
modify fact=“modify”“=”时间值
The create fact indicates when a file, or directory, was first created. Exactly what "creation" is for this purpose is not specified here, and may vary from server to server. About all that can be said about the value returned is that it can never indicate a later time than the modify fact.
“创建”事实指示文件或目录首次创建的时间。此处未指定用于此目的的“创建”的确切内容，可能因服务器而异。关于返回的值，我们只能说，它永远不能指示比修改事实晚的时间。
create-fact = "Create" "=" time-val
创建事实=“创建”“=”时间值
Implementation Note: Implementors of this fact on UNIX(TM) systems should note that the unix "stat" "st_ctime" field does not give creation time, and that unix file systems do not record creation time at all. Unix (and POSIX) implementations will normally not include this fact.
实现说明：在UNIX（TM）系统上实现这一事实的人应该注意，UNIX“stat”“st_ctime”字段不提供创建时间，UNIX文件系统根本不记录创建时间。Unix（和POSIX）实现通常不包括这一事实。
The perm fact is used to indicate access rights the current FTP user has over the object listed. Its value is always an unordered sequence of alphabetic characters.
perm事实用于指示当前FTP用户对所列对象的访问权限。它的值始终是字母字符的无序序列。
perm-fact = "Perm" "=" *pvals
pvals = "a" / "c" / "d" / "e" / "f" /
"l" / "m" / "p" / "r" / "w"
perm-fact = "Perm" "=" *pvals
pvals = "a" / "c" / "d" / "e" / "f" /
"l" / "m" / "p" / "r" / "w"
There are ten permission indicators currently defined. Many are meaningful only when used with a particular type of object. The indicators are case independent, "d" and "D" are the same indicator.
当前定义了十个权限指示符。许多仅在与特定类型的对象一起使用时才有意义。指标是独立于大小写的，“d”和“d”是相同的指标。
The "a" permission applies to objects of type=file, and indicates that the APPE (append) command may be applied to the file named.
“a”权限适用于类型=file的对象，并指示APPE（append）命令可应用于名为的文件。
The "c" permission applies to objects of type=dir (and type=pdir, type=cdir). It indicates that files may be created in the directory named. That is, that a STOU command is likely to succeed, and that STOR and APPE commands might succeed if the file named did not previously exist, but is to be created in the directory object that has the "c" permission. It also indicates that the RNTO command is likely to succeed for names in the directory.
“c”权限适用于类型为dir（类型为pdir，类型为cdir）的对象。它表示可以在名为的目录中创建文件。也就是说，STOU命令可能会成功，如果名为的文件以前不存在，但要在具有“c”权限的目录对象中创建，则STOR和APPE命令可能会成功。它还表明，对于目录中的名称，RNTO命令可能会成功。
The "d" permission applies to all types. It indicates that the object named may be deleted, that is, that the RMD command may be applied to it if it is a directory, and otherwise that the DELE command may be applied to it.
“d”权限适用于所有类型。它表示可以删除名为的对象，也就是说，如果该对象是目录，则可以对其应用RMD命令，否则可以对其应用DELE命令。
The "e" permission applies to the directory types. When set on an object of type=dir, type=cdir, or type=pdir it indicates that a CWD
“e”权限适用于目录类型。在类型为dir、类型为cdir或类型为pdir的对象上设置时，表示CWD
command naming the object should succeed, and the user should be able to enter the directory named. For type=pdir it also indicates that the CDUP command may succeed (if this particular pathname is the one to which a CDUP would apply.)
命令命名对象应该成功，并且用户应该能够进入名为的目录。对于type=pdir，它还指示CDUP命令可能会成功（如果此特定路径名将应用CDUP）
The "f" permission for objects indicates that the object named may be renamed - that is, may be the object of an RNFR command.
对象的“f”权限表示可以重命名名为的对象，即可能是RNFR命令的对象。
The "l" permission applies to the directory file types, and indicates that the listing commands, LIST, NLST, and MLSD may be applied to the directory in question.
“l”权限适用于目录文件类型，并表示列表命令、列表、NLST和MLSD可应用于相关目录。
The "m" permission applies to directory types, and indicates that the MKD command may be used to create a new directory within the directory under consideration.
“m”权限适用于目录类型，并指示MKD命令可用于在考虑中的目录内创建新目录。
The "p" permission applies to directory types, and indicates that objects in the directory may be deleted, or (stretching naming a little) that the directory may be purged. Note: it does not indicate that the RMD command may be used to remove the directory named itself, the "d" permission indicator indicates that.
“p”权限适用于目录类型，并指示目录中的对象可能会被删除，或者（稍微扩展命名）目录可能会被清除。注意：这并不表示可以使用RMD命令删除名为自身的目录，“d”权限指示符表示。
The "r" permission applies to type=file objects, and for some systems, perhaps to other types of objects, and indicates that the RETR command may be applied to that object.
“r”权限适用于type=file对象，对于某些系统，可能适用于其他类型的对象，并指示RETR命令可能应用于该对象。
The "w" permission applies to type=file objects, and for some systems, perhaps to other types of objects, and indicates that the STOR command may be applied to the object named.
“w”权限适用于type=file对象，对于某些系统，可能适用于其他类型的对象，并指示STOR命令可能应用于名为的对象。
Note: That a permission indicator is set can never imply that the appropriate command is guaranteed to work -- just that it might. Other system specific limitations, such as limitations on available space for storing files, may cause an operation to fail, where the permission flags may have indicated that it was likely to succeed. The permissions are a guide only.
注意：权限指示符的设置绝不意味着适当的命令可以保证工作——只是它可能会工作。其他特定于系统的限制，例如对存储文件的可用空间的限制，可能会导致操作失败，其中权限标志可能表明操作可能成功。权限仅供参考。
Implementation note: The permissions are described here as they apply to FTP commands. They may not map easily into particular permissions available on the server's operating system. Servers are expected to synthesize these permission bits from the permission information available from operating system. For example, to correctly determine whether the "D" permission bit should be set on a directory for a server running on the UNIX(TM) operating system, the server should check that the directory named is empty, and that the user has write permission on both the directory under consideration, and its parent directory.
实现说明：此处描述了应用于FTP命令的权限。它们可能无法轻松映射到服务器操作系统上可用的特定权限。服务器需要从操作系统提供的权限信息中综合这些权限位。例如，要正确确定是否应在UNIX（TM）操作系统上运行的服务器的目录上设置“D”权限位，服务器应检查名为的目录是否为空，以及用户是否对所考虑的目录及其父目录都具有写权限。
Some systems may have more specific permissions than those listed here, such systems should map those to the flags defined as best they are able. Other systems may have only more broad access controls. They will generally have just a few possible permutations of permission flags, however they should attempt to correctly represent what is permitted.
某些系统可能比此处列出的系统具有更为特定的权限，此类系统应将这些权限映射到定义为最佳权限的标志。其他系统可能只有更广泛的访问控制。它们通常只有几个可能的权限标志排列，但是它们应该尝试正确地表示允许的内容。
The lang fact describes the natural language of the file name for use in display purposes. Values used here should be taken from the language registry of the IANA. See [12] for the syntax, and procedures, related to language tags.
lang事实描述了用于显示目的的文件名的自然语言。此处使用的值应取自IANA的语言注册表。有关语言标记的语法和过程，请参见[12]。
lang-fact = "Lang" "=" token
lang fact=“lang”“=”标记
Server-FTP implementations MUST NOT guess language values. Language values must be determined in an unambiguous way such as file system tagging of language or by user configuration. Note that the lang fact provides no information at all about the content of a file, only about the encoding of its name.
服务器FTP实现不能猜测语言值。必须以明确的方式确定语言值，如文件系统标记语言或用户配置。请注意，lang事实根本不提供有关文件内容的信息，只提供有关文件名编码的信息。
The size fact applies to non-directory file types and should always reflect the approximate size of the file. This should be as accurate as the server can make it, without going to extraordinary lengths, such as reading the entire file. The size is expressed in units of octets of data in the file.
大小事实适用于非目录文件类型，并且应始终反映文件的大致大小。这应该尽可能精确，而不需要太长的时间，比如读取整个文件。大小以文件中数据的八位字节为单位表示。
Given limitations in some systems, Client-FTP implementations must understand this size may not be precise and may change between the time of a MLST and RETR operation.
鉴于某些系统中的限制，客户端FTP实现必须了解此大小可能不精确，并且可能在MLST和RETR操作之间发生变化。
Clients that need highly accurate size information for some particular reason should use the SIZE command as defined in section 4. The most common need for this accuracy is likely to be in conjunction with the REST command described in section 5. The size fact, on the other hand, should be used for purposes such as indicating to a human user the approximate size of the file to be transferred, and perhaps to give an idea of expected transfer completion time.
出于某些特殊原因需要高度准确的尺寸信息的客户端应使用第4节中定义的size命令。这种精度的最常见需求可能与第5节中描述的REST命令结合使用。另一方面，大小事实应该用于诸如向人类用户指示要传输的文件的大致大小的目的，并且可能是为了给出预期传输完成时间的概念。
size-fact = "Size" "=" 1*DIGIT
size-fact = "Size" "=" 1*DIGIT
The media-type fact represents the IANA media type of the file named, and applies only to non-directory types. The list of values used must follow the guidelines set by the IANA registry.
媒体类型事实表示名为的文件的IANA媒体类型，仅适用于非目录类型。使用的值列表必须遵循IANA注册表设置的准则。
media-type = "Media-Type" "=" <per IANA guidelines>
media-type = "Media-Type" "=" <per IANA guidelines>
Server-FTP implementations MUST NOT guess media type values. Media type values must be determined in an unambiguous way such as file system tagging of media-type or by user configuration. This fact gives information about the content of the file named. Both the primary media type, and any appropriate subtype should be given, separated by a slash "/" as is traditional.
服务器FTP实现不得猜测媒体类型值。媒体类型值必须以明确的方式确定，例如媒体类型的文件系统标记或用户配置。此事实提供了有关名为的文件内容的信息。主媒体类型和任何适当的子类型都应按传统方式用斜线“/”分隔。
The charset fact provides the IANA character set name, or alias, for the encoded pathnames in a MLSx response. The default character set is UTF-8 unless specified otherwise. FTP implementations SHOULD use UTF-8 if possible to encourage maximum inter-operability. The value of this fact applies to the pathname only, and provides no information about the contents of the file.
字符集事实为MLSx响应中的编码路径名提供IANA字符集名称或别名。除非另有规定，否则默认字符集为UTF-8。FTP实施应尽可能使用UTF-8，以鼓励最大程度的互操作性。此事实的值仅适用于路径名，不提供有关文件内容的信息。
charset-type = "Charset" "=" token
charset type=“charset”“=”令牌
Servers are not required to support any particular set of the available facts. However, servers SHOULD, if conceivably possible, support at least the type, perm, size, unique, and modify facts.
服务器不需要支持任何特定的可用事实集。然而，如果可能的话，服务器应该至少支持类型、perm、大小、唯一性和修改事实。
By using an system dependent fact, or a local fact, a server-PI may communicate to the user-PI information about the file named that is peculiar to the underlying file system.
通过使用依赖于系统的事实或本地事实，服务器PI可以向用户PI传递底层文件系统特有的关于名为的文件的信息。
System dependent fact names are labeled by prefixing a label identifying the specific information returned by the name of the appropriate operating system from the IANA maintained list of operating system names.
通过在IANA维护的操作系统名称列表中的相应操作系统名称返回的特定信息的前缀中添加标签来标记系统相关事实名称。
The value of an OS dependent fact may be whatever is appropriate to convey the information available. It must be encoded as a "token" as defined in section 2.1 however.
依赖操作系统的事实的价值可以是任何适合于传达可用信息的东西。但是，必须将其编码为第2.1节中定义的“标记”。
In order to allow reliable inter-operation between users of system dependent facts, the IANA will maintain a registry of system dependent fact names, their syntax, and the interpretation to be given to their values. Registrations of system dependent facts are to be accomplished according to the procedures of section 10.
为了允许系统相关事实的用户之间进行可靠的交互操作，IANA将维护系统相关事实名称、其语法以及对其值的解释的注册表。系统相关事实的登记应按照第10节的程序完成。
Implementations may also make available other facts of their own choosing. As the method of interpretation of such information will generally not be widely understood, server-PIs should be aware that clients will typically ignore any local facts provided. As there is no registration of locally defined facts, it is entirely possible that different servers will use the same local fact name to provide vastly different information. Hence user-PIs should be hesitant about making any use of any information in a locally defined fact without some other specific assurance that the particular fact is one that they do comprehend.
实现还可以提供他们自己选择的其他事实。由于这些信息的解释方法通常不会被广泛理解，服务器PI应该知道客户端通常会忽略提供的任何本地事实。由于没有本地定义事实的注册，不同的服务器完全可能使用相同的本地事实名称来提供截然不同的信息。因此，用户PI应该在没有其他特定保证的情况下犹豫是否使用本地定义事实中的任何信息，即特定事实是他们确实理解的。
Local fact names all begin with the sequence "X.". The rest of the name is a "token" (see section 2.1). The value of a local fact can be anything at all, provided it can be encoded as a "token".
本地事实名称都以序列“X”开头。名称的其余部分是“标记”（见第2.1节）。本地事实的值可以是任何东西，只要它可以被编码为“令牌”。
The following examples are all taken from dialogues between existing FTP clients and servers. Because of this, not all possible variations of possible response formats are shown in the examples. This should not be taken as limiting the options of other server implementors. Where the examples show OS dependent information, that is to be treated as being purely for the purposes of demonstration of some possible OS specific information that could be defined. As at the time of the writing of this document, no OS specific facts or file types have been defined, the examples shown here should not be treated as in any way to be preferred over other possible similar definitions. Consult the IANA registries to determine what types and facts have been defined. Finally also beware that as the examples shown are taken from existing implementations, coded before this document was completed, the possibility of variations between the text of this document and the examples exists. In any such case of inconsistency, the example is to be treated as incorrect.
以下示例均取自现有FTP客户端和服务器之间的对话。因此，示例中并未显示可能响应格式的所有可能变化。这不应被视为限制其他服务器实现者的选项。如果示例显示了与操作系统相关的信息，则应将其视为纯粹用于演示可定义的某些可能的操作系统特定信息。在编写本文档时，尚未定义任何特定于操作系统的事实或文件类型，此处所示的示例不应被视为优先于其他可能的类似定义。请咨询IANA注册中心，以确定已定义的类型和事实。最后还要注意，由于所示示例取自现有实现，在本文档完成之前进行了编码，因此本文档文本与示例之间存在差异的可能性。在任何此类不一致的情况下，该示例将被视为不正确。
In the examples shown, only relevant commands and responses have been included. This is not to imply that other commands (including authentication, directory modification, PORT or PASV commands, or similar) would not be present in an actual connection, or were not, in fact, actually used in the examples before editing. Note also that the formats shown are those that are transmitted between client
在所示示例中，仅包含相关命令和响应。这并不意味着其他命令（包括身份验证、目录修改、端口或PASV命令或类似命令）不会出现在实际连接中，或者实际上在编辑之前的示例中没有实际使用。还请注意，显示的格式是在客户端之间传输的格式
and server, not formats that would normally ever be reported to the user of the client.
和服务器，而不是通常向客户端用户报告的格式。
C> PWD
S> 257 "/tmp" is current directory.
C> MLst cap60.pl198.tar.gz
S> 250- Listing cap60.pl198.tar.gz
S> Type=file;Size=1024990;Perm=r; /tmp/cap60.pl198.tar.gz
S> 250 End
C> PWD
S> 257 "/tmp" is current directory.
C> MLst cap60.pl198.tar.gz
S> 250- Listing cap60.pl198.tar.gz
S> Type=file;Size=1024990;Perm=r; /tmp/cap60.pl198.tar.gz
S> 250 End
The client first asked to be told the current directory of the server. This was purely for the purposes of clarity of this example. The client then requested facts about a specific file. The server returned the "250-" first control-response line, followed by a single line of facts about the file, followed by the terminating "250 " line. The text on the control-response line and the terminating line can be anything the server decides to send. Notice that the fact line is indented by a single space. Notice also that there are no spaces in the set of facts returned, until the single space before the file name. The file name returned on the fact line is a fully qualified pathname of the file listed. The facts returned show that the line refers to a file, that file contains approximately 1024990 bytes, though more or less than that may be transferred if the file is retrieved, and a different number may be required to store the file at the client's file store, and the connected user has permission to retrieve the file but not to do anything else particularly interesting.
客户端首先要求被告知服务器的当前目录。这纯粹是为了澄清本示例。然后，客户要求提供有关特定文件的事实。服务器返回“250-”第一个控件响应行，然后是关于文件的一行事实，最后是终止的“250”行。控制响应行和终止行上的文本可以是服务器决定发送的任何内容。请注意，事实行由单个空格缩进。还要注意，在返回的事实集合中没有空格，直到文件名前面有一个空格。事实行上返回的文件名是所列文件的完全限定路径名。返回的事实表明，该行引用了一个文件，该文件包含大约1024990个字节，但如果检索该文件，可能会传输更多或更少的字节，并且在客户端的文件存储区存储该文件可能需要不同的数字，连接的用户有权检索文件，但不做任何其他特别有趣的事情。
C> PWD
S> 257 "/" is current directory.
C> MLst tmp
S> 250- Listing tmp
S> Type=dir;Modify=19981107085215;Perm=el; /tmp
S> 250 End
C> PWD
S> 257 "/" is current directory.
C> MLst tmp
S> 250- Listing tmp
S> Type=dir;Modify=19981107085215;Perm=el; /tmp
S> 250 End
Again the PWD is just for the purposes of demonstration for the example. The MLST fact line this time shows that the file listed is a directory, that it was last modified at 08:52:15 on the 7th of November, 1998 UTC, and that the user has permission to enter the directory, and to list its contents, but not to modify it in any way. Again, the fully qualified pathname of the directory listed is given.
同样，PWD仅用于示例的演示目的。这次MLST事实行显示列出的文件是一个目录，最后一次修改是在UTC 1998年11月7日08:52:15，用户有权进入该目录并列出其内容，但无权以任何方式修改。同样，给出了所列目录的完全限定路径名。
C> MLSD tmp
S> 150 BINARY connection open for MLSD tmp
D> Type=cdir;Modify=19981107085215;Perm=el; tmp
D> Type=cdir;Modify=19981107085215;Perm=el; /tmp
D> Type=pdir;Modify=19990112030508;Perm=el; ..
D> Type=file;Size=25730;Modify=19940728095854;Perm=; capmux.tar.z
D> Type=file;Size=1830;Modify=19940916055648;Perm=r; hatch.c
D> Type=file;Size=25624;Modify=19951003165342;Perm=r; MacIP-02.txt
D> Type=file;Size=2154;Modify=19950501105033;Perm=r; uar.netbsd.patch
D> Type=file;Size=54757;Modify=19951105101754;Perm=r; iptnnladev.1.0.sit.hqx
D> Type=file;Size=226546;Modify=19970515023901;Perm=r; melbcs.tif
D> Type=file;Size=12927;Modify=19961025135602;Perm=r; tardis.1.6.sit.hqx
D> Type=file;Size=17867;Modify=19961025135602;Perm=r; timelord.1.4.sit.hqx
D> Type=file;Size=224907;Modify=19980615100045;Perm=r; uar.1.2.3.sit.hqx
D> Type=file;Size=1024990;Modify=19980130010322;Perm=r; cap60.pl198.tar.gz
S> 226 MLSD completed
C> MLSD tmp
S> 150 BINARY connection open for MLSD tmp
D> Type=cdir;Modify=19981107085215;Perm=el; tmp
D> Type=cdir;Modify=19981107085215;Perm=el; /tmp
D> Type=pdir;Modify=19990112030508;Perm=el; ..
D> Type=file;Size=25730;Modify=19940728095854;Perm=; capmux.tar.z
D> Type=file;Size=1830;Modify=19940916055648;Perm=r; hatch.c
D> Type=file;Size=25624;Modify=19951003165342;Perm=r; MacIP-02.txt
D> Type=file;Size=2154;Modify=19950501105033;Perm=r; uar.netbsd.patch
D> Type=file;Size=54757;Modify=19951105101754;Perm=r; iptnnladev.1.0.sit.hqx
D> Type=file;Size=226546;Modify=19970515023901;Perm=r; melbcs.tif
D> Type=file;Size=12927;Modify=19961025135602;Perm=r; tardis.1.6.sit.hqx
D> Type=file;Size=17867;Modify=19961025135602;Perm=r; timelord.1.4.sit.hqx
D> Type=file;Size=224907;Modify=19980615100045;Perm=r; uar.1.2.3.sit.hqx
D> Type=file;Size=1024990;Modify=19980130010322;Perm=r; cap60.pl198.tar.gz
S> 226 MLSD completed
In this example notice that there is no leading space on the fact lines returned over the data connection. Also notice that two lines of "type=cdir" have been given. These show two alternate names for the directory listed, one a fully qualified pathname, and the other a local name relative to the servers current directory when the MLSD was performed. Note that all other file names in the output are relative to the directory listed, though the server could, if it chose, give a fully qualified pathname for the "type=pdir" line. This server has chosen not to. The other files listed present a fairly boring set of files that are present in the listed directory. Note that there is no particular order in which they are listed. They are not sorted by file name, by size, or by modify time. Note also that the "perm" fact has an empty value for the file "capmux.tar.z" indicating that the connected user has no permissions at all for that file. This server has chosen to present the "cdir" and "pdir" lines before the lines showing the content of the directory, it is not required to do so. The "size" fact does not provide any meaningful information for a directory, so is not included in the fact lines for the directory types shown.
在本例中，请注意，通过数据连接返回的事实行上没有前导空格。还要注意，已经给出了两行“type=cdir”。它们为列出的目录显示两个备用名称，一个是完全限定的路径名，另一个是执行MLSD时相对于服务器当前目录的本地名称。请注意，输出中的所有其他文件名都与列出的目录相关，但如果服务器选择，它可以为“type=pdir”行提供完全限定的路径名。此服务器已选择不执行此操作。列出的其他文件显示了列出的目录中存在的一组相当无聊的文件。请注意，它们没有特定的列出顺序。它们不按文件名、大小或修改时间排序。还要注意，“perm”事实对于文件“capmux.tar.z”有一个空值，表示连接的用户对该文件没有任何权限。此服务器已选择在显示目录内容的行之前显示“cdir”和“pdir”行，不需要这样做。“大小”事实没有为目录提供任何有意义的信息，因此不包括在所示目录类型的事实行中。
C> MLst test
S> 250- Listing test
S> Type=dir;Perm=el;Unique=keVO1+ZF4 test
S> 250 End
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
D> Type=OS.unix=chr-13/29;Perm=;Unique=keVO1+5G4; device
D> Type=OS.unix=blk-11/108;Perm=;Unique=keVO1+6G4; block
D> Type=file;Perm=awr;Unique=keVO1+8G4; writable
D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; promiscuous
D> Type=dir;Perm=;Unique=keVO1+1t2; no-exec
D> Type=file;Perm=r;Unique=keVO1+EG4; two words
D> Type=file;Perm=r;Unique=keVO1+IH4; leading space
D> Type=file;Perm=r;Unique=keVO1+1G4; file1
D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; incoming
D> Type=file;Perm=r;Unique=keVO1+1G4; file2
D> Type=file;Perm=r;Unique=keVO1+1G4; file3
D> Type=file;Perm=r;Unique=keVO1+1G4; file4
S> 226 MLSD completed
C> MLSD test/incoming
S> 150 BINARY connection open for MLSD test/incoming
D> Type=cdir;Perm=cpmel;Unique=keVO1+7G4; test/incoming
D> Type=pdir;Perm=el;Unique=keVO1+ZF4; ..
D> Type=file;Perm=awdrf;Unique=keVO1+EH4; bar
D> Type=file;Perm=awdrf;Unique=keVO1+LH4;
D> Type=file;Perm=rf;Unique=keVO1+1G4; file5
D> Type=file;Perm=rf;Unique=keVO1+1G4; file6
D> Type=dir;Perm=cpmdelf;Unique=keVO1+!s2; empty
S> 226 MLSD completed
C> MLst test
S> 250- Listing test
S> Type=dir;Perm=el;Unique=keVO1+ZF4 test
S> 250 End
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
D> Type=OS.unix=chr-13/29;Perm=;Unique=keVO1+5G4; device
D> Type=OS.unix=blk-11/108;Perm=;Unique=keVO1+6G4; block
D> Type=file;Perm=awr;Unique=keVO1+8G4; writable
D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; promiscuous
D> Type=dir;Perm=;Unique=keVO1+1t2; no-exec
D> Type=file;Perm=r;Unique=keVO1+EG4; two words
D> Type=file;Perm=r;Unique=keVO1+IH4; leading space
D> Type=file;Perm=r;Unique=keVO1+1G4; file1
D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; incoming
D> Type=file;Perm=r;Unique=keVO1+1G4; file2
D> Type=file;Perm=r;Unique=keVO1+1G4; file3
D> Type=file;Perm=r;Unique=keVO1+1G4; file4
S> 226 MLSD completed
C> MLSD test/incoming
S> 150 BINARY connection open for MLSD test/incoming
D> Type=cdir;Perm=cpmel;Unique=keVO1+7G4; test/incoming
D> Type=pdir;Perm=el;Unique=keVO1+ZF4; ..
D> Type=file;Perm=awdrf;Unique=keVO1+EH4; bar
D> Type=file;Perm=awdrf;Unique=keVO1+LH4;
D> Type=file;Perm=rf;Unique=keVO1+1G4; file5
D> Type=file;Perm=rf;Unique=keVO1+1G4; file6
D> Type=dir;Perm=cpmdelf;Unique=keVO1+!s2; empty
S> 226 MLSD completed
For the purposes of this example the fact set requested has been modified to delete the "size" and "modify" facts, and add the "unique" fact. First, facts about a file name have been obtained via MLST. Note that no fully qualified pathname was given this time. That was because the server was unable to determine that information. Then having determined that the file name represents a directory, that directory has been listed. That listing also shows no fully qualified pathname, for the same reason, thus has but a single "type=cdir" line. This directory (which was created especially for the purpose) contains several interesting files. There are some with OS dependent file types, several sub-directories, and several ordinary files.
在本例中，已修改请求的事实集，以删除“大小”和“修改”事实，并添加“唯一”事实。首先，有关文件名的事实已通过MLST获得。请注意，这次没有提供完全限定的路径名。这是因为服务器无法确定该信息。然后确定文件名代表一个目录后，该目录已列出。出于同样的原因，该清单也没有显示完全限定的路径名，因此只有一行“type=cdir”。此目录（专门为此目的创建）包含几个有趣的文件。有一些与操作系统相关的文件类型、几个子目录和几个普通文件。
Not much can be said here about the OS dependent file types, as none of the information shown there should be treated as any more than possibilities. It can be seen that the OS type of the server is "unix" though, which is one of the OS types in the IANA registry of Operating System names.
关于依赖操作系统的文件类型，这里不能说太多，因为这里显示的任何信息都不应被视为可能。可以看出，服务器的操作系统类型是“unix”，这是IANA操作系统名称注册表中的操作系统类型之一。
Of the three directories listed, "no-exec" has no permission granted to this user to access at all. From the "Unique" fact values, it can be determined that "promiscuous" and "incoming" in fact represent the same directory. Its permissions show that the connected user has permission to do essentially anything other than to delete the directory. That directory was later listed. It happens that the directory can not be deleted because it is not empty.
在列出的三个目录中，“no exec”根本没有授予该用户访问权限。根据“唯一”事实值，可以确定“混杂”和“传入”事实上代表相同的目录。它的权限表明连接的用户除了删除目录外，基本上还有权执行任何操作。该目录后来被列出。由于目录不是空的，因此无法删除该目录。
Of the normal files listed, two contain spaces in their names. The file called " leading space" actually contains two spaces in its name, one before the "l" and one between the "g" and the "s". The two spaces that separate the facts from the visible part of the pathname make that clear. The file "writable" has the "a" and "w" permission bits set, and consequently the connected user should be able to STOR or APPE to that file.
在列出的普通文件中，有两个文件的名称中包含空格。名为“前导空格”的文件实际上在其名称中包含两个空格，一个在“l”之前，另一个在“g”和“s”之间。将事实与路径名的可见部分分开的两个空格清楚地说明了这一点。文件“可写”设置了“a”和“w”权限位，因此连接的用户应该能够存储或显示该文件。
The other four file names, "file1", "file2", "file3", and "file4" all represent the same underlying file, as can be seen from the values of the "unique" facts of each. It happens that "file1" and "file2" are Unix "hard" links, and that "file3" and "file4" are "soft" or "symbolic" links to the first two. None of that information is available via standard MLST facts, it is sufficient for the purposes of FTP to note that all represent the same file, and that the same data would be fetched no matter which of them was retrieved, and that all would be simultaneously modified were data stored in any.
其他四个文件名“file1”、“file2”、“file3”和“file4”都表示相同的底层文件，从每个文件的“唯一”事实的值可以看出。碰巧，“file1”和“file2”是Unix的“硬”链接，“file3”和“file4”是指向前两个的“软”或“符号”链接。所有这些信息都无法通过标准MLST事实获得，为了FTP的目的，请注意，所有这些信息都表示相同的文件，并且无论检索到哪一个数据，都将获取相同的数据，并且如果数据存储在任何文件中，所有这些信息都将被同时修改。
Finally, the sub-directory "incoming" is listed. Since "promiscuous" is the same directory there would be no point listing it as well. In that directory, the files "file5" and "file6" represent still more names for the "file1" file we have seen before. Notice the entry between that for "bar" and "file5". Though it is not possible to easily represent it in this document, that shows a file with a name comprising exactly three spaces (" "). A client will have no difficulty determining that name from the output presented to it however. The directory "empty" is, as its name implies, empty, though that is not shown here. It can, however, be deleted, as can file "bar" and the file whose name is three spaces. All the files that reside in this directory can be renamed. This is a consequence of the UNIX semantics of the directory that contains them being modifiable.
最后，将列出子目录“incoming”。因为“混杂”是同一个目录，所以也没有必要列出它。在该目录中，文件“file5”和“file6”表示我们以前看到的“file1”文件的更多名称。注意“bar”和“file5”之间的条目。虽然不可能在本文档中轻松地表示它，但它显示了一个名称正好包含三个空格（“”）的文件。但是，客户机将很容易从提供给它的输出中确定该名称。目录“empty”顾名思义是空的，尽管这里没有显示。但是，它可以被删除，文件“bar”和名为三个空格的文件也可以被删除。可以重命名此目录中的所有文件。这是包含它们的目录的UNIX语义可修改的结果。
C> MLst file1
S> 250- Listing file1
S> Type=file;Modify=19990929003355.237; file1
S> 250 End
C> MLst file1
S> 250- Listing file1
S> Type=file;Modify=19990929003355.237; file1
S> 250 End
In this example, the server-FTP is indicating that "file1" was last modified 237 milliseconds after 00:33:55 UTC on the 29th of September, 1999.
在本例中，服务器FTP表示上次修改“file1”是在1999年9月29日00:33:55 UTC之后237毫秒。
C> MLST
S> 250-Begin
S> type=dir;unique=AQkAAAAAAAABCAAA; /
S> 250 End.
C> MLSD
S> 150 Opening ASCII mode data connection for MLS.
D> type=cdir;unique=AQkAAAAAAAABCAAA; /
D> type=dir;unique=AQkAAAAAAAABEAAA; bin
D> type=dir;unique=AQkAAAAAAAABGAAA; etc
D> type=dir;unique=AQkAAAAAAAAB8AwA; halflife
D> type=dir;unique=AQkAAAAAAAABoAAA; incoming
D> type=dir;unique=AQkAAAAAAAABIAAA; lib
D> type=dir;unique=AQkAAAAAAAABWAEA; linux
D> type=dir;unique=AQkAAAAAAAABKAEA; ncftpd
D> type=dir;unique=AQkAAAAAAAABGAEA; outbox
D> type=dir;unique=AQkAAAAAAAABuAAA; quake2
D> type=dir;unique=AQkAAAAAAAABQAEA; winstuff
S> 226 Listing completed.
C> MLSD linux
S> 150 Opening ASCII mode data connection for MLS.
D> type=cdir;unique=AQkAAAAAAAABWAEA; /linux
D> type=pdir;unique=AQkAAAAAAAABCAAA; /
D> type=dir;unique=AQkAAAAAAAABeAEA; firewall
D> type=file;size=12;unique=AQkAAAAAAAACWAEA; helo_world
D> type=dir;unique=AQkAAAAAAAABYAEA; kernel
D> type=dir;unique=AQkAAAAAAAABmAEA; scripts
D> type=dir;unique=AQkAAAAAAAABkAEA; security
S> 226 Listing completed.
C> MLSD linux/kernel
S> 150 Opening ASCII mode data connection for MLS.
D> type=cdir;unique=AQkAAAAAAAABYAEA; /linux/kernel
D> type=pdir;unique=AQkAAAAAAAABWAEA; /linux
D> type=file;size=6704;unique=AQkAAAAAAAADYAEA; k.config
D> type=file;size=7269221;unique=AQkAAAAAAAACYAEA; linux-2.0.36.tar.gz
D> type=file;size=12514594;unique=AQkAAAAAAAAEYAEA; linux-2.1.130.tar.gz
C> MLST
S> 250-Begin
S> type=dir;unique=AQkAAAAAAAABCAAA; /
S> 250 End.
C> MLSD
S> 150 Opening ASCII mode data connection for MLS.
D> type=cdir;unique=AQkAAAAAAAABCAAA; /
D> type=dir;unique=AQkAAAAAAAABEAAA; bin
D> type=dir;unique=AQkAAAAAAAABGAAA; etc
D> type=dir;unique=AQkAAAAAAAAB8AwA; halflife
D> type=dir;unique=AQkAAAAAAAABoAAA; incoming
D> type=dir;unique=AQkAAAAAAAABIAAA; lib
D> type=dir;unique=AQkAAAAAAAABWAEA; linux
D> type=dir;unique=AQkAAAAAAAABKAEA; ncftpd
D> type=dir;unique=AQkAAAAAAAABGAEA; outbox
D> type=dir;unique=AQkAAAAAAAABuAAA; quake2
D> type=dir;unique=AQkAAAAAAAABQAEA; winstuff
S> 226 Listing completed.
C> MLSD linux
S> 150 Opening ASCII mode data connection for MLS.
D> type=cdir;unique=AQkAAAAAAAABWAEA; /linux
D> type=pdir;unique=AQkAAAAAAAABCAAA; /
D> type=dir;unique=AQkAAAAAAAABeAEA; firewall
D> type=file;size=12;unique=AQkAAAAAAAACWAEA; helo_world
D> type=dir;unique=AQkAAAAAAAABYAEA; kernel
D> type=dir;unique=AQkAAAAAAAABmAEA; scripts
D> type=dir;unique=AQkAAAAAAAABkAEA; security
S> 226 Listing completed.
C> MLSD linux/kernel
S> 150 Opening ASCII mode data connection for MLS.
D> type=cdir;unique=AQkAAAAAAAABYAEA; /linux/kernel
D> type=pdir;unique=AQkAAAAAAAABWAEA; /linux
D> type=file;size=6704;unique=AQkAAAAAAAADYAEA; k.config
D> type=file;size=7269221;unique=AQkAAAAAAAACYAEA; linux-2.0.36.tar.gz
D> type=file;size=12514594;unique=AQkAAAAAAAAEYAEA; linux-2.1.130.tar.gz
S> 226 Listing completed.
S> 226个名单已完成。
Note that this server returns its "unique" fact value in quite a different format. It also returns fully qualified pathnames for the "pdir" entry.
请注意，此服务器以完全不同的格式返回其“唯一”事实值。它还返回“pdir”项的完全限定路径名。
C> MLSD
S> 150 BINARY connection open for MLSD .
D> Type=cdir;Modify=19990219183438; /iana/assignments
D> Type=pdir;Modify=19990112030453; ..
D> Type=dir;Modify=19990219073522; media-types
D> Type=dir;Modify=19990112033515; character-set-info
D> Type=dir;Modify=19990112033529; languages
D> Type=file;Size=44242;Modify=19990217230400; character-sets
D> Type=file;Size=1947;Modify=19990209215600; operating-system-names
S> 226 MLSD completed
C> MLSD media-types
S> 150 BINARY connection open for MLSD media-types
D> Type=cdir;Modify=19990219073522; media-types
D> Type=cdir;Modify=19990219073522; /iana/assignments/media-types
D> Type=pdir;Modify=19990219183438; ..
D> Type=dir;Modify=19990112033045; text
D> Type=dir;Modify=19990219183442; image
D> Type=dir;Modify=19990112033216; multipart
D> Type=dir;Modify=19990112033254; video
D> Type=file;Size=30249;Modify=19990218032700; media-types
S> 226 MLSD completed
C> MLSD character-set-info
S> 150 BINARY connection open for MLSD character-set-info
D> Type=cdir;Modify=19990112033515; character-set-info
D> Type=cdir;Modify=19990112033515; /iana/assignments/character-set-info
D> Type=pdir;Modify=19990219183438; ..
D> Type=file;Size=1234;Modify=19980903020400; windows-1251
D> Type=file;Size=4557;Modify=19980922001400; tis-620
D> Type=file;Size=801;Modify=19970324130000; ibm775
D> Type=file;Size=552;Modify=19970320130000; ibm866
D> Type=file;Size=922;Modify=19960505140000; windows-1258
S> 226 MLSD completed
C> MLSD languages
S> 150 BINARY connection open for MLSD languages
D> Type=cdir;Modify=19990112033529; languages
D> Type=cdir;Modify=19990112033529; /iana/assignments/languages
D> Type=pdir;Modify=19990219183438; ..
D> Type=file;Size=2391;Modify=19980309130000; default
D> Type=file;Size=943;Modify=19980309130000; tags
D> Type=file;Size=870;Modify=19971026130000; navajo
C> MLSD
S> 150 BINARY connection open for MLSD .
D> Type=cdir;Modify=19990219183438; /iana/assignments
D> Type=pdir;Modify=19990112030453; ..
D> Type=dir;Modify=19990219073522; media-types
D> Type=dir;Modify=19990112033515; character-set-info
D> Type=dir;Modify=19990112033529; languages
D> Type=file;Size=44242;Modify=19990217230400; character-sets
D> Type=file;Size=1947;Modify=19990209215600; operating-system-names
S> 226 MLSD completed
C> MLSD media-types
S> 150 BINARY connection open for MLSD media-types
D> Type=cdir;Modify=19990219073522; media-types
D> Type=cdir;Modify=19990219073522; /iana/assignments/media-types
D> Type=pdir;Modify=19990219183438; ..
D> Type=dir;Modify=19990112033045; text
D> Type=dir;Modify=19990219183442; image
D> Type=dir;Modify=19990112033216; multipart
D> Type=dir;Modify=19990112033254; video
D> Type=file;Size=30249;Modify=19990218032700; media-types
S> 226 MLSD completed
C> MLSD character-set-info
S> 150 BINARY connection open for MLSD character-set-info
D> Type=cdir;Modify=19990112033515; character-set-info
D> Type=cdir;Modify=19990112033515; /iana/assignments/character-set-info
D> Type=pdir;Modify=19990219183438; ..
D> Type=file;Size=1234;Modify=19980903020400; windows-1251
D> Type=file;Size=4557;Modify=19980922001400; tis-620
D> Type=file;Size=801;Modify=19970324130000; ibm775
D> Type=file;Size=552;Modify=19970320130000; ibm866
D> Type=file;Size=922;Modify=19960505140000; windows-1258
S> 226 MLSD completed
C> MLSD languages
S> 150 BINARY connection open for MLSD languages
D> Type=cdir;Modify=19990112033529; languages
D> Type=cdir;Modify=19990112033529; /iana/assignments/languages
D> Type=pdir;Modify=19990219183438; ..
D> Type=file;Size=2391;Modify=19980309130000; default
D> Type=file;Size=943;Modify=19980309130000; tags
D> Type=file;Size=870;Modify=19971026130000; navajo
D> Type=file;Size=699;Modify=19950911140000; no-bok S> 226 MLSD completed C> PWD S> 257 "/iana/assignments" is current directory.
D> 类型=文件；尺寸=699；修改=19950911140000；没有作业S>226 MLSD已完成C>PWD S>257“/iana/assignments”是当前目录。
This example shows some of the IANA maintained files that are relevant for this specification in MLSD format. Note that these listings have been edited by deleting many entries, the actual listings are much longer.
此示例以MLSD格式显示了一些IANA维护的与此规范相关的文件。请注意，这些列表已通过删除许多条目进行编辑，实际的列表要长得多。
The following example is intended to make clear some cases where case dependent strings are permitted in the MLSx commands, and where case independent strings are required.
以下示例旨在说明MLSx命令中允许大小写相关字符串以及需要大小写无关字符串的一些情况。
Note first that the "MLSD" command, shown here as "MlsD" is case independent. Clients may issue this command in any case, or combination of cases, they desire. This is the case for all FTP commands.
首先请注意，这里显示为“MLSD”的“MLSD”命令与大小写无关。客户机可以在任何情况下发出此命令，或者在他们希望的组合情况下发出此命令。这是所有FTP命令的情况。
C> MlsD
S> 150 BINARY connection open for MLSD .
D> Type=pdir;Modify=19990929011228;Perm=el;Unique=keVO1+ZF4; ..
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; FILE2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+aG8; file3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+ag8; FILE3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1
S> 226 MLSD completed
C> MlsD
S> 150 BINARY connection open for MLSD .
D> Type=pdir;Modify=19990929011228;Perm=el;Unique=keVO1+ZF4; ..
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; FILE2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+aG8; file3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+ag8; FILE3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2
D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1
S> 226 MLSD completed
Next, notice the labels of the facts. These are also case-independent strings; the server-FTP is permitted to return them in any case desired. User-FTP must be prepared to deal with any case, though it may do this by mapping the labels to a common case if desired.
接下来，注意事实的标签。它们也是大小写无关的字符串；允许服务器FTP在任何需要的情况下返回它们。用户FTP必须准备好处理任何情况，但如果需要，它可以通过将标签映射到常见情况来实现这一点。
Then, notice that there are nine objects of "type" file returned. In a case-independent NVFS these would represent three different file names, "file1", "file2", and "file3". With a case-dependent NVFS all nine represent different file names. Either is possible, server-FTPs may implement a case dependent or a case independent NVFS. User-FTPs must allow for case dependent selection of files to manipulate on the server.
然后，请注意，返回了九个“type”file对象。在案例独立的NVFS中，它们将表示三个不同的文件名，“file1”、“file2”和“file3”。对于区分大小写的NVF，所有九个都表示不同的文件名。无论哪种情况都是可能的，服务器FTP可以实现案例相关或案例无关的NVFS。用户FTP必须允许根据具体情况选择要在服务器上操作的文件。
Lastly, notice that the value of the "unique" fact is case dependent. In the example shown, "file1", "File1", and "file2" all have the same "unique" fact value "keVO1+bD8", and thus all represent the same underlying file. On the other hand, "FILE1" has a different "unique" fact value ("keVO1+bd8") and hence represents a different file. Similarly, "FILE2" and "File2" are two names for the same underlying file, whereas "file3", "File3" and "FILE3" all represent different underlying files.
最后，请注意，“unique”事实的值取决于大小写。在所示的示例中，“file1”、“file1”和“file2”都具有相同的“唯一”事实值“keVO1+bD8”，因此都表示相同的底层文件。另一方面，“FILE1”具有不同的“唯一”事实值（“keVO1+bd8”），因此表示不同的文件。类似地，“FILE2”和“FILE2”是同一基础文件的两个名称，而“file3”、“file3”和“file3”都表示不同的基础文件。
That the approximate sizes ("size" fact) and last modification times ("modify" fact) are the same in all cases might be no more than a coincidence.
在所有情况下，近似大小（“大小”事实）和上次修改时间（“修改”事实）是相同的，这可能只是巧合。
It is not suggested that the operators of server-FTPs create an NVFS that stresses the protocols to this extent; however, both user and server implementations must be prepared to deal with such extreme examples.
不建议服务器FTP的运营商创建一个在这种程度上强调协议的NVFS；然而，用户和服务器实现都必须准备好处理这种极端的例子。
C> MlsD
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150227;perm=el; /MISC
D> type=pdir;modify=19791231130000;perm=el; /
D> type=dir;modify=19990426150227;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; SRC
S> 226 Transfer finished successfully.
C> MlsD src
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150228;perm=el; /MISC/src
D> type=pdir;modify=19990426150227;perm=el; /MISC
D> type=dir;modify=19990426150228;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; INSTALL
D> type=dir;modify=19990426150230;perm=el; INSTALLI
D> type=dir;modify=19990426150230;perm=el; TREES
S> 226 Transfer finished successfully.
C> MlsD src/install
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150228;perm=el; /MISC/src/install
D> type=pdir;modify=19990426150228;perm=el; /MISC/src
D> type=file;modify=19990406234304;perm=r;size=20059; BOOTPC.C
D> type=file;modify=19980401170153;perm=r;size=278; BOOTPC.H
D> type=file;modify=19990413153736;perm=r;size=54220; BOOTPC.O
D> type=file;modify=19990223044003;perm=r;size=3389; CDROM.C
D> type=file;modify=19990413153739;perm=r;size=30192; CDROM.O
D> type=file;modify=19981119155324;perm=r;size=1055; CHANGELO
D> type=file;modify=19981204171040;perm=r;size=8297; COMMANDS.C
D> type=file;modify=19980508041749;perm=r;size=580; COMMANDS.H
C> MlsD
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150227;perm=el; /MISC
D> type=pdir;modify=19791231130000;perm=el; /
D> type=dir;modify=19990426150227;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; SRC
S> 226 Transfer finished successfully.
C> MlsD src
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150228;perm=el; /MISC/src
D> type=pdir;modify=19990426150227;perm=el; /MISC
D> type=dir;modify=19990426150228;perm=el; CVS
D> type=dir;modify=19990426150228;perm=el; INSTALL
D> type=dir;modify=19990426150230;perm=el; INSTALLI
D> type=dir;modify=19990426150230;perm=el; TREES
S> 226 Transfer finished successfully.
C> MlsD src/install
S> 150 File Listing Follows in IMAGE / Binary mode.
D> type=cdir;modify=19990426150228;perm=el; /MISC/src/install
D> type=pdir;modify=19990426150228;perm=el; /MISC/src
D> type=file;modify=19990406234304;perm=r;size=20059; BOOTPC.C
D> type=file;modify=19980401170153;perm=r;size=278; BOOTPC.H
D> type=file;modify=19990413153736;perm=r;size=54220; BOOTPC.O
D> type=file;modify=19990223044003;perm=r;size=3389; CDROM.C
D> type=file;modify=19990413153739;perm=r;size=30192; CDROM.O
D> type=file;modify=19981119155324;perm=r;size=1055; CHANGELO
D> type=file;modify=19981204171040;perm=r;size=8297; COMMANDS.C
D> type=file;modify=19980508041749;perm=r;size=580; COMMANDS.H
...
D> type=file;modify=19990419052351;perm=r;size=54264; URLMETHO.O
D> type=file;modify=19980218161629;perm=r;size=993; WINDOWS.C
D> type=file;modify=19970912154859;perm=r;size=146; WINDOWS.H
D> type=file;modify=19990413153731;perm=r;size=16812; WINDOWS.O
D> type=file;modify=19990322174959;perm=r;size=129; _CVSIGNO
D> type=file;modify=19990413153640;perm=r;size=82536; _DEPEND
S> 226 Transfer finished successfully.
C> MLst src/install/windows.c
S> 250-Listing src/install/windows.c
S> type=file;perm=r;size=993; /misc/src/install/windows.c
S> 250 End
S> ftp> mlst SRC/INSTALL/WINDOWS.C
C> MLst SRC/INSTALL/WINDOWS.C
S> 250-Listing SRC/INSTALL/WINDOWS.C
S> type=file;perm=r;size=993; /misc/SRC/INSTALL/WINDOWS.C
S> 250 End
...
D> type=file;modify=19990419052351;perm=r;size=54264; URLMETHO.O
D> type=file;modify=19980218161629;perm=r;size=993; WINDOWS.C
D> type=file;modify=19970912154859;perm=r;size=146; WINDOWS.H
D> type=file;modify=19990413153731;perm=r;size=16812; WINDOWS.O
D> type=file;modify=19990322174959;perm=r;size=129; _CVSIGNO
D> type=file;modify=19990413153640;perm=r;size=82536; _DEPEND
S> 226 Transfer finished successfully.
C> MLst src/install/windows.c
S> 250-Listing src/install/windows.c
S> type=file;perm=r;size=993; /misc/src/install/windows.c
S> 250 End
S> ftp> mlst SRC/INSTALL/WINDOWS.C
C> MLst SRC/INSTALL/WINDOWS.C
S> 250-Listing SRC/INSTALL/WINDOWS.C
S> type=file;perm=r;size=993; /misc/SRC/INSTALL/WINDOWS.C
S> 250 End
Note that this server gives fully qualified pathnames for the "pdir" and "cdir" entries in MLSD listings. Also notice that this server does, though it is not required to, sort its directory listing outputs. That may be an artifact of the underlying file system access mechanisms of course. Finally notice that the NVFS supported by this server, in contrast to the earlier ones, implements its pathnames in a case independent manner. The server seems to return files using the case in which they were requested, when the name was sent by the client, and otherwise uses an algorithm known only to itself to select the case of the names it returns.
请注意，此服务器为MLSD列表中的“pdir”和“cdir”条目提供完全限定的路径名。还请注意，尽管不要求该服务器对其目录列表输出进行排序，但该服务器会对其目录列表输出进行排序。当然，这可能是底层文件系统访问机制的产物。最后请注意，与早期的NVFS不同，该服务器支持的NVFS以独立于大小写的方式实现其路径名。当客户机发送名称时，服务器似乎会使用请求文件的大小写返回文件，否则，服务器会使用仅为其自身所知的算法来选择其返回名称的大小写。
C> MLst f
S> 250-MLST f
S> Type=dir;Modify=20000710052229;Unique=AAD/AAAABIA; f
S> 250 End
C> CWD f
S> 250 CWD command successful.
C> MLSD
S> 150 Opening ASCII mode data connection for 'MLSD'.
D> Type=cdir;Unique=AAD/AAAABIA; .
D> Type=pdir;Unique=AAD/AAAAAAI; ..
D> Type=file;Size=987;Unique=AAD/AAAABIE; Makefile
D> Type=file;Size=20148;Unique=AAD/AAAABII; conf.c
D> Type=file;Size=11111;Unique=AAD/AAAABIM; extern.h
D> Type=file;Size=38721;Unique=AAD/AAAABIQ; ftpcmd.y
D> Type=file;Size=17922;Unique=AAD/AAAABIU; ftpd.8
D> Type=file;Size=60732;Unique=AAD/AAAABIY; ftpd.c
D> Type=file;Size=3127;Unique=AAD/AAAABIc; logwtmp.c
C> MLst f
S> 250-MLST f
S> Type=dir;Modify=20000710052229;Unique=AAD/AAAABIA; f
S> 250 End
C> CWD f
S> 250 CWD command successful.
C> MLSD
S> 150 Opening ASCII mode data connection for 'MLSD'.
D> Type=cdir;Unique=AAD/AAAABIA; .
D> Type=pdir;Unique=AAD/AAAAAAI; ..
D> Type=file;Size=987;Unique=AAD/AAAABIE; Makefile
D> Type=file;Size=20148;Unique=AAD/AAAABII; conf.c
D> Type=file;Size=11111;Unique=AAD/AAAABIM; extern.h
D> Type=file;Size=38721;Unique=AAD/AAAABIQ; ftpcmd.y
D> Type=file;Size=17922;Unique=AAD/AAAABIU; ftpd.8
D> Type=file;Size=60732;Unique=AAD/AAAABIY; ftpd.c
D> Type=file;Size=3127;Unique=AAD/AAAABIc; logwtmp.c
D> Type=file;Size=2294;Unique=AAD/AAAABIg; pathnames.h D> Type=file;Size=7605;Unique=AAD/AAAABIk; popen.c D> Type=file;Size=9951;Unique=AAD/AAAABIo; ftpd.conf.5 D> Type=file;Size=5023;Unique=AAD/AAAABIs; ftpusers.5 D> Type=file;Size=3547;Unique=AAD/AAAABIw; logutmp.c D> Type=file;Size=2064;Unique=AAD/AAAABI0; version.h D> Type=file;Size=20420;Unique=AAD/AAAAAAM; cmds.c D> Type=file;Size=15864;Unique=AAD/AAAAAAg; ls.c D> Type=file;Size=2898;Unique=AAD/AAAAAAk; ls.h D> Type=file;Size=2769;Unique=AAD/AAAAAAo; lsextern.h D> Type=file;Size=2042;Unique=AAD/AAAAAAs; stat_flags.h D> Type=file;Size=5708;Unique=AAD/AAAAAAw; cmp.c D> Type=file;Size=9280;Unique=AAD/AAAAAA0; print.c D> Type=file;Size=4657;Unique=AAD/AAAAAA4; stat_flags.c D> Type=file;Size=2664;Unique=AAD/AAAAAA8; util.c D> Type=file;Size=10383;Unique=AAD/AAAABJ0; ftpd.conf.cat5 D> Type=file;Size=3631;Unique=AAD/AAAABJ4; ftpusers.cat5 D> Type=file;Size=17729;Unique=AAD/AAAABJ8; ftpd.cat8 S> 226 MLSD complete.
D> 类型=文件；尺寸=2294；唯一=AAD/AAAABIg；pathnames.hd>Type=file；尺寸=7605；唯一=AAD/aabik；popen.cd>Type=file；尺寸=9951；唯一=AAD/AABIO；ftpd.conf.5d>Type=file；尺寸=5023；唯一=AAD/aabis；ftpusers.5d>Type=file；尺寸=3547；唯一=AAD/AABAW；logutmp.cd>Type=file；尺寸=2064；唯一=AAD/AABI0；version.hd>Type=文件；尺寸=20420；唯一=AAD/aaaam；cmds.cd>Type=file；尺寸=15864；唯一=AAD/aaaag；ls.cd>Type=file；尺寸=2898；唯一=AAD/aaaak；ls.hd>Type=file；尺寸=2769；唯一=AAD/aaaao；lsextern.hd>Type=file；尺寸=2042；唯一=AAD/aaaas；stat_flags.hd>Type=file；尺寸=5708；唯一=AAD/aaaaaa w；cmp.cd>Type=file；尺寸=9280；唯一=AAD/aaaa 0；print.cd>Type=file；尺寸=4657；唯一=AAD/aaaaaa 4；stat_flags.cd>Type=file；尺寸=2664；唯一=AAD/aaaa 8；util.cd>Type=file；尺寸=10383；唯一=AAD/AABJ0；ftpd.conf.cat5d>Type=file；尺寸=3631；唯一=AAD/AABJ4；ftpusers.cat5 D>类型=文件；规模=17729；唯一=AAD/AABJ8；ftpd.cat8 S>226 MLSD完成。
This examples shows yet another server implementation, showing a listing of its own source code. Note that this implementation does not include the fully qualified path name in its "cdir" and "pdir" entries, nor in the output from "MLST". Also note that the facts requested were modified between the "MLST" and "MLSD" commands, though that exchange has not been shown here.
这个例子展示了另一个服务器实现，展示了它自己的源代码列表。请注意，此实现在其“cdir”和“pdir”条目中以及在“MLST”的输出中都不包括完全限定路径名。还请注意，请求的事实在“MLST”和“MLSD”命令之间进行了修改，尽管这里没有显示这种交换。
C> PASV
S> 227 Entering Passive Mode (127,0,0,1,255,46)
C> MLSD
S> 150 I tink I tee a trisector tree
D> Type=file;Unique=aaaaafUYqaaa;Perm=rf;Size=15741; x
D> Type=cdir;Unique=aaaaacUYqaaa;Perm=cpmel; /
D> Type=file;Unique=aaaaajUYqaaa;Perm=rf;Size=5760; x4
D> Type=dir;Unique=aaabcaUYqaaa;Perm=elf; sub
D> Type=file;Unique=aaaaagUYqaaa;Perm=rf;Size=8043; x1
D> Type=dir;Unique=aaab8aUYqaaa;Perm=cpmelf; files
D> Type=file;Unique=aaaaahUYqaaa;Perm=rf;Size=4983; x2
D> Type=file;Unique=aaaaaiUYqaaa;Perm=rf;Size=6854; x3
S> 226 That's all folks...
C> CWD sub
S> 250 CWD command successful.
C> PWD
S> 257 "/sub" is current directory.
C> PASV
S> 227 Entering Passive Mode (127,0,0,1,255,44)
C> PASV
S> 227 Entering Passive Mode (127,0,0,1,255,46)
C> MLSD
S> 150 I tink I tee a trisector tree
D> Type=file;Unique=aaaaafUYqaaa;Perm=rf;Size=15741; x
D> Type=cdir;Unique=aaaaacUYqaaa;Perm=cpmel; /
D> Type=file;Unique=aaaaajUYqaaa;Perm=rf;Size=5760; x4
D> Type=dir;Unique=aaabcaUYqaaa;Perm=elf; sub
D> Type=file;Unique=aaaaagUYqaaa;Perm=rf;Size=8043; x1
D> Type=dir;Unique=aaab8aUYqaaa;Perm=cpmelf; files
D> Type=file;Unique=aaaaahUYqaaa;Perm=rf;Size=4983; x2
D> Type=file;Unique=aaaaaiUYqaaa;Perm=rf;Size=6854; x3
S> 226 That's all folks...
C> CWD sub
S> 250 CWD command successful.
C> PWD
S> 257 "/sub" is current directory.
C> PASV
S> 227 Entering Passive Mode (127,0,0,1,255,44)
C> MLSD S> 150 I tink I tee a trisector tree D> Type=dir;Unique=aaabceUYqaaa;Perm=elf; dir D> Type=file;Unique=aaabcbUYqaaa;Perm=rf;Size=0; y1 D> Type=file;Unique=aaabccUYqaaa;Perm=rf;Size=0; y2 D> Type=file;Unique=aaabcdUYqaaa;Perm=rf;Size=0; y3 D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=cdir;Unique=aaabcaUYqaaa;Perm=el; /sub S> 226 That's all folks... C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,42) C> MLSD dir S> 150 I tink I tee a trisector tree D> Type=pdir;Unique=aaabcaUYqaaa;Perm=el; /sub D> Type=pdir;Unique=aaabcaUYqaaa;Perm=el; .. D> Type=file;Unique=aaab8cUYqaaa;Perm=r;Size=15039; mlst.c D> Type=dir;Unique=aaabcfUYqaaa;Perm=el; ect D> Type=cdir;Unique=aaabceUYqaaa;Perm=el; dir D> Type=cdir;Unique=aaabceUYqaaa;Perm=el; /sub/dir D> Type=dir;Unique=aaabchUYqaaa;Perm=el; misc D> Type=file;Unique=aaab8bUYqaaa;Perm=r;Size=34589; ftpd.c S> 226 That's all folks... C> CWD dir/ect S> 250 CWD command successful. C> PWD S> 257 "/sub/dir/ect" is current directory. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,40) C> MLSD S> 150 I tink I tee a trisector tree D> Type=dir;Unique=aaabcgUYqaaa;Perm=el; ory D> Type=pdir;Unique=aaabceUYqaaa;Perm=el; /sub/dir D> Type=pdir;Unique=aaabceUYqaaa;Perm=el; .. D> Type=cdir;Unique=aaabcfUYqaaa;Perm=el; /sub/dir/ect S> 226 That's all folks... C> CWD /files S> 250 CWD command successful. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,36) C> MLSD S> 150 I tink I tee a trisector tree D> Type=cdir;Unique=aaab8aUYqaaa;Perm=cpmel; /files D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=file;Unique=aaab8cUYqaaa;Perm=rf;Size=15039; mlst.c D> Type=file;Unique=aaab8bUYqaaa;Perm=rf;Size=34589; ftpd.c S> 226 That's all folks...
C> MLSD S>150 I tink I tee a三分体树D>Type=dir；唯一=aaabceUYqaaa；Perm=elf；dird>Type=file；唯一=aaabcbUYqaaa；Perm=rf；尺寸=0；y1 D>类型=文件；唯一=aaabccUYqaaa；Perm=rf；尺寸=0；y2 D>类型=文件；唯一=aaabcdUYqaaa；Perm=rf；尺寸=0；y3d>Type=pdir；唯一=AAAAA CUYQAAA；Perm=cpmel；/D> 类型=pdir；唯一=AAAAA CUYQAAA；Perm=cpmel。。D> 类型=cdir；唯一=aaabcaUYqaaa；Perm=el/潜艇S>226这就是所有的人。。。C> PASV S>227进入被动模式（127,0,0,1255,42）C>MLSD dir S>150 I tink I tee a trisector tree D>Type=pdir；唯一=aaabcaUYqaaa；Perm=el/子D>类型=pdir；唯一=aaabcaUYqaaa；Perm=el。。D> 类型=文件；唯一=aaab8cUYqaaa；Perm=r；尺寸=15039；mlst.cd>Type=dir；唯一=aaabcfUYqaaa；Perm=el；ect D>类型=cdir；唯一=aaabceUYqaaa；Perm=el；dird>Type=cdir；唯一=aaabceUYqaaa；Perm=el/sub/dir D>Type=dir；唯一=aaabchUYqaaa；Perm=el；杂项D>类型=文件；唯一=aaab8bUYqaaa；Perm=r；尺寸=34589；ftpd.c S>226这就是所有人。。。C> CWD dir/ect S>250 CWD命令成功。C> PWD S>257“/sub/dir/ect”是当前目录。C> PASV S>227进入被动模式（127,0,0,1255,40）C>MLSD S>150 I tink I tee a trisector tree D>Type=dir；唯一=aaabcgUYqaaa；Perm=el；ory D>Type=pdir；唯一=aaabceUYqaaa；Perm=el/sub/dir D>Type=pdir；唯一=aaabceUYqaaa；Perm=el。。D> 类型=cdir；唯一=aaabcfUYqaaa；Perm=el/sub/dir/ect S>226就是这些人。。。C> CWD/files S>250 CWD命令成功。C> PASV S>227进入被动模式（127,0,0,1255,36）C>MLSD S>150 I tink I tee a trisector tree D>Type=cdir；唯一=aaab8aUYqaaa；Perm=cpmel/文件D>Type=pdir；唯一=AAAAA CUYQAAA；Perm=cpmel；/D> 类型=pdir；唯一=AAAAA CUYQAAA；Perm=cpmel。。D> 类型=文件；唯一=aaab8cUYqaaa；Perm=rf；尺寸=15039；mlst.cd>Type=file；唯一=aaab8bUYqaaa；Perm=rf；尺寸=34589；ftpd.c S>226这就是所有人。。。
C> RNFR mlst.c S> 350 File exists, ready for destination name C> RNTO list.c S> 250 RNTO command successful. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,34) C> MLSD S> 150 I tink I tee a trisector tree D> Type=file;Unique=aaab8cUYqaaa;Perm=rf;Size=15039; list.c D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=file;Unique=aaab8bUYqaaa;Perm=rf;Size=34589; ftpd.c D> Type=cdir;Unique=aaab8aUYqaaa;Perm=cpmel; /files S> 226 That's all folks...
C> RNFR mlst.cs>350文件存在，准备好接收目标名称C>RNTO list.cs>250 RNTO命令成功。C> PASV S>227进入被动模式（127,0,0,1255,34）C>MLSD S>150 I tink I tee a trisector tree D>Type=file；唯一=aaab8cUYqaaa；Perm=rf；尺寸=15039；list.cd>Type=pdir；唯一=AAAAA CUYQAAA；Perm=cpmel；/D> 类型=pdir；唯一=AAAAA CUYQAAA；Perm=cpmel。。D> 类型=文件；唯一=aaab8bUYqaaa；Perm=rf；尺寸=34589；ftpd.cd>Type=cdir；唯一=aaab8aUYqaaa；Perm=cpmel/文件S>226这是所有的人。。。
The server shown here returns its directory listings in seemingly random order, and even seems to modify the order of the directory as its contents change -- perhaps the underlying directory structure is based upon hashing of some kind. Note that the "pdir" and "cdir" entries are interspersed with other entries in the directory. Note also that this server does not show a "pdir" entry when listing the contents of the root directory of the virtual filestore; however, it does however include multiple "cdir" and "pdir" entries when it feels inclined. The server also uses obnoxiously "cute" messages.
这里显示的服务器以看似随机的顺序返回其目录列表，甚至似乎随着目录内容的变化而修改目录的顺序——可能底层目录结构是基于某种散列的。请注意，“pdir”和“cdir”条目与目录中的其他条目相互交错。还要注意，当列出虚拟文件存储的根目录的内容时，此服务器不显示“pdir”条目；然而，当它感觉有倾向时，它确实包括多个“cdir”和“pdir”条目。服务器还使用令人讨厌的“可爱”消息。
When responding to the FEAT command, a server-FTP process that supports MLST, and MLSD, plus internationalization of pathnames, MUST indicate that this support exists. It does this by including a MLST feature line. As well as indicating the basic support, the MLST feature line indicates which MLST facts are available from the server, and which of those will be returned if no subsequent "OPTS MLST" command is sent.
响应FEAT命令时，支持MLST和MLSD以及路径名国际化的服务器FTP进程必须指示存在此支持。它通过包含MLST要素线来实现这一点。除了指示基本支持外，MLST功能行还指示哪些MLST事实可从服务器获得，以及如果没有发送后续的“OPTS MLST”命令，将返回哪些事实。
mlst-feat = SP "MLST" [SP factlist] CRLF
factlist = 1*( factname ["*"] ";" )
mlst-feat = SP "MLST" [SP factlist] CRLF
factlist = 1*( factname ["*"] ";" )
The initial space shown in the mlst-feat response is that required by the FEAT command, two spaces are not permitted. If no factlist is given, then the server-FTP process is indicating that it supports MLST, but implements no facts. Only pathnames can be returned. This would be a minimal MLST implementation, and useless for most practical purposes. Where the factlist is present, the factnames included indicate the facts supported by the server. Where the optional asterisk appears after a factname, that fact will be included in MLST format responses, until an "OPTS MLST" is given to alter the list of facts returned. After that, subsequent FEAT
mlst feat响应中显示的初始空间是feat命令所要求的，不允许使用两个空间。如果没有给出事实列表，那么服务器FTP进程表示它支持MLST，但不实现任何事实。只能返回路径名。这将是一个最小的MLST实现，对于大多数实际用途来说毫无用处。如果存在事实列表，则包含的事实名称表示服务器支持的事实。如果可选星号出现在事实名称之后，则该事实将包含在MLST格式的响应中，直到给出“OPTS MLST”以更改返回的事实列表。在那之后，接下来的壮举
commands will return the asterisk to show the facts selected by the most recent "OPTS MLST".
命令将返回星号以显示最近的“OPTS MLST”选择的事实。
Note that there is no distinct FEAT output for MLSD. The presence of the MLST feature indicates that both MLST and MLSD are supported.
注意MLSD没有明显的专长输出。MLST功能的存在表明MLST和MLSD都受支持。
C> Feat
S> 211- Features supported
S> REST STREAM
S> MDTM
S> SIZE
S> TVFS
S> UTF8
S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> Feat
S> 211- Features supported
S> REST STREAM
S> MDTM
S> SIZE
S> TVFS
S> UTF8
S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
Aside from some features irrelevant here, this server indicates that it supports MLST including several, but not all, standard facts, all of which it will send by default. It also supports two OS dependent facts, and one locally defined fact. The latter three must be requested expressly by the client for this server to supply them.
除了一些与此无关的特性外，此服务器还表示它支持MLST，其中包括一些标准事实，但不是全部，默认情况下将发送所有这些标准事实。它还支持两个依赖操作系统的事实和一个本地定义的事实。客户机必须明确请求后三个，此服务器才能提供它们。
C> Feat S> 211-Extensions supported: S> CLNT S> MDTM S> MLST type*;size*;modify*;UNIX.mode*;UNIX.owner;UNIX.group;unique; S> PASV S> REST STREAM S> SIZE S> TVFS S> Compliance Level: 19981201 (IETF mlst-05) S> 211 End.
C> 支持的Feat S>211扩展：S>CLNT S>MDTM S>MLST类型*；大小*；修改*；UNIX.mode*；UNIX.owner；UNIX.group；唯一的S> PASV S>静止流S>大小S>TVFS>符合性级别：19981201（IETF mlst-05）S>211结束。
Again, in addition to some irrelevant features here, this server indicates that it supports MLST, four of the standard facts, one of which ("unique") is not enabled by default, and several OS dependent facts, one of which is provided by the server by default. This server actually supported more OS dependent facts. Others were deleted for the purposes of this document to comply with document formatting restrictions.
此外，除了一些不相关的功能外，此服务器还表示它支持MLST、四个标准事实（其中一个（“唯一”）在默认情况下未启用）和几个依赖于操作系统的事实（其中一个默认情况下由服务器提供）。此服务器实际上支持更多依赖操作系统的事实。出于本文件的目的，删除了其他文件，以符合文件格式限制。
C> FEAT
S> 211-Features supported
S> MDTM
S> MLST Type*;Size*;Modify*;Perm;Unique*;
S> REST STREAM
S> SIZE
S> TVFS
S> 211 End
C> FEAT
S> 211-Features supported
S> MDTM
S> MLST Type*;Size*;Modify*;Perm;Unique*;
S> REST STREAM
S> SIZE
S> TVFS
S> 211 End
This server has wisely chosen not to implement any OS dependent facts. At the time of writing this document, no such facts have been defined (using the mechanisms of section 10.1) so rational support for them would be difficult at best. All but one of the facts supported by this server are enabled by default.
此服务器明智地选择不实现任何依赖操作系统的事实。在编写本文件时，尚未对此类事实进行定义（使用第10.1节中的机制），因此对其进行合理支持充其量是困难的。默认情况下，此服务器支持的所有事实（只有一个除外）均已启用。
For the MLSx commands, the Client-FTP may specify a list of facts it wishes to be returned in all subsequent MLSx commands until another OPTS MLST command is sent. The format is specified by:
对于MLSx命令，客户端FTP可以指定希望在所有后续MLSx命令中返回的事实列表，直到发送另一个OPTS MLST命令。格式由以下内容指定：
mlst-opts = "OPTS" SP "MLST" [ SP 1*( factname ";" ) ]
mlst opts=“opts”SP“mlst”[SP 1*（factname；”）]
By sending the "OPTS MLST" command, the client requests the server to include only the facts listed as arguments to the command in subsequent output from MLSx commands. Facts not included in the "OPTS MLST" command MUST NOT be returned by the server. Facts that are included should be returned for each entry returned from the MLSx command where they meaningfully apply. Facts requested that are not supported, or that are inappropriate to the file or directory being listed should simply be omitted from the MLSx output. This is not an error. Note that where no factname arguments are present, the client is requesting that only the file names be returned. In this case, and in any other case where no facts are included in the result, the space that separates the fact names and their values from the file name is still required. That is, the first character of the output line will be a space, (or two characters will be spaces when the line is returned over the control connection) and the file name will start immediately thereafter.
通过发送“OPTS MLST”命令，客户机请求服务器在MLSx命令的后续输出中仅包括作为命令参数列出的事实。服务器不得返回“OPTS MLST”命令中未包含的事实。对于从MLSx命令返回的每个条目，都应该返回包含的事实，这些事实在其中有意义地应用。请求的事实不受支持，或者不适合所列出的文件或目录，只需从MLSx输出中省略即可。这不是一个错误。请注意，如果不存在factname参数，客户机将请求仅返回文件名。在这种情况下，以及在结果中不包含事实的任何其他情况下，仍然需要将事实名称及其值与文件名分隔开的空间。也就是说，输出行的第一个字符将是一个空格（当通过控制连接返回该行时，两个字符将是空格），并且文件名将在其后立即开始。
Clients should note that generating values for some facts can be possible, but very expensive, for some servers. It is generally acceptable to retrieve any of the facts that the server offers as its default set before any "OPTS MLST" command has been given, however clients should use particular caution before requesting any facts not in that set. That is, while other facts may be available from the server, clients should refrain from requesting such facts unless
客户机应该注意，为某些事实生成值是可能的，但对于某些服务器来说非常昂贵。在发出任何“OPTS MLST”命令之前，通常可以检索服务器作为其默认集提供的任何事实，但是客户端在请求不在该集合中的任何事实之前应特别小心。也就是说，虽然可以从服务器获得其他事实，但客户端应避免请求此类事实，除非
there is a particular operational requirement for that particular information, which ought be more significant than perhaps simply improving the information displayed to an end user.
对于该特定信息有一个特定的操作要求，这应该比仅仅改进向最终用户显示的信息更重要。
Note, there is no "OPTS MLSD" command, the fact names set with the "OPTS MLST" command apply to both MLST and MLSD commands.
注意，没有“OPTS MLSD”命令，使用“OPTS MLST”命令设置的事实名称同时适用于MLST和MLSD命令。
Servers are not required to accept "OPTS MLST" commands before authentication of the user-PI, but may choose to permit them.
在验证用户PI之前，服务器不需要接受“OPTS MLST”命令，但可以选择允许它们。
The "response-message" from [6] to a successful OPTS MLST command has the following syntax.
从[6]到成功的OPTS MLST命令的“响应消息”具有以下语法。
mlst-opt-resp = "MLST OPTS" [ SP 1*( factname ";" ) ]
mlst-opt-resp = "MLST OPTS" [ SP 1*( factname ";" ) ]
This defines the "response-message" as used in the "opts-good" message in RFC 2389 [6].
这定义了RFC 2389[6]中“opts good”消息中使用的“响应消息”。
The facts named in the response are those that the server will now include in MLST (and MLSD) response, after the processing of the "OPTS MLST" command. Any facts from the request not supported by the server will be omitted from this response message. If no facts will be included, the list of facts will be empty. Note that the list of facts returned will be the same as those marked by a trailing asterisk ("*") in a subsequent FEAT command response. There is no requirement that the order of the facts returned be the same as that in which they were requested, or that in which they will be listed in a FEAT command response, or that in which facts are returned in MLST responses. The fixed string "MLST OPTS" in the response may be returned in any case, or mixture of cases.
响应中命名的事实是服务器在处理“OPTS MLST”命令后，现在将包含在MLST（和MLSD）响应中的事实。此响应消息中将忽略服务器不支持的请求中的任何事实。如果不包括任何事实，则事实列表将为空。请注意，返回的事实列表将与后续FEAT命令响应中用尾随星号（“*”）标记的事实列表相同。不要求返回事实的顺序与请求的顺序相同，也不要求在FEAT命令响应中列出事实的顺序相同，也不要求在MLST响应中返回事实的顺序相同。响应中的固定字符串“MLST OPTS”可以在任何情况下返回，也可以混合返回。
C> Feat
S> 211- Features supported
S> MLST Type*;Size;Modify*;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> OptS Mlst Type;UNIX.mode;Perm;
S> 200 MLST OPTS Type;Perm;UNIX.mode;
C> Feat
S> 211- Features supported
S> MLST Type*;Size;Modify;Perm*;Unique;UNIX.mode*;UNIX.chgd;X.hidden;
S> 211 End
C> opts MLst lang;type;charset;create;
S> 200 MLST OPTS Type;
C> Feat
C> Feat
S> 211- Features supported
S> MLST Type*;Size;Modify*;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> OptS Mlst Type;UNIX.mode;Perm;
S> 200 MLST OPTS Type;Perm;UNIX.mode;
C> Feat
S> 211- Features supported
S> MLST Type*;Size;Modify;Perm*;Unique;UNIX.mode*;UNIX.chgd;X.hidden;
S> 211 End
C> opts MLst lang;type;charset;create;
S> 200 MLST OPTS Type;
C> Feat
S> 211- Features supported
S> MLST Type*;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> OPTS mlst size;frogs;
S> 200 MLST OPTS Size;
C> Feat
S> 211- Features supported
S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> opts MLst unique type;
S> 501 Invalid MLST options
C> Feat
S> 211- Features supported
S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
S> 211- Features supported
S> MLST Type*;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> OPTS mlst size;frogs;
S> 200 MLST OPTS Size;
C> Feat
S> 211- Features supported
S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> opts MLst unique type;
S> 501 Invalid MLST options
C> Feat
S> 211- Features supported
S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
For the purposes of this example, features other than MLST have been deleted from the output to avoid clutter. The example shows the initial default feature output for MLST. The facts requested are then changed by the client. The first change shows facts that are available from the server being selected. Subsequent FEAT output shows the altered features as being returned. The client then attempts to select some standard features that the server does not support. This is not an error, however the server simply ignores the requests for unsupported features, as the FEAT output that follows shows. Then, the client attempts to request a non-standard, and unsupported, feature. The server ignores that, and selects only the supported features requested. Lastly, the client sends a request containing a syntax error (spaces cannot appear in the factlist.) The server-FTP sends an error response and completely ignores the request, leaving the fact set selected as it had been previously.
在本例中，已从输出中删除MLST以外的功能，以避免混乱。该示例显示了MLST的初始默认特性输出。客户随后会更改请求的事实。第一个更改显示可从所选服务器获得的事实。随后的专长输出显示被改变的特征被返回。然后，客户端尝试选择服务器不支持的一些标准功能。这不是一个错误，但是服务器只是忽略对不受支持的功能的请求，如下面的FEAT输出所示。然后，客户端尝试请求非标准且不受支持的功能。服务器会忽略这一点，并仅选择请求的受支持功能。最后，客户端发送一个包含语法错误的请求（事实列表中不能出现空格）。服务器FTP发送一个错误响应并完全忽略该请求，使事实集保持先前的选中状态。
Note that in all cases, except the error response, the response lists the facts that have been selected.
请注意，在所有情况下，除了错误响应之外，响应都会列出已选择的事实。
C> Feat
S> 211- Features supported
S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> Opts MLST
S> 200 MLST OPTS
C> Feat
S> 211- Features supported
S> MLST Type;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> MLst tmp
S> 250- Listing tmp
S> /tmp
C> Feat
S> 211- Features supported
S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> Opts MLST
S> 200 MLST OPTS
C> Feat
S> 211- Features supported
S> MLST Type;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
S> 211 End
C> MLst tmp
S> 250- Listing tmp
S> /tmp
S> 250 End
C> OPTS mlst unique;size;
S> 200 MLST OPTS Size;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Unique=keVO1+YZ5; /tmp
S> 250 End
C> OPTS mlst unique;type;modify;
S> 200 MLST OPTS Type;Modify;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Type=dir;Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
C> OPTS mlst fish;cakes;
S> 200 MLST OPTS
C> MLst tmp
S> 250- Listing tmp
S> /tmp
S> 250 End
C> OptS Mlst Modify;Unique;
S> 200 MLST OPTS Modify;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
C> opts MLst fish cakes;
S> 501 Invalid MLST options
C> MLst tmp
S> 250- Listing tmp
S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
S> 250 End
C> OPTS mlst unique;size;
S> 200 MLST OPTS Size;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Unique=keVO1+YZ5; /tmp
S> 250 End
C> OPTS mlst unique;type;modify;
S> 200 MLST OPTS Type;Modify;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Type=dir;Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
C> OPTS mlst fish;cakes;
S> 200 MLST OPTS
C> MLst tmp
S> 250- Listing tmp
S> /tmp
S> 250 End
C> OptS Mlst Modify;Unique;
S> 200 MLST OPTS Modify;Unique;
C> MLst tmp
S> 250- Listing tmp
S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
C> opts MLst fish cakes;
S> 501 Invalid MLST options
C> MLst tmp
S> 250- Listing tmp
S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp
S> 250 End
This example shows the effect of changing the facts requested upon subsequent MLST commands. Notice that a syntax error leaves the set of selected facts unchanged. Also notice exactly two spaces preceding the pathname when no facts were selected, either deliberately, or because none of the facts requested were available.
此示例显示了更改后续MLST命令所请求事实的效果。请注意，语法错误使所选事实集保持不变。另外，请注意，如果故意或因为请求的事实不可用而未选择任何事实，则路径名前面正好有两个空格。
Along with the introduction of MLST, traditional FTP commands must be extended to allow for the use of more than US-ASCII [1] or EBCDIC character sets. In general, the support of MLST requires support for arbitrary character sets wherever file names and directory names are allowed. This applies equally to both arguments given to the following commands and to the replies from them, as appropriate.
随着MLST的引入，必须扩展传统的FTP命令，以允许使用超过US-ASCII[1]或EBCDIC字符集。通常，MLST的支持要求在允许文件名和目录名的地方支持任意字符集。这同样适用于为以下命令提供的参数和它们的回复（视情况而定）。
APPE RMD CWD RNFR DELE RNTO MKD STAT PWD STOR RETR STOU
附录D CWD RNFR DELE RNTO MKD STAT PWD STOR RETR STOU
The arguments to all of these commands should be processed the same way that MLST commands and responses are processed with respect to handling embedded spaces, CRs and NULs. See section 2.2.
处理所有这些命令的参数的方式应与处理嵌入空格、CRs和NUL时处理MLST命令和响应的方式相同。见第2.2节。
FTP commands are protocol elements, and are always expressed in ASCII. FTP responses are composed of the numeric code, which is a protocol element, and a message, which is often expected to convey information to the user. It is not expected that users normally interact directly with the protocol elements, rather the user-FTP process constructs the commands, and interprets the results, in the manner best suited for the particular user. Explanatory text in responses generally has no particular meaning to the protocol. The numeric codes provide all necessary information. Server-PIs are free to provide the text in any language that can be adequately represented in ASCII, or where an alternative language and representation has been negotiated (see [7]) in that language and representation.
FTP命令是协议元素，始终以ASCII表示。FTP响应由数字代码和消息组成，数字代码是协议元素，消息通常用于向用户传递信息。用户通常不会直接与协议元素交互，而是由用户FTP进程以最适合特定用户的方式构造命令并解释结果。答复中的解释性文本通常对议定书没有特殊意义。数字代码提供了所有必要的信息。服务器PI可以自由地提供任何语言的文本，这些语言可以用ASCII充分表示，或者可以用该语言和表示协商其他语言和表示（见[7]）。
Pathnames are expected to be encoded in UTF-8 allowing essentially any character to be represented in a pathname. Meaningful pathnames are defined by the server NVFS.
路径名应采用UTF-8编码，允许在路径名中表示基本上任何字符。有意义的路径名由服务器NVFS定义。
No restrictions at all are placed upon the contents of files transferred using the FTP protocols. Unless the "media-type" fact is provided in a MLSx response nor is any advice given here that would allow determining the content type. That information is assumed to be obtained via other means.
对使用FTP协议传输的文件内容没有任何限制。除非MLSx响应中提供了“媒体类型”事实，否则此处也没有给出任何允许确定内容类型的建议。假定该信息是通过其他方式获得的。
This specification makes use of some lists of values currently maintained by the IANA, and creates two new lists for the IANA to maintain. It does not add any values to any existing registries.
本规范使用了IANA当前维护的一些值列表，并为IANA创建了两个要维护的新列表。它不会向任何现有注册表添加任何值。
The existing IANA registries used by this specification are modified using mechanisms specified elsewhere.
本规范使用的现有IANA注册表使用其他地方指定的机制进行修改。
A registry of OS specific fact names shall be maintained by the IANA. The OS names for the OS portion of the fact name must be taken from the IANA's list of registered OS names. To add a fact name to this OS specific registry of OS specific facts, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific fact name, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values. Upon receipt of such an application, and if the combination of OS name and OS specific fact name has not been previously defined, the IANA will add the specification to the registry.
IANA应维护操作系统特定事实名称的登记册。事实名称中OS部分的OS名称必须取自IANA的注册OS名称列表。要向特定于操作系统的事实的特定于操作系统的注册表添加事实名称，申请人必须向IANA发送一个请求，其中指定了操作系统名称、特定于操作系统的事实名称、事实值语法的定义，该定义必须符合本文档中给出的令牌语法，以及与特定事实及其值关联的语义规范。收到此类应用程序后，如果之前未定义操作系统名称和操作系统特定事实名称的组合，IANA将向注册表添加规范。
Any examples of OS specific facts found in this document are to be treated as examples of possible OS specific facts, and do not form a part of the IANA's registry merely because of being included in this document.
本文件中发现的任何操作系统特定事实的示例应被视为可能的操作系统特定事实的示例，并且不会仅仅因为包含在本文件中而成为IANA注册的一部分。
A registry of OS specific file types shall be maintained by the IANA. The OS names for the OS portion of the fact name must be taken from the IANA's list of registered OS names. To add a file type to this OS specific registry of OS specific file types, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific file type, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values. Upon receipt of such an application, and if the combination of OS name and OS specific file type has not been previously defined, the IANA will add the specification to the registry.
IANA应维护操作系统特定文件类型的注册表。事实名称中OS部分的OS名称必须取自IANA的注册OS名称列表。要将文件类型添加到此操作系统特定文件类型的操作系统特定注册表，申请人必须向IANA发送一个请求，其中指定了操作系统名称、操作系统特定文件类型、事实值语法定义，该定义必须符合本文档中给出的令牌语法，以及与特定事实及其值关联的语义规范。收到此类应用程序后，如果之前未定义操作系统名称和操作系统特定文件类型的组合，IANA将向注册表添加规范。
Any examples of OS specific file types found in this document are to be treated as potential OS specific file types only, and do not form a part of the IANA's registry merely because of being included in this document.
本文件中发现的任何特定于操作系统的文件类型示例仅被视为潜在的特定于操作系统的文件类型，并且不会仅仅因为包含在本文件中而成为IANA注册表的一部分。
This memo does not directly concern security. It is not believed that any of the mechanisms documented here impact in any particular way upon the security of FTP.
本备忘录不直接涉及安全问题。这里记录的任何机制都不会以任何特定方式影响FTP的安全性。
Implementing the SIZE command, and perhaps some of the facts of the MLSx commands, may impose a considerable load on the server, which could lead to denial of service attacks. Servers have, however, implemented this for many years, without significant reported difficulties.
实现SIZE命令，以及MLSx命令的某些事实，可能会给服务器带来相当大的负载，从而导致拒绝服务攻击。然而，服务器已经实施了多年，没有出现重大困难。
The server-FTP should take care not to reveal sensitive information about files to unauthorised parties. In particular, some underlying filesystems provide a file identifier that, if known, can allow many of the filesystem protection mechanisms to be by-passed. That identifier would not be a suitable choice to use as the basis of the value of the unique fact.
FTP服务器应注意不要将有关文件的敏感信息泄露给未经授权的方。特别是，一些底层文件系统提供了一个文件标识符，如果已知，它可以允许许多文件系统保护机制被旁路。该标识符不是用作唯一事实价值基础的合适选择。
The FEAT and OPTS commands may be issued before the FTP authentication has occurred [6]. This allows unauthenticated clients to determine which of the features defined here are supported, and to negotiate the fact list for MLSx output. No actual MLSx commands may be issued however, and no problems with permitting the selection of the format prior to authentication are foreseen.
FEAT和OPTS命令可能在FTP身份验证发生之前发出[6]。这允许未经验证的客户端确定此处定义的哪些功能受支持，并协商MLSx输出的事实列表。但是，可能不会发出实际的MLSx命令，并且在认证之前允许选择格式不会出现问题。
A general discussion of issues related to the security of FTP can be found in [13].
关于FTP安全相关问题的一般性讨论见[13]。
[1] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[1] 编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986。
[2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.
[2] “UTF-8，ISO 10646的转换格式”，RFC 3629，2003年11月。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[3] Postel，J.和J.Reynolds，“文件传输协议（FTP）”，标准9，RFC 959，1985年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[5] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[6] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[6] Hethmon，P.和R.Elz，“文件传输协议的特征协商机制”，RFC 2389，1998年8月。
[7] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.
[7] Curtin，B.，“文件传输协议的国际化”，RFC 26401999年7月。
[8] Postel, J. and J. Reynolds, "Telnet protocol Specification", STD 8, RFC 854, May 1983.
[8] Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[9] Braden, R,. "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[9] 布拉登，R，。“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[10] ISO/IEC 10646-1:1993 "Universal multiple-octet coded character set (UCS) -- Part 1: Architecture and basic multilingual plane", International Standard -- Information Technology, 1993.
[10] ISO/IEC 10646-1:1993“通用多八位编码字符集（UCS）——第1部分：体系结构和基本多语言平面”，国际标准——信息技术，1993年。
[11] Internet Assigned Numbers Authority. http://www.iana.org Email: iana@iana.org.
[11] 互联网分配号码管理局。http://www.iana.org 电邮：iana@iana.org.
[12] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[12] Phillips，A.和M.Davis，“识别语言的标签”，BCP 47，RFC 46462006年9月。
[13] Allman, M. and S. Ostermann, "FTP Security Considerations" RFC 2577, May 1999.
[13] Allman，M.和S.Ostermann，“FTP安全注意事项”RFC 2577，1999年5月。
Acknowledgments
致谢
This document is a product of the FTPEXT working group of the IETF.
本文件是IETF FTPEXT工作组的产品。
The following people are among those who have contributed to this document:
以下人员参与了本文件的编写：
Alex Belits D. J. Bernstein Dave Cridland Martin J. Duerst Bill Fenner (and the rest of the IESG) Paul Ford-Hutchinson Mike Gleason Mark Harris Stephen Head Alun Jones Andrew Main James Matthews Luke Mewburn Jan Mikkelsen Keith Moore Buz Owen Mark Symons Stephen Tihor and the entire FTPEXT working group of the IETF.
Alex Belits D.J.Bernstein Dave Cridland Martin J.Duerst Bill Fenner（和IESG的其他成员）Paul Ford Hutchinson Mike Gleason Mark Harris Stephen Head Alun Jones Andrew Main James Matthews Luke Mewburn Jan Mikkelsen Keith Moore Buz Owen Mark Symons Stephen Tihor和IETF的整个FTPEXT工作组。
Apologies are offered to any inadvertently omitted.
对于任何疏忽大意的疏忽，我们表示歉意。
The description of the modifications to the REST command and the MDTM and SIZE commands comes from a set of modifications suggested for STD 9, RFC 959 by Rick Adams in 1989. A document containing just those commands, edited by David Borman, has been merged with this document.
对REST命令、MDTM和SIZE命令修改的描述来自Rick Adams在1989年为STD 9、RFC 959建议的一组修改。由David Borman编辑的仅包含这些命令的文档已与此文档合并。
Mike Gleason, Alun Jones and Luke Mewburn provided access to FTP servers used in some of the examples.
Mike Gleason、Alun Jones和Luke Mewburn提供了对一些示例中使用的FTP服务器的访问。
All of the examples in this document are taken from actual client/server exchanges, though some have been edited for brevity, or to meet document formatting requirements.
本文档中的所有示例均取自实际的客户机/服务器交换，但有些示例已进行编辑，以简化或满足文档格式要求。
RFC Editor Note:
RFC编者注：
Several of the examples in this document exceed the RFC standard line length of 72 characters. Since this document is a standards-track result of an IETF working group and is important to an IETF sub-community, the RFC Editor is publishing it with the margin violations. This is not a precedent.
本文档中的几个示例超过了72个字符的RFC标准行长度。由于本文件是IETF工作组的标准跟踪结果，并且对IETF子社区很重要，RFC编辑将其发布为违反边距的文件。这不是先例。
Author's Address
作者地址
Paul Hethmon Hethmon Software 10420 Jackson Oaks Way, Suite 201 Knoxville, TN 37922
Paul Hethmon Hethmon软件田纳西州诺克斯维尔市杰克逊橡树路10420号201室37922
EMail: phethmon@hethmon.com
EMail: phethmon@hethmon.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
本文件受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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。