Network Working Group
P. Hethmon
Hethmon Software
Request for Comments: 3659
Updates: 959
March 2007
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命令，以获得远程目录的列表，这些列表具有定义的格式，并允许在STREAM模式下重新启动中断的数据传输。它允许使用除US-ASCII之外的字符集，并且还定义了一个可选的虚拟文件存储结构。
1. Introduction 引言
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 trFTP的扩展ansfer 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）的一个可选结构，允许支持这种结构的服务器以标准方式将该信息传达给客户端，从而允许客户端在构建和解释路径名时更加确定。
2. Document Conventions 文档约定
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]中定义的文档约定。这提供了大写命令词如MUST、SHOULD等的解释。
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定义将在本节后面定义。首次阅读时，最好简单记住这些定义的存在，并跳到下一节。
2.1. Basic Tokens 基础标记
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定义。在那里可以找到像ALPHA、DIGIT、SP等基础ABNF元素的定义。以下术语被添加到本文档中使用。
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
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特别是区分大小写的。这意味着“标记”是一个区分大小写的值。除非本文档或其他一些定义本文档指定在特定上下文中使用的值的规范中明确指出相反的情况，否则这种推论是正确的。
2.2. Pathnames 路径名
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>
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节。
2.2.1 Pathname Syntax 路径名语法
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需要理解所有可能的路径名。服务器-PI可以以任何适合其实现或底层文件系统的方式限制其NVFS中有效路径名的语法。同样，服务器-PI可能会解析路径名并为检测到的组件分配含义。
2.2.2 Wildcarding 通配符
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.
希望某种形式的模式匹配功能的客户端必须获取相关目录的列表，或目录，并实施自己的文件名选择程序。
2.3. Times 时间
The syntax of a time value is:
时间值的语法为：
time-val = 14DIGIT [ "." 1*DIGIT ]
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.
可选的数字，前面有一个句点，表示秒的小数部分。这些数字可以根据情况以适当的精度给出，但是实现在传输的底层值中不存在该精度时，不得增加time-vals的精度。
Symbolically, a time-val may be viewed as
符号上，一个time-val可以视为
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进程应始终使用相同的时间参考，因此它返回的时间将是一致的。客户端不期望与服务器时间同步，因此可能由不同的时间标准报告的时间差异不被认为重要。
2.4. Server Replies 服务器回复
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
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相关的文档中使用的ABNF语法（但在[3]中未使用），有时显示回复使用单行格式。除非另有明确说明，这并不意味着不允许多行回应。实现者应假定，除非有相反的说明，对任何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”的回复。
2.5. Interpreting Examples 解读示例
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的，并在发送后立即关闭的。这里没有示例显示从客户端到服务器通过数据连接传输的数据。在所有情况下，上述前缀，包括一个空格，都是为了本文档的目的而添加的，并不是客户端和服务器之间交换的数据的一部分。
3. File Modification Time 文件修改时间 (MDTM)
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服务器多年来都存在此命令，作为STREAM模式下REST命令的辅助功能，因此广泛可用。然而，如果支持，建议使用新的MLST命令结果中可以提供的“modify”事实作为更好的替代方案。
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.
当尝试重新启动RETRieve时，用户-FTP可以使用MDTM命令或“modify”事实来检查源文件的修改时间是否比部分传输文件的修改时间更新。如果是，那么很可能源文件已更改，重新启动先前未完成的文件传输将是不安全的。
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通常应在初始RETRieval之前从服务器获取文件的修改时间，并在RESTart之前比较这两个时间。如果它们不同，文件可能已更改，而RESTart将是不明智的。如果这不可能，用户-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. 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.
当尝试重新启动STORe时，用户FTP可以使用MDTM命令发现部分传输文件的修改时间。如果它比即将STORed的文件的修改时间旧，那么很可能源文件已更改，重新启动文件传输将是不安全的。请注意，使用MLST（下文将描述），在可用的情况下，可以提供这些信息并且更多，因此提供了更好的指示，表明文件已更改，重新启动传输将不会产生有效结果。
Note that this is applicable to any RESTart attempt, regardless of the mode of the file transfer.
注意，这适用于任何RESTart尝试，无论文件传输的模式如何。
3.1. Syntax 语法
The syntax for the MDTM command is:
MDTM命令的语法如下：
mdtm = "MdTm" SP pathname 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命令对象的对象。尝试查询存在但无法检索的文件的修改时间可能会生成错误响应，或者可以产生一个带有未指定值的time-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-response = "213" SP time-val CRLF /
error-response
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响应时，即没有错误时，格式必须完全按照指定的格式。不允许多行响应。
3.2. Error Responses 错误响应
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回复。
3.3. FEAT Response for MDTM 对MDTM的FEAT响应
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
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]。
3.4. MDTM Examples MDTM示例
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.
如果我们假设存在三个文件A、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.
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.
时间是GMT，所以文件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”的文件。
4. File 文件大小 SIZE
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），用于从服务器-FTP进程获取文件的传输大小。这是传输该文件时将通过数据连接传输的确切八位字节（8位字节）数。这个值会根据当前的数据连接或现在将要创建的数据连接的STRUcture（结构）、MODE（模式）和TYPE（类型）而变化。因此，SIZE命令的结果取决于当前建立的STRU、MODE和TYPE参数。
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命令返回如果使用当前传输结构、模式和类型传输文件将会传输多少八位字节。这个命令通常与重启（REST）命令一起使用，当以STREAM模式向远程服务器存储文件时，用于确定重启点。服务器-PI可能需要读取部分传输的文件，进行任何适当的转换，并计算发送文件时将生成的八位字节数，以便正确响应此命令。必须返回文件传输大小的精确信息，不得返回估计值。
4.1. Syntax 语法
The syntax of the SIZE command is:
SIZE命令的语法为：
size = "Size" SP pathname 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命令，给出提供路径名的文件的传输大小，或者如果文件不存在、大小不可用或发生了其他错误，则返回错误响应。返回的值适合与重启（REST）命令一起使用，用于模式STREAM，前提是传输模式和类型未被更改。
size-response = "213" SP 1*DIGIT CRLF /
error-response
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响应时，即没有错误时，格式必须完全按照指定的格式。不允许多行响应。
4.2. Error Responses 错误响应
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.
如果命令解析正确但大小不可用，可能是因为路径名没有标识现有实体或因为在当前MODE和TYPE（或根本无法）中无法传输命名实体，则应发送550回复。如果命令无法正确解析，则应发送500或501回复，如[3]中所指定。客户端不得将对SIZE命令的550错误响应视为在当前MODE和TYPE中无法传输文件的指示。服务器可能因其他原因生成此错误——例如，如果认为处理开销太大。在适当的情况下，也可能发出各种4xy回复。
4.3. FEAT Response for SIZE 对SIZE的FEAT响应
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
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]。
4.4. Size Examples 大小示例
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)服务器上的文本文件“Example”，其中每个行尾由一个单八位字节表示。假设文件包含112行，总共1830八位字节。然后SIZE命令将产生：
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
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的传输提供正确的行尾语义。其他系统在转换TYPE和MODE时，可能需要对文件的传输格式进行其他更改。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命令的“Size”事实（见第7.5.7节）。
5. Restart of Interrupted Transfer 中断传输的重启 (REST)
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]包括三种数据传输模式：STREAM（流式）、Block（块）和Compressed（压缩）。在Block和Compressed模式中，通过数据连接传输的数据流是格式化的，允许将重启标记嵌入到流中。发送DTP可以包含一个重启标记，并附带它需要的任何信息，以便能够在那一点重启文件传输。接收DTP可以保留这些重启标记的列表，并将它们与文件的保存方式相关联。要重启文件传输，接收者只需发送回最后一个重启标记，双方都知道如何恢复数据传输。注意，STD 9, RFC 959 [3]中对重启机制的描述有一些缺陷。关于更正，请参见RFC 1123 [9]的第4.1.3.4节。
5.1. Restarting in STREAM Mode 在STREAM模式下重启
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.
在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.
因为在STREAM模式下，数据流定义了文件，不同的数据流将代表不同的文件。因此，偏移量将始终代表文件中的相同位置。另一方面，在STREAM模式之外的其他模式中，相同的文件可以使用完全不同的八位字节序列传输，并且仍然被重构成同一个文件。因此，在非STREAM传输模式下的数据流中的偏移量不会给出一个明确的重启点。
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.
如果数据表示类型为IMAGE且结构为File，对于许多系统，文件将以与其通过数据连接发送的格式完全相同的格式存储。然后，接收者通常很容易确定之前接收了多少数据，并通知发送者应在何处重启传输。在其他表示类型和结构中，将需要更多努力，但始终有可能以有限但可能不可忽视的努力确定偏移量。在最坏的情况下，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节所述。
5.2. Error Recovery and Restart 错误恢复和重启
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.
即使没有除了数据本身之外传输重启标记，也可以重新启动STREAM模式和FILE结构的传输。这是通过在需要时结合使用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 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.
当使用TYPE ASCII或IMAGE时，SIZE命令将返回如果文件要在两个系统之间发送，实际会传输多少八位字节，即，使用IMAGE类型时，SIZE通常会是文件中的八位字节数量。使用ASCII类型时，SIZE将是文件中的八位字节数量，包括满足TYPE ASCII CR-LF行尾约定所需的任何修改。
5.3. Syntax 语法
The syntax for the REST command when the current transfer mode is STREAM is:
当前传输模式为STREAM时，REST命令的语法是：
rest = "Rest" SP 1*DIGIT 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
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（存储唯一文件）在此用法中未定义，因为将文件的剩余部分存储到唯一文件名中很少会有用。如果允许APPE（追加），它必须与设置了重启标记的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. 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命令旨在完成失败的传输。与RETR的使用在所有情况下相对明确定义，因为客户端负责将检索到的数据与部分检索到的文件合并。它可能选择使用获取的数据完成之前的传输，或重新检索之前已检索的数据。然而，对于STOR，服务器必须将数据插入到命名的文件中。如果客户端使用REST来完成之前未能完全传输的文件的传输而不是重启，结果是未定义的。特别是，如果用REST命令设置的重启标记不在服务器报告的当前存储数据的末尾，或者如果在REST之后的STOR中提供的数据不足以将目标文件扩展到至少其先前的大小，则效果是未定义的。REST命令必须是在导致重启而非完整文件传输的数据传输命令之前发出的最后一个命令。在其他任何时间发出REST命令的效果是未定义的。服务器-PI可能通过对随后的命令（不是可重启的数据传输命令）发出错误响应，或者保存重启值并将其应用于下一个数据传输命令，或者可能会默默忽略不适当的重启尝试来响应位置不当的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命令之后只有在服务器不实现该命令，或当重启标记值在当前传输模式下语法无效时（例如，在STREAM模式下，REST命令的参数中出现了一个或多个数字之外的内容），才会跟随一个错误响应。任何其他错误，包括重启标记超出范围等问题，应在发出随后的传输命令时报告。这样的错误将导致该传输请求被拒绝，并伴随表示重启尝试无效的错误。
5.4. FEAT Response for REST 对REST的FEAT响应
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进程如此处指定的那样支持STREAM模式下的RESTart，它必须在对FEAT命令[6]的响应中包含一个包含字符串"REST STREAM"的行。这个字符串不区分大小写，但应以大写形式传输。如果根本不支持REST或仅在块或压缩模式下支持，FEAT响应中必须不包括REST行。在需要时，响应应该是：
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]。
5.5. REST Example
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八位字节后被中断，之前的传输使用的是TYPE=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.
6. A Trivial Virtual File Store 简单虚拟文件存储 (TVFS)
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），则提供了该机制。
6.1. TVFS File Names 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.
除了”/“字符外，任何有效的IS10646字符[10]都可以用于TVFS文件名。传输时，文件名字符使用UTF-8编码[2]。请注意，文件名中出现的两个字符序列CR LF将使该名称无法通过数据连接传输。因此，应避免使用它，如果这无法实现，则必须以某种可逆方式编码。
6.2. TVFS Pathnames TVFS路径名
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.
作为特例，路径名“/”被定义为指向根目录的完全限定路径名。也就是说，根目录没有目录（或文件）名称，但确实有一个路径名。这个特殊的路径名只能作为对根目录的引用而使用。它不能使用上述规则与其他路径名组合，因为这样会导致包含两个连续“/”字符的路径名，这是未定义的序列。
6.2.1 Notes 注释
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 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.
虽然任何合法的IS10646字符都允许出现在TVFS文件或目录名称中，除了“/”，但服务器FTP实现不需要支持所有可能的IS10646字符。支持的子集完全由服务器自行决定。构成文件、目录和路径名的字符的大小写（如果存在）可能是重要的。除非通过此处未指定的其他方式确定，客户端应假设所有这些名称都由大小写敏感的字符组成。服务器可以将名称的大小写（或任何其他属性）视为不相关，因此将两个看似不同的名称映射到同一个底层文件上。
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没有对文件施加特定的语义或属性，不保证访问控制方案或文件存储的其他常见属性。只定义了命名方案。
6.3. FEAT Response for TVFS 对TVFS的FEAT响应
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
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命令库中添加新命令。
6.4. OPTS for TVFS 对TVFS的OPTS
There are no options in this TVFS specification, and hence there is no OPTS command defined.
此TVFS规范中没有选项，因此没有定义OPTS命令。
6.5. TVFS Examples TVFS示例
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
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
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.
很明显，路径/ /A /B 或 /A/D都不指向相同的目录，因为每个目录的内容都不同。/ /A /A/C 或 /A/D也不相同。然而，/A/C 和 /B 可能是相同的目录，给定的信息不足以判断。其他任何路径名（/X /Y /A/Z /A/C/P /A/C/Q /B/P 和 /B/Q）可能指向相同的底层文件，几乎可以是任何组合。
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
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
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相对路径。
7. Listings for Machine Processing 面向机器处理的列表 (MLST and MLSD)
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和“原始”形式作为参数，并在对MLST和MLSD命令的响应中，以及所有其他接受路径名作为参数的FTP命令中，都允许这两种形式。
7.1. Format of MLSx Requests MLSx请求的格式
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 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.
如果没有给出参数，则MLSD必须返回当前工作目录的内容列表，而MLST必须返回关于当前工作目录本身的信息列表。出于这些目的，目录的内容是服务器-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
7.2. Format of MLSx Response MLSx响应的格式
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
control-response = "250-" [ response-message ] CRLF
1*( SP entry CRLF )
"250" [ SP response-message ] CRLF
initial-response = "150" [ SP response-message ] CRLF
final-response = "226" SP response-message CRLF
response-message = *TCHAR
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
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将发送控制响应的第一行（前导行），给定路径名的条目，或当前目录（如果没有提供路径名），以及终止行。通常会返回恰好一个条目，只有在需要返回具有多个“Type”事实的文件时，才允许更多条目。在这种情况下，每个响应的路径名组件必须是相同的。
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响应打开的数据连接应该是如同已经给出了“TYPE L 8”、“MODE 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
...
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页）。没有要求为每个文件提供相同的事实集，或者事实呈现的顺序对每个文件都相同。
7.2.1. Error Responses to MLSx commands 对MLSx命令的错误响应
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回复）也可能在适当的情况下出现。
7.3. File Name Encoding 文件名编码
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 names. FTP implementations SHOULD use UTF-8 whenever possible to encourage the maximum inter-operability.
支持MLSx命令的FTP实现必须是8位清洁的。这是为了传输UTF-8编码的文件名所必需的。本规范推荐使用UTF-8编码的文件名。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]。
7.3.1. Notes about the File Name 关于文件名的注释
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. 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可以通过将类型为“cdir”的名称与目录列表中的适当名称结合使用，按照第6.2节中定义的程序来引用列表中的任何文件或目录。或者，无论是否支持TVFS，用户-PI都可以发出CWD命令（[3]），给出列表中的类型为“cdir”的名称，并从获得cdir的MLSD响应中引用返回的文件，使用列表的文件名组件。
7.4. Format of Facts 事实的格式
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;
7.5. Standard Facts 标准事实
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)
Fact names are case-insensitive. Size, size, SIZE, and SiZe are the same fact.
事实名称不区分大小写。Size、size、SIZE和SiZe是相同的事实。
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)
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
7.5.1. The Type Fact 类型事实
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
The syntax is defined to be:
语法定义为：
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.
类型事实的值（“type-val”）是一个不区分大小写的字符串。
7.5.1.1. type=file
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事实的存在表明列出的条目是包含非系统数据的文件。也就是说，它可能从一个系统传输到另一个具有完全不同特性的系统，并且可能仍然有意义。
7.5.1.2. type=cdir
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 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.
type=cdir事实表明列出的条目包含列出内容的目录的路径名。当包括类型事实并且作为MLSD命令结果的一部分返回时，才会返回此类型的条目，它为列出的目录提供一个名称和有关该目录的事实。在某种意义上，它可以被视为以机器友好格式表示的列表标题。它可以出现在列表的任何点，不限于出现在开头，尽管经常可能这样做，并且可能出现多次。如果未包含类型事实，则不得包含它，否则用户-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的当前目录更改为其当前工作目录中列出的目录。
7.5.1.3. type=dir
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命令的对象。
7.5.1.4. type=pdir
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.
仅当包括类型事实并且响应MLSD命令时，才会出现type=pdir条目，它代表列出目录的父目录的路径名。除了具有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类型的实体都指向同一个目录。如果支持并提供了"unique"事实（见下一节），可以使用它来确定type=pdir条目之间是否存在关系。
7.5.1.5. System Defined Types 系统定义的类型
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
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-name"指示支持特定localtype的特定系统类型。特定于操作系统的类型由IANA使用第10节中指定的程序注册。“os-kind"提供了关于列出文件的类型的系统依赖信息。os-type中的os-name和os-kind字符串不区分大小写。“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中多次出现，每次都包含相同的"unique"事实值（见下一节），表明所有这些名称都代表同一个文件。用户-PI在传输文件时，然后只需传输一次，然后插入他们自己形式的间接引用来构造所需的备用名称，或者如果这是提供具有相同内容的两个名称的唯一方式，甚至可能复制本地文件。如果一个文件将是对另一个文件的引用，只有如果另一个文件实际存在，可能以任何适当的操作系统依赖方式表示，或根本不表示。
7.5.1.6. Multiple Types 多种类型
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 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.
如果一个文件是这样的，服务器-PI可以有效且合理地将其视为多种上述类型之一，那么应该返回多个条目，每个条目都有其自己的适当类型的"Type"事实，并且每个条目都包含相同的路径名。例如，对于可能包含子文件的结构化文件，当服务器-PI允许将结构化文件作为一个单元处理，或者将其视为目录以引用其中的子文件时，可能会发生这种情况。当这样做时，与每个条目返回的路径名必须与代表同一个文件的其他条目完全相同。
7.5.2. The unique Fact 唯一事实
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可以预期使用此事实，其主机系统允许诸如符号链接之类的东西，因此同一个文件可能在服务器上的多个目录中表示。唯一应该得出的结论是，如果两个不同的名称具有相同的唯一事实值，它们就引用相同的底层对象。唯一事实的值（令牌）应被视为比较目的的不透明字符串，它是一个依赖于大小写的值。令牌"A"和"a"不代表相同的底层对象。
7.5.3. The modify Fact 修改事实
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
7.5.4. The create Fact 创建事实
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）实现通常不会包括此事实。
7.5.5. The perm Fact 权限事实
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"
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"权限适用于type=file类型的对象，并表明可以对命名的文件应用APPE（追加）命令。
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"权限适用于type=dir（以及type=pdir, type=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 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.)
“e"权限适用于目录类型。当设置在type=dir、type=cdir或type=pdir类型的对象上时，它表示命名对象的CWD命令应成功，并且用户应能够进入命名的目录。对于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"权限适用于目录文件类型，并表明可以对有问题的目录应用列表命令，LIST、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. 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.
实现注意事项：这里描述的权限是如何应用于FTP命令的。它们可能不容易映射到服务器操作系统上可用的特定权限。服务器预计将从操作系统可用的权限信息中合成这些权限位。例如，为了正确确定是否应该在UNIX(TM)操作系统上运行的服务器的目录上设置“D”权限位，服务器应检查命名的目录是否为空，并且用户是否同时对所考虑的目录及其父目录具有写权限。某些系统可能具有比这里列出的更具体的权限，这些系统应尽可能最好地将这些映射到定义的标志上。其他系统可能只有更广泛的访问控制。它们通常只有几种可能的权限标志排列，但它们应尝试正确表示所允许的内容。
7.5.6. The lang Fact 语言事实
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.
语言事实描述了文件名的自然语言，用于显示目的。这里使用的值应该来自IANA的语言注册表。有关语言标签的语法和相关程序，请参见[12]。
lang-fact = "Lang" "=" token
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事实根本不提供有关文件内容的信息，只有关于其名称的编码。
7.5.7. The size Fact 大小事实
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
7.5.8. The media-type Fact 媒体类型事实
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>
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实现不得猜测媒体类型值。媒体类型值必须以明确的方式确定，例如通过文件系统标记媒体类型或通过用户配置。这个事实提供了有关命名文件内容的信息。应给出主要媒体类型和任何适当的子类型，两者之间用斜杠“/”分隔，如传统所示。
7.5.9. The charset Fact 字符集事实
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
7.5.10. Required Facts 必需的事实
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.
服务器不要求支持任何特定的事实集。然而，如果可能的话，服务器应至少支持type、perm、size、unique和modify事实。
7.6. System Dependent and Local Facts 系统依赖和本地事实
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传达有关命名文件的信息，这些信息特定于底层文件系统。
7.6.1. System Dependent Facts 系统依赖事实
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节中定义的“token”进行编码。
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节的程序完成。
7.6.2. Local Facts 本地事实
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.”开头。名称的其余部分是一个“token”（见第2.1节）。本地事实的值可以是任何内容，只要它可以被编码为一个“token”。
7.7. MLSx Examples MLSx示例
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 and server, not formats that would normally ever be reported to the user of the client.
在展示的示例中，只包含了相关的命令和响应。这并不意味着在实际连接中不会出现其他命令（包括身份验证、目录修改、PORT或PASV命令等），或者事实上在编辑之前示例中确实使用了这些命令。还要注意，展示的格式是客户端和服务器之间传输的格式，而不是通常会报告给客户端用户的格式。
7.7.1. Simple MLST 简单的MLST
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字节，尽管如果检索该文件可能会传输更多或更少的字节，并且客户端的文件存储可能需要不同数量的字节，并且连接的用户有权限检索文件，但没有权限做其他特别有趣的事情。
7.7.2. MLST of a directory 目录的MLST
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事实行显示列出的文件是一个目录，最后修改时间是1998年11月7日UTC的08:52:15，用户有权限进入目录，并列出其内容，但无法以任何方式修改它。同样，列出的目录的完全限定路径名也给出了。
7.7.3. MLSD of a directory 目录的MLSD
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”。这些显示了列出目录的两个备用名称，一个是完全限定路径名，另一个是相对于服务器当前目录的本地名称。请注意，输出中的所有其他文件名都是相对于列出的目录的，尽管服务器可以选择为"type=pdir"行给出完全限定的路径名。这个服务器选择不这样做。列出的其他文件呈现了列出目录中存在的相当无聊的文件集。请注意，它们没有按文件名、大小或修改时间排序。还要注意，文件"capmux.tar.z"的"perm"事实值为空，表明连接的用户对该文件没有任何权限。这个服务器选择在显示目录内容的行之前呈现"cdir"和"pdir"行，并非必须这样做。对于目录，“size"事实不提供任何有意义的信息，因此不包括在所示目录类型的事实行中。
7.7.4. A More Complex Example 更复杂的示例
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. 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.
为了本示例的目的，请求的事实集已被修改，删除了"size"和"modify"事实，并添加了"unique"事实。首先，通过MLST获得了关于文件名的事实。请注意，这次没有给出完全限定的路径名。这是因为服务器无法确定该信息。然后确定文件名代表一个目录后，该目录已被列出。该列表也没有显示完全限定的路径名，原因相同，因此只有一行"type=cdir”。这个目录（特别为此目的创建）包含几个有趣的文件。有一些具有操作系统依赖的文件类型、几个子目录和几个普通文件。关于操作系统依赖的文件类型，这里无法说太多，因为这里显示的信息不应被视为比可能定义的其他类似信息更优先。可以看出，服务器的操作系统类型是"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"对此用户完全没有授权访问。从"Unique"事实值可以确定，“promiscuous"和"incoming"实际上代表同一个目录。其权限显示连接的用户几乎可以做任何事，除了删除目录。该目录后来被列出。事实证明，该目录不能被删除，因为它不是空的。
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.
在列出的普通文件中，有两个包含空格的名称。名为” leading space"的文件实际上在其名称中包含两个空格，一个位于"l"之前，一个位于"g"和"s"之间。两个空格将事实与路径名的可见部分分开，使其清晰可见。文件"writable"设置了"a"和"w"权限位，因此连接的用户应该能够对该文件执行STOR或APPE操作。
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"都代表同一个底层文件，这可以从每个文件的"unique"事实值中看出。事实证明，“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”。由于"promiscuous"是同一个目录，因此没有必要再列出它。在那个目录中，文件"file5"和"file6"代表我们之前见过的"file1"文件的更多名称。注意"bar"和"file5"之间的条目。虽然在本文档中不容易表示，但它显示了一个文件名完全由三个空格（” “）组成的文件。然而，客户端将毫无困难地从呈现给它的输出中确定该名称。正如其名称所暗示的，目录"empty"是空的，尽管这里没有显示。然而，它可以被删除，就像文件"bar"和名称是三个空格的文件一样。此目录中的所有文件都可以被重命名。这是UNIX目录语义可修改的结果。
7.7.5. More Accurate Time Information 更准确的时间信息
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日UTC的00:33:55之后的237毫秒被最后修改。
7.7.6. A Different Server 不同的服务器
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.
Note that this server returns its “unique” fact value in quite a different format. It also returns fully qualified pathnames for the “pdir” entry.
请注意，这个服务器以完全不同的格式返回其"unique"事实值。它还为"pdir"条目返回完全限定的路径名。
7.7.7. Some IANA Files 一些IANA文件
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.
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.
此示例显示了一些与本规范相关的IANA维护的文件，以MLSD格式显示。请注意，这些列表经过编辑，删除了许多条目，实际列表要长得多。
7.7.8. A Stress Test of Case (In)dependence 大小写（不）敏感的压力测试
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
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"为文件的对象。在不区分大小写的NVFS中，这些将代表三个不同的文件名"file1”、“file2"和"file3”。在区分大小写的NVFS中，所有九个代表不同的文件名。两者都是可能的，服务器-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"都有相同的"unique"事实值"keVO1+bD8”，因此都代表相同的底层文件。另一方面，“FILE1"有一个不同的"unique"事实值（“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.
尽管在所有情况下"size"事实（大约大小）和"modify"事实（最后修改时间）的值相同可能不过是巧合。
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；然而，用户和服务器实现都必须准备好处理这种极端示例。
7.7.9. Example from Another Server 另一服务器的示例
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
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以不区分大小写的方式实现其路径名。当客户端发送名称时，服务器似乎以请求的大小写返回文件，否则使用只有服务器自己知道的算法选择返回的名称的大小写。
7.7.10. A Server Listing Itself 列出自身的服务器
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.
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"命令之间修改了请求的事实，尽管这里没有显示该交换。
7.7.11. A Server with a Difference 有所不同的服务器
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> 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...
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"条目。服务器还使用了令人讨厌的“可爱”信息。
7.8. FEAT Response for MLSx 对MLSx的FEAT响应
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 ["*"] ";" )
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 commands will return the asterisk to show the facts selected by the most recent “OPTS MLST”.
mlst-feat响应中显示的初始空格是FEAT命令所要求的，不允许两个空格。如果没有给出factlist，则服务器-FTP进程表示它支持MLST，但不实现任何事实。只能返回路径名。这将是一个最小的MLST实现，对于大多数实际目的而言是无用的。如果存在factlist，则包含的factnames表明服务器支持的事实。如果事实名称后出现可选的星号，那么该事实将包含在MLST格式响应中，直到给出"OPTS MLST"来更改返回的事实列表。此后，后续的FEAT命令将返回星号以显示最近的"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没有单独的FEAT输出。MLST特性的存在表明支持MLST和MLSD。
7.8.1. Examples 示例
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.
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，四个标准事实中的一个（“unique”）默认情况下不启用，以及几个操作系统依赖的事实，其中一个服务器默认提供。这个服务器实际上支持更多的操作系统依赖事实。出于本文档的格式限制目的，其他事实已被删除。
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节的机制），因此最好难以合理支持它们。这个服务器支持的所有事实中，只有一个默认情况下未启用。
7.9. OPTS Parameters for MLST 对MLST的OPTS参数
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可以指定它希望在发送另一个OPTS MLST命令之前在所有后续MLSx命令中返回的事实列表。格式由以下内容指定：
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 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.
客户端应注意，对某些服务器生成某些事实的值可能是可能的，但非常昂贵。在给出任何"OPTS MLST"命令之前，检索服务器提供的默认事实集通常是可以接受的，然而，在请求不在该集中的任何事实之前，客户端应特别小心。也就是说，虽然其他事实可能可从服务器获得，但除非有特定的操作要求需要该特定信息，否则客户端应避免请求此类事实，这应该比仅仅改善最终用户显示的信息更重要。
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"命令，但可以选择允许它们。
7.9.1. OPTS MLST Response 对OPTS MLST的响应
The “response-message” from [6] to a successful OPTS MLST command has the following syntax.
对于成功的OPTS MLST命令，[6]中的“响应消息”具有以下语法。
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"可以以任何大小写或大小写组合返回。
7.9.2. Examples 示例
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*
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输出显示作为返回的更改特性。然后，客户端尝试选择服务器不支持的一些标准特性。这不是错误，但服务器简单地忽略对不支持特性的请求，如随后的FEAT输出所示。然后，客户端尝试请求一个非标准且不支持的特性。服务器忽略了这一点，并只选择了请求的受支持特性。最后，客户端发送了包含语法错误的请求（factlist中不能出现空格）。服务器-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
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命令的影响。请注意，语法错误会使选定的事实集保持不变。还请注意，在未选择任何事实时，路径名前恰好有两个空格，无论是故意的，还是因为所请求的事实都不可用。
8. Impact on Other FTP Commands 对其他FTP命令的影响
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
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.
所有这些命令的参数应该以与处理MLST命令和响应中嵌入的空格、CR和NULs相同的方式处理。参见第2.2节。
9. Character Sets and Internationalization 字符集与国际化
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响应中提供了"media-type"事实，否则这里也不提供任何允许确定内容类型的建议。假设通过其他方式获得该信息。
10. IANA Considerations IANA注意事项
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注册表是使用其他地方指定的机制修改的。
10.1. The OS Specific Fact Registry 操作系统特定事实注册表
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部分必须取自IANA的注册OS名称列表。要将事实名称添加到此操作系统特定事实注册表中，申请人必须向IANA发送请求，在请求中指定OS名称、操作系统特定事实名称、事实值的语法定义，该语法必须符合本文档给出的token的语法，并指定与特定事实及其值相关的语义。收到此类申请后，如果OS名称和操作系统特定事实名称的组合尚未定义，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注册表的一部分。
10.2. The OS Specific Filetype Registry 操作系统特定文件类型注册表
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部分必须取自IANA的注册OS名称列表。要将文件类型添加到此操作系统特定文件类型注册表中，申请人必须向IANA发送请求，在请求中指定OS名称、操作系统特定文件类型、事实值的语法定义，该语法必须符合本文档给出的token的语法，并指定与特定事实及其值相关的语义。收到此类申请后，如果OS名称和操作系统特定文件类型的组合尚未定义，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注册表的一部分。
11. Security Considerations 安全考虑
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应注意不向未经授权的方泄露有关文件的敏感信息。特别是，一些底层文件系统提供的文件标识符（如果已知）可能允许绕过许多文件系统保护机制。该标识符不适合用作unique事实值的基础。
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]中找到。
12. Normative References
Coded Character Set–7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
Yergeau, F., “UTF-8, a transformation format of ISO 10646”, RFC 3629, November 2003.
Postel, J. and J. Reynolds, “File Transfer Protocol (FTP)”, STD 9, RFC 959, October 1985.
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 4234, October 2005.
Hethmon, P. and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol”, RFC 2389, August 1998.
Curtin, B., “Internationalization of the File Transfer Protocol”, RFC 2640, July 1999.
Postel, J. and J. Reynolds, “Telnet protocol Specification”, STD 8, RFC 854, May 1983.
Braden, R,. “Requirements for Internet Hosts – Application and Support”, STD 3, RFC 1123, October 1989.
ISO/IEC 10646-1:1993 “Universal multiple-octet coded character set (UCS) – Part 1: Architecture and basic multilingual plane”, International Standard – Information Technology, 1993.
Internet Assigned Numbers Authority. http://www.iana.org Email: iana@iana.org.
Phillips, A. and M. Davis, “Tags for Identifying Languages”, BCP 47, RFC 4646, September 2006.
Allman, M. and S. Ostermann, “FTP Security Considerations” RFC 2577, May 1999.
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.
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.
本文档中的几个示例超过了RFC标准行长度72个字符。由于本文档是IETF工作组的标准跟踪结果，对IETF子社区很重要，RFC编辑员带着边距违规发布了它。这不是一个先例。
Author’s Address 作者地址
Paul Hethmon Hethmon Software 10420 Jackson Oaks Way, Suite 201 Knoxville, TN 37922
EMail: phethmon@hethmon.com