Network Working Group
Request for Comments: 959
J. Postel
J. Reynolds
ISI
October 1985
Status of this Memo 本备忘录的状态
This memo is the official specification of the File Transfer Protocol (FTP). Distribution of this memo is unlimited.
本备忘录是文件传输协议（FTP）的官方规范。本备忘录的分发不受限制。
The following new optional commands are included in this edition of the specification:
在这版规范中包括了以下新的可选命令：
- CDUP (Change to Parent Directory 切换到父目录)
- SMNT (Structure Mount 结构挂载)
- STOU (Store Unique 存储唯一文件)
- RMD (Remove Directory 移除目录)
- MKD (Make Directory 创建目录)
- PWD (Print Directory 打印目录)
- SYST (System 系统).
Note that this specification is compatible with the previous edition.
请注意，本规范与前一版兼容。
1. Introduction 引言
The objectives of FTP are
FTP的目标是
to promote sharing of files (computer programs and/or data)
促进文件（计算机程序和/或数据）的共享
to encourage indirect or implicit (via programs) use of remote computers
鼓励间接或隐式（通过程序）使用远程计算机
to shield a user from variations in file storage systems among hosts
使用户不受主机间文件存储系统差异的影响
to transfer data reliably and efficiently.
可靠且高效地传输数据。
FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.
FTP虽然可以直接由终端用户使用，但主要设计给程序使用。
The attempt in this specification is to satisfy the diverse needs of users of maxi-hosts, mini-hosts, personal workstations, and TACs, with a simple, and easily implemented protocol design.
本规范的尝试是满足使用大型主机、小型主机、个人工作站和TACs的用户的多样化需求，通过一个简单且易于实现的协议设计。
This paper assumes knowledge of the Transmission Control Protocol (TCP) and the Telnet Protocol. These documents are contained in the ARPA-Internet protocol handbook.
本文假设读者已了解传输控制协议（TCP）和Telnet协议。这些文档包含在ARPA-Internet协议手册中。
2. Overview 概述
In this section, the history, the terminology, and the FTP model are discussed. The terms defined in this section are only those that have special significance in FTP. Some of the terminology is very specific to the FTP model; some readers may wish to turn to the section on the FTP model while reviewing the terminology.
本节讨论了历史、术语和FTP模型。本节定义的术语仅是在FTP中具有特殊意义的那些。一些术语非常特定于FTP模型；一些读者可能希望在回顾术语时参考关于FTP模型的部分。
2.1 History 历史
FTP has had a long evolution over the years. Appendix III is a chronological compilation of Request for Comments documents relating to FTP. These include the first proposed file transfer mechanisms in 1971 that were developed for implementation on hosts at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
FTP经历了多年的演变。附录III是与FTP相关的请求评论稿文档的编年史编纂。这些包括1971年首次提出的文件传输机制，这些机制是为在麻省理工学院的主机上实现而开发的（RFC 114），以及RFC 141中的评论和讨论。
RFC 172 provided a user-level oriented protocol for file transfer between host computers (including terminal IMPs). A revision of this as RFC 265, restated FTP for additional review, while RFC 281 suggested further changes. The use of a “Set Data Type” transaction was proposed in RFC 294 in January 1982.
RFC 172提供了一个面向用户级别的协议，用于主机计算机之间的文件传输（包括终端IMP）。作为RFC 265的修订版，重新陈述了FTP以供进一步审查，而RFC 281则提出了进一步的变更。在1982年1月的RFC 294中提出了使用“设置数据类型”交易的建议。
RFC 354 obsoleted RFCs 264 and 265. The File Transfer Protocol was now defined as a protocol for file transfer between HOSTs on the ARPANET, with the primary function of FTP defined as transfering files efficiently and reliably among hosts and allowing the convenient use of remote file storage capabilities. RFC 385 further commented on errors, emphasis points, and additions to the protocol, while RFC 414 provided a status report on the working server and user FTPs. RFC 430, issued in 1973, (among other RFCs too numerous to mention) presented further comments on FTP. Finally, an “official” FTP document was published as RFC 454.
RFC 354使RFCs 264和265过时。文件传输协议现在被定义为ARPANET上HOST之间的文件传输协议，FTP的主要功能被定义为在主机之间高效可靠地传输文件，并允许方便地使用远程文件存储能力。RFC 385进一步评论了协议中的错误、强调点和添加内容，而RFC 414提供了工作服务器和用户FTP的状态报告。1973年发布的RFC 430（以及其他太多而无法一一提及的RFC）对FTP提出了进一步的评论。最终，一个“官方”的FTP文档作为RFC 454发布。
By July 1973, considerable changes from the last versions of FTP were made, but the general structure remained the same. RFC 542 was published as a new “official” specification to reflect these changes. However, many implementations based on the older specification were not updated.
到1973年7月，FTP的最新版本进行了相当大的变化，但总体结构保持不变。RFC 542作为新的“官方”规范发布，以反映这些变化。然而，许多基于旧规范的实现并未更新。
In 1974, RFCs 607 and 614 continued comments on FTP. RFC 624 proposed further design changes and minor modifications. In 1975, RFC 686 entitled, “Leaving Well Enough Alone”, discussed the differences between all of the early and later versions of FTP. RFC 691 presented a minor revision of RFC 686, regarding the subject of print files.
1974年，RFCs 607和614继续对FTP进行评论。RFC 624提出了进一步的设计变更和小的修改。1975年，标题为“保持现状”的RFC 686讨论了FTP的早期版本和后期版本之间的差异。RFC 691提出了RFC 686的一个小修订，关于打印文件的主题。
Motivated by the transition from the NCP to the TCP as the underlying protocol, a phoenix was born out of all of the above efforts in RFC 765 as the specification of FTP for use on TCP.
受从NCP到TCP作为底层协议的过渡的激励，一个凤凰涅槃般的RFC 765诞生了，作为在TCP上使用FTP的规范。
This current edition of the FTP specification is intended to correct some minor documentation errors, to improve the explanation of some protocol features, and to add some new optional commands.
本版FTP规范旨在纠正一些小的文档错误，改善对某些协议特性的解释，并添加一些新的可选命令。
In particular, the following new optional commands are included in this edition of the specification:
特别是，本版规范中包括了以下新的可选命令：
- CDUP - Change to Parent Directory 切换到父目录
- SMNT - Structure Mount 结构挂载
- STOU - Store Unique 存储唯一文件
- RMD - Remove Directory 移除目录
- MKD - Make Directory 创建目录
- PWD - Print Directory 打印目录
- SYST - System 系统
This specification is compatible with the previous edition. A program implemented in conformance to the previous specification should automatically be in conformance to this specification.
本规范与前一版兼容。根据前一规范实施的程序应自动符合本规范。
2.2 Terminology 术语
ASCII
The ASCII character set is as defined in the ARPA-Internet Protocol Handbook. In FTP, ASCII characters are defined to be the lower half of an eight-bit code set (i.e., the most significant bit is zero).
ASCII字符集在ARPA-Internet协议手册中定义。在FTP中，ASCII字符被定义为八位代码集的下半部分（即，最高有效位为零）。
access controls 访问控制
Access controls define users’ access privileges to the use of a system, and to the files in that system. Access controls are necessary to prevent unauthorized or accidental use of files. It is the prerogative of a server-FTP process to invoke access controls.
访问控制定义了用户对系统的使用权限以及对该系统中文件的访问权限。访问控制是防止未经授权或意外使用文件所必需的。服务器-FTP进程调用访问控制是其特权。
byte size 字节大小
There are two byte sizes of interest in FTP: the logical byte size of the file, and the transfer byte size used for the transmission of the data. The transfer byte size is always 8 bits. The transfer byte size is not necessarily the byte size in which data is to be stored in a system, nor the logical byte size for interpretation of the structure of the data.
在FTP中，有两种字节大小值得关注：文件的逻辑字节大小，以及用于数据传输的传输字节大小。传输字节大小始终为8位。传输字节大小不一定是数据在系统中存储的字节大小，也不一定是用于解释数据结构的逻辑字节大小。
control connection 控制连接
The communication path between the USER-PI and SERVER-PI for the exchange of commands and replies. This connection follows the Telnet Protocol.
用户-PI和服务器-PI之间的通信路径，用于命令和回复的交换。此连接遵循Telnet协议。
data connection 数据连接
A full duplex connection over which data is transferred, in a specified mode and type. The data transferred may be a part of a file, an entire file or a number of files. The path may be between a server-DTP and a user-DTP, or between two server-DTPs.
全双工连接，通过该连接以指定的模式和类型传输数据。传输的数据可能是文件的一部分、整个文件或多个文件。路径可能是在服务器-DTP和用户-DTP之间，或两个服务器-DTP之间。
data port 数据端口
The passive data transfer process “listens” on the data port for a connection from the active transfer process in order to open the data connection.
被动数据传输过程在数据端口上“监听”，等待主动传输过程的连接，以打开数据连接。
DTP
The data transfer process establishes and manages the data connection. The DTP can be passive or active.
数据传输过程建立并管理数据连接。DTP可以是被动的或主动的。
End-of-Line 行尾
The end-of-line sequence defines the separation of printing lines. The sequence is Carriage Return, followed by Line Feed.
行尾序列定义了打印行的分隔。序列是回车，后跟换行。
EOF
The end-of-file condition that defines the end of a file being transferred.
文件结束条件，定义了被传输文件的结束。
EOR
The end-of-record condition that defines the end of a record being transferred.
记录结束条件，定义了被传输记录的结束。
error recovery 错误恢复
A procedure that allows a user to recover from certain errors such as failure of either host system or transfer process. In FTP, error recovery may involve restarting a file transfer at a given checkpoint.
一种允许用户从某些错误中恢复的程序，例如主机系统或传输过程的失败。在FTP中，错误恢复可能涉及在给定检查点重新启动文件传输。
FTP commands FTP命令
A set of commands that comprise the control information flowing from the user-FTP to the server-FTP process.
一组命令，构成了从用户-FTP到服务器-FTP进程的控制信息流。
file 文件
An ordered set of computer data (including programs), of arbitrary length, uniquely identified by a pathname.
一组有序的计算机数据（包括程序），长度任意，通过路径名唯一标识。
mode 模式
The mode in which data is to be transferred via the data connection. The mode defines the data format during transfer including EOR and EOF. The transfer modes defined in FTP are described in the Section on Transmission Modes.
通过数据连接传输数据的模式。模式定义了传输期间的数据格式，包括EOR和EOF。FTP中定义的传输模式在传输模式部分中描述。
NVT
The Network Virtual Terminal as defined in the Telnet Protocol.
网络虚拟终端，如Telnet协议中定义。
NVFS
The Network Virtual File System. A concept which defines a standard network file system with standard commands and pathname conventions.
网络虚拟文件系统。一个定义了标准网络文件系统、标准命令和路径名惯例的概念。
page 页面
A file may be structured as a set of independent parts called pages. FTP supports the transmission of discontinuous files as independent indexed pages.
文件可能被结构化为一组称为页面的独立部分。FTP支持以独立索引页面的形式传输不连续文件。
pathname 路径名
Pathname is defined to be the character string which must be input to a file system by a user in order to identify a file. Pathname normally contains device and/or directory names, and file name specification. FTP does not yet specify a standard pathname convention. Each user must follow the file naming conventions of the file systems involved in the transfer.
路径名被定义为用户输入到文件系统以识别文件所需的字符字符串。路径名通常包含设备和/或目录名，以及文件名规范。FTP尚未指定标准路径名惯例。每个用户必须遵循涉及传输的文件系统的文件命名惯例。
PI
The protocol interpreter. The user and server sides of the protocol have distinct roles implemented in a user-PI and a server-PI.
协议解释器。协议的用户端和服务器端有不同的角色，分别由用户-PI和服务器-PI实现。
record 记录
A sequential file may be structured as a number of contiguous parts called records. Record structures are supported by FTP but a file need not have record structure.
顺序文件可能被结构化为称为记录的多个连续部分。FTP支持记录结构，但文件不必有记录结构。
reply 回复
A reply is an acknowledgment (positive or negative) sent from server to user via the control connection in response to FTP commands. The general form of a reply is a completion code (including error codes) followed by a text string. The codes are for use by programs and the text is usually intended for human users.
服务器通过控制连接向用户发送的对FTP命令的确认（正面或负面）。回复的一般形式是完成代码（包括错误代码）后跟文本字符串。代码供程序使用，文本通常面向人类用户。
server-DTP 服务器-DTP
The data transfer process, in its normal “active” state, establishes the data connection with the “listening” data port. It sets up parameters for transfer and storage, and transfers data on command from its PI. The DTP can be placed in a “passive” state to listen for, rather than initiate a connection on the data port.
数据传输过程，在其正常的“主动”状态下，与“监听”数据端口的数据连接建立连接。它设置传输和存储的参数，并根据其PI的命令传输数据。DTP可以被置于“被动”状态，以侦听而非在数据端口上发起连接。
server-FTP process 服务器-FTP进程
A process or set of processes which perform the function of file transfer in cooperation with a user-FTP process and, possibly, another server. The functions consist of a protocol interpreter (PI) and a data transfer process (DTP).
一个或一组进程，与用户-FTP进程（可能还有另一个服务器）合作执行文件传输的功能。这些功能由协议解释器（PI）和数据传输过程（DTP）组成。
server-PI 服务器-PI
The server protocol interpreter “listens” on Port L for a connection from a user-PI and establishes a control communication connection. It receives standard FTP commands from the user-PI, sends replies, and governs the server-DTP.
服务器协议解释器在端口L上“监听”，等待来自用户-PI的连接，并建立控制通信连接。它接收来自用户-PI的标准FTP命令，发送回复，并管理服务器-DTP。
type 类型
The data representation type used for data transfer and storage. Type implies certain transformations between the time of data storage and data transfer. The representation types defined in FTP are described in the Section on Establishing Data Connections.
用于数据传输和存储的数据表示类型。类型意味着数据存储和数据传输之间的某些转换。FTP中定义的表示类型在建立数据连接部分中描述。
user 用户
A person or a process on behalf of a person wishing to obtain file transfer service. The human user may interact directly with a server-FTP process, but use of a user-FTP process is preferred since the protocol design is weighted towards automata.
一个希望获得文件传输服务的人或代表一个人的进程。人类用户可以直接与服务器-FTP进程交互，但由于协议设计偏向自动化，推荐使用用户-FTP进程。
user-DTP 用户-DTP
The data transfer process “listens” on the data port for a connection from a server-FTP process. If two servers are transferring data between them, the user-DTP is inactive.
数据传输过程在数据端口上“监听”，等待来自服务器-FTP进程的连接。如果两个服务器之间传输数据，则用户-DTP处于非活动状态。
user-FTP process 用户-FTP进程
A set of functions including a protocol interpreter, a data transfer process and a user interface which together perform the function of file transfer in cooperation with one or more server-FTP processes. The user interface allows a local language to be used in the command-reply dialogue with the user.
一组功能，包括协议解释器、数据传输过程和用户界面，这些功能一起与一个或多个服务器-FTP进程合作执行文件传输的功能。用户界面允许在与用户的命令-回复对话中使用本地语言。
user-PI 用户-PI
The user protocol interpreter initiates the control connection from its port U to the server-FTP process, initiates FTP commands, and governs the user-DTP if that process is part of the file transfer.
用户协议解释器从其端口U向服务器-FTP进程发起控制连接，发起FTP命令，并在文件传输中涉及该过程时管理用户-DTP。
2.3 The FTP Model
With the above definitions in mind, the following model (shown in Figure 1) may be diagrammed for an FTP service.
考虑到上述定义，以下模型（如图1所示）可用于描述FTP服务。
-------------
|/---------\|
|| User || --------
||Interface|<--->| User |
|\----^----/| --------
---------- | | |
|/------\| FTP Commands |/----V----\|
||Server|<---------------->| User ||
|| PI || FTP Replies || PI ||
|\--^---/| |\----^----/|
| | | | | |
-------- |/--V---\| Data |/----V----\| --------
| File |<--->|Server|<---------------->| User |<--->| File |
|System| || DTP || Connection || DTP || |System|
-------- |\------/| |\---------/| --------
---------- -------------
Server-FTP USER-FTP
Figure 1 图1 Model for FTP Use FTP使用的模型
NOTES 注:
The data connection may be used in either direction.
数据连接可以双向使用。
The data connection need not exist all of the time.
数据连接不需要一直存在。
In the model described in Figure 1, the user-protocol interpreter initiates the control connection. The control connection follows the Telnet protocol. At the initiation of the user, standard FTP commands are generated by the user-PI and transmitted to the server process via the control connection. (The user may establish a direct control connection to the server-FTP, from a TAC terminal for example, and generate standard FTP commands independently, bypassing the user-FTP process.) Standard replies are sent from the server-PI to the user-PI over the control connection in response to the commands.
在图1中描述的模型中，用户协议解释器（user-PI）启动控制连接。控制连接遵循Telnet协议。在用户的启动下，标准FTP命令由用户-PI生成，并通过控制连接传输到服务器进程。（例如，用户可以从TAC终端直接建立与服务器-FTP的控制连接，并独立生成标准FTP命令，绕过用户-FTP进程。）标准回复通过控制连接从服务器-PI发送给用户-PI，以响应命令。
The FTP commands specify the parameters for the data connection (data port, transfer mode, representation type, and structure) and the nature of file system operation (store, retrieve, append, delete, etc.). The user-DTP or its designate should “listen” on the specified data port, and the server initiate the data connection and data transfer in accordance with the specified parameters. It should be noted that the data port need not be in the same host that initiates the FTP commands via the control connection, but the user or the user-FTP process must ensure a “listen” on the specified data port. It ought to also be noted that the data connection may be used for simultaneous sending and receiving.
FTP命令指定数据连接的参数（数据端口、传输模式、表示类型和结构）以及文件系统操作的性质（存储、检索、附加、删除等）。用户-DTP或其指定代理应在指定的数据端口上“监听”，服务器根据指定的参数启动数据连接和数据传输。应注意，数据端口不需要在通过控制连接发起FTP命令的同一主机上，但用户或用户-FTP进程必须确保在指定的数据端口上“监听”。还应注意，数据连接可用于同时发送和接收。
In another situation a user might wish to transfer files between two hosts, neither of which is a local host. The user sets up control connections to the two servers and then arranges for a data connection between them. In this manner, control information is passed to the user-PI but data is transferred between the server data transfer processes. Following is a model of this server-server interaction.
在另一种情况下，用户可能希望在两台主机之间传输文件，这两台主机都不是本地主机。用户建立与两个服务器的控制连接，然后安排它们之间的数据连接。以这种方式，控制信息传递给用户-PI，但数据在服务器数据传输过程之间传输。以下是服务器-服务器交互的模型。
Control ------------ Control
---------->| User-FTP |<-----------
| | User-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| Server-FTP | Data Connection | Server-FTP |
| "A" |<---------------------->| "B" |
-------------- Port (A) Port (B) --------------
Figure 2 图2
The protocol requires that the control connections be open while data transfer is in progress. It is the responsibility of the user to request the closing of the control connections when finished using the FTP service, while it is the server who takes the action. The server may abort data transfer if the control connections are closed without command.
协议要求在数据传输进行时控制连接保持开放。当不再使用FTP服务时，用户有责任请求关闭控制连接，而服务器则执行此操作。如果在没有命令的情况下控制连接被关闭，服务器可能会中止数据传输。
The Relationship between FTP and Telnet FTP与Telnet的关系
The FTP uses the Telnet protocol on the control connection. This can be achieved in two ways: first, the user-PI or the server-PI may implement the rules of the Telnet Protocol directly in their own procedures; or, second, the user-PI or the server-PI may make use of the existing Telnet module in the system.
FTP在控制连接上使用Telnet协议。这可以通过两种方式实现：首先，用户-PI或服务器-PI可以直接在自己的程序中实现Telnet协议的规则；或者，用户-PI或服务器-PI可以使用系统中现有的Telnet模块。
Ease of implementaion, sharing code, and modular programming argue for the second approach. Efficiency and independence argue for the first approach. In practice, FTP relies on very little of the Telnet Protocol, so the first approach does not necessarily involve a large amount of code.
易于实现、共享代码和模块化编程支持第二种方法。效率和独立性支持第一种方法。实际上，FTP很少依赖Telnet协议，因此第一种方法不一定涉及大量代码。
3. Data Transfer Functions 数据传输功能
Files are transferred only via the data connection. The control connection is used for the transfer of commands, which describe the functions to be performed, and the replies to these commands (see the Section on FTP Replies). Several commands are concerned with the transfer of data between hosts. These data transfer commands include the MODE command which specify how the bits of the data are to be transmitted, and the STRUcture and TYPE commands, which are used to define the way in which the data are to be represented. The transmission and representation are basically independent but the “Stream” transmission mode is dependent on the file structure attribute and if “Compressed” transmission mode is used, the nature of the filler byte depends on the representation type.
文件仅通过数据连接传输。控制连接用于传输命令，这些命令描述要执行的功能，以及对这些命令的回复（见FTP回复部分）。有几个命令涉及到主机之间的数据传输。这些数据传输命令包括MODE命令，它指定数据的比特如何传输，以及STRUcture（结构）和TYPE（类型）命令，用于定义数据的表示方式。传输和表示基本上是独立的，但“流”传输模式依赖于文件结构属性，如果使用“压缩”传输模式，则填充字节的性质取决于表示类型。
3.1 Data Representation and Storage 数据表示和存储
Data is transferred from a storage device in the sending host to a storage device in the receiving host. Often it is necessary to perform certain transformations on the data because data storage representations in the two systems are different. For example, NVT-ASCII has different data storage representations in different systems. DEC TOPS-20s’s generally store NVT-ASCII as five 7-bit ASCII characters, left-justified in a 36-bit word. IBM Mainframe’s store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-ASCII as four 9-bit characters in a 36-bit word. It is desirable to convert characters into the standard NVT-ASCII representation when transmitting text between dissimilar systems. The sending and receiving sites would have to perform the necessary transformations between the standard representation and their internal representations.
数据从发送主机的存储设备传输到接收主机的存储设备。由于两个系统中的数据存储表示不同，因此通常需要对数据执行某些转换。例如，NVT-ASCII在不同系统中有不同的数据存储表示。DEC TOPS-20s通常将NVT-ASCII存储为一个36位字中左对齐的五个7位ASCII字符。IBM大型机将NVT-ASCII存储为8位EBCDIC代码。Multics将NVT-ASCII存储为一个36位字中的四个9位字符。在传输文本时，将字符转换为标准的NVT-ASCII表示是可取的，当在不同系统之间传输时。发送和接收站点将不得不执行必要的转换，以将标准表示转换为它们自己的内部表示。
A different problem in representation arises when transmitting binary data (not character codes) between host systems with different word lengths. It is not always clear how the sender should send data, and the receiver store it. For example, when transmitting 32-bit bytes from a 32-bit word-length system to a 36-bit word-length system, it may be desirable (for reasons of efficiency and usefulness) to store the 32-bit bytes right-justified in a 36-bit word in the latter system. In any case, the user should have the option of specifying data representation and transformation functions. It should be noted that FTP provides for very limited data type representations. Transformations desired beyond this limited capability should be performed by the user directly.
在传输不同字长主机系统之间的二进制数据（非字符代码）时，出现了表示的另一个问题。发送者如何发送数据，接收者如何存储数据并不总是清楚的。例如，当从32位字长系统传输32位字节到36位字长系统时，可能希望（出于效率和实用性的原因）将32位字节在后者系统中右对齐存储在36位字中。无论如何，用户应该有选择指定数据表示和转换功能的选项。应该注意，FTP提供的数据类型表示非常有限。超出这种有限能力的转换应该由用户直接执行。
3.1.1 Data Types 数据类型
Data representations are handled in FTP by a user specifying a representation type. This type may implicitly (as in ASCII or EBCDIC) or explicitly (as in Local byte) define a byte size for interpretation which is referred to as the “logical byte size.” Note that this has nothing to do with the byte size used for transmission over the data connection, called the “transfer byte size”, and the two should not be confused. For example, NVT-ASCII has a logical byte size of 8 bits. If the type is Local byte, then the TYPE command has an obligatory second parameter specifying the logical byte size. The transfer byte size is always 8 bits.
FTP通过用户指定表示类型来处理数据表示。这种类型可能隐含地（如在ASCII或EBCDIC中）或显式地（如在本地字节中）定义了用于解释的字节大小，称为“逻辑字节大小”。注意，这与通过数据连接用于传输的字节大小无关，称为“传输字节大小”，两者不应混淆。例如，NVT-ASCII的逻辑字节大小为8位。如果类型是本地字节，则TYPE命令必须有一个指定逻辑字节大小的必选第二参数。传输字节大小始终为8位。
3.1.1.1 ASCII Type ASCII类型
This is the default type and must be accepted by all FTP implementations. It is intended primarily for the transfer of text files, except when both hosts would find the EBCDIC type more convenient.
这是默认类型，所有FTP实现都必须接受。它主要用于文本文件的传输，除非两个主机都发现EBCDIC类型更方便。
The sender converts the data from an internal character representation to the standard 8-bit NVT-ASCII representation (see the Telnet specification). The receiver will convert the data from the standard form to his own internal form.
发送方将数据从内部字符表示转换为标准的8位NVT-ASCII表示（见Telnet规范）。接收方将数据从标准形式转换为自己的内部形式。
In accordance with the NVT standard, the sequence should be used where necessary to denote the end of a line of text. (See the discussion of file structure at the end of the Section on Data Representation and Storage.)
根据NVT标准，应在必要时使用序列来表示文本行的结束。（见关于数据表示和存储的部分末尾的文件结构讨论。）
Using the standard NVT-ASCII representation means that data must be interpreted as 8-bit bytes.
使用标准NVT-ASCII表示意味着必须将数据解释为8位字节。
The Format parameter for ASCII and EBCDIC types is discussed below.
ASCII和EBCDIC类型的格式参数将在下面讨论。
3.1.1.2 EBCDIC Type EBCDIC类型
This type is intended for efficient transfer between hosts which use EBCDIC for their internal character representation.
此类型旨在实现使用EBCDIC作为其内部字符表示的主机之间的高效传输。
For transmission, the data are represented as 8-bit EBCDIC characters. The character code is the only difference between the functional specifications of EBCDIC and ASCII types.
对于传输，数据表示为8位EBCDIC字符。字符代码是EBCDIC和ASCII类型的功能规范之间唯一的区别。
End-of-line (as opposed to end-of-record–see the discussion of structure) will probably be rarely used with EBCDIC type for purposes of denoting structure, but where it is necessary the character should be used.
用于表示结构的行尾（与记录结束相对–见结构的讨论）可能很少与EBCDIC类型一起使用，但在必要时应使用字符。
3.1.1.3 Image Type 图像类型
The data are sent as contiguous bits which, for transfer, are packed into the 8-bit transfer bytes. The receiving site must store the data as contiguous bits. The structure of the storage system might necessitate the padding of the file (or of each record, for a record-structured file) to some convenient boundary (byte, word or block). This padding, which must be all zeros, may occur only at the end of the file (or at the end of each record) and there must be a way of identifying the padding bits so that they may be stripped off if the file is retrieved. The padding transformation should be well publicized to enable a user to process a file at the storage site.
数据作为连续的位发送，这些位用于传输时打包成8位的传输字节。接收站点必须将数据存储为连续的位。存储系统的结构可能需要将文件（或对于有记录结构的文件，则每个记录）填充到某个方便的边界（字节、字或块）。这种填充必须全为零，只能出现在文件（或每个记录）的末尾，并且必须有办法识别填充位，以便在检索文件时可以剥离它们。填充转换应该被广泛宣传，以便用户能够在存储站点处理文件。
Image type is intended for the efficient storage and retrieval of files and for the transfer of binary data. It is recommended that this type be accepted by all FTP implementations.
图像类型旨在高效存储和检索文件以及传输二进制数据。建议所有FTP实现都接受此类型。
3.1.1.4 Local Type 本地类型
The data is transferred in logical bytes of the size specified by the obligatory second parameter, Byte size. The value of Byte size must be a decimal integer; there is no default value. The logical byte size is not necessarily the same as the transfer byte size. If there is a difference in byte sizes, then the logical bytes should be packed contiguously, disregarding transfer byte boundaries and with any necessary padding at the end. When the data reaches the receiving host, it will be transformed in a manner dependent on the logical byte size and the particular host. This transformation must be invertible (i.e., an identical file can be retrieved if the same parameters are used) and should be well publicized by the FTP implementors.
数据以必选的第二参数Byte size指定的逻辑字节大小传输。Byte size的值必须是十进制整数；没有默认值。逻辑字节大小不一定与传输字节大小相同。如果字节大小有差异，则应连续紧密地打包逻辑字节，忽略传输字节边界，并在末端进行必要的填充。当数据到达接收主机时，将根据逻辑字节大小和特定主机以特定方式进行转换。这种转换必须是可逆的（即，如果使用相同的参数，则可以检索到相同的文件），并且FTP实现者应该广泛宣传这种转换。
For example, a user sending 36-bit floating-point numbers to a host with a 32-bit word could send that data as Local byte with a logical byte size of 36. The receiving host would then be expected to store the logical bytes so that they could be easily manipulated; in this example putting the 36-bit logical bytes into 64-bit double words should suffice.
例如，一个用户将36位浮点数发送到一个32位字长的主机，可以将数据作为本地字节类型发送，逻辑字节大小为36。然后，接收主机应该存储逻辑字节，以便它们可以被轻松操作；在此示例中，将36位逻辑字节放入64位双字应该足够。
In another example, a pair of hosts with a 36-bit word size may send data to one another in words by using TYPE L 36. The data would be sent in the 8-bit transmission bytes packed so that 9 transmission bytes carried two host words.
在另一个示例中，两个具有36位字大小的主机可以使用TYPE L 36相互发送数据。数据将被打包到8位传输字节中，以便9个传输字节携带两个主机字。
3.1.1.5 Format Control 格式控制
The types ASCII and EBCDIC also take a second (optional) parameter; this is to indicate what kind of vertical format control, if any, is associated with a file. The following data representation types are defined in FTP:
ASCII和EBCDIC类型还采用第二个（可选）参数；这是为了指示与文件相关联的垂直格式控制（如果有）的类型。FTP中定义了以下数据表示类型：
A character file may be transferred to a host for one of three purposes: for printing, for storage and later retrieval, or for processing. If a file is sent for printing, the receiving host must know how the vertical format control is represented. In the second case, it must be possible to store a file at a host and then retrieve it later in exactly the same form. Finally, it should be possible to move a file from one host to another and process the file at the second host without undue trouble. A single ASCII or EBCDIC format does not satisfy all these conditions. Therefore, these types have a second parameter specifying one of the following three formats:
字符文件可能因三个目的之一而被传输到主机：打印、存储以及稍后检索，或处理。如果文件发送用于打印，接收主机必须知道垂直格式控制是如何表示的。在第二种情况下，必须能够在主机上存储文件，然后以完全相同的形式稍后检索它。最后，应该能够将文件从一个主机移动到另一个主机，并在第二个主机上处理文件而不会有太多麻烦。单一的ASCII或EBCDIC格式不能满足所有这些条件。因此，这些类型有一个指定以下三种格式之一的第二参数：
3.1.1.5.1 Non Print 非打印
This is the default format to be used if the second (format) parameter is omitted. Non-print format must be accepted by all FTP implementations. The file need contain no vertical format information. If it is passed to a printer process, this process may assume standard values for spacing and margins.
如果省略了第二个（格式）参数，则使用默认格式。所有FTP实现都必须接受非打印格式。文件无需包含垂直格式信息。如果将其传递给打印进程，该进程可能会假设间距和边距的标准值。
Normally, this format will be used with files destined for processing or just storage.
通常，此格式将用于目的是处理或仅存储的文件。
3.1.1.5.2 Telnet Format Controls Telnet格式控制
The file contains ASCII/EBCDIC vertical format controls (i.e., , , , , ) which the printer process will interpret appropriately. , in exactly this sequence, also denotes end-of-line.
文件包含ASCII/EBCDIC垂直格式控制（即，、、、、），打印进程将适当地解释这些控制。精确的序列也表示行尾。
3.1.1.5.3 Carriage Control 车控制
The file contains ASA (FORTRAN) vertical format control characters. (See RFC 740 Appendix C; and Communications of the ACM, Vol. 7, No. 10, p. 606, October 1964.) In a line or a record formatted according to the ASA Standard, the first character is not to be printed. Instead, it should be used to determine the vertical movement of the paper which should take place before the rest of the record is printed.
文件包含ASA（FORTRAN）垂直格式控制字符。（参见RFC 740 附录C；以及《通讯的ACM》，第7卷，第10期，第606页，1964年10月。）根据ASA标准，一行或一个记录的格式化中，第一个字符不应被打印。相反，它应该用于确定在打印其余记录之前纸张应该发生的垂直移动。
The ASA Standard specifies the following control characters:
ASA标准指定以下控制字符：
| Character 字符 | Vertical Spacing 垂直间距 |
|---|---|
| blank 空格 | Move paper up one line 将纸张上移一行 |
| 0 | Move paper up two lines 将纸张上移两行 |
| 1 | Move paper to top of next page 将纸张移至下一页顶部 |
| + | No movement, i.e., overprint 无移动，即，重叠打印 |
Clearly there must be some way for a printer process to distinguish the end of the structural entity. If a file has record structure (see below) this is no problem; records will be explicitly marked during transfer and storage. If the file has no record structure, the end-of-line sequence is used to separate printing lines, but these format effectors are overridden by the ASA controls.
显然，打印进程必须有某种方式来区分结构实体的结束。如果文件具有记录结构（见下文），则这不是问题；在传输和存储期间记录将被显式标记。如果文件没有记录结构，行尾序列用于分隔打印行，但这些格式效应器被ASA控制覆盖。
3.1.2 Data Structures 数据结构
In addition to different representation types, FTP allows the structure of a file to be specified. Three file structures are defined in FTP:
除了不同的表示类型，FTP允许指定文件的结构。FTP定义了三种文件结构：
file-structure, where there is no internal structure and the file is considered to be a continuous sequence of data bytes,
文件结构，其中没有内部结构，文件被视为连续的数据字节序列，
record-structure, where the file is made up of sequential records,
记录结构，文件由顺序记录组成，
page-structure, where the file is made up of independent indexed pages.
页面结构，文件由独立的索引页面组成。
File-structure is the default to be assumed if the STRUcture command has not been used but both file and record structures must be accepted for “text” files (i.e., files with TYPE ASCII or EBCDIC) by all FTP implementations. The structure of a file will affect both the transfer mode of a file (see the Section on Transmission Modes) and the interpretation and storage of the file.
如果没有使用STRUcture命令，则默认假定文件结构，但所有FTP实现必须接受“文本”文件（即，具有TYPE ASCII或EBCDIC的文件）的文件和记录结构。文件的结构将影响文件的传输模式（见传输模式部分）以及文件的解释和存储。
The “natural” structure of a file will depend on which host stores the file. A source-code file will usually be stored on an IBM Mainframe in fixed length records but on a DEC TOPS-20 as a stream of characters partitioned into lines, for example by . If the transfer of files between such disparate sites is to be useful, there must be some way for one site to recognize the other’s assumptions about the file.
文件的“自然”结构将取决于存储文件的主机。例如，源代码文件通常存储在IBM大型机中为固定长度的记录，但在DEC TOPS-20中作为字符流存储，并通过划分为行。如果要在如此不同的站点之间传输文件以便有用，就必须有某种方式让一个站点识别另一个站点对文件的假设。
With some sites being naturally file-oriented and others naturally record-oriented there may be problems if a file with one structure is sent to a host oriented to the other. If a text file is sent with record-structure to a host which is file oriented, then that host should apply an internal transformation to the file based on the record structure. Obviously, this transformation should be useful, but it must also be invertible so that an identical file may be retrieved using record structure.
由于一些站点天生面向文件，而另一些天生面向记录，如果将具有一种结构的文件发送到面向另一种结构的主机，可能会存在问题。如果将带有记录结构的文本文件发送到面向文件的主机，则该主机应根据记录结构对文件应用内部转换。显然，这种转换应该是有用的，但它也必须是可逆的，以便使用记录结构检索时可以获得相同的文件。
In the case of a file being sent with file-structure to a record-oriented host, there exists the question of what criteria the host should use to divide the file into records which can be processed locally. If this division is necessary, the FTP implementation should use the end-of-line sequence, for ASCII, or for EBCDIC text files, as the delimiter. If an FTP implementation adopts this technique, it must be prepared to reverse the transformation if the file is retrieved with file-structure.
如果文件以文件结构发送到面向记录的主机，则存在主机应如何将文件划分为可以在本地处理的记录的问题。如果需要这种划分，FTP实现应使用行尾序列，对于ASCII文本文件为，对于EBCDIC文本文件为，作为分隔符。如果FTP实现采用这种技术，它必须准备好如果使用文件结构检索文件，则反转转换。
3.1.2.1 File Structure 文件结构
File structure is the default to be assumed if the STRUcture command has not been used.
如果没有使用STRUcture命令，则默认假定文件结构。
In file-structure there is no internal structure and the file is considered to be a continuous sequence of data bytes.
在文件结构中，没有内部结构，文件被视为连续的数据字节序列。
3.1.2.2 Record Structure 记录结构
Record structures must be accepted for “text” files (i.e., files with TYPE ASCII or EBCDIC) by all FTP implementations.
所有FTP实现必须接受“文本”文件（即，具有TYPE ASCII或EBCDIC的文件）的记录结构。
In record-structure the file is made up of sequential records.
在记录结构中，文件由顺序记录组成。
3.1.2.3 Page Structure 页面结构
To transmit files that are discontinuous, FTP defines a page structure. Files of this type are sometimes known as “random access files” or even as “holey files”. In these files there is sometimes other information associated with the file as a whole (e.g., a file descriptor), or with a section of the file (e.g., page access controls), or both. In FTP, the sections of the file are called pages.
为了传输不连续的文件，FTP定义了页面结构。这类文件有时被称为“随机访问文件”或甚至为“有洞的文件”。在这些文件中，有时与整个文件（例如，文件描述符）或文件的某个部分（例如，页面访问控制）相关联的其他信息。在FTP中，文件的部分称为页面。
To provide for various page sizes and associated information, each page is sent with a page header. The page header has the following defined fields:
为了提供各种页面大小和相关信息，每个页面都带有页面头。页面头有以下定义的字段：
Header Length 头长度
The number of logical bytes in the page header including this byte. The minimum header length is 4.
页面头中的逻辑字节数量，包括这个字节。最小头长度为4。
Page Index 页面索引
The logical page number of this section of the file. This is not the transmission sequence number of this page, but the index used to identify this page of the file.
该文件部分的逻辑页面号。这不是该页面的传输序列号，而是用于识别该文件页面的索引。
Data Length 数据长度
The number of logical bytes in the page data. The minimum data length is 0.
页面数据中的逻辑字节数量。最小数据长度为0。
Page Type 页面类型
The type of page this is. The following page types are defined:
此页面的类型。定义了以下页面类型：
0 = Last Page 最后一页
This is used to indicate the end of a paged structured transmission. The header length must be 4, and the data length must be 0.
用于指示分页结构传输的结束。头长度必须为4，数据长度必须为0。
1 = Simple Page 简单页面
This is the normal type for simple paged files with no page level associated control information. The header length must be 4.
对于没有页面级别关联控制信息的简单分页文件的正常类型。头长度必须为4。
2 = Descriptor Page 描述符页面
This type is used to transmit the descriptive information for the file as a whole.
用于传输整个文件的描述性信息。
3 = Access Controlled Page 访问控制页面
This type includes an additional header field for paged files with page level access control information. The header length must be 5.
该类型包括用于具有页面级别访问控制信息的分页文件的附加头字段。头长度必须为5。
Optional Fields 可选字段
Further header fields may be used to supply per page control information, for example, per page access control.
进一步的头字段可用于提供每页控制信息，例如，每页访问控制。
All fields are one logical byte in length. The logical byte size is specified by the TYPE command. See Appendix I for further details and a specific case at the page structure.
所有字段都是一个逻辑字节长度。逻辑字节大小由TYPE命令指定。有关更多详细信息和页面结构的具体案例，请参见附录I。
A note of caution about parameters: a file must be stored and retrieved with the same parameters if the retrieved version is to be identical to the version originally transmitted. Conversely, FTP implementations must return a file identical to the original if the parameters used to store and retrieve a file are the same.
关于参数的注意事项：必须使用相同的参数存储和检索文件，如果要检索的版本与最初传输的版本相同。相反，如果用于存储和检索文件的参数相同，FTP实现必须返回与原始文件相同的文件。
3.2 Establishing Data Connections 建立数据连接
The mechanics of transferring data consists of setting up the data connection to the appropriate ports and choosing the parameters for transfer. Both the user and the server-DTPs have a default data port. The user-process default data port is the same as the control connection port (i.e., U). The server-process default data port is the port adjacent to the control connection port (i.e., L-1).
传输数据的机制包括设置数据连接到适当的端口并选择传输参数。用户和服务器-DTP都有默认的数据端口。用户进程的默认数据端口与控制连接端口相同（即U）。服务器进程的默认数据端口是与控制连接端口相邻的端口（即L-1）。
The transfer byte size is 8-bit bytes. This byte size is relevant only for the actual transfer of the data; it has no bearing on representation of the data within a host’s file system.
传输字节大小为8位字节。这个字节大小仅与数据的实际传输相关；它与主机文件系统中的数据表示无关。
The passive data transfer process (this may be a user-DTP or a second server-DTP) shall “listen” on the data port prior to sending a transfer request command. The FTP request command determines the direction of the data transfer. The server, upon receiving the transfer request, will initiate the data connection to the port. When the connection is established, the data transfer begins between DTP’s, and the server-PI sends a confirming reply to the user-PI.
被动数据传输过程（这可能是用户-DTP或第二个服务器-DTP）应在发送传输请求命令之前在数据端口上“监听”。FTP请求命令确定数据传输的方向。服务器在收到传输请求后，将启动到端口的数据连接。当连接建立时，数据传输在DTP之间开始，服务器-PI发送确认回复给用户-PI。
Every FTP implementation must support the use of the default data ports, and only the USER-PI can initiate a change to non-default ports.
每个FTP实现必须支持使用默认数据端口，且只有用户-PI可以发起更改到非默认端口的操作。
It is possible for the user to specify an alternate data port by use of the PORT command. The user may want a file dumped on a TAC line printer or retrieved from a third party host. In the latter case, the user-PI sets up control connections with both server-PI’s. One server is then told (by an FTP command) to “listen” for a connection which the other will initiate. The user-PI sends one server-PI a PORT command indicating the data port of the other. Finally, both are sent the appropriate transfer commands. The exact sequence of commands and replies sent between the user-controller and the servers is defined in the Section on FTP Replies.
用户可以通过使用PORT命令指定一个替代数据端口。用户可能希望在TAC行打印机上转储文件或从第三方主机检索文件。在后一种情况下，用户-PI与两个服务器-PI建立控制连接。然后，通过FTP命令告诉一个服务器去“监听”另一个将要发起的连接。用户-PI发送PORT命令给一个服务器-PI，指示另一个的数据端口。最后，两个服务器都被发送适当的传输命令。用户控制器和服务器之间发送的命令和回复的确切序列在FTP回复部分中定义。
In general, it is the server’s responsibility to maintain the data connection–to initiate it and to close it. The exception to this is when the user-DTP is sending the data in a transfer mode that requires the connection to be closed to indicate EOF. The server MUST close the data connection under the following conditions:
通常，服务器负责维护数据连接——发起它和关闭它。例外情况是当用户-DTP在要求关闭连接以表示EOF的传输模式中发送数据时。服务器必须在以下条件下关闭数据连接：
The server has completed sending data in a transfer mode that requires a close to indicate EOF.
服务器在需要关闭以指示EOF的传输模式中完成发送数据。
The server receives an ABORT command from the user.
服务器从用户收到ABORT命令。
The port specification is changed by a command from the user.
用户通过命令更改端口规范。
The control connection is closed legally or otherwise.
控制连接合法或以其他方式关闭。
An irrecoverable error condition occurs.
发生不可恢复的错误条件。
Otherwise the close is a server option, the exercise of which the server must indicate to the user-process by either a 250 or 226 reply only.
否则关闭是服务器的一个选项，服务器必须通过250或226回复仅向用户进程指示这种操作。
3.3 Data Connection Management 数据连接管理
Default Data Connection Ports: All FTP implementations must support use of the default data connection ports, and only the User-PI may initiate the use of non-default ports.
**默认数据连接端口：**所有FTP实现必须支持使用默认数据连接端口，且只有用户-PI可能发起使用非默认端口的操作。
Negotiating Non-Default Data Ports: The User-PI may specify a non-default user side data port with the PORT command. The User-PI may request the server side to identify a non-default server side data port with the PASV command. Since a connection is defined by the pair of addresses, either of these actions is enough to get a different data connection, still it is permitted to do both commands to use new ports on both ends of the data connection.
**协商非默认数据端口：**用户-PI可以使用PORT命令指定非默认用户侧数据端口。用户-PI可以请求服务器侧用PASV命令标识非默认服务器侧数据端口。由于连接由地址对定义，这些操作中的任何一个都足以获取不同的数据连接，但允许执行两个命令在数据连接的两端使用新端口。
Reuse of the Data Connection: When using the stream mode of data transfer the end of the file must be indicated by closing the connection. This causes a problem if multiple files are to be transfered in the session, due to need for TCP to hold the connection record for a time out period to guarantee the reliable communication. Thus the connection can not be reopened at once.
**数据连接的重用：**在使用流模式进行数据传输时，必须通过关闭连接来指示文件结束。如果在会话中要传输多个文件，这会引起问题，因为TCP需要保留连接记录一段时间以保证可靠通信。因此，连接不能立即重新打开。
There are two solutions to this problem. The first is to negotiate a non-default port. The second is to use another transfer mode.
这个问题有两个解决方案。第一个是协商一个非默认端口。第二个是使用另一种传输模式。
A comment on transfer modes. The stream transfer mode is inherently unreliable, since one can not determine if the connection closed prematurely or not. The other transfer modes (Block, Compressed) do not close the connection to indicate the end of file. They have enough FTP encoding that the data connection can be parsed to determine the end of the file. Thus using these modes one can leave the data connection open for multiple file transfers.
关于传输模式的评论。流传输模式本质上是不可靠的，因为无法确定连接是否过早关闭。其他传输模式（块、压缩）不关闭连接来指示文件结束。它们有足够的FTP编码，可以解析数据连接以确定文件的结束。因此，使用这些模式可以保持数据连接开放以传输多个文件。
3.4 Transmission Modes 传输模式
The next consideration in transferring data is choosing the appropriate transmission mode. There are three modes: one which formats the data and allows for restart procedures; one which also compresses the data for efficient transfer; and one which passes the data with little or no processing. In this last case the mode interacts with the structure attribute to determine the type of processing. In the compressed mode, the representation type determines the filler byte.
在传输数据时的下一个考虑是选择适当的传输模式。有三种模式：一种格式化数据并允许重启程序；一种还压缩数据以高效传输；以及一种几乎不处理或完全不处理数据的模式。在最后一种情况下，模式与结构属性相互作用，以确定处理的类型。在压缩模式中，表示类型决定填充字节。
All data transfers must be completed with an end-of-file (EOF) which may be explicitly stated or implied by the closing of the data connection. For files with record structure, all the end-of-record markers (EOR) are explicit, including the final one. For files transmitted in page structure a “last-page” page type is used.
所有数据传输必须以文件结束（EOF）完成，这可以通过明确声明或通过关闭数据连接隐含表示。对于有记录结构的文件，所有记录结束标记（EOR）都是明确的，包括最后一个。对于以页面结构传输的文件，使用“最后一页”页面类型。
NOTE: In the rest of this section, byte means “transfer byte” except where explicitly stated otherwise.
注意： 在本节的其余部分中，字节意味着“传输字节”，除非明确说明了其他含义。
For the purpose of standardized transfer, the sending host will translate its internal end of line or end of record denotation into the representation prescribed by the transfer mode and file structure, and the receiving host will perform the inverse translation to its internal denotation. An IBM Mainframe record count field may not be recognized at another host, so the end-of-record information may be transferred as a two byte control code in Stream mode or as a flagged bit in a Block or Compressed mode descriptor. End-of-line in an ASCII or EBCDIC file with no record structure should be indicated by or , respectively. Since these transformations imply extra work for some systems, identical systems transferring non-record structured text files might wish to use a binary representation and stream mode for the transfer.
为了标准化传输的目的，发送主机将其内部的行结束或记录结束标记转换为传输模式和文件结构规定的表示形式，接收主机将执行逆向转换到其内部标记。一个IBM大型机的记录计数字段可能在另一个主机上无法识别，因此，记录结束信息可能作为流模式中的两个字节控制代码或作为块或压缩模式描述符中的标记位传输。ASCII或EBCDIC文件（无记录结构）中的行结束应分别由或指示。由于这些转换对某些系统来说意味着额外的工作，传输非记录结构文本文件的相同系统可能希望使用二进制表示和流模式进行传输。
The following transmission modes are defined in FTP:
FTP中定义了以下传输模式：
3.4.1 Stream Mode 流模式
The data is transmitted as a stream of bytes. There is no restriction on the representation type used; record structures are allowed.
数据作为字节流传输。使用的表示类型没有限制；允许有记录结构。
In a record structured file EOR and EOF will each be indicated by a two-byte control code. The first byte of the control code will be all ones, the escape character. The second byte will have the low order bit on and zeros elsewhere for EOR and the second low order bit on for EOF; that is, the byte will have value 1 for EOR and value 2 for EOF. EOR and EOF may be indicated together on the last byte transmitted by turning both low order bits on (i.e., the value 3). If a byte of all ones was intended to be sent as data, it should be repeated in the second byte of the control code.
在有记录结构的文件中，EOR和EOF将分别由两个字节的控制代码指示。控制代码的第一个字节为全1，即转义字符。第二个字节的低位为1表示EOR，第二低位为1表示EOF；即，该字节的值为EOR时为1，为EOF时为2。EOR和EOF可以通过在最后传输的字节上同时打开两个低位来一起指示（即，值为3）。如果打算发送全1的数据字节，它应在控制代码的第二个字节中重复。
If the structure is a file structure, the EOF is indicated by the sending host closing the data connection and all bytes are data bytes.
如果结构是文件结构，则EOF通过发送主机关闭数据连接来指示，所有字节都是数据字节。
3.4.2 Block Mode 块模式
The file is transmitted as a series of data blocks preceded by one or more header bytes. The header bytes contain a count field, and descriptor code. The count field indicates the total length of the data block in bytes, thus marking the beginning of the next data block (there are no filler bits). The descriptor code defines: last block in the file (EOF) last block in the record (EOR), restart marker (see the Section on Error Recovery and Restart) or suspect data (i.e., the data being transferred is suspected of errors and is not reliable). This last code is NOT intended for error control within FTP. It is motivated by the desire of sites exchanging certain types of data (e.g., seismic or weather data) to send and receive all the data despite local errors (such as “magnetic tape read errors”), but to indicate in the transmission that certain portions are suspect). Record structures are allowed in this mode, and any representation type may be used.
文件作为一系列数据块传输，每个数据块前面有一个或多个头字节。头字节包含计数字段和描述符代码。计数字段指示数据块的总长度（以字节为单位），从而标记下一个数据块的开始（没有填充位）。描述符代码定义：文件中的最后一个块（EOF）、记录中的最后一个块（EOR）、重启标记（见错误恢复和重启部分）或可疑数据（即，正在传输的数据存在错误且不可靠）。这种最后一种代码不是FTP内部的错误控制意图。它是由希望交换某些类型数据（例如，地震或天气数据）的站点的愿望驱动的，尽管本地错误（如“磁带读取错误”），但发送和接收所有数据，并在传输中指示某些部分是可疑的。此模式允许记录结构，并且可以使用任何表示类型。
The header consists of the three bytes. Of the 24 bits of header information, the 16 low order bits shall represent byte count, and the 8 high order bits shall represent descriptor codes as shown below.
头由三个字节组成。在24位头信息中，16位低位表示字节计数，8位高位表示如下所示的描述符代码。
Block Header 描述
+----------------+----------------+----------------+
| Descriptor | Byte Count |
| 8 bits | 16 bits |
+----------------+----------------+----------------+
The descriptor codes are indicated by bit flags in the descriptor byte. Four codes have been assigned, where each code number is the decimal value of the corresponding bit in the byte.
描述符代码由描述符字节中的位标志指示。已分配四个代码，其中每个代码编号是字节中相应位的十进制值。
| Code 代码 | Meaning 含义 |
|---|---|
| 128 | End of data block is EOR 数据块结束是EOR |
| 64 | End of data block is EOF 数据块结束是EOF |
| 32 | Suspected errors in data block 数据块中的可疑错误 |
| 16 | Data block is a restart marker 数据块是重启标记 |
With this encoding, more than one descriptor coded condition may exist for a particular block. As many bits as necessary may be flagged.
使用这种编码，特定块可能存在多个描述符编码条件。可以标记尽可能多的位。
The restart marker is embedded in the data stream as an integral number of 8-bit bytes representing printable characters in the language being used over the control connection (e.g., default–NVT-ASCII). (Space, in the appropriate language) must not be used WITHIN a restart marker.
重启标记作为打印字符的8位字节的整数倍嵌入到数据流中，使用控制连接上使用的语言（例如，默认情况下是NVT-ASCII）。在重启标记内部，（空格，适当的语言）不得使用。
For example, to transmit a six-character marker, the following would be sent:
例如，要传输六个字符的标记，将发送以下内容：
+--------+--------+--------+
|Descrptr| Byte count |
|code= 16| = 6 |
+--------+--------+--------+
+--------+--------+--------+
| Marker | Marker | Marker |
| 8 bits | 8 bits | 8 bits |
+--------+--------+--------+
+--------+--------+--------+
| Marker | Marker | Marker |
| 8 bits | 8 bits | 8 bits |
+--------+--------+--------+
3.4.3 Compressed Mode 压缩模式
There are three kinds of information to be sent: regular data, sent in a byte string; compressed data, consisting of replications or filler; and control information, sent in a two-byte escape sequence. If n>0 bytes (up to 127) of regular data are sent, these n bytes are preceded by a byte with the left-most bit set to 0 and the right-most 7 bits containing the number n.
需要发送三种信息：常规数据，以字节字符串发送；压缩数据，包括复制或填充；控制信息，以两个字节的转义序列发送。如果发送n>0个字节（最多127）的常规数据，这n个字节前面会有一个字节，最左边的位设置为0，最右边的7位包含数字n。
Byte string 字节字符串:
1 7 8 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| n | | d(1) | ... | d(n) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
^ ^
|---n bytes---|
of data
String of n data bytes d(1),…, d(n) Count n must be positive.
字符串n个数据字节d(1),…, d(n) 计数n必须为正。
To compress a string of n replications of the data byte d, the following 2 bytes are sent:
要压缩n个复制的数据字节d，发送以下2个字节：
Replicated Byte: 复制字节：
2 6 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1 0| n | | d |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
A string of n filler bytes can be compressed into a single byte, where the filler byte varies with the representation type. If the type is ASCII or EBCDIC the filler byte is (Space, ASCII code 32, EBCDIC code 64). If the type is Image or Local byte the filler is a zero byte.
可以将n个填充字节压缩成一个字节，其中填充字节随表示类型变化。如果类型是ASCII或EBCDIC，填充字节是（空格，ASCII码32，EBCDIC码64）。如果类型是图像或本地字节，则填充是零字节。
Filler String 填充字符串：
2 6
+-+-+-+-+-+-+-+-+
|1 1| n |
+-+-+-+-+-+-+-+-+
The escape sequence is a double byte, the first of which is the escape byte (all zeros) and the second of which contains descriptor codes as defined in Block mode. The descriptor codes have the same meaning as in Block mode and apply to the succeeding string of bytes.
转义序列是双字节，第一个字节是转义字节（全零），第二个字节包含定义在块模式中的描述符代码。描述符代码的含义与块模式中的含义相同，并适用于后续的字节字符串。
Compressed mode is useful for obtaining increased bandwidth on very large network transmissions at a little extra CPU cost. It can be most effectively used to reduce the size of printer files such as those generated by RJE hosts.
压缩模式对于在非常大的网络传输上获得增加的带宽非常有用，代价是略微增加CPU成本。它可以最有效地用于减小打印文件的大小，例如RJE主机生成的文件。
3.5 Error Recovery and Restart 错误恢复和重启
There is no provision for detecting bits lost or scrambled in data transfer; this level of error control is handled by the TCP. However, a restart procedure is provided to protect users from gross system failures (including failures of a host, an FTP-process, or the underlying network).
FTP没有提供检测数据传输中丢失或混乱的位的方法；这一级别的错误控制由TCP处理。然而，提供了重启程序来保护用户免受严重系统故障（包括主机、FTP进程或底层网络的故障）的影响。
The restart procedure is defined only for the block and compressed modes of data transfer. It requires the sender of data to insert a special marker code in the data stream with some marker information. The marker information has meaning only to the sender, but must consist of printable characters in the default or negotiated language of the control connection (ASCII or EBCDIC). The marker could represent a bit-count, a record-count, or any other information by which a system may identify a data checkpoint. The receiver of data, if it implements the restart procedure, would then mark the corresponding position of this marker in the receiving system, and return this information to the user.
重启程序仅为数据传输的块和压缩模式定义。它要求数据的发送方在数据流中插入一个特殊的标记代码和一些标记信息。标记信息只对发送方有意义，但必须由控制连接的默认或协商语言中的可打印字符组成（ASCII或EBCDIC）。标记可以代表位计数、记录计数或任何其他信息，系统可以通过该信息识别数据检查点。数据的接收方，如果实现了重启程序，那么将在接收系统中标记此标记对应的位置，并将此信息返回给用户。
In the event of a system failure, the user can restart the data transfer by identifying the marker point with the FTP restart procedure. The following example illustrates the use of the restart procedure.
在系统故障的情况下，用户可以通过使用FTP重启程序并指定标记点来重启数据传输。以下示例说明了重启程序的使用。
The sender of the data inserts an appropriate marker block in the data stream at a convenient point. The receiving host marks the corresponding data point in its file system and conveys the last known sender and receiver marker information to the user, either directly or over the control connection in a 110 reply (depending on who is the sender). In the event of a system failure, the user or controller process restarts the server at the last server marker by sending a restart command with server’s marker code as its argument. The restart command is transmitted over the control connection and is immediately followed by the command (such as RETR, STOR or LIST) which was being executed when the system failure occurred.
数据的发送方在数据流中的一个方便点插入一个适当的标记块。接收主机在其文件系统中标记相应的数据点，并将最后已知的发送方和接收方标记信息传达给用户，无论是直接还是通过控制连接以110回复的形式（取决于谁是发送方）。在系统故障的情况下，用户或控制器进程使用服务器的标记代码作为参数发送重启命令，以重启服务器上最后一个服务器标记。重启命令通过控制连接传输，并立即跟随执行系统故障发生时正在执行的命令（如RETR、STOR或LIST）。
4. File Transfer Functions 文件传输功能
The communication channel from the user-PI to the server-PI is established as a TCP connection from the user to the standard server port. The user protocol interpreter is responsible for sending FTP commands and interpreting the replies received; the server-PI interprets commands, sends replies and directs its DTP to set up the data connection and transfer the data. If the second party to the data transfer (the passive transfer process) is the user-DTP, then it is governed through the internal protocol of the user-FTP host; if it is a second server-DTP, then it is governed by its PI on command from the user-PI. The FTP replies are discussed in the next section. In the description of a few of the commands in this section, it is helpful to be explicit about the possible replies.
用户-PI到服务器-PI的通信通道通过用户到标准服务器端口的TCP连接建立。用户协议解释器负责发送FTP命令并解释收到的回复；服务器-PI解释命令，发送回复，并指导其DTP设置数据连接和传输数据。如果数据传输的第二方（被动传输过程）是用户-DTP，则通过用户-FTP主机的内部协议进行管理；如果是第二个服务器-DTP，则由其PI根据用户-PI的命令进行管理。FTP回复将在下一节讨论。在本节中描述一些命令时，明确可能的回复很有帮助。
4.1 FTP Commands FTP命令
4.1.1 Access Control Commands 访问控制命令
The following commands specify access control identifiers (command codes are shown in parentheses).
以下命令指定访问控制标识符（命令代码显示在括号中）。
USER NAME 用户名 (USER)
The argument field is a Telnet string identifying the user. The user identification is that which is required by the server for access to its file system. This command will normally be the first command transmitted by the user after the control connections are made (some servers may require this). Additional identification information in the form of a password and/or an account command may also be required by some servers. Servers may allow a new USER command to be entered at any point in order to change the access control and/or accounting information. This has the effect of flushing any user, password, and account information already supplied and beginning the login sequence again. All transfer parameters are unchanged and any file transfer in progress is completed under the old access control parameters.
参数字段是一个Telnet字符串，用于识别用户。用户标识是服务器为访问其文件系统所需的。这个命令通常是用户在控制连接建立后传输的第一个命令（有些服务器可能要求这样）。一些服务器还可能要求额外的身份信息，如密码和/或账户命令。服务器可能允许在任何时候输入新的USER命令，以更改访问控制和/或记账信息。这将清除已提供的任何用户、密码和账户信息，并重新开始登录序列。所有传输参数保持不变，任何正在进行的文件传输都将在旧的访问控制参数下完成。
PASSWORD 密码 (PASS)
The argument field is a Telnet string specifying the user’s password. This command must be immediately preceded by the user name command, and, for some sites, completes the user’s identification for access control. Since password information is quite sensitive, it is desirable in general to “mask” it or suppress typeout. It appears that the server has no foolproof way to achieve this. It is therefore the responsibility of the user-FTP process to hide the sensitive password information.
参数字段是一个指定用户密码的Telnet字符串。这个命令必须紧跟在用户名命令之后，并且对于一些站点来说，完成了用户的访问控制身份验证。由于密码信息非常敏感，通常希望“掩盖”或抑制打印出来。看来服务器没有确保这一点的万无一失的方法。因此，隐藏敏感密码信息的责任在于用户-FTP进程。
ACCOUNT 账户 (ACCT)
The argument field is a Telnet string identifying the user’s account. The command is not necessarily related to the USER command, as some sites may require an account for login and others only for specific access, such as storing files. In the latter case the command may arrive at any time.
参数字段是一个Telnet字符串，用于识别用户的账户。这个命令不一定与USER命令相关，因为有些站点可能需要登录账户，而其他站点只在特定访问时需要，如存储文件。在后一种情况下，命令可以在任何时候到达。
There are reply codes to differentiate these cases for the automation: when account information is required for login, the response to a successful PASSword command is reply code 332. On the other hand, if account information is NOT required for login, the reply to a successful PASSword command is 230; and if the account information is needed for a command issued later in the dialogue, the server should return a 332 or 532 reply depending on whether it stores (pending receipt of the ACCounT command) or discards the command, respectively.
对于自动化，有回复代码来区分这些情况：当登录需要账户信息时，成功的PASSword命令的响应是回复代码332。另一方面，如果登录不需要账户信息，成功的PASSword命令的回复是230；如果在对话中稍后发出的命令需要账户信息，服务器应根据它是存储（等待接收ACCounT命令）还是丢弃命令，分别返回332或532回复。
CHANGE WORKING DIRECTORY 更改工作目录 (CWD)
This command allows the user to work with a different directory or dataset for file storage or retrieval without altering his login or accounting information. Transfer parameters are similarly unchanged. The argument is a pathname specifying a directory or other system dependent file group designator.
此命令允许用户在不更改其登录或记账信息的情况下，使用不同的目录或数据集进行文件存储或检索。传输参数同样未改变。参数是指定目录或其他系统依赖的文件组指示符的路径名。
CHANGE TO PARENT DIRECTORY 更改到父目录 (CDUP)
This command is a special case of CWD, and is included to simplify the implementation of programs for transferring directory trees between operating systems having different syntaxes for naming the parent directory. The reply codes shall be identical to the reply codes of CWD. See Appendix II for further details.
此命令是CWD的特例，包含在内是为了简化在具有不同父目录命名语法的操作系统之间传输目录树的程序的实现。回复代码应与CWD的回复代码相同。有关更多详细信息，请参见附录II。
STRUCTURE MOUNT 结构挂载 (SMNT)
This command allows the user to mount a different file system data structure without altering his login or accounting information. Transfer parameters are similarly unchanged. The argument is a pathname specifying a directory or other system dependent file group designator.
此命令允许用户在不更改其登录或记账信息的情况下，挂载不同的文件系统数据结构。传输参数同样未改变。参数是指定目录或其他系统依赖的文件组指示符的路径名。
REINITIALIZE 重新初始化 (REIN)
This command terminates a USER, flushing all I/O and account information, except to allow any transfer in progress to be completed. All parameters are reset to the default settings and the control connection is left open. This is identical to the state in which a user finds himself immediately after the control connection is opened. A USER command may be expected to follow.
此命令终止一个USER会话，清除所有I/O和账户信息，但允许任何正在进行的传输完成。所有参数重置为默认设置，控制连接保持开放。这与用户刚刚打开控制连接后发现的状态相同。预计之后会有一个USER命令。
LOGOUT 注销 (QUIT)
This command terminates a USER and if file transfer is not in progress, the server closes the control connection. If file transfer is in progress, the connection will remain open for result response and the server will then close it. If the user-process is transferring files for several USERs but does not wish to close and then reopen connections for each, then the REIN command should be used instead of QUIT.
此命令终止一个USER会话，如果没有进行文件传输，服务器将关闭控制连接。如果文件传输正在进行中，连接将保持开放以等待结果响应，然后服务器将其关闭。如果用户进程为多个用户传输文件但不希望为每个用户关闭然后重新打开连接，则应使用REIN命令而不是QUIT。
An unexpected close on the control connection will cause the server to take the effective action of an abort (ABOR) and a logout (QUIT).
控制连接上的意外关闭将导致服务器采取中止（ABOR）和注销（QUIT）的有效操作。
4.1.2 Transfer Parameter Commands 传输参数命令
All data transfer parameters have default values, and the commands specifying data transfer parameters are required only if the default parameter values are to be changed. The default value is the last specified value, or if no value has been specified, the standard default value is as stated here. This implies that the server must “remember” the applicable default values. The commands may be in any order except that they must precede the FTP service request. The following commands specify data transfer parameters:
所有数据传输参数都有默认值，仅在需要更改默认参数值时才需要指定数据传输参数的命令。默认值是最后指定的值，或者如果没有指定值，则标准默认值如本文所述。这意味着服务器必须“记住”适用的默认值。命令的顺序可以任意，但必须在FTP服务请求之前。以下命令指定数据传输参数：
DATA PORT 数据端口 (PORT)
The argument is a HOST-PORT specification for the data port to be used in data connection. There are defaults for both the user and server data ports, and under normal circumstances this command and its reply are not needed. If this command is used, the argument is the concatenation of a 32-bit internet host address and a 16-bit TCP port address. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A port command would be:
参数是用于数据连接的数据端口的HOST-PORT规范。用户和服务器数据端口都有默认值，在正常情况下不需要这个命令及其回复。如果使用此命令，参数是32位互联网主机地址和16位TCP端口地址的连接。这个地址信息被分解为8位字段，每个字段的值作为十进制数（以字符字符串表示）传输。字段之间用逗号分隔。一个端口命令将是：
PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host address.
其中h1是互联网主机地址的高8位。
PASSIVE 被动 (PASV)
This command requests the server-DTP to “listen” on a data port (which is not its default data port) and to wait for a connection rather than initiate one upon receipt of a transfer command. The response to this command includes the host and port address this server is listening on.
此命令请求服务器-DTP在一个数据端口（不是其默认数据端口）上“监听”，并等待连接而不是在收到传输命令时发起连接。此命令的响应包括服务器正在监听的主机和端口地址。
REPRESENTATION TYPE 表示类型 (TYPE)
The argument specifies the representation type as described in the Section on Data Representation and Storage. Several types take a second parameter. The first parameter is denoted by a single Telnet character, as is the second Format parameter for ASCII and EBCDIC; the second parameter for local byte is a decimal integer to indicate Bytesize. The parameters are separated by a (Space, ASCII code 32).
参数指定了在数据表示和存储部分描述的表示类型。一些类型需要第二个参数。第一个参数由单个Telnet字符表示，就像ASCII和EBCDIC的第二个格式参数一样；本地字节的第二个参数是一个十进制整数，表示字节大小。参数之间用（空格，ASCII代码32）分隔。
The following codes are assigned for type:
为类型分配以下代码：
\ /
A - ASCII | | N - Non-print
|-><-| T - Telnet format effectors
E - EBCDIC| | C - Carriage Control (ASA)
/ \
I - Image
L <byte size> - Local byte Byte size
The default representation type is ASCII Non-print. If the Format parameter is changed, and later just the first argument is changed, Format then returns to the Non-print default.
默认表示类型是ASCII非打印。如果更改了格式参数，稍后仅更改第一个参数，格式则返回到非打印默认值。
FILE STRUCTURE 文件结构 (STRU)
The argument is a single Telnet character code specifying file structure described in the Section on Data Representation and Storage.
参数是一个指定文件结构的单个Telnet字符代码，如数据表示和存储部分所述。
The following codes are assigned for structure:
为结构分配以下代码：
- F - File (no record structure) 文件（无记录结构）
- R - Record structure 记录结构
- P - Page structure 页面结构
The default structure is File.
默认结构是文件。
TRANSFER MODE 传输模式 (MODE)
The argument is a single Telnet character code specifying the data transfer modes described in the Section on Transmission Modes.
参数是一个指定数据传输模式的单个Telnet字符代码，如传输模式部分所述。
The following codes are assigned for transfer modes:
为传输模式分配以下代码：
- S - Stream 流
- B - Block 块
- C - Compressed 压缩
The default transfer mode is Stream.
默认传输模式是流。
4.1.3 FTP Service Commands FTP服务命令
The FTP service commands define the file transfer or the file system function requested by the user. The argument of an FTP service command will normally be a pathname. The syntax of pathnames must conform to server site conventions (with standard defaults applicable), and the language conventions of the control connection. The suggested default handling is to use the last specified device, directory or file name, or the standard default defined for local users. The commands may be in any order except that a “rename from” command must be followed by a “rename to” command and the restart command must be followed by the interrupted service command (e.g., STOR or RETR). The data, when transferred in response to FTP service commands, shall always be sent over the data connection, except for certain informative replies. The following commands specify FTP service requests:
FTP服务命令定义了用户请求的文件传输或文件系统功能。FTP服务命令的参数通常是路径名。路径名的语法必须符合服务器站点的约定（适用标准默认值），以及控制连接的语言约定。建议的默认处理是使用最后指定的设备、目录或文件名，或为本地用户定义的标准默认值。命令的顺序可以任意，但是“重命名从”命令必须由“重命名到”命令跟随，并且重启命令必须由被中断的服务命令（例如，STOR或RETR）跟随。根据FTP服务命令的响应，数据总是通过数据连接发送，除了某些提供信息的回复外。以下命令指定FTP服务请求：
RETRIEVE 检索 (RETR)
This command causes the server-DTP to transfer a copy of the file, specified in the pathname, to the server- or user-DTP at the other end of the data connection. The status and contents of the file at the server site shall be unaffected.
此命令使服务器-DTP将指定路径名中的文件副本传输到数据连接另一端的服务器或用户-DTP。服务器站点上的文件的状态和内容不受影响。
STORE 存储 (STOR)
This command causes the server-DTP to accept the data transferred via the data connection and to store the data as a file at the server site. If the file specified in the pathname exists at the server site, then its contents shall be replaced by the data being transferred. A new file is created at the server site if the file specified in the pathname does not already exist.
此命令使服务器-DTP接受通过数据连接传输的数据，并将数据作为文件存储在服务器站点。如果路径名中指定的文件在服务器站点存在，则其内容将被传输的数据替换。如果路径名中指定的文件不存在，则将在服务器站点创建新文件。
STORE UNIQUE 存储唯一 (STOU)
This command behaves like STOR except that the resultant file is to be created in the current directory under a name unique to that directory. The 250 Transfer Started response must include the name generated.
此命令的行为类似于STOR，除了结果文件将在当前目录下以该目录唯一的名称创建。250传输开始响应必须包括生成的名称。
APPEND (with create) 追加（带创建）(APPE)
This command causes the server-DTP to accept the data transferred via the data connection and to store the data in a file at the server site. If the file specified in the pathname exists at the server site, then the data shall be appended to that file; otherwise the file specified in the pathname shall be created at the server site.
此命令使服务器-DTP接受通过数据连接传输的数据，并将数据存储在服务器站点的文件中。如果路径名中指定的文件在服务器站点存在，则数据将被追加到该文件中；否则，将在服务器站点创建路径名中指定的文件。
ALLOCATE 分配 (ALLO)
This command may be required by some servers to reserve sufficient storage to accommodate the new file to be transferred. The argument shall be a decimal integer representing the number of bytes (using the logical byte size) of storage to be reserved for the file. For files sent with record or page structure a maximum record or page size (in logical bytes) might also be necessary; this is indicated by a decimal integer in a second argument field of the command. This second argument is optional, but when present should be separated from the first by the three Telnet characters R . This command shall be followed by a STORe or APPEnd command. The ALLO command should be treated as a NOOP (no operation) by those servers which do not require that the maximum size of the file be declared beforehand, and those servers interested in only the maximum record or page size should accept a dummy value in the first argument and ignore it.
某些服务器可能要求此命令来预留足够的存储空间以容纳要传输的新文件。参数应该是一个十进制整数，表示要为文件保留的字节（使用逻辑字节大小）的数量。对于带有记录或页面结构的文件，可能还需要最大记录或页面大小（以逻辑字节为单位）；这由命令的第二个参数字段中的十进制整数表示。这第二个参数是可选的，但如果存在，应该用三个Telnet字符 R 与第一个参数分开。此命令应该后跟一个STORe或APPEnd命令。对于那些不需要事先声明文件的最大大小的服务器，ALLO命令应该被视为NOOP（无操作），而那些只对最大记录或页面大小感兴趣的服务器应该接受第一个参数中的虚拟值并忽略它。
RESTART 重启 (REST)
The argument field represents the server marker at which file transfer is to be restarted. This command does not cause file transfer but skips over the file to the specified data checkpoint. This command shall be immediately followed by the appropriate FTP service command which shall cause file transfer to resume.
参数字段代表要重新启动文件传输的服务器标记。此命令不会导致文件传输，而是跳过文件到指定的数据检查点。此命令应立即后跟适当的FTP服务命令，该命令将导致文件传输恢复。
RENAME FROM 重命名从 (RNFR)
This command specifies the old pathname of the file which is to be renamed. This command must be immediately followed by a “rename to” command specifying the new file pathname.
此命令指定要重命名的文件的旧路径名。此命令必须立即由指定新文件路径名的“重命名到”命令跟随。两个命令一起导致文件被重命名。
RENAME TO 重命名到 (RNTO)
This command specifies the new pathname of the file specified in the immediately preceding “rename from” command. Together the two commands cause a file to be renamed.
此命令指定在紧接前面的“重命名从”命令中指定的文件的新路径名。两个命令一起导致一个文件被重命名。
ABORT 中止 (ABOR)
This command tells the server to abort the previous FTP service command and any associated transfer of data. The abort command may require “special action”, as discussed in the Section on FTP Commands, to force recognition by the server. No action is to be taken if the previous command has been completed (including data transfer). The control connection is not to be closed by the server, but the data connection must be closed.
此命令告诉服务器中止前一个FTP服务命令及其相关的数据传输。中止命令可能需要“特殊操作”，如FTP命令部分所讨论的，以强制服务器识别。如果前一个命令已经完成（包括数据传输），则不采取任何行动。服务器不应关闭控制连接，但必须关闭数据连接。
There are two cases for the server upon receipt of this command:
服务器收到此命令有两种情况：
the FTP service command was already completed
FTP服务命令已经完成
the FTP service command is still in progress.
FTP服务命令仍在进行中。
In the first case, the server closes the data connection (if it is open) and responds with a 226 reply, indicating that the abort command was successfully processed.
在第一种情况下，如果数据连接已经打开，服务器关闭数据连接，并以226回复响应，表明中止命令已成功处理。
In the second case, the server aborts the FTP service in progress and closes the data connection, returning a 426 reply to indicate that the service request terminated abnormally. The server then sends a 226 reply, indicating that the abort command was successfully processed.
在第二种情况下，服务器中止正在进行的FTP服务并关闭数据连接，返回426回复以指示服务请求异常终止。然后服务器发送226回复，表明中止命令已成功处理。
DELETE (DELE) 删除
This command causes the file specified in the pathname to be deleted at the server site. If an extra level of protection is desired (such as the query, “Do you really wish to delete?”), it should be provided by the user-FTP process.
此命令导致在路径名中指定的文件在服务器站点被删除。如果需要额外的保护级别（如查询，“您真的希望删除吗？”），则应由用户-FTP进程提供。
REMOVE DIRECTORY (RMD) 删除目录
This command causes the directory specified in the pathname to be removed as a directory (if the pathname is absolute) or as a subdirectory of the current working directory (if the pathname is relative). See Appendix II.
此命令导致在路径名中指定的目录被删除，作为一个目录（如果路径名是绝对的）或作为当前工作目录的子目录（如果路径名是相对的）。见附录II。
MAKE DIRECTORY (MKD) 创建目录
This command causes the directory specified in the pathname to be created as a directory (if the pathname is absolute) or as a subdirectory of the current working directory (if the pathname is relative). See Appendix II.
此命令导致在路径名中指定的目录被创建为一个目录（如果路径名是绝对的）或作为当前工作目录的子目录（如果路径名是相对的）。见附录II。
PRINT WORKING DIRECTORY (PWD) 打印工作目录
This command causes the name of the current working directory to be returned in the reply. See Appendix II.
此命令导致在回复中返回当前工作目录的名称。见附录II。
LIST 列表 (LIST)
This command causes a list to be sent from the server to the passive DTP. If the pathname specifies a directory or other group of files, the server should transfer a list of files in the specified directory. If the pathname specifies a file then the server should send current information on the file. A null argument implies the user’s current working or default directory. The data transfer is over the data connection in type ASCII or type EBCDIC. (The user must ensure that the TYPE is appropriately ASCII or EBCDIC). Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user.
此命令导致服务器将列表从服务器发送到被动DTP。如果路径名指定了一个目录或其他文件组，则服务器应传输指定目录中的文件列表。如果路径名指定了一个文件，则服务器应发送有关该文件的当前信息。空参数意味着用户的当前工作或默认目录。数据传输在类型ASCII或类型EBCDIC上通过数据连接进行。（用户必须确保类型适当地为ASCII或EBCDIC）。由于不同系统上关于文件的信息可能差异很大，这些信息可能很难在程序中自动使用，但对于人类用户可能非常有用。
NAME LIST 名称列表 (NLST)
This command causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor; a null argument implies the current directory. The server will return a stream of names of files and no other information. The data will be transferred in ASCII or EBCDIC type over the data connection as valid pathname strings separated by or . (Again the user must ensure that the TYPE is correct.) This command is intended to return information that can be used by a program to further process the files automatically. For example, in the implementation of a “multiple get” function.
此命令导致目录列表从服务器发送到用户站点。路径名应指定一个目录或其他系统特定的文件组描述符；空参数意味着当前目录。服务器将返回文件名流，而没有其他信息。数据将以ASCII或EBCDIC类型通过数据连接传输，作为有效的路径名字符串，由或分隔。（同样，用户必须确保类型正确。）此命令旨在返回可以由程序进一步自动处理文件的信息。例如，在实现“多个获取”功能时。
SITE PARAMETERS 站点参数 (SITE)
This command is used by the server to provide services specific to his system that are essential to file transfer but not sufficiently universal to be included as commands in the protocol. The nature of these services and the specification of their syntax can be stated in a reply to the HELP SITE command.
此命令由服务器用来提供对其系统特定的、对文件传输至关重要但不足以作为协议中的命令包括的服务。这些服务的性质和语法规范可以在对HELP SITE命令的回复中说明。
SYSTEM 系统 (SYST)
This command is used to find out the type of operating system at the server. The reply shall have as its first word one of the system names listed in the current version of the Assigned Numbers document [4].
此命令用于找出服务器的操作系统类型。回复的第一个词应该是在当前版本的Assigned Numbers文档[4]中列出的系统名称之一。
STATUS 状态 (STAT)
This command shall cause a status response to be sent over the control connection in the form of a reply. The command may be sent during a file transfer (along with the Telnet IP and Synch signals–see the Section on FTP Commands) in which case the server will respond with the status of the operation in progress, or it may be sent between file transfers. In the latter case, the command may have an argument field. If the argument is a pathname, the command is analogous to the “list” command except that data shall be transferred over the control connection. If a partial pathname is given, the server may respond with a list of file names or attributes associated with that specification. If no argument is given, the server should return general status information about the server FTP process. This should include current values of all transfer parameters and the status of connections.
此命令将导致通过控制连接以回复形式发送状态响应。该命令可以在文件传输期间发送（连同Telnet IP和同步信号——见FTP命令部分），在这种情况下，服务器将响应正在进行的操作的状态，或者可以在文件传输之间发送。在后一种情况下，命令可能有一个参数字段。如果参数是路径名，则该命令类似于“list”命令，只是数据将通过控制连接传输。如果给出部分路径名，服务器可能会回复与该规范相关的文件名或属性列表。如果没有给出参数，则服务器应返回有关服务器FTP进程的一般状态信息。这应该包括所有传输参数的当前值和连接的状态。
HELP 帮助 (HELP)
This command shall cause the server to send helpful information regarding its implementation status over the control connection to the user. The command may take an argument (e.g., any command name) and return more specific information as a response. The reply is type 211 or 214. It is suggested that HELP be allowed before entering a USER command. The server may use this reply to specify site-dependent parameters, e.g., in response to HELP SITE.
此命令将导致服务器通过控制连接向用户发送有关其实现状态的有用信息。该命令可以带有一个参数（例如，任何命令名称），并返回更具体的信息作为响应。回复类型为211或214。建议在输入USER命令之前允许使用HELP。服务器可以使用此回复来指定站点依赖的参数，例如，响应于HELP SITE。
NOOP 无操作 (NOOP)
This command does not affect any parameters or previously entered commands. It specifies no action other than that the server send an OK reply.
此命令不影响任何参数或之前输入的命令。它指定的唯一操作是服务器发送OK回复。
The File Transfer Protocol follows the specifications of the Telnet protocol for all communications over the control connection. Since the language used for Telnet communication may be a negotiated option, all references in the next two sections will be to the “Telnet language” and the corresponding “Telnet end-of-line code”. Currently, one may take these to mean NVT-ASCII and . No other specifications of the Telnet protocol will be cited.
文件传输协议（FTP）遵循Telnet协议的规范进行所有控制连接上的通信。由于用于Telnet通信的语言可能是一个协商的选项，因此在接下来的两个部分中的所有引用将指向“Telnet语言”和相应的“Telnet行结束代码”。目前，这些可以理解为NVT-ASCII和。不会引用Telnet协议的其他规范。
FTP commands are “Telnet strings” terminated by the “Telnet end of line code”. The command codes themselves are alphabetic characters terminated by the character (Space) if parameters follow and Telnet-EOL otherwise. The command codes and the semantics of commands are described in this section; the detailed syntax of commands is specified in the Section on Commands, the reply sequences are discussed in the Section on Sequencing of Commands and Replies, and scenarios illustrating the use of commands are provided in the Section on Typical FTP Scenarios.
FTP命令是由“Telnet行结束代码”终止的“Telnet字符串”。命令代码本身是字母字符，如果后面跟有参数，则由字符（空格）终止，否则由Telnet-EOL终止。本节描述了命令的命令代码和语义；命令的详细语法在命令部分中指定，命令和回复的顺序在命令和回复的顺序部分中讨论，而典型FTP场景部分提供了使用命令的场景示例。
FTP commands may be partitioned as those specifying access-control identifiers, data transfer parameters, or FTP service requests. Certain commands (such as ABOR, STAT, QUIT) may be sent over the control connection while a data transfer is in progress. Some servers may not be able to monitor the control and data connections simultaneously, in which case some special action will be necessary to get the server’s attention. The following ordered format is tentatively recommended:
FTP命令可以划分为指定访问控制标识符、数据传输参数或FTP服务请求的命令。某些命令（如ABOR、STAT、QUIT）可以在数据传输进行中通过控制连接发送。一些服务器可能无法同时监视控制和数据连接，在这种情况下，需要采取一些特殊行动来引起服务器的注意。暂时推荐以下有序格式：
User system inserts the Telnet “Interrupt Process” (IP) signal in the Telnet stream.
用户系统在Telnet流中插入Telnet“中断进程”（IP）信号。
User system sends the Telnet “Synch” signal.
用户系统发送Telnet“同步”信号。
User system inserts the command (e.g., ABOR) in the Telnet stream.
用户系统在Telnet流中插入命令（例如，ABOR）。
Server PI, after receiving “IP”, scans the Telnet stream for EXACTLY ONE FTP command.
服务器PI在收到“IP”后，扫描Telnet流以寻找恰好一个FTP命令。
(For other servers this may not be necessary but the actions listed above should have no unusual effect.)
（对于其他服务器，这可能不是必需的，但上述操作应该没有不寻常的效果。）
4.2 FTP Replies FTP回复
Replies to File Transfer Protocol commands are devised to ensure the synchronization of requests and actions in the process of file transfer, and to guarantee that the user process always knows the state of the Server. Every command must generate at least one reply, although there may be more than one; in the latter case, the multiple replies must be easily distinguished. In addition, some commands occur in sequential groups, such as USER, PASS and ACCT, or RNFR and RNTO. The replies show the existence of an intermediate state if all preceding commands have been successful. A failure at any point in the sequence necessitates the repetition of the entire sequence from the beginning.
FTP命令的回复旨在确保文件传输过程中请求和动作的同步，并保证用户进程始终了解服务器的状态。每个命令必须生成至少一个回复，尽管可能有多个；在后一种情况下，必须容易区分多个回复。此外，一些命令以顺序组出现，例如USER、PASS和ACCT，或RNFR和RNTO。如果所有前面的命令都成功了，回复显示中间状态的存在。序列中任何点的失败都需要从头开始重复整个序列。
The details of the command-reply sequence are made explicit in a set of state diagrams below.
命令-回复序列的细节在下面的一组状态图中明确说明。
An FTP reply consists of a three digit number (transmitted as three alphanumeric characters) followed by some text. The number is intended for use by automata to determine what state to enter next; the text is intended for the human user. It is intended that the three digits contain enough encoded information that the user-process (the User-PI) will not need to examine the text and may either discard it or pass it on to the user, as appropriate. In particular, the text may be server-dependent, so there are likely to be varying texts for each reply code.
FTP回复由三位数字（以三个字母数字字符传输）和一些文本组成。这个数字旨在供自动机使用，以确定下一个要进入的状态；文本旨在供人类用户使用。目的是三位数字包含足够的编码信息，以使用户进程（用户-PI）无需检查文本，可以根据需要将其丢弃或传递给用户。特别是，文本可能依赖于服务器，因此每个回复代码可能会有不同的文本。
A reply is defined to contain the 3-digit code, followed by Space , followed by one line of text (where some maximum line length has been specified), and terminated by the Telnet end-of-line code. There will be cases however, where the text is longer than a single line. In these cases the complete text must be bracketed so the User-process knows when it may stop reading the reply (i.e. stop processing input on the control connection) and go do other things. This requires a special format on the first line to indicate that more than one line is coming, and another on the last line to designate it as the last. At least one of these must contain the appropriate reply code to indicate the state of the transaction. To satisfy all factions, it was decided that both the first and last line codes should be the same.
回复被定义为包含3位代码，后跟空格，然后是一行文本（已指定某些最大行长度），并以Telnet行结束代码终止。然而，会有文本超过单行的情况。在这些情况下，必须用括号括起完整的文本，以便用户进程知道何时可以停止阅读回复（即停止处理控制连接上的输入）并去做其他事情。这需要在第一行上使用特殊格式以指示有多行内容即将到来，以及在最后一行上使用另一种格式以指定它为最后一行。这两者中至少有一个必须包含适当的回复代码以指示交易的状态。为了满足所有方，决定第一行和最后一行的代码应该相同。
Thus the format for multi-line replies is that the first line will begin with the exact required reply code, followed immediately by a Hyphen, “-” (also known as Minus), followed by text. The last line will begin with the same code, followed immediately by Space , optionally some text, and the Telnet end-of-line code.
因此，多行回复的格式是，第一行将以确切要求的回复代码开始，紧接着是连字符“-”（也称为减号），然后是文本。最后一行将以相同的代码开始，紧接着是空格，可选一些文本，以及Telnet行结束代码。
For example:
例如：
123-First line Second line 234 A line beginning with numbers 123 The last lineThe user-process then simply needs to search for the second occurrence of the same reply code, followed by (Space), at the beginning of a line, and ignore all intermediary lines. If an intermediary line begins with a 3-digit number, the Server must pad the front to avoid confusion.
然后，用户进程只需在一行的开头搜索相同回复代码的第二次出现，后跟（空格），并忽略所有中间行。如果中间行以3位数字开头，服务器必须在前面填充以避免混淆。
This scheme allows standard system routines to be used for reply information (such as for the STAT reply), with “artificial” first and last lines tacked on. In rare cases where these routines are able to generate three digits and a Space at the beginning of any line, the beginning of each text line should be offset by some neutral text, like Space.
此方案允许使用标准系统例程来用于回复信息（例如STAT回复），并添加了“人为的”第一行和最后一行。在极少数情况下，这些例程能够在任何行的开头生成三位数字和一个空格，每行文本的开头应该用一些中性文本（如空格）偏移。
This scheme assumes that multi-line replies may not be nested.
此方案假设多行回复不能嵌套。
The three digits of the reply each have a special significance. This is intended to allow a range of very simple to very sophisticated responses by the user-process. The first digit denotes whether the response is good, bad or incomplete. (Referring to the state diagram), an unsophisticated user-process will be able to determine its next action (proceed as planned, redo, retrench, etc.) by simply examining this first digit. A user-process that wants to know approximately what kind of error occurred (e.g. file system error, command syntax error) may examine the second digit, reserving the third digit for the finest gradation of information (e.g., RNTO command without a preceding RNFR).
回复代码的三位数字每一位都有其特殊的意义。这旨在允许用户进程做出从非常简单到非常复杂的响应。第一位数字表示响应是好的、坏的还是不完整的。参考状态图，一个不复杂的用户进程可以通过简单地检查这第一位数字来确定其下一步行动（按计划进行、重做、缩减等）。想要大致了解发生了什么类型错误的用户进程（例如文件系统错误、命令语法错误）可以检查第二位数字，保留第三位数字给予最细微的信息分级（例如，没有先前的RNFR命令的RNTO）。
There are five values for the first digit of the reply code:
回复代码的第一位有五个值：
1yz Positive Preliminary reply 正面预备回复
The requested action is being initiated; expect another reply before proceeding with a new command. (The user-process sending another command before the completion reply would be in violation of protocol; but server-FTP processes should queue any commands that arrive while a preceding command is in progress.) This type of reply can be used to indicate that the command was accepted and the user-process may now pay attention to the data connections, for implementations where simultaneous monitoring is difficult. The server-FTP process may send at most, one 1yz reply per command.
请求的动作正在被启动；在进行新命令之前，期待另一个回复。（在完成回复之前发送另一个命令的用户进程将违反协议；但服务器-FTP进程应该对在前一个命令进行中时到达的任何命令进行排队。）这种类型的回复可以用来指示命令已被接受，用户进程现在可以注意数据连接，对于同时监控困难的实现而言。服务器-FTP进程最多可以对每个命令发送一个1yz回复。
2yz Positive Completion reply 正面完成回复
The requested action has been successfully completed. A new request may be initiated.
请求的动作已成功完成。可以启动一个新请求。
3yz Positive Intermediate reply 正面中间回复
The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information. The user should send another command specifying this information. This reply is used in command sequence groups.
命令已被接受，但请求的动作正在等待接收更多信息后再进行。用户应发送另一个指定此信息的命令。这个回复用于命令序列组。
4yz Transient Negative Completion reply 临时负面完成回复
The command was not accepted and the requested action did not take place, but the error condition is temporary and the action may be requested again. The user should return to the beginning of the command sequence, if any. It is difficult to assign a meaning to “transient”, particularly when two distinct sites (Server- and User-processes) have to agree on the interpretation. Each reply in the 4yz category might have a slightly different time value, but the intent is that the user-process is encouraged to try again. A rule of thumb in determining if a reply fits into the 4yz or the 5yz (Permanent Negative) category is that replies are 4yz if the commands can be repeated without any change in command form or in properties of the User or Server (e.g., the command is spelled the same with the same arguments used; the user does not change his file access or user name; the server does not put up a new implementation.)
命令未被接受，请求的动作没有发生，但错误条件是暂时的，动作可能会被再次请求。用户应返回到命令序列的开始，如果有的话。很难给“临时”分配一个意义，尤其是当两个不同的站点（服务器和用户进程）必须对解释达成一致时。4yz类别中的每个回复可能有稍微不同的时间值，但意图是鼓励用户进程再次尝试。在判断回复属于4yz还是5yz（永久负面）类别时的经验法则是，如果命令可以重复而不改变命令形式或用户或服务器的属性，则回复为4yz（例如，命令拼写相同，使用相同的参数；用户没有改变他的文件访问或用户名；服务器没有实施新的实现）。
5yz Permanent Negative Completion reply 永久负面完成回复
The command was not accepted and the requested action did not take place. The User-process is discouraged from repeating the exact request (in the same sequence). Even some “permanent” error conditions can be corrected, so the human user may want to direct his User-process to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered his directory status.)
命令未被接受，请求的动作没有发生。不鼓励用户进程重复完全相同的请求（以相同的序列）。即使一些“永久”的错误条件可以被纠正，所以人类用户可能希望在未来的某个时刻通过直接行动指导他的用户进程重新启动命令序列（例如，在拼写被更改后，或用户已更改他的目录状态后）。
The following function groupings are encoded in the second digit:
在回复代码的第二位中编码的功能分组：
x0z Syntax 语法
These replies refer to syntax errors, syntactically correct commands that don’t fit any functional category, unimplemented or superfluous commands.
这些回复指的是语法错误、语法上正确但不属于任何功能类别的命令、未实现或多余的命令。
x1z Information 信息
These are replies to requests for information, such as status or help.
这些是对信息请求的回复，如状态或帮助。
x2z Connections 连接
Replies referring to the control and data connections.
指的是控制和数据连接的回复。
x3z Authentication and accounting 身份验证和账户
Replies for the login process and accounting procedures.
登录过程的回复。
x4z Unspecified as yet. 尚未指定。
x5z File system 文件系统
These replies indicate the status of the Server file system vis-a-vis the requested transfer or other file system action.
这些回复指出服务器文件系统相对于请求的传输或其他文件系统操作的状态。
The third digit gives a finer gradation of meaning in each of the function categories, specified by the second digit. The list of replies below will illustrate this. Note that the text associated with each reply is recommended, rather than mandatory, and may even change according to the command with which it is associated. The reply codes, on the other hand, must strictly follow the specifications in the last section; that is, Server implementations should not invent new codes for situations that are only slightly different from the ones described here, but rather should adapt codes already defined.
第三位数字在由第二位指定的每个功能类别中提供更细的意义分级。下面列出的回复将说明这一点。请注意，与每个回复关联的文本是推荐的，而不是强制的，并且可能会根据与之关联的命令而改变。另一方面，回复代码必须严格遵循最后一部分的规范；也就是说，服务器实现不应为与此处描述的情况仅略有不同的情况发明新的代码，而应适应已定义的代码。
A command such as TYPE or ALLO whose successful execution does not offer the user-process any new information will cause a 200 reply to be returned. If the command is not implemented by a particular Server-FTP process because it has no relevance to that computer system, for example ALLO at a TOPS20 site, a Positive Completion reply is still desired so that the simple User-process knows it can proceed with its course of action. A 202 reply is used in this case with, for example, the reply text: “No storage allocation necessary.” If, on the other hand, the command requests a non-site-specific action and is unimplemented, the response is 502. A refinement of that is the 504 reply for a command that is implemented, but that requests an unimplemented parameter.
如TYPE或ALLO这样的命令，其成功执行不为用户进程提供任何新信息，将导致返回200回复。如果某个特定的服务器-FTP进程因为它与那台计算机系统无关，例如TOPS20站点的ALLO，未实现该命令，仍然希望得到正面完成回复，以便简单的用户进程知道它可以继续其行动。在这种情况下使用202回复，例如，回复文本：“不需要存储分配。”如果另一方面，命令请求一个非站点特定的动作并且未实现，响应是502。一个细化的情况是504回复，用于实现了命令但请求了未实现的参数的情况。
4.2.1 Reply Codes by Function Groups 按功能组分类的回复代码
200 Command okay. 命令正常。
500 Syntax error, command unrecognized. 语法错误，命令无法识别。
This may include errors such as command line too long.
这可能包括命令行太长等错误。
501 Syntax error in parameters or arguments. 参数或参数中的语法错误。
202 Command not implemented, superfluous at this site. 命令未实现，此站点多余。
502 Command not implemented. 命令未实现。
503 Bad sequence of commands. 命令序列错误。
504 Command not implemented for that parameter. 该参数未实现命令。
110 Restart marker reply. 重启标记回复。
In this case, the text is exact and not left to the particular implementation; it must read:
在这种情况下，文本是准确的，不留给特定的实现；它必须读作：
MARK yyyy = mmmmWhere yyyy is User-process data stream marker, and mmmm server’s equivalent marker (note the spaces between markers and “=”).
其中yyyy是用户进程数据流标记，mmmm是服务器的等效标记（注意标记和"=“之间的空格）。
211 System status, or system help reply. 系统状态，或系统帮助回复。
212 Directory status. 目录状态。
213 File status. 文件状态。
214 Help message. 帮助消息。
On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user.
关于如何使用服务器或某个特定的非标准命令的含义。这个回复只对人类用户有用。
215 NAME system type. NAME系统类型。
Where NAME is an official system name from the list in the Assigned Numbers document.
其中NAME是从分配的数字文档中的官方系统名称列表中选取的。
120 Service ready in nnn minutes. 服务在nnn分钟内准备就绪。
220 Service ready for new user. 服务为新用户准备就绪。
221 Service closing control connection. 服务关闭控制连接。
Logged out if appropriate.
如适当，注销。
421 Service not available, closing control connection. 服务不可用，关闭控制连接。
This may be a reply to any command if the service knows it must shut down.
如果服务知道它必须关闭，则可能是对任何命令的回复。
125 Data connection already open; transfer starting. 数据连接已打开；传输开始。
225 Data connection open; no transfer in progress. 数据连接打开；没有进行中的传输。
425 Can’t open data connection. 无法打开数据连接。
226 Closing data connection. 关闭数据连接。
Requested file action successful (for example, file transfer or file abort).
请求的文件操作成功（例如，文件传输或文件中止）。
426 Connection closed; transfer aborted. 连接关闭；传输中止。
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). 进入被动模式（h1,h2,h3,h4,p1,p2）。
230 User logged in, proceed. 用户登录，继续。
530 Not logged in. 未登录。
331 User name okay, need password. 用户名正常，需要密码。
332 Need account for login. 登录需要账户。
532 Need account for storing files. 存储文件需要账户。
150 File status okay; about to open data connection. 文件状态正常；即将打开数据连接。
250 Requested file action okay, completed. 请求的文件操作正常，已完成。
257 “PATHNAME” created. “PATHNAME”已创建。
350 Requested file action pending further information. 请求的文件操作等待更多信息。
450 Requested file action not taken. 未采取请求的文件操作。
File unavailable (e.g., file busy).
文件不可用（例如，文件忙）。
550 Requested action not taken. 未采取请求的操作。
File unavailable (e.g., file not found, no access).
文件不可用（例如，文件未找到，无访问权限）。
451 Requested action aborted. Local error in processing. 请求的操作中止。处理过程中的本地错误。
551 Requested action aborted. Page type unknown. 请求的操作中止。未知的页面类型。
452 Requested action not taken. 未采取请求的操作。
Insufficient storage space in system.
系统中的存储空间不足。
552 Requested file action aborted. 请求的文件操作中止。
Exceeded storage allocation (for current directory or dataset).
超出存储分配（对当前目录或数据集）。
553 Requested action not taken. 未采取请求的操作。
File name not allowed.
文件名不允许。
4.2.2 Numeric Order List of Reply Codes 回复代码的数字顺序列表
110 Restart marker reply. 重启标记回复。
In this case, the text is exact and not left to the particular implementation; it must read:
在这种情况下，文本是准确的，不留给特定的实现；它必须读作：
MARK yyyy = mmmmWhere yyyy is User-process data stream marker, and mmmm server’s equivalent marker (note the spaces between markers and “=”).
其中yyyy是用户进程数据流标记，mmmm是服务器的等效标记（注意标记和”=“之间的空格）。
120 Service ready in nnn minutes. 服务在nnn分钟内准备就绪。
125 Data connection already open; transfer starting. 数据连接已打开；传输开始。
150 File status okay; about to open data connection. 文件状态正常；即将打开数据连接。
200 Command okay. 命令正常。
202 Command not implemented, superfluous at this site. 命令未实现，此站点多余。
211 System status, or system help reply. 系统状态，或系统帮助回复。
212 Directory status. 目录状态。
213 File status. 文件状态。
214 Help message. 帮助消息。
On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user.
关于如何使用服务器或某个特定的非标准命令的含义。这个回复只对人类用户有用。
215 NAME system type. NAME系统类型。
Where NAME is an official system name from the list in the Assigned Numbers document.
其中NAME是从分配的数字文档中的官方系统名称列表中选取的。
220 Service ready for new user. 服务为新用户准备就绪。
221 Service closing control connection. 服务关闭控制连接。
Logged out if appropriate.
如适当，注销。
225 Data connection open; no transfer in progress. 数据连接打开；没有进行中的传输。
226 Closing data connection. 关闭数据连接。
Requested file action successful (for example, file transfer or file abort).
请求的文件操作成功（例如，文件传输或文件中止）。
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). 进入被动模式（h1,h2,h3,h4,p1,p2）。
230 User logged in, proceed. 用户登录，继续。
250 Requested file action okay, completed. 请求的文件操作正常，已完成。
257 “PATHNAME” created. “PATHNAME”已创建。
331 User name okay, need password. 用户名正常，需要密码。
332 Need account for login. 登录需要账户。
350 Requested file action pending further information. 请求的文件操作等待更多信息。
421 Service not available, closing control connection. 服务不可用，关闭控制连接。
This may be a reply to any command if the service knows it must shut down.
如果服务知道它必须关闭，则可能是对任何命令的回复。
425 Can’t open data connection. 无法打开数据连接。
426 Connection closed; transfer aborted. 连接关闭；传输中止。
450 Requested file action not taken. 未采取请求的文件操作。
File unavailable (e.g., file busy).
文件不可用（例如，文件忙）。
451 Requested action aborted: local error in processing. 请求的操作中止：处理中的本地错误。
452 Requested action not taken. 未采取请求的操作。
Insufficient storage space in system.
系统中的存储空间不足。
500 Syntax error, command unrecognized. 语法错误，命令无法识别。
This may include errors such as command line too long.
这可能包括命令行太长等错误。
501 Syntax error in parameters or arguments. 参数或参数中的语法错误。
502 Command not implemented. 命令未实现。
503 Bad sequence of commands. 命令序列错误。
504 Command not implemented for that parameter. 该参数未实现命令。
530 Not logged in. 未登录。
532 Need account for storing files. 存储文件需要账户。
550 Requested action not taken. 未采取请求的操作。
File unavailable (e.g., file not found, no access).
文件不可用（例如，文件未找到，无访问权限）。
551 Requested action aborted: page type unknown. 请求的操作中止：页面类型未知。
552 Requested file action aborted. 请求的文件操作中止。
Exceeded storage allocation (for current directory or dataset).
超出存储分配（对当前目录或数据集）。
553 Requested action not taken. 未采取请求的操作。
File name not allowed.
文件名不允许。
5. Declarative Specifications 声明性规范
5.1 Minimum Implementation 最小实现
In order to make FTP workable without needless error messages, the following minimum implementation is required for all servers:
为了使FTP可行而不产生不必要的错误消息，所有服务器都需要以下最小实现：
TYPE - ASCII Non-print
类型 - ASCII非打印
MODE - Stream
模式 - 流
STRUCTURE - File, Record
结构 - 文件，记录
COMMANDS 命令 -
USER,QUIT,PORT,TYPE,MODE,STRU,for the default values
对于默认值
RETR,STOR,NOOP。
The default values for transfer parameters are:
传输参数的默认值为：
- TYPE - ASCII Non-print
- 类型 - ASCII非打印
- MODE - Stream
- 模式 - 流
- STRU - File
- 结构 - 文件
All hosts must accept the above as the standard defaults.
所有主机必须接受以上作为标准默认值。
5.2 Connections 连接
The server protocol interpreter shall “listen” on Port L. The user or user protocol interpreter shall initiate the full-duplex control connection. Server- and user- processes should follow the conventions of the Telnet protocol as specified in the ARPA-Internet Protocol Handbook [1]. Servers are under no obligation to provide for editing of command lines and may require that it be done in the user host. The control connection shall be closed by the server at the user’s request after all transfers and replies are completed.
服务器协议解释器应在端口L上“监听”。用户或用户协议解释器应初始化全双工控制连接。服务器和用户进程应遵循ARPA-Internet协议手册[1]中指定的Telnet协议的约定。服务器无义务提供命令行的编辑，并可能要求在用户主机中完成编辑。在所有传输和回复完成后，应应用户的请求由服务器关闭控制连接。
The user-DTP must “listen” on the specified data port; this may be the default user port (U) or a port specified in the PORT command. The server shall initiate the data connection from his own default data port (L-1) using the specified user data port. The direction of the transfer and the port used will be determined by the FTP service command.
用户-DTP必须在指定的数据端口上“监听”；这可能是默认的用户端口（U）或PORT命令中指定的端口。服务器应从自己的默认数据端口（L-1）使用指定的用户数据端口发起数据连接。传输的方向和使用的端口将由FTP服务命令决定。
Note that all FTP implementation must support data transfer using the default port, and that only the USER-PI may initiate the use of non-default ports.
请注意，所有FTP实现必须支持使用默认端口进行数据传输，且只有USER-PI可以启动使用非默认端口。
When data is to be transferred between two servers, A and B (refer to Figure 2), the user-PI, C, sets up control connections with both server-PI’s. One of the servers, say A, is then sent a PASV command telling him to “listen” on his data port rather than initiate a connection when he receives a transfer service command. When the user-PI receives an acknowledgment to the PASV command, which includes the identity of the host and port being listened on, the user-PI then sends A’s port, a, to B in a PORT command; a reply is returned. The user-PI may then send the corresponding service commands to A and B. Server B initiates the connection and the transfer proceeds. The command-reply sequence is listed below where the messages are vertically synchronous but horizontally asynchronous:
当数据需要在两个服务器A和B之间传输时（参见图2），用户-PI，C，与两个服务器-PI建立控制连接。然后向其中一个服务器，比如说A，发送PASV命令，告诉他在接收到传输服务命令时在他的数据端口上“监听”，而不是发起连接。当用户-PI收到PASV命令的确认时，其中包括被监听的主机和端口的身份，用户-PI随后将A的端口a发送给B的PORT命令；返回一个回复。然后用户-PI可以向A和B发送相应的服务命令。服务器B发起连接，传输开始进行。命令-回复序列在下面列出，其中消息在垂直方向上是同步的，但在水平方向上是异步的：
User-PI - Server A User-PI - Server B
------------------ ------------------
C->A : Connect C->B : Connect
C->A : PASV
A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
C->B : PORT A1,A2,A3,A4,a1,a2
B->C : 200 Okay
C->A : STOR C->B : RETR
B->A : Connect to HOST-A, PORT-a
Figure 3 图3
The data connection shall be closed by the server under the conditions described in the Section on Establishing Data Connections. If the data connection is to be closed following a data transfer where closing the connection is not required to indicate the end-of-file, the server must do so immediately. Waiting until after a new transfer command is not permitted because the user-process will have already tested the data connection to see if it needs to do a “listen”; (remember that the user must “listen” on a closed data port BEFORE sending the transfer request). To prevent a race condition here, the server sends a reply (226) after closing the data connection (or if the connection is left open, a “file transfer completed” reply (250) and the user-PI should wait for one of these replies before issuing a new transfer command).
服务器在建立数据连接部分中描述的条件下应关闭数据连接。如果数据连接在数据传输后要关闭，而关闭连接并非必须表示文件结束，则服务器必须立即这样做。因为用户进程已经测试了数据连接，看是否需要执行“监听”操作（记住，在发送传输请求之前，用户必须在一个关闭的数据端口上“监听”），所以等到新的传输命令之后不允许关闭数据连接。为了防止这里出现竞争条件，服务器在关闭数据连接后发送回复（226），或者如果连接保持打开，则发送“文件传输完成”回复（250），用户-PI应该在发出新的传输命令之前等待这些回复之一。
Any time either the user or server see that the connection is being closed by the other side, it should promptly read any remaining data queued on the connection and issue the close on its own side.
任何时候，当用户或服务器看到对方正在关闭连接时，它应该立即读取连接上排队的任何剩余数据，并在自己这边发出关闭指令。
5.3 Commands 命令
The commands are Telnet character strings transmitted over the control connections as described in the Section on FTP Commands. The command functions and semantics are described in the Section on Access Control Commands, Transfer Parameter Commands, FTP Service Commands, and Miscellaneous Commands. The command syntax is specified here.
命令是通过控制连接传输的Telnet字符字符串，如FTP命令部分所述。命令的功能和语义在访问控制命令、传输参数命令、FTP服务命令和杂项命令部分中有描述。命令语法在此处指定。
The commands begin with a command code followed by an argument field. The command codes are four or fewer alphabetic characters. Upper and lower case alphabetic characters are to be treated identically. Thus, any of the following may represent the retrieve command:
命令以命令代码开始，后跟一个参数字段。命令代码是四个或更少的字母字符。大写和小写字母字符应视为相同。因此，以下任何一个都可以代表检索命令：
RETR，Retr，retr，ReTr，rETr
This also applies to any symbols representing parameter values, such as A or a for ASCII TYPE. The command codes and the argument fields are separated by one or more spaces.
这也适用于表示参数值的任何符号，如ASCII类型的A或a。命令代码和参数字段之间由一个或多个空格分隔。
The argument field consists of a variable length character string ending with the character sequence (Carriage Return, Line Feed) for NVT-ASCII representation; for other negotiated languages a different end of line character might be used. It should be noted that the server is to take no action until the end of line code is received.
参数字段由一个变长字符字符串组成，以字符序列（回车换行）结束，表示NVT-ASCII；对于其他协商的语言，可能使用不同的行结束字符。应注意，服务器在接收到行结束代码之前不采取任何行动。
The syntax is specified below in NVT-ASCII. All characters in the argument field are ASCII characters including any ASCII represented decimal integers. Square brackets denote an optional argument field. If the option is not taken, the appropriate default is implied.
语法如下用NVT-ASCII指定。参数字段中的所有字符都是ASCII字符，包括任何ASCII表示的十进制整数。方括号表示可选的参数字段。如果未采用选项，则意味着适用适当的默认值。
5.3.1 FTP Commands FTP命令
The following are the FTP commands:
以下是FTP命令：
USER <SP> <username> <CRLF>PASS <SP> <password> <CRLF>ACCT <SP> <account-information> <CRLF>CWD <SP> <pathname> <CRLF>CDUP <CRLF>SMNT <SP> <pathname> <CRLF>QUIT <CRLF>REIN <CRLF>PORT <SP> <host-port> <CRLF>PASV <CRLF>TYPE <SP> <type-code> <CRLF>STRU <SP> <structure-code> <CRLF>MODE <SP> <mode-code> <CRLF>RETR <SP> <pathname> <CRLF>STOR <SP> <pathname> <CRLF>STOU <CRLF>APPE <SP> <pathname> <CRLF>ALLO <SP> <decimal-integer>[<SP> R <SP> <decimal-integer>] <CRLF>REST <SP> <marker> <CRLF>RNFR <SP> <pathname> <CRLF>RNTO <SP> <pathname> <CRLF>ABOR <CRLF>DELE <SP> <pathname> <CRLF>RMD <SP> <pathname> <CRLF>MKD <SP> <pathname> <CRLF>PWD <CRLF>LIST [<SP> <pathname>] <CRLF>NLST [<SP> <pathname>] <CRLF>SITE <SP> <string> <CRLF>SYST <CRLF>STAT [<SP> <pathname>] <CRLF>HELP [<SP> <string>] <CRLF>NOOP <CRLF>
5.3.2 FTP Commands Arguments FTP命令参数
The syntax of the above argument fields (using BNF notation where applicable) is:
上述参数字段的语法（适用时使用BNF表示法）是：
<username> ::= <string>
<password> ::= <string>
<account-information> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and
<LF>
<marker> ::= <pr-string>
<pr-string> ::= <pr-char> | <pr-char><pr-string>
<pr-char> ::= printable characters, any
ASCII code 33 through 126
<byte-size> ::= <number>
<host-port> ::= <host-number>,<port-number>
<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255
<form-code> ::= N | T | C
<type-code> ::= A [<sp> <form-code>]
| E [<sp> <form-code>]
| I
| L <sp> <byte-size>
<structure-code> ::= F | R | P
<mode-code> ::= S | B | C
<pathname> ::= <string>
<decimal-integer> ::= any decimal integer
5.4 Sequencing of Commands and Replies 命令和回复的顺序
The communication between the user and server is intended to be an alternating dialogue. As such, the user issues an FTP command and the server responds with a prompt primary reply. The user should wait for this initial primary success or failure response before sending further commands.
用户和服务器之间的通信旨在是一种交替对话。因此，用户发出FTP命令，服务器以提示性的初步回复响应。用户应在发送进一步的命令之前等待这一初始的成功或失败响应。
Certain commands require a second reply for which the user should also wait. These replies may, for example, report on the progress or completion of file transfer or the closing of the data connection. They are secondary replies to file transfer commands.
某些命令需要第二个回复，用户也应等待这个回复。这些回复可能会报告文件传输的进展或完成，或数据连接的关闭。它们是对文件传输命令的次级回复。
One important group of informational replies is the connection greetings. Under normal circumstances, a server will send a 220 reply, “awaiting input”, when the connection is completed. The user should wait for this greeting message before sending any commands. If the server is unable to accept input right away, a 120 “expected delay” reply should be sent immediately and a 220 reply when ready. The user will then know not to hang up if there is a delay.
一组重要的信息回复是连接问候。在正常情况下，服务器在连接完成时发送220回复，“等待输入”。用户应在发送任何命令之前等待此问候消息。如果服务器无法立即接受输入，则应立即发送120“预期延迟”回复，并在准备就绪时发送220回复。用户将知道如果有延迟不要挂断。
Spontaneous Replies 自发回复
Sometimes “the system” spontaneously has a message to be sent to a user (usually all users). For example, “System going down in 15 minutes”. There is no provision in FTP for such spontaneous information to be sent from the server to the user. It is recommended that such information be queued in the server-PI and delivered to the user-PI in the next reply (possibly making it a multi-line reply).
有时“系统”自发地有消息要发送给用户（通常是所有用户）。例如，“系统在15分钟内关闭”。FTP中没有规定服务器向用户发送此类自发信息的方法。建议将此类信息排队在服务器-PI中，并在下一个回复中（可能使其成为多行回复）传递给用户-PI。
The table below lists alternative success and failure replies for each command. These must be strictly adhered to; a server may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered.
下表列出了每个命令的成功和失败回复的替代选项。必须严格遵守这些；服务器可以替换回复中的文本，但是代码编号的含义和特定命令回复序列所暗示的行动不能更改。
Command-Reply Sequences 命令-回复序列
In this section, the command-reply sequence is presented. Each command is listed with its possible replies; command groups are listed together. Preliminary replies are listed first (with their succeeding replies indented and under them), then positive and negative completion, and finally intermediary replies with the remaining commands from the sequence following. This listing forms the basis for the state diagrams, which will be presented separately.
在本节中，将呈现命令-回复序列。每个命令都列出了其可能的回复；命令组聚在一起。初步回复首先列出（其成功的回复缩进并列在其下），然后是正面和负面完成，最后是中间回复，序列中的其余命令跟随。此列表构成了状态图的基础，状态图将单独呈现。
- Connection Establishment 连接建立
- 120
- 220
- 220
- 421
- 120
- Login 登录
- USER
- 230
- 530
- 500, 501, 421
- 331, 332
- PASS
- 230
- 202
- 530
- 500, 501, 503, 421
- 332
- ACCT
- 230
- 202
- 530
- 500, 501, 503, 421
- CWD
- 250
- 500, 501, 502, 421, 530, 550
- CDUP
- 200
- 500, 501, 502, 421, 530, 550
- SMNT
- 202, 250
- 500, 501, 502, 421, 530, 550
- USER
- Logout 注销
- REIN
- 120
- 220
- 220
- 421
- 500, 502
- 120
- QUIT
- 221
- 500
- REIN
- Transfer parameters 传输参数
- PORT
- 200
- 500, 501, 421, 530
- PASV
- 227
- 500, 501, 502, 421, 530
- MODE
- 200
- 500, 501, 504, 421, 530
- TYPE
- 200
- 500, 501, 504, 421, 530
- STRU
- 200
- 500, 501, 504, 421, 530
- PORT
- File action commands 文件操作命令
- ALLO
- 200
- 202
- 500, 501, 504, 421, 530
- REST
- 500, 501, 502, 421, 530
- 350
- STOR
- 125, 150
- (110)
- 226, 250
- 425, 426, 451, 551, 552
- 532, 450, 452, 553
- 500, 501, 421, 530
- 125, 150
- STOU
- 125, 150
- (110)
- 226, 250
- 425, 426, 451, 551, 552
- 532, 450, 452, 553
- 500, 501, 421, 530
- 125, 150
- RETR
- 125, 150
- (110)
- 226, 250
- 425, 426, 451
- 450, 550
- 500, 501, 421, 530
- 125, 150
- LIST
- 125, 150
- 226, 250
- 425, 426, 451
- 450
- 500, 501, 502, 421, 530
- 125, 150
- NLST
- 125, 150
- 226, 250
- 425, 426, 451
- 450
- 500, 501, 502, 421, 530
- 125, 150
- APPE
- 125, 150
- (110)
- 226, 250
- 425, 426, 451, 551, 552
- 532, 450, 550, 452, 553
- 500, 501, 502, 421, 530
- 125, 150
- RNFR
- 450, 550
- 500, 501, 502, 421, 530
- 350
- RNTO
- 250
- 532, 553
- 500, 501, 502, 503, 421, 530
- DELE
- 250
- 450, 550
- 500, 501, 502, 421, 530
- RMD
- 250
- 500, 501, 502, 421, 530, 550
- MKD
- 257
- 500, 501, 502, 421, 530, 550
- PWD
- 257
- 500, 501, 502, 421, 550
- ABOR
- 225, 226
- 500, 501, 502, 421
- ALLO
- Informational commands 信息命令
- SYST
- 215
- 500, 501, 502, 421
- STAT
- 211, 212, 213
- 450
- 500, 501, 502, 421, 530
- HELP
- 211, 214
- 500, 501, 502, 421
- SYST
- Miscellaneous commands 杂项命令
- SITE
- 200
- 202
- 500, 501, 530
- NOOP
- 200
- 500 421
- SITE
6. State Diagrams 状态图
Here we present state diagrams for a very simple minded FTP implementation. Only the first digit of the reply codes is used. There is one state diagram for each group of FTP commands or command sequences.
这里我们展示了一个非常简单的FTP实现的状态图。仅使用回复代码的第一位数字。对于每组FTP命令或命令序列，有一个状态图。
The command groupings were determined by constructing a model for each command then collecting together the commands with structurally identical models.
命令分组是通过为每个命令构建一个模型，然后将具有结构相同模型的命令收集在一起确定的。
For each command or command sequence there are three possible outcomes: success (S), failure (F), and error (E). In the state diagrams below we use the symbol B for “begin”, and the symbol W for “wait for reply”.
对于每个命令或命令序列，有三种可能的结果：成功（S）、失败（F）和错误（E）。在下面的状态图中，我们使用符号B表示“开始”，符号W表示“等待回复”。
We first present the diagram that represents the largest group of FTP commands:
我们首先展示代表最大一组FTP命令的图表：
This diagram models the commands:
该图模型包括以下命令：
ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE.
The other large group of commands is represented by a very similar diagram:
另一大组命令由非常相似的图表示：
This diagram models the commands:
该图模型包括以下命令：
APPE, LIST, NLST, REIN, RETR, STOR, and STOU.
Note that this second model could also be used to represent the first group of commands, the only difference being that in the first group the 100 series replies are unexpected and therefore treated as error, while the second group expects (some may require) 100 series replies. Remember that at most, one 100 series reply is allowed per command.
请注意，这第二个模型也可以用来表示第一组命令，唯一的区别是在第一组中100系列回复是意外的，因此被视为错误，而第二组期望（一些可能要求）100系列回复。记住，每个命令最多允许一个100系列回复。
The remaining diagrams model command sequences, perhaps the simplest of these is the rename sequence:
剩余的图模型命令序列，也许最简单的是重命名序列：
+---+ RNFR +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 1,3 | | +---+
| 2| --------
| | | |
V | | |
+---+ RNTO +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ +---+ +---+
The next diagram is a simple model of the Restart command:
下一个图是重启命令的简单模型：
+---+ REST +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 3 | | +---+
| 2| --------
| | | |
V | | |
+---+ cmd +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ -->+---+ +---+
| |
| 1 |
------
Where “cmd” is APPE, STOR, or RETR.
其中“cmd”是APPE、STOR或RETR。
We note that the above three models are similar. The Restart differs from the Rename two only in the treatment of 100 series replies at the second stage, while the second group expects (some may require) 100 series replies. Remember that at most, one 100 series reply is allowed per command.
我们注意到上述三个模型是相似的。重启与重命名的区别仅在于第二阶段对100系列回复的处理，而第二组期望（一些可能要求）100系列回复。记住，每个命令最多允许一个100系列回复。
The most complicated diagram is for the Login sequence:
最复杂的图是登录序列：
1
+---+ USER +---+------------->+---+
| B |---------->| W | 2 ---->| E |
+---+ +---+------ | -->+---+
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| | | | |
| --------- |
| 1| | | |
V | | | |
+---+ PASS +---+ 2 | ------>+---+
| |---------->| W |------------->| S |
+---+ +---+ ---------->+---+
| | | | |
3 | |4,5| | |
-------------- -------- |
| | | | |
| | | | |
| -----------
| 1,3| | | |
V | 2| | |
+---+ ACCT +---+-- | ----->+---+
| |---------->| W | 4,5 -------->| F |
+---+ +---+------------->+---+
Finally, we present a generalized diagram that could be used to model the command and reply interchange:
最后，我们提出了一个可以用来模拟命令和回复交换的通用图：
------------------------------------
| |
Begin | |
| V |
| +---+ cmd +---+ 2 +---+ |
-->| |------->| |---------->| | |
| | | W | | S |-----|
-->| | -->| |----- | | |
| +---+ | +---+ 4,5 | +---+ |
| | | | | | |
| | | 1| |3 | +---+ |
| | | | | | | | |
| | ---- | ---->| F |-----
| | | | |
| | | +---+
-------------------
|
|
V
End
7. Typical FTP Scenario 典型FTP场景
User at host U wanting to transfer files to/from host S:
主机U的用户希望与主机S传输文件：
In general, the user will communicate to the server via a mediating user-FTP process. The following may be a typical scenario. The user-FTP prompts are shown in parentheses, ‘—->’ represents commands from host U to host S, and ‘<—-’ represents replies from host S to host U.
通常，用户将通过一个中介的用户-FTP进程与服务器通信。以下可能是一个典型的场景。用户-FTP提示显示在括号中，’—->‘代表从主机U到主机S的命令，’<—-‘代表从主机S到主机U的回复。
| User | ACTION INVOLVED |
|---|---|
ftp (host) multics<CR> | Connect to host S, port L, establishing control connections. |
| <—- 220 Service ready . | |
username Doe <CR> | USER Doe<CRLF> —-> |
| <—- 331 User name ok, need password. | |
password mumble <CR> | PASS mumble<CRLF> —-> |
| <—- 230 User logged in. | |
retrieve (local type) ASCII<CR> | |
(local pathname) test 1 <CR> | User-FTP opens local file in ASCII. |
(for. pathname) test.pl1<CR> | RETR test.pl1<CRLF> —-> |
| <—- 150 File status okay; about to open data connection. | |
| Server makes data connection to port U. | |
| <—- 226 Closing data connection, file transfer successful. | |
type Image<CR> | TYPE I<CRLF> —-> |
| <—- 200 Command OK | |
store (local type) image<CR> | |
(local pathname) file dump<CR> | User-FTP opens local file in Image. |
(for.pathname) >udd>cn>fd<CR> | STOR >udd>cn>fd<CRLF> —-> |
| <—- 550 Access denied | |
terminate | QUIT <CRLF> —-> |
| Server closes all connections. |
8. Connection Establishment 连接建立
The FTP control connection is established via TCP between the user process port U and the server process port L. This protocol is assigned the service port 21 (25 octal), that is L=21.
FTP控制连接通过TCP在用户进程端口U和服务器进程端口L之间建立。该协议被分配服务端口21（25八进制），即L=21。
Appendix I - Page Structure 页面结构
The need for FTP to support page structure derives principally from the need to support efficient transmission of files between TOPS-20 systems, particularly the files used by NLS.
FTP需要支持页面结构主要是因为需要支持在TOPS-20系统之间高效传输文件，特别是NLS使用的文件。
The file system of TOPS-20 is based on the concept of pages. The operating system is most efficient at manipulating files as pages. The operating system provides an interface to the file system so that many applications view files as sequential streams of characters. However, a few applications use the underlying page structures directly, and some of these create holey files.
TOPS-20的文件系统基于页面的概念。操作系统在以页面为单位操作文件时最为高效。操作系统提供了一个文件系统接口，使得许多应用程序将文件视为字符的顺序流。然而，少数应用程序直接使用底层页面结构，其中一些创建了空洞文件。
A TOPS-20 disk file consists of four things: a pathname, a page table, a (possibly empty) set of pages, and a set of attributes.
TOPS-20磁盘文件由四部分组成：路径名、页面表、一组（可能为空）页面和一组属性。
The pathname is specified in the RETR or STOR command. It includes the directory name, file name, file name extension, and generation number.
路径名 在RETR或STOR命令中指定。它包括目录名、文件名、文件扩展名和生成号。
The page table contains up to 2^18 entries. Each entry may be EMPTY, or may point to a page. If it is not empty, there are also some page-specific access bits; not all pages of a file need have the same access protection.
页面表包含多达2^18个条目。每个条目可能为空，或可能指向一个页面。如果它不为空，还有一些页面特定的访问位；文件的不是所有页面都需要具有相同的访问保护。
A page is a contiguous set of 512 words of 36 bits each.
一个页面是一组连续的512个36位的字。
The attributes of the file, in the File Descriptor Block (FDB), contain such things as creation time, write time, read time, writer’s byte-size, end-of-file pointer, count of reads and writes, backup system tape numbers, etc.
文件的属性，在文件描述符块（FDB）中，包含创建时间、写入时间、读取时间、写入者字节大小、文件结束指针、读写次数、备份系统磁带号等。
Note that there is NO requirement that entries in the page table be contiguous. There may be empty page table slots between occupied ones. Also, the end of file pointer is simply a number. There is no requirement that it in fact point at the “last” datum in the file. Ordinary sequential I/O calls in TOPS-20 will cause the end of file pointer to be left after the last datum written, but other operations may cause it not to be so, if a particular programming system so requires.
请注意，页面表中的条目不要求是连续的。占用的页面之间可能有空的页面表插槽。此外，文件结束指针仅仅是一个数字。它实际上指向文件中的“最后”数据并无要求。TOPS-20中的普通顺序I/O调用将导致文件结束指针位于最后写入的数据之后，但如果特定的编程系统有此要求，其他操作可能导致不是这样。
In fact, in both of these special cases, “holey” files and end-of-file pointers NOT at the end of the file, occur with NLS data files. The TOPS-20 paged files can be sent with the FTP transfer parameters: TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
事实上，在这两种特殊情况下，NLS数据文件中会出现“空洞”文件和文件结束指针不在文件末尾的情况。TOPS-20分页文件可以使用FTP传输参数发送：TYPE L 36、STRU P和MODE S（实际上，任何模式都可以使用）。
Each page of information has a header. Each header field, which is a logical byte, is a TOPS-20 word, since the TYPE is L 36.
每页信息都有一个头部。每个头部字段，即逻辑字节，都是TOPS-20字，因为类型是L 36。
The header fields are:
头部字段包括：
Word 0 字0: Header Length. 头部长度。
The header length is 5.
头部长度为5。
Word 1 字1: Page Index. 页面索引。
If the data is a disk file page, this is the number of that page in the file’s page map. Empty pages (holes) in the file are simply not sent. Note that a hole is NOT the same as a page of zeros.
如果数据是磁盘文件页面，这是该页面在文件页面映射中的编号。文件中的空页面（空洞）根本不发送。请注意，一个空洞不同于零页面。
Word 2 字2: Data Length. 数据长度。
The number of data words in this page, following the header. Thus, the total length of the transmission unit is the Header Length plus the Data Length.
这一页中数据字的数量，跟在头部之后。因此，传输单元的总长度是头部长度加上数据长度。
Word 3 字3: Page Type. 页面类型。
A code for what type of chunk this is. A data page is type 3, the FDB page is type 2.
这是指这是什么类型的块的代码。数据页面是类型3，FDB页面是类型2。
Word 4 字4: Page Access Control. 页面访问控制。
The access bits associated with the page in the file’s page map. (This full word quantity is put into AC2 of an SPACS by the program reading from net to disk.)
文件页面映射中与页面关联的访问位。（这个完整字数量被放入通过程序从网到磁盘读取的SPACS的AC2中。）
After the header are Data Length data words. Data Length is currently either 512 for a data page or 31 for an FDB. Trailing zeros in a disk file page may be discarded, making Data Length less than 512 in that case.
在头部之后是数据长度的数据字。数据长度当前要么是512（对于数据页面），要么是31（对于FDB）。磁盘文件页面中的尾随零可能被丢弃，使得数据长度小于512。
Appendix II - Directory Commands 目录命令
Since UNIX has a tree-like directory structure in which directories are as easy to manipulate as ordinary files, it is useful to expand the FTP servers on these machines to include commands which deal with the creation of directories. Since there are other hosts on the ARPA-Internet which have tree-like directories (including TOPS-20 and Multics), these commands are as general as possible.
由于UNIX具有树状的目录结构，在这种结构中，操作目录和操作普通文件一样容易，因此对于这些机器上的FTP服务器来说，扩展包含处理创建目录的命令变得非常有用。由于ARPA-Internet上还有其他具有树状目录的主机（包括TOPS-20和Multics），这些命令尽可能通用。
Four directory commands have been added to FTP FTP中新增了四个目录命令
- MKD pathname: Make a directory with the name “pathname”. 使用“pathname”创建一个目录。
- RMD pathname: Remove the directory with the name “pathname”. 删除名为“pathname”的目录。
- PWD: Print the current working directory name. 打印当前工作目录的名称。
- CDUP: Change to the parent of the current working directory. 更改到当前工作目录的父目录。
The “pathname” argument should be created (removed) as a subdirectory of the current working directory, unless the “pathname” string contains sufficient information to specify otherwise to the server, e.g., “pathname” is an absolute pathname (in UNIX and Multics), or pathname is something like “<abso.lute.path>” to TOPS-20.
“路径名”参数应在当前工作目录下创建（删除）为子目录，除非“路径名”字符串包含足够的信息以指定给服务器不同的位置，例如，“路径名”是绝对路径名（在UNIX和Multics中），或者路径名类似于TOPS-20中的”<abso.lute.path>"。
Reply Codes 回复代码
The CDUP command is a special case of CWD, and is included to simplify the implementation of programs for transferring directory trees between operating systems having different syntaxes for naming the parent directory. The reply codes for CDUP be identical to the reply codes of CWD.
CDUP命令是CWD的特殊情况，包含在内是为了简化在具有不同命名父目录语法的操作系统之间传输目录树的程序的实现。CDUP的回复代码应与CWD的回复代码相同。
The reply codes for RMD be identical to the reply codes for its file analogue, DELE.
RMD的回复代码应与其文件类似物DELE的回复代码相同。
The reply codes for MKD, however, are a bit more complicated. A freshly created directory will probably be the object of a future CWD command. Unfortunately, the argument to MKD may not always be a suitable argument for CWD. This is the case, for example, when a TOPS-20 subdirectory is created by giving just the subdirectory name. That is, with a TOPS-20 server FTP, the command sequence
然而，MKD的回复代码稍微复杂一些。新创建的目录可能会是未来CWD命令的对象。不幸的是，MKD的参数可能并不总是适合CWD的参数。例如，通过仅给出子目录名来创建TOPS-20子目录时，就会出现这种情况。也就是说，对于TOPS-20服务器FTP，命令序列
MKD MYDIR
CWD MYDIR
will fail. The new directory may only be referred to by its “absolute” name; e.g., if the MKD command above were issued while connected to the directory , the new subdirectory could only be referred to by the name <DFRANKLIN.MYDIR>.
将会失败。新目录只能通过其“绝对”名称引用；例如，如果上述MKD命令是在连接到目录时发出的，那么新子目录只能通过名称<DFRANKLIN.MYDIR>引用。
To solve these problems, upon successful completion of an MKD command, the server should return a line of the form:
为了解决这些问题，在成功完成MKD命令后，服务器应返回以下形式的行：
257 "<directory-name>" <commentary>
That is, the server will tell the user what string to use when referring to the created directory. The directory name can contain any character; embedded double-quotes should be escaped by double-quotes (the “quote-doubling” convention).
也就是说，服务器将告诉用户在引用创建的目录时使用哪个字符串。目录名可以包含任何字符；嵌入的双引号应该通过双引号转义（“引号加倍”约定）。
For example, a user connects to the directory /usr/dm, and creates a subdirectory, named pathname:
例如，用户连接到目录/usr/dm，并创建一个名为pathname的子目录：
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
257 "/usr/dm/pathname" directory created
An example with an embedded double quote:
带有嵌入双引号的示例：
MKD foo"bar
257 "/usr/dm/foo""bar" directory created
CWD /usr/dm/foo"bar
200 directory changed to /usr/dm/foo"bar
The prior existence of a subdirectory with the same name is an error, and the server must return an “access denied” error reply in that case.
已经存在同名的子目录是一个错误，服务器必须在这种情况下返回一个“访问被拒绝”的错误回复。
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
521-"/usr/dm/pathname" directory already exists;
521 taking no action.
The failure replies for MKD are analogous to its file creating cousin, STOR. Also, an “access denied” return is given if a file name with the same name as the subdirectory will conflict with the creation of the subdirectory (this is a problem on UNIX, but shouldn’t be one on TOPS-20).
MKD的失败回复与其创建文件的类似物STOR相似。如果与子目录同名的文件名将与子目录的创建冲突，也会返回“访问被拒绝”，这在UNIX上是一个问题，但在TOPS-20上不应该是问题。
Essentially because the PWD command returns the same type of information as the successful MKD command, the successful PWD command uses the 257 reply code as well.
由于PWD命令返回与成功的MKD命令相同类型的信息，因此成功的PWD命令也使用257回复代码。
Subtleties 细节
Because these commands will be most useful in transferring subtrees from one machine to another, carefully observe that the argument to MKD is to be interpreted as a sub-directory of the current working directory, unless it contains enough information for the destination host to tell otherwise. A hypothetical example of its use in the TOPS-20 world:
因为这些命令在从一台机器转移到另一台机器时最有用，因此请仔细观察，MKD的参数应该被解释为当前工作目录的子目录，除非它包含足够的信息让目标主机能够判断。TOPS-20世界中其使用的假设示例：
CWD <some.where>
200 Working directory changed
MKD overrainbow
257 "<some.where.overrainbow>" directory created
CWD overrainbow
431 No such directory
CWD <some.where.overrainbow>
200 Working directory changed
CWD <some.where>
200 Working directory changed to <some.where>
MKD <unambiguous>
257 "<unambiguous>" directory created
CWD <unambiguous>
Note that the first example results in a subdirectory of the connected directory. In contrast, the argument in the second example contains enough information for TOPS-20 to tell that the directory is a top-level directory. Note also that in the first example the user “violated” the protocol by attempting to access the freshly created directory with a name other than the one returned by TOPS-20. Problems could have resulted in this case had there been an directory; this is an ambiguity inherent in some TOPS-20 implementations. Similar considerations apply to the RMD command. The point is this: except where to do so would violate a host’s conventions for denoting relative versus absolute pathnames, the host should treat the operands of the MKD and RMD commands as subdirectories. The 257 reply to the MKD command must always contain the absolute pathname of the created directory.
请注意，第一个示例的结果是连接目录的子目录。相比之下，第二个示例中的参数包含足够的信息，以便TOPS-20知道目录是顶级目录。另请注意，在第一个示例中，用户违反了协议，试图使用TOPS-20返回的名称之外的名称访问新创建的目录。如果存在目录，这种情况可能会导致问题；这是某些TOPS-20实现中固有的模糊性。类似的考虑也适用于RMD命令。重点是：除非这样做会违反主机表示相对路径名与绝对路径名的约定，否则主机应将MKD和RMD命令的操作数视为子目录。MKD命令的257回复必须始终包含创建的目录的绝对路径名。
Appendix III - RFCs on FTP 关于FTP的RFC文档
Bhushan, Abhay, “A File Transfer Protocol”, RFC 114 (NIC 5823), MIT-Project MAC, 16 April 1971.
Harslem, Eric, and John Heafner, “Comments on RFC 114 (A File Transfer Protocol)”, RFC 141 (NIC 6726), RAND, 29 April 1971.
Bhushan, Abhay, et al, “The File Transfer Protocol”, RFC 172 (NIC 6794), MIT-Project MAC, 23 June 1971.
Braden, Bob, “Comments on DTP and FTP Proposals”, RFC 238 (NIC 7663), UCLA/CCN, 29 September 1971.
Bhushan, Abhay, et al, “The File Transfer Protocol”, RFC 265 (NIC 7813), MIT-Project MAC, 17 November 1971.
McKenzie, Alex, “A Suggested Addition to File Transfer Protocol”, RFC 281 (NIC 8163), BBN, 8 December 1971.
Bhushan, Abhay, “The Use of “Set Data Type” Transaction in File Transfer Protocol”, RFC 294 (NIC 8304), MIT-Project MAC, 25 January 1972.
Bhushan, Abhay, “The File Transfer Protocol”, RFC 354 (NIC 10596), MIT-Project MAC, 8 July 1972.
Bhushan, Abhay, “Comments on the File Transfer Protocol (RFC 354)”, RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
Hicks, Greg, “User FTP Documentation”, RFC 412 (NIC 12404), Utah, 27 November 1972.
Bhushan, Abhay, “File Transfer Protocol (FTP) Status and Further Comments”, RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.
Braden, Bob, “Comments on File Transfer Protocol”, RFC 430 (NIC 13299), UCLA/CCN, 7 February 1973.
Thomas, Bob, and Bob Clements, “FTP Server-Server Interaction”, RFC 438 (NIC 13770), BBN, 15 January 1973.
Braden, Bob, “Print Files in FTP”, RFC 448 (NIC 13299), UCLA/CCN, 27 February 1973.
McKenzie, Alex, “File Transfer Protocol”, RFC 454 (NIC 14333), BBN, 16 February 1973.
Bressler, Bob, and Bob Thomas, “Mail Retrieval via FTP”, RFC 458 (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.
Neigus, Nancy, “File Transfer Protocol”, RFC 542 (NIC 17759), BBN, 12 July 1973.
Krilanovich, Mark, and George Gregg, “Comments on the File Transfer Protocol”, RFC 607 (NIC 21255), UCSB, 7 January 1974.
Pogran, Ken, and Nancy Neigus, “Response to RFC 607 - Comments on the File Transfer Protocol”, RFC 614 (NIC 21530), BBN, 28 January 1974.
Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White, “Comments on the File Transfer Protocol”, RFC 624 (NIC 22054), UCSB, Ames Research Center, SRI-ARC, 28 February 1974.
Bhushan, Abhay, “FTP Comments and Response to RFC 430”, RFC 463 (NIC 14573), MIT-DMCG, 21 February 1973.
Braden, Bob, “FTP Data Compression”, RFC 468 (NIC 14742), UCLA/CCN, 8 March 1973.
Bhushan, Abhay, “FTP and Network Mail System”, RFC 475 (NIC 14919), MIT-DMCG, 6 March 1973.
Bressler, Bob, and Bob Thomas “FTP Server-Server Interaction - II”, RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.
White, Jim, “Use of FTP by the NIC Journal”, RFC 479 (NIC 14948), SRI-ARC, 8 March 1973.
White, Jim, “Host-Dependent FTP Parameters”, RFC 480 (NIC 14949), SRI-ARC, 8 March 1973.
Padlipsky, Mike, “An FTP Command-Naming Problem”, RFC 506 (NIC 16157), MIT-Multics, 26 June 1973.
Day, John, “Memo to FTP Group (Proposal for File Access Protocol)”, RFC 520 (NIC 16819), Illinois, 25 June 1973.
Merryman, Robert, “The UCSD-CC Server-FTP Facility”, RFC 532 (NIC 17451), UCSD-CC, 22 June 1973.
Braden, Bob, “TENEX FTP Problem”, RFC 571 (NIC 18974), UCLA/CCN, 15 November 1973.
McKenzie, Alex, and Jon Postel, “Telnet and FTP Implementation - Schedule Change”, RFC 593 (NIC 20615), BBN and MITRE, 29 November 1973.
Sussman, Julie, “FTP Error Code Usage for More Reliable Mail Service”, RFC 630 (NIC 30237), BBN, 10 April 1974.
Postel, Jon, “Revised FTP Reply Codes”, RFC 640 (NIC 30843), UCLA/NMC, 5 June 1974.
Harvey, Brian, “Leaving Well Enough Alone”, RFC 686 (NIC 32481), SU-AI, 10 May 1975.
Harvey, Brian, “One More Try on the FTP”, RFC 691 (NIC 32700), SU-AI, 28 May 1975.
Lieb, J., “CWD Command of FTP”, RFC 697 (NIC 32963), 14 July 1975.
Harrenstien, Ken, “FTP Extension: XSEN”, RFC 737 (NIC 42217), SRI-KL, 31 October 1977.
Harrenstien, Ken, “FTP Extension: XRSQ/XRCP”, RFC 743 (NIC 42758), SRI-KL, 30 December 1977.
Lebling, P. David, “Survey of FTP Mail and MLFL”, RFC 751, MIT, 10 December 1978.
Postel, Jon, “File Transfer Protocol Specification”, RFC 765, ISI, June 1980.
Mankins, David, Dan Franklin, and Buzz Owen, “Directory Oriented FTP Commands”, RFC 776, BBN, December 1980.
Padlipsky, Michael, “FTP Unique-Named Store Command”, RFC 949, MITRE, July 1985.
References 参考文献
- Feinler, Elizabeth, “Internet Protocol Transition Workbook”, Network Information Center, SRI International, March 1982.
- Postel, Jon, “Transmission Control Protocol - DARPA Internet Program Protocol Specification”, RFC 793, DARPA, September 1981.
- Postel, Jon, and Joyce Reynolds, “Telnet Protocol Specification”, RFC 854, ISI, May 1983.
- Reynolds, Joyce, and Jon Postel, “Assigned Numbers”, RFC 943, ISI, April 1985.