文件传输协议 (FTP)
备忘录状态
本备忘录描述了文件传输协议（FTP）的官方规范。对本备忘录的发布没有限制。
本规范新包括了如下可选命令：
CDUP (返回父目录), SMNT (结构装备), STOU(唯一保存),
RMD (删除目录), MKD (新建目录), PWD(打印目录), and SYST (系统)。
本规范与前一个版本兼容
目录
1. 介绍
2. 概述
2.1. 历史
2.2. 术语
2.3. FTP模型
3. 数据传输功能
3.1. 数据表示和存储
3.1.1. 数据类型
3.1.1.1. ASCII类型
3.1.1.2. EBCDIC类型
3.1.1.3. 图像类型
3.1.1.4. 本地类型
3.1.1.5. 格式控制
3.1.1.5.1. 非打印（NON PRINT）
3.1.1.5.2. TELNET格式控制
3.1.1.5.2. CARRIAGE CONTROL(ASA)
3.1.2. 数据结构
3.1.2.1. 文件结构
3.1.2.2. 记录结构
3.1.2.3. 页结构
3.2. 建立数据连接
3.3. 数据连接管理
3.4. 传输模式
3.4.1. 流模式
3.4.2. 块模式
3.4.3. 压缩模式
3.5. 错误恢复和重新开始
4. 文件传送功能
4.1. FTP命令
4.1.1. 访问控制命令
4.1.2. 传输参数命令
4.1.3. FTP服务命令
4.2. FTP响应
4.2.1. 按功能分组的响应代码
4.2.2. 按数字顺序排列的响应代码
1. 介绍
FTP的目标是：1）促进程序/数据文件的共享；2）鼓励（通过程序）使用远程计算机；3）使用户不必面对不同主机上不同文件系统的差异；4）对数据进行高效可靠的传输。FTP尽管可以直接在终端上应用，但它主要被设计通过程序来使用。
本规范通过设计简单易实现的协议来试图满足大型机、小型机、个人工作站、TAC等用户的需要。
本文需要文件传输协议（TCP）[2]以及Telnet协议[3]的知识。关于它们的文档可以在ARPA-互联网协议手册[1]中找到。
2. 概述
本章讨论内容包括历史、术语、FTP模型。本章所描述的都是关于FTP的重要内容。一些术语专用于FTP模型；一些读者可能有必要在回顾这些术语时参考关于FTP模型的章节。
2.1. 历史
FTP的发展经历了很多年。附录III是按年代编辑的关于FTP的RFC文档。其中包括最早在1971年提出用在M.I.T.主机上的文件传输机制（RFC 114），以及在RFC 141中的注释和讨论。
RFC 172提供了一个在主机（包括终端IMP）间基于用户层协议的文件传输方法。RFC 265做为其修订，通过附加评论重定义了FTP，RFC 281建议进一步改进。“Set Data Type”在传输中应用在1982年1月的RFC 294中提出。
RFC 354废弃了RFC 264和265。文件传输协议被定义为ARPANET上主机间的文件传输协议，FTP的主要作用则被定义为用来在主机间高效可靠地传输文件以及对远程存储的方便使用。RFC 385进一步讨论了协议的错误，重点和一些附加内容，RFC 414提供了使用中的FTP状态报告。1973年的RFC 430（被其它RFC多次引用），提供了对FTP的进一步讨论。最后，一个“官方的”FTP文件在RFC 454中发布。
至1973年1月，FTP协议又有了大量的变化，但总体的结构仍保持一致。为了应对这些变化，RFC 542中发布了新的“官方”规范。但很多基于老规范的应用并没有被更新。
1974年，RFC 607和614继续讨论FTP。RFC 624提出进一步改变设计和一些小的修补。1975年，RFC 686用题为“Leaving Well Enough Alone”讨论早期以及近期FTP版本的差别。RFC 691对RFC 686中关于打印文件部分做了小的修订。
在之前所有努力的基础上，通过将底层的传输协议由NCP改为TCP，应用TCP的FTP协议在RFC 765中诞生了。
本文描述的FTP规范目的在于纠正之前文档中的某些小错误，进一步解释一些协议特性，以及引入一些可选的命令。
特别地，本版本规范新包含了以下可选命令：
CDUP - 返回父目录
SMNT - 结构装备
STOU - 唯一保存
RMD - 删除目录
MKD - 新建目录
SYST - 系统
本规范兼容之前版本。应用在前一版本的程序应该可以自动应用于本规范。
2.2. 术语
ASCII
ASCII字符集定义于ARPA-互联网协议手册。FTP中ASCII字符指8位编码集的低半部（也就是最高位为0）。
访问控制（access controls）
访问控制定义了用户使用系统、系统文件的访问权力。访问控制必要性在于防止未被授权的或意外的对文件的访问。在服务器端使用访问控制正是FTP的优势所在。
字节长度（byte size）
有两种字节长度与FTP有关：文件的逻辑字节长度和用来传输数据的字节长度。传输字节长度总是8位。传输字节长度不必要和系统存储数据的字节长度或用来描述数据结构的逻辑字节长度相同。
控制连接（control connection）
用户PI与服务器PI用来交换命令和响应的信息路径。这个连接遵守Telnet协议。
数据连接（data connection）
用规定的模式和类型进行数据传输的全双向连接。传输的数据可能是文件的一部分、整个文件或一些文件。传输路径可能是服务器DTP与用户DTP之间或两个服务器DTP之间。
数据端口（data port）
数据接收者在数据端口监听，等待数据传输者从此端口建立数据连接。
DTP（data transfer process）
数据传输过程，用以建立并管理数据连接。DTP可以是被动或主动。
行结束符（End-of-Line）
行结束符序列定义了印刷行间的分隔。行结束符序列为回车符加换行符。
文件结束符（End-of-File）
文件结束符标志定义了传输中一个文件的结束。
记录结束符（End-of-Record）
记录结束符标志定义了传输中一个记录的结束。
错误恢复（error recovery）
允许用户从一些诸如主机系统或传输过程失败中恢复。FTP中，错误恢复可以是在给定点上重新开始文件传输。
FTP命令（FTP commands）
用户FTP到服务器FTP的控制信息流由一些命令集合组成。
文件（file）
计算机数据的有序集合（包括程序），有任意的大小，由路径名唯一指定。
模式（mode）
通过数据连接传输数据的方式。模式定义了包括EOR和EOF的数据传输格式。FTP的传输模式在传输模式一章中介绍。
NVT（Network Virtual Terminal）
网络虚拟终端在Telnet协议中定义。
NVFS（Network Virtual File System）
网络虚拟文件系统用标准命令和路径规定定义了标准网络文件系统概念。
页（page）
一个文件可能被分为彼此独立部分的结构集合，称为页。FTP支持将不连续的文件作为独立的页来传输。
路径名（pathname）
路径名定义为用户为了指定文件系统中某个特定文件而输入的字符串。路径一般包括驱动器名，目录名，以及文件名。FTP尚未规定标准的路径名规则。用户必须传输方文件系统的命名规则。
PI（protocol interpreter）
协议解析器。用户和服务器用其来解析协议，它们的具体实现分别称为用户PI和服务器PI。
记录（record）
顺序文件可能被由很多连续的部分组成称为记录。FTP支持记录结构，但文件不是必须具备记录结构。
响应（reply）
响应是由服务器发给用户的对FTP命令的回应（肯定或否定）。一般的响应格式是完成码（包括错误码）跟上一个文本字符串。完成码用于程序，文本用于用户。
服务器DTP（server-DTP）
数据传输过程，在通常的“主动”状态下是用“监听”的数据端口建立数据连接。它建立传输和存储参数，并在服务器端PI的命令下传输数据。服务器端DTP也可以用于“被动”模式，而不是主动在数据端口建立连接。
服务器FTP过程（server-FTP process）
与用户FTP过程或另一个服务器FTP过程配合实现文件传输功能。由协议解析器（PI）和数据传输过程（DTP）组成。
服务器PI（server-PI）
服务器PI在L端口“监听”用户协议解析器的连接请求并建立控制连接。它从用户PI接收标准的FTP命令，发送响应，并管理服务器DTP
类型（type）
用于数据传输和存储的数据表示类型。类型暗示了在数据存储和数据传输之间的时间变化。FTP中定义的表示类型在建立数据连接一章中描述。
用户（user）
希望得到文件传输服务的人或程序。用户可能直接与服务器FTP过程互相作用，但推荐使用用户FTP过程，协议的设计有利于自动化操作。
用户DTP（user-DTP）
数据传输过程在数据端口“监听”服务器FTP过程的连接。如果两个服务器通过它来传输数据，用户DTP就为非活跃的。
用户FTP过程（user-FTP process）
一系列功能集合，包括协议解析器、数据传输过程和用户界面，它们共同与服务器FTP过程配合完成文件传输功能。用户界面允许使用本地语言对用户发送命令响应。
用户PI（user-PI）
用户协议解析器用U端口建立到服务器FTP过程的控制连接，并在文件传输时管理用户DTP。
2.3. FTP模型
了解了上面的定义，下面的模型（图一所示）用来描述一个FTP服务。
-------------
|/---------\|
|| 用户 || --------
|| 界面 |<--->| 用户 |
|\----^----/| --------
---------- | | |
|/------\| FTP 命令 |/----V----\|
||服务器|<---------------->| 用户 ||
|| PI || FTP 响应 || PI ||
|\--^---/| |\----^----/|
| | | | | |
-------- |/--V---\| 数据 |/----V----\| --------
| 文件 |<--->|服务器|<---------------->| 用户 |<--->| 文件 |
| 系统 | || DTP || 连接 || DTP || | 系统 |
-------- |\------/| |\---------/| --------
---------- -------------
服务器-FTP 用户-FTP
注意：1. 数据连接可能是任一方向。
2. 数据连接不必须一直存在。
图 1 FTP使用模型
图1中描述的模型中，控制连接由用户PI发起。控制连接遵守Telnet协议。首先用户由用户PI产生标准FTP命令通过控制连接传输到服务器过程。（用户可能建立一个到服务器FTP的直接连接，例如从TAC终端不经过用户FTP过程直接产生标准的FTP命令。）标准响应由服务器端PI通过数据连接发送到用户PI作为命令的回应。
FTP命令指定数据连接参数（端口，传输模式，表示类型，以及结构）和文件系统操作种类（store，retrieve，append，delete等）。用户DTP则应在指定的数据端口“监听”，服务器用相应的参数发起数据连接并传送数据。而数据端口主机不一定必须与发送FTP命令的主机一至，但用户或用户FTP过程要保证指定的端口处在“监听”下。
另需指出的是数据连接可能同时用于发送和接收数据。
另一种情形是用户可能要在两台远程主机间传送文件。用户分别与两台服务器建立控制连接，并安排两服务器间的数据连接。这种情况下，控制信息传送到用户PI，但数据在两服务器间传送。以下是服务器-服务器交互模型：
控制 ------------ 控制
---------->| User-FTP |<-----------
| | User-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| 服务器-FTP | 数据连接 | 服务器-FTP |
| "A" |<---------------------->| "B" |
-------------- 端口 (A) 端口 (B) --------------
图 2
协议规定在数据传输过程中控制连接必须一直打开。当FTP服务使用完以后，用户应该要求服务器关闭控制连接。当没有发送关闭命令但控制连接事实已经关闭的情况下，服务器可能终止数据传送。
FTP与Telnet的关系：
FTP在数据连接中使用Telnet协议。这可能以两种方法实现：第一，用户PI或服务器PI在它们的实现过程中应用Telnet协议。第二，用户PI或服务器PI可能用系统中已经存在的Telnet模块。
第二种方法使用更简单，达到了代码共享，模块化编程的目的。比第一种方法更独立和高效。实际上FTP对Telnet协议的依赖非常小，因此第一种方法也不一定会引入大量的代码。
3. 数据传输功能
文件只通过数据连接传输。控制连接用来发送操作命令以及相应的命令响应（参见FTP响应一章）。一些命令与主机间数据传输有关。这些数据传输命令包括：指定数据位怎样被传输的模式（MODE）命令，以及用来定义数据表示方式的结构（STRU）类型（TYPE）命令。传送和表示基本上是独立的，但“流式”传输模式依赖于文件结构参数，而当使用“压缩”传送模式时，填充字节的表示依赖于表示类型。
3.1. 数据表示和存储
数据由发送端主机存储设备传输到接收端主机的存储设备上。由于两个系统的数据存储形式不同，经常需要将数据转换形式。例如，NVT-ASCII在不同的系统中有不同的存储表示。DEC TOP-20一般用5个7位的ASCII字符存储NVT-ASCII，左对齐成36位的字。IBM Mainframe用8位EBCDIC编码存储NVT-ASCII。Multics将NVT-ASCII存储成4个9位字符组成的字。当在不同的系统中传输字符时理应将其转换成标准的NVT-ASCII表示。发送和接收端则应相应地在标准表示法和内部表示法间转换。
当传输二进制数据时表示法的另一个问题就是不同主机有不同的字长度。并不总是明确发送端怎样发送数据以及接收端怎样接收数据。例如，当从一个32位字长的系统传输32位字节到一个36位字长的系统时，应该（为了高效和实用）在后一个系统中将32位字节在36位字中右对齐。无论哪种情况，用户都应该可以选择数据表示形式和传输功能。应该注意FTP提供了非常有限的数据表示形式。传输这些表示形式之外的数据时用户应该自行转换。
3.1.1. 数据类型
当用户指定一个表示类型时，FTP为我们管理数据表示。这种类型可能隐含的（ASCII/EBCDIC）或显式的（本地字节）为解释器作为“逻辑字节长度”定义字节长度。注意这并不是用于在数据连接传输时的字节长度，被称为“传输字节长度”，两种长度不能互相冲突。例如，NVT-ASCII具有8位的逻辑字节长度。如果类型是本地字节，那么TYPE命令必须有第二个参数指定逻辑字节长度。传输字节长度始终是8位。
3.1.1.1. ASCII类型
这是缺省类型，必须被所有FTP实现支持。主要用来传输文本文件，除非主机双方认为EBCDIC类型更方便。
发送方将内部字符表示转换为标准的8位NVT-ASCII表示（参见Telnet协议）。接收方将标准格式数据转换为它自己的内部格式。
NVT规定，<CRLF>序列用来表示文本一行的结尾。（参见本章末文件结构中有关数据表示和存储的讨论）
用标准NVT-ASCII表示意味着数据必须解释为8位字节。
用于ASCII和EBCDIC格式参数将在下面讨论。
3.1.1.2. EBCDIC类型
这种类型用来在使用EBCDIC编码的主机间高效地传输。
传输时，数制被表示为8位的EBCDIC字符。EBCDIC与ASCII类型的区别仅仅是字符编码的不同。
行尾（End-of-Line）很少用在EBCDIC类型中表示结构，必要时应该用<NL>。
3.1.1.3. 图像类型
数据以8位连续字节流传输。接收端必须将数据存储为连续位。存储系统结构可能要将文件（或对于记录结构文件来说，每个记录）填充到合适的边界（字节、字或块）。填充的字节必须为0，并追加到文件末尾（或每个记录末尾）。必须有方法来指出填充字节，当取得文件时，以将填充字节剔除。填充转换方法应当公开，使用户可以方便的处理文件。
图像类型目的是为了高效地存储和检索文件，以及传输二进制文件。建议所有的FTP实现都应该支持这个类型。
3.1.1.4. 本地类型
数据以参数Byte size指定的逻辑字节长度传输。字节长度值必须是十进制整数，并且没有缺省值。逻辑字节长度不一定要和传输字节长度一样。如果字节长度不同，那么逻辑字节将忽略传输字节边界连续打包，并在最后做必要的填充。
当数据到达接收端主机时，将以独立的方式被转换为特定主机的逻辑字节长度。这个转换过程必须是可逆的（就是说，用同样的参数会产生同样的文件）并且应该被FTP实现者公开。
例如，用户发送36位浮点数到一个32位字长的主机时可以以本地字节长度36来发送。接收端主机将存储逻辑字节，以方便操作。在这个例子中，将36位的逻辑字节放入64位双字中将满足需要。
另一个例子中，一对用36位字长的主机间用“TYPE L 36”传送数据。数据将用8位传输字节包装，因此9个传输字节代表两个主机字。
3.1.1.5. 格式控制
ASCII和EBCDIC类型也支持第二个可选的参数。这代表了一种纵向的文件格式控制。以下数据表示类型在FTP中定义：
一个被传输到主机的字符文件可能具有以下三个目的之一：为了打印；为了存储用来以后重现；为了处理。如果文件传送是为了打印，接收主机必须知道垂直控制是如何被表示的。第二种目的中，可能需要在主机中存储为一个文件，日后将其重现为一样的格式。最后一种目的中，必须保证将文件从一主机传输到另一主机并在第二台主机上处理文件并不带来麻烦。单独的ASCII或EBCDIC格式不能满足所有这些条件。因此，这些类型具有第二个参数指定以下三种格式之一：
3.1.1.5.1. 非打印（NON PRINT）
如果第二个格式参数被省略，这将是缺省格式。非打印格式必须被所有FTP实现支持。
文件不要包含垂直格式信息。如果文件被送到打印过程，那么打印过程将假定使用标准的间距和页边距值。
一般来说，这个格式被用作处理或存储。
3.1.1.5.2. TELNET格式控制
文件包含ASCII/EBCDIC垂直格式控制（也就是，<CR>,<LF>,<NL>,<VT>,<FF>），打印过程将适当的解释这些控制符。<CRLF>表示行末。
3.1.1.5.3. CARRIAGE CONTROL(ASA)
文件包含ASA（FORTRAN）垂直格式控制字符。（参见RFC 740附录C；《Communications of the ACM》7卷，10章，606页，1964十月）ASA标准规定，每行或记录的头一个字符不用来打印。这个字符用来决定本行或记录打印机的垂直走纸量。
ASA标准指定如下控制字符：
字符 垂直间距
空 走纸一行
0 走纸两行
1 走纸到下页顶
＋ 不移动，也就是覆盖打印
打印机过程必须有方法区分结构体的结束。如果文件具有记录结构（后面将介绍）就没有问题；记录会在传输与存储中显式的标记。如果文件没有记录结构，将以<CRLF>行尾标记作为打印时行的分隔，但这些格式符会被ASA控制符覆盖。
3.1.2. 数据结构
由于表示类型的不同，FTP允许文件具有指定的结构。FTP中定义了以下三种文件结构：
文件结构，内部没有结构，文件被视为连续的数据字节流
记录结构，文件由连续的记录组成
页结构，文件由独立的具有索引的页组成
如果没有使用结构命令（STRU），文件结构是缺省值。但在所有的FTP实现中，文件和记录结构必须用在“文本”文件（就是说，带有TYPE ASCII或EBCDIC的文件）里。文件结构将影响文件的传输模式（参见传输模式一章）以及文件的表示和存储。
文件的“自然”结构取决于存储文件的的主机。源代码文件在IBM Mainframe上以固定长度的记录存储，而在DEC TOPS-20以用类似于<CRLF>的行分隔符行分开的字符流存储。如果文件在这两种站点间传输，就必须要让其中的一个站点知道另一个站点的文件结构。
在基于文件结构的主机和基于记录结构的主机间传输文件时可能会出现问题。如果文件是基于记录结构传输到基于文件结构的主机，应该在内部将记录结构转换为文件结构。显然这种转换应该能够可逆，以便可以再转回记录结构。
在将文件从基于文件结构的主机传输到基于记录结构的主机时，存在如何将文件切分成记录的问题。如果必须切分一个文本文件，那么FTP实现应该使用行末符，ASCII中是<CRLF>，EBCDIC中是<NL>，作为分隔。
3.1.2.1. 文件结构
如果没有使用结构命令（STRU），文件结构就默认使用。
在文件结构中没有内部结构，文件被当作连续的字节流。
3.1.2.2. 记录结构
在所有的FTP实现中，必须支持“文本”文件（就是，使用TYPE ASCII或EBCDIC）的记录结构。
在记录结构文件中，文件由连续的记录组成。
3.1.2.3. 页结构
为了传输不连续的文件，FTP定义了页结构。一般说的“随机存取文件”或“多穴文件”属于这个类型。对于这些文件，一般有另外的对应整个文件信息（例如，文件描述符），或者对应文件部分信息（例如，页存取控制），或两者都有。在FTP中，文件的部分称为页。
为了提供不同页大小以及相关信息，每页传输时将额外包括一个页头。页头有如下定义的域：
头长度
包括这个字节在内的头逻辑长度。最小头长度是4。
页索引
文件区域的逻辑页号。并不是传输的序列号，而是标识本页的索引号。
数据长度
页中数据的逻辑字节数。最小数据长度为0。
页类型
标示了页的类型。定义了如下的类型：
0 ＝ 最末页
用来标示页结构传输结束。页头长度必须为4，数据长度必须为0。
1 ＝ 单独页
对于没有页相关控制信息的单独页来说这是普通的类型。页头长度必须为4。
2 ＝ 描述页
这个类型用来传输整个文件的描述信息。
3 ＝ 存取控制页
此类型包括一个额外的指定页存取信息的头域。头长度必须为5。
可选域
其他的头域可能用来提供每页的控制信息，例如，每页的存取控制。
所有域都是一个逻辑字节。逻辑字节长度由TYPE命令指定。参见附录I中的更详细信息以及一个页结构的例子。
关于参数需要注意的一点：必须用相同参数续传相同的文件。相应的，FTP实现在用相同参数续传文件时要保证传输的文件与原始文件相同。
3.2. 建立数据连接
传输数据的过程包括在指定端口建立数据连接选择传输参数。用户和服务器DTP都有缺省的端口号。用户过程缺省的数据端口与控制连接端口相同（也就是，端口U）。服务器过程的默认端口与控制连接的端口相邻（也就是L-1）。
传输字节长度是8位字节长。这个字节长度只与实际传输数据有关；而与主机文件系统的数据表示无关。
被动数据传输过程（可能是用户DTP或另一服务器DTP）应该在发送FTP请求命令之前“监听”在数据端口。FTP请求命令决定了数据传输方向。服务器在接到传输请求后将建立到指定端口的连接。当连接建立后，数据将在两端DTP间传输，同时服务器PI向用户PI发送确认回复。
每个FTP实现必须支持使用缺省的数据端口，只有用户PI可以使用变化的非缺省端口。
用户可能会用PORT命令指定一个其他的数据端口。用户可能想将文件下载到TAC行式打印机或者从第三方主机下载。后种情况下，用户PI同时建立到两服务器PI的控制连接。一个服务器（用FTP命令）等待连接，另一个服务器建立连接。用户PI给一个服务器PI发送PORT命令指示另一服务器的数据端口。最后，向两端发送合适的传输命令。用户控制端与服务器间传送的详细命令以及回复顺序定义在FTP响应一章。
一般来说，维护数据连接是服务器的责任，包括连接的建立与关闭。例外的情况是当用户DTP在传输模式下发送数据时需要关闭连接表示文件结束。服务器必须在以下条件下关闭数据连接：
1. 服务器在传输模式下完成数据传输，需要关闭连接，表示文件结束。
2. 服务器收到用户发来的ABORT命令。
3. 用户用命令改变了端口设定。
4. 控制连接合法地或由于其他原因关闭。
5. 发生了不可挽回的错误。
其他情况下是否关闭连接是服务器可选择的，这种情况下服务器必须用250或226号响应通知用户过程。
3.3. 数据连接管理
缺省数据连接端口：所有FTP实现必须支持使用缺省数据连接端口，只有用户PI可能使用非缺省端口。
协商非缺省端口：用户PI可能使用PORT命令指定非缺省用户端口。用户PI可能要求服务器端用PASV命令指定非缺省端口。连接用一对地址指定，上面两种动作之一都会得到一个不同的连接，仍然允许同时使用两个命令在两端指定新的端口。
数据连接复用：当使用流模式传输数据时，在文件传输结束后必须关闭连接。如果有多个文件传输时可能带来的问题是TCP为了保证传输可靠要保持连接记录一段时间。因此不能马上重新连接。
有两种解决方案。第一种是协商一个非缺省端口。第二种是使用另一种传输模式。
对于传输模式，流式传输模式有天生的不可靠性，不能确定连接是否过早的关闭。其他的传输模式（块，压缩）不用关闭连接来指示文件结束。他们使用FTP编码来确定文件结束。因此使用这些模式可以在多文件传输时保持使用同一个数据连接。
3.4. 传输模式
传输数据时下一个要考虑的问题是选择合适的传输模式。有三种传输模式：一个对数据格式化，并允许重新开始过程；一个压缩数据提供高效传输；一个不加修改的传输数据。最后一种模式与结构属性配合决定处理过程。在压缩模式中，表示类型决定填充字节。
所有的数据传输必须显式的或隐式的用关闭数据连接来指示文件结束（EOF）。对记录结构的文件，所有的记录结束标志（EOR）都是显式的，包括最后一个记录。对于使用文件结构的传输，使用“末页”的页类型。
注意：在本章其他部分，除非明确指出，字节都表示“传输字节”。
为了使传输标准化，发送主机将根据传输模式和文件结构把行尾或记录尾转换成传输时的格式，接收主机将进行相反的转换。IBM Mainframe的记录记数域可能不会被另一台主机识别，因此在流模式中记录尾信息可能以两字节的控制码来传输，在块模式或压缩模式中作为标志位。没有记录结构的ASCII或EBCDIC文件中的行尾应该分别表示为<CRLF>或<NL>。这些转换工作在某些系统中可能意味着额外的工作，同样的系统在传输非记录结构文本文件时可能希望用流模式直接传输二进制流。
FTP定义了如下传输模式：
3.4.1. 流模式
数据以字节流传输。对表示类型没有限制；可以使用记录结构。
在记录结构文件中，EOR和EOF将分别用两个字节的控制码表示。第一个字节都是同样的escape字符。第二个字节中，EOR将低位置一，其他位置零；EOF则是将第二低位置一；也就是这个字节对于EOR来说是1，对于EOF来说是2。EOR和EOF可能在传输结束时通过使最低两置一来同时指定（就是值3）。如果想发送escape字符，要在第二个字节再重复一次。
如果结构是文件结构，则使用关闭主机连接来指示EOF，传输的所有数据字节就是原始字节。
3.4.2. 块模式
文件以连续的带有数据头的数据块来传输。数据头包括一个计数域和描述码。计数域指示了数据块整个长度，由此可以算出下一数据块的开始位置（没有填充位）。描述码定义了：文件最后一块（EOF），记录最后块（EOR），重开始标记（参见错误恢复和重开始章）或者怀疑数据（也就是被怀疑在传输中可能不可靠的数据）。最后的描述符不是FTP错误控制的一部分。它用来在站点间交换指定类型的数据（比如地震或天气数据）而且简略本地错误（比如磁带读错误）。记录结构可以在这种模式下使用，而且可以用任何表示类型。
头包括3个字节。在这24位的头信息中，低16位表示字节记数，高8位表示描述符。
块头
+----------------+----------------+----------------+
| 描述符 | 字节记数 |
| 8 bits | 16 bits |
+----------------+----------------+----------------+
描述符字节由各个标志位组成。指定了4个描述码，每一个描述码为描述符的十进制值。
描述码 意义
128 数据块结束是EOR
64 数据块结束是EOF
32 怀疑数据块有错
16 数据块是重开始标志
通过对不同的标志位置一，每个数据块可以使用不同的描述符组合。
重开始标志是在数据流中的8位整数，表示在控制连接中使用的可打印字符（比如，缺省的NVT-ASCII）。在重开始标志中不能使用<SP>（空格）
例如，要传输6个字符标记，应该按如下发送：
+--------+--------+--------+
|描述符 | 字节记数 |
| = 16| = 6 |
+--------+--------+--------+
+--------+--------+--------+
| 标记 | 标记 | 标记 |
| 8 位 | 8 位 | 8 位 |
+--------+--------+--------+
+--------+--------+--------+
| 标记 | 标记 | 标记 |
| 8 位 | 8 位 | 8 位 |
+--------+--------+--------+
3.4.3. 压缩模式此模式下，有三种信息要发送：常规数据，以字节串发送；压缩数据，包括复本或填充；控制信息，以两字节的转义字符传送。如果发送n>0（最多127）个字节的常规数据，这n个字节前要有一头字节，这字节的最高位为0，其余7位代表数n.
字节串：
1 7 8 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| n | | d(1) | ... | d(n) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
^ ^
|---n个字节---|
n字节的字节串d(1),...,d(n)
数n必须为正。
为了压缩n字节的复本，下面两个字节要发送：
复制字节：
2 6 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1 0| n | | d |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
一串长度n的填充字节可以压缩成一个字节，填充字节与表示类型有关。如果类型是ASCII或EBCDIC，填充字节是<SP>（空格，ASCII码是32，EBCDIC码是64）。如果类型是图像或本地字节，填充字节为0。
填充字节：
2 6
+-+-+-+-+-+-+-+-+
|1 1| n |
+-+-+-+-+-+-+-+-+
转义序列由两个字节组成，第一个字节为转义字节（全0）第二个字节包括块模式中定义的描述码。这里的描述码与块模式中的描述码意义相同，并对后面的字节串有效。
压缩模式适用于在传输大数据时以较小的CPU代价换来一定的网络带宽。最适合用在减少RJE主机产生的打印文件大小。
3.5. 错误恢复和重开始
这里并没有提供是否在传输中存在丢失字节或者数据包混乱的方法。这个级别的错误由TCP控制。但必须提供一个重开始的方法来应对系统错误（包括主机、FTP过程、或网络的失败）。
重开始过程只定义在块模式和压缩模式下。它要求数据发送者在数据流中插入一个特殊的标记。这个标记信息只对发送方有意义，但必须由缺省或协商的控制连接语言（ASCII或EBCDIC）中的可打印字符组成。标记要表示一个位记数，一个记录记数，或者可以表示数据检查点的信息。数据的接收方，如果要实现重开始过程，将用此标记指定数据位置，并将此信息返回给用户。
系统失败的情况下，用户可以用标记的位置信息重新开始传送过程。下面的例子演示了重开始过程的使用。
数据的发送方在数据流中的适当的位置插入了一个标记块。接收主机在它的文件系统中标记对应的数据点，并直接或用110号控制连接响应（取决于发送方是谁）向用户传达最后的标记信息。在系统失败时，用户或控制过程使用重开始命令并以标记信息为其参数来重开始传输。重开始命令通过控制连接传输，后面跟上系统失败时正在执行的命令（比如RETR，STOR或LIST）。
4. 文件传送功能
从用户PI到服务器PI的传输通道是通过一个从用户到标准服务器端口的TCP连接建立的。用户PI负责发送FTP命令并解析接收到的响应；服务器PI解析命令，发送响应以及控制DTP建立数据连接并传送数据。如果数据传输（被动传输过程）的另一端是用户DTP，则用户DTP由用户FTP主机的内部协议控制；如果另一端是另一个服务器DTP，则这个服务器DTP由用户PI通过发送命令来控制。FTP的响应将在下一部分讨论。这部分描述的一些命令对理解可能出现的响应会有帮助。
4.1. FTP命令
4.1.1. 访问控制命令
下面的命令表示访问控制标识符（括号中表示命令代码）
用户名 （USER）
这个命令的参数域是一个用来标识用户的Telnet字符串。用户识别对于服务器控制文件系统存取权限是必需的。这个命令通常是控制连接建立后从用户端发送的第一条命令(一些服务器可能需要保证这一点)。一些服务器可能还需要附加的识别信息如密码或帐号命令。为了改变控制权限和/或帐户信息，服务器可能在任何时候都允许接受一个新的USER命令，来更换存取权限或帐户信息。产生的效果是刷新早先登录的用户名、密码和帐户信息，并重新开始一个登录过程。所有的传输参数不发生变化，并且所有正在传输中的文件传输过程均在原来的访问控制权限下完成。
密码 （PASS）
这个命令的参数域是一个用来指定用户密码的Telnet字符串。这个命令必须紧跟在用户名命令之后，在某些站点上，它用来完成用户访问权限识别。因为密码信息非常敏感，一般应该使用掩码代替或者禁止回显。显然服务器没有安全的办法做到这一点，所以隐藏敏感的密码信息就成了用户FTP进程的责任。
帐户 （ACCT）
这个命令的参数域是一个用来识别用户帐户的Telnet字符串。这个命令不需要和USER命令相关，某些站点可能需要一个帐户用来登录，另一些站点仅用于特殊访问权限，比如存储文件。后一种情况下这个命令可能在任何时候收到。
有一些响应代码用来自动地区分这些情况：当登录过程必须要求帐户信息的时候，PASS命令成功的响应代码是332。相应，如果登录过程不要求帐户信息时，PASS命令成功的响应代码是230；如果帐户信息需要在随后的对话命令中给出，服务器应该根据是保留（等侍收到ACCT命令）还是放弃命令来相应的返回332或532。
改变工作目录 （CWD）
这个命令允许用户在不改变登录用户和帐户信息的情况下改变工作目录或数据集。传输参数保持不变。这个命令的参数是一个路径名，用来指定相应的目录或者其他系统上的文件组名。
返回上层目录 （CDUP）
这个命令是CWD命令的特例，因为在不同的操作系统下表达父目录可能有不同的语法，所以可以用这个命令简化目录树的传输实现。它的响应代码应该和CWD的响应代码相同。更多信息参看附录II。
结构装备 （SMNT）
这个命令允许用户在不改变用户和帐户信息的情况下装备一个不同的文件系统数据结构。传置传输参数不会改变。它的参数是一个用来标识目录或者其他系统中依赖文件组的路径名。
重新初始化 （REIN）
此命令除允许当前正在传输过程完成外，终止一个用户，刷新所有的I/O和帐户信息。所有参数重设为默认值，并保持控制连接。此时等同于控制连接刚刚建立的状态。这条命令之后可能需要USER命令。
注销 (QUIT)
此命令终止一个用户，并且当没有文件正在传输的话，服务器将关闭控制连接。如果当前有文件正在传输，连接会保持并等待回应，之后服务器将关闭连接。如果用户进程想以不同的用户名传输文件，而不想关闭然后再重建立连接的情况下，应该使用REIN命令而不是QUIT。
控制连接的意外关闭将会导致服务器产生等同于放弃（ABOR）和注销（QUIT）动作。
4.1.2. 传输参数命令
所有的数据传输参数都有默认值，只有在默认值需要改变的时候才需要用命令去指定传送数据传输参数。默认值是最后一次指定的值，或者如果未被指定，则是标准默认值。这意味着服务器必须“记住”可用的默认值。这些命令可以在FTP服务请求前以任何顺序执行。下面这些命令用来指定数据传输参数：
数据端口（PORT）
这个参数是用来指定数据连接时的主机数据端口。对于用户和服务器都有默认的数据端口值，并且一般情况下这条命令以及它的响应都不需要。如果使用了这条命令，那它的参数是一个32位的因特网主机地址和一个16位TCP端口号。地址信息被分解为每8位一个段，每个段都作为十进制数(用字符串表示)传送。段之间用逗号分隔，一个PORT命令像下面这样：
PORT h1,h2,h3,h4,p1,p2
h1是因特网主机地址的高8位。
被动 (PASV)
此命令请求服务器DTP在一个数据端口(不是它的默认端口)上“监听”并等待连接而不是在收到传输命令后主动发起连接。这个命令的响应包括服务器监听的地址和端口号。
表示类型（TYPE）
这个命令的参数指定在数据表示和存储部分介绍的表示类型。某些类型需要第二个参数。第一个参数用单个Telnet字符表示，对于ASCII和EBCDIC的第二个格式化参数也是如此;本地字节的第二个参数是一个表示字节长度的十进制整数。参数之间用<SP>(空格，ASCII码的32)分开。
下面的编码用来表示类型：
\ /
A - ASCII | | N - 非打印
|-><-| T - Telnet格式
E - EBCDIC| | C - Carriage Control (ASA)
/ \
I - 图像
L <字节长度> - 本地字节长度
默认的表示类型是ASCII非打印。如果格式化参数首先被更改，然后单独更改第一个参数，格式化参数会变回默认的非打印。
文件结构（STRU）
这个命令的参数是单个Telnet字符，用来指定在数据表示和存储部分描述的文件结构。
下面编码用来表示文件结构：
F - 文件 (没有记录的结构)
R - 记录结构
P - 页结构
默认的结构是文件。
传输模式（MODE）
这个命令的参数是单个Telnet字符，用来指定在传输模式部分描述的数据传送传输模式。
下面的编码用来表示传送模式：
S - 流
B - 块
C - 压缩
默认的传送模式是流。
4.1.3. FTP服务命令
FTP服务命令定义了用户请求传送文件或者文件系统的功能。FTP服务命令的参数一般是一个路径。路径的语法必须符合服务器站点的惯例（尽量用默认标准）和控制连接的语言习惯。建议的默认参数是使用最后一个设备，目录或文件名，或者本地用户的默认标准。除"rename from"命令后面必须紧跟"rename to"命令以及restart命令必须紧跟随中断服务命令(例如STOR或RETR)之外，其他命令可以使用任意的顺序。服务器应当总是使用数据连接来发送服务命令响应，只有少数特定的信息响应除外。下面为FTP服务请求命令：
获得 (RETR)
这个命令引起服务器DTP传送一个由路径指定的文件拷贝到数据连接另一端的服务器或用户DTP。服务器文件的状态和内容应该不受影响。
保存 (STOR)
这个命令引起服务器DTP接受经过数据连接传送的数据并将这些数据存储为服务器端的一个文件。如果在路径参数里指定的文件在服务器端已经存在，那么这个文件会被传送过来的数据覆盖。如果指定的文件不存在则会在服务器端新建一个文件。
唯一保存 (STOU)
这个命令类似于STOR命令，但是它会在在当前目录下创建一个名字唯一的文件。在250号标准响应里必须包含创建出的文件名。
追加 (包括创建) (APPE)
这个命令引起服务DTP接受从数据连接传送过来的数据并存储在服务器端的一个文件里。如果指定的文件在服务器端已经存在，则这个数据会附加到文件的后面；否则服务器端会创建这个文件。
分配 (ALLO)
一些服务器可能要求用这个命令来保留足够的空间来容纳新文件。其参数是一个十进制整数，用来指定保留给文件存储用的字节数（用逻辑字节长度)。对于用记录或者而结构传送的文件而言，还需要有最大结构或页的大小（使用逻辑字节），这个值在这个命令的第二个参数域用十进制整数指定。第二个参数是可选的，但当它存在的时候应该用三个Telnet字符<SP>R<SP>和第一个参数分开。这个命令之后应该是STOR或者APPE命令。在那些不需要预先知道文件最大值的服务器上，这个命令应该被作为NOOP(无操作)对待，在那些只对记录或页最大值感兴趣的服务器上应该忽略第一个参数。
重新开始 (REST)
这个命令的参数域指定了需要重新开始传输的文件的位置标记。这个命令不会引起文件的传输，只是忽略文件中指定标记点前的数据。
重命名开始 （RNFR）
这个命令指定了需要重新命名的文件的原始路径名。后面必须马上接着“重命名为”命令，来指定新的文件路径
重命名为 （RNTO）
这个命令为在“重命名开始”命令中指定的文件指定新的路径。这两个命令一起为文件重新命名。
放弃（ABOR）
该命令告诉服务器放弃先前的FTP服务命令和相关的传输的数据。放弃命令也许需要引起服务器的“特别注意”（参见FTP命令部分），使服务器强制识别。当前一个命令（包括数据传输）完成时，将不会产生动作。服务器不会关闭控制连接，但是数据连接必须关闭。
服务器接收这个命令时可能处在两种状态：(1)FTP服务命令已经完成，或者(2)FTP服务命令还在执行中。
第一种情况，服务器关闭数据连接（如果数据连接是打开的）回应226代码，表示放弃命令已经成功处理。
第二种情况，服务器放弃正在进行的FTP服务，关闭数据连接，返回426响应代码，表示请求服务请求异常终止。然后服务器发送226响应代码，表示放弃命令成功处理。
删除 (DELE)
这个命令在服务器端删除指定的文件。如果需要额外的保护（比如讯问“你丫的真的想删除么？”），应该由用户FTP进程提供。
删除目录（RMD）
这个命令移除指定路径下的目录（如果是绝对路径），或者是当前工作目录的子目录（如果是相对路径）。参看附录II
新建目录（MKD）
该命令在指定的路径下新建一个目录（如果是绝对路径），或者在当前工作目录下建子目录（如果路径是相对的）。参看附录II
打印工作目录（PWD）
该命令返回一个当前的工作目录名。参看附录II
列表（LIST）
该命令从服务器端发送一个列表到被动的DTP。如果路径名指定了目录或者别的文件组，服务器应该传送指定目录下的文件列表。如果路径名指定了文件，服务器应当传送这个文件的信息。没有参数，意味着用户的当前工作目录或者缺省目录。数据通过数据连接以ASCII或EBCDIC类型传输。（用户必须确定类型是ASCII或者EBCDIC）。因为不同系统间的文件信息差别很大，这个信息可能不易被程序自动使用，但可能对于用户来说是有用处的。
名字列表 （NLST）
该命令从服务器端传送目录列表到用户端。路径名应该指定一个目录名或者其他系统文件组描述符；无参数意味着当前目录。服务器只返回文件的名字组成的字节流，不包括其他的信息。数据将通过数据连接以ASCII或者EBCDIC类型传输，每个路径名字符串由<CRLF>或<NL>分割。（用户仍必须保证类型使用正确）。这个命令的响应信息将可能被用于程序对文件的自动处理。例如，多线程下载的实现。
站点参数（SITE）
服务器使用这个命令，提供本系统可能对文件传输有帮助的特殊服务。在协议中它的用处不是很普遍。服务的种类和语法规约可以在HELP SITE命令的响应中确定。
系统（SYST）
该命令来得到服务器端操作系统的类型。响应的第一个词应该是Assigned Numbers文档[4]中表示操作系统名字的一个词。
状态 （STAT）
该命令应该通过控制连接以响应码的形式返回状态信息。此命令可能在文件传输过程中发出（与Telnet IP和同步信号一起，参见FTP命令道听部分），此时服务器将返回正在传输的状态。或者这个命令也可能在两个文件传输过程之间发出，这种情况下，命令可能将有一个参数域。如果参数指定了一个路径名，则命令将与列表命令类似，只是数据由控制连接传输。如果给出了部分路径，服务器可能响应指定的路径下的文件名列表或者相关属性。如果没有提供参数，将返回服务器FTP进程一般的状态信息，其中应该包括所有传传输参数的当前值和连接的状态。
帮助（HELP）
该命令使服务器通过控制连接传送关于具体实现状态的帮助信息给用户。该命令可以有参数（例如，命令的名字）返回更加具体的信息。回应代码是211或者214。建议在输入USER命令前允许HELP。服务器可以用这个响应指定站点特定的参数，例如，在HELP SITE响应中指定。
空操作（NOOP）
该命令不应影响任何参数或者之前发送的命令。该命令不指定任何动作，只是要求服务器返回OK响应。
文件传输协议在控制连接上的所有通信都遵守Telnet协议。因为Telnet传输使用的语言可能是一个可协商的选项，下两部分提到的所有参考信息将使用“Telnet语言”和相应的“Telnet行尾符”。当然可以将这些转换成NVT-ASCII和<CRLF>。没有其它的Telnet协议规范被引用。
FTP命令是以"Telnet行末符"结尾的"Telnet字符串"。命令如果带有参数，那么命令代码本身是以<SP>（空格）结尾的文字字符，或者当没有参数时以Telnet行末符结尾。命令代码和命令的语义在本章描述；详细的命令语法在命令一章描述，响应序列在命令和响应一章中描述，命令用法的情景演示说明在典型FTP情景一章中给出。
FTP命令分为访问控制命令、数据传输参数命令、FTP服务请求命令三种。某些命令（例如，ABOR，STAT，QUIT）可以在数据传输过程中，通过控制连接发送。一些服务器可能不能同时监控控制连接和数据连接，此时就要发出一些特殊的动作来引起服务器的注意。下面的指令格式是试验性建议：
1.用户系统在Telnet流中插入Telnet"中断过程"（Interrupt Process-IP）信号
2.用户系统发出Telnet “同步”（Synch）信号
3.用户系统在Telnet流中插入命令（例如，ABOR）
4.服务器PI，在接收到"IP"后，扫描telnet流，寻找FTP命令
（对于其它服务器，这些操作可能没有必要，但并不会引起意外的后果。）
4.2. FTP响应
文件传输协议命令的响应，用来确保在文件传输过程中的请求和正在执行的动作保持一致，保证用户程序总是可以得到服务器的状态信息。每一个命令必须产生至少一个响应，也可能产生多个响应；多重的响应必须是可以简单区分的。另外，一些命令是有一定顺序的组合。比如USER、PASS和ACCT，或者RNFR和RNTO。此时的响应表示一种中间状态，说明前面的命令是成功的。顺序组合中出现任何错误都会导致需要从头开始整个命令序列。
命令-响应序列的细节，将由下面一组状态图表明确表示。
FTP响应由3位数字组成（以3个数字字符传递）后面跟着一些文本。数字用来自动的判断当前的状态，文本内容提供给人类用户。三位数字应该包含足够的信息，使用户PI不需要检查文本内容，而将其忽略或返回给用户。文本内容可能是与特定服务器相关的，所以每一个响应的文本内容很可能不同。
响应包含的3位数字，后面跟着空格<SP>，然后是一行文本（已指定一行最大的长度），以Telnet行末符结尾。有可能出现文本长度大于一行的情况。在这种情况下，文本全文必须在两端加以标识，使用户进程知道什么时候应该停止读取响应（也就是，停止从控制连接读取输入），去做别的事情。这要求第一行文本需要一种特殊的格式，来标识传来的文本内容有多行，并在文本最后一行指明这是最后。必需要包含适当的响应代码，以指明当前文本的状态。为了满足这些功能，第一行和最后一行的代码应该是一样的。
因此，多行回应的格式是：第一行以正常的响应代码开始，后接连字符“-”（也就是那个减号）后面跟着文本。最后一行需要以相同的代码开始，后面跟空格<SP>分隔的可选文本，然后是Telnet行末符
例如:
123-第一行
第二行
234 以数字开始的一行
123 最后一行
用户进程只需要简单地寻找一行开始时后面跟随（空格）的相同响应代码，并忽略掉中间的文本。如果中间文本的某一行首出现了3位数字，服务器必须在前面填充，以避免混淆。
添加“人工的”第一行和最后一行标志的这种方案，允许使用标准系统例行程序产生响应信息（例如，产生STAT响应）。少数情况下，如果例行程序必须在某一行行首生成3位数字后跟空格，文本的每一行行首应该填充一些空文本，例如空格。
这个方案假定多行的响应不能被嵌套。
3位数字的每一位都有特定的意义。允许用户进程将复杂的响应简化。第一位数字标识了响应是好，坏或者未完成。（参见状态图），简单的用户进程可以通过检查第一位数字，决定它的下一个动作（依计划处理，重试，放弃等等）。用户进程如果希望知道大概是发生了什么错误（比如，文件系统错误，语法错误），可以通过检查第二位数字来完成。第三位数字指示信息顺序是否有误（例如，RNTO前没有RNFR命令）。
响应的第一位数字可能有以下五个值：
1yz，预备状态
请求的动作已经启动；在下一个新命令之前，期望一个回应。（用户进程在接收到完成响应前就发送另一条命令是违返协议的。但服务器FTP进程在处理前面命令的过程中应该将后续收到的命令存入队列。）这种类型的响应用来表明命令已被接受，对于不能同时监视数据和控制连接的用户进程来说，它可能要开始关注数据的连接了。服务器FTP进程最多每个命令发送一个1yz代码。
2yz，完成状态
请求动作被成功的完成。一个新的请求可以开始。
3yz，中间状态
命令被接受，但是请求动作暂时没有被执行，等侍收到进一步的信息。用户应该发送另一个命令来指定这个信息。这个回应用在命令组合中。
4yz，暂时拒绝状态
命令没有被接受，请求动作没有发生，但是这个错误状态是暂时的，动作可以被再次请求。用户应该重新回到命令队列的开始。说明“暂时”的具体意思是很困难的，尤其在两个截然不同的站点（服务器和用户进程）间要达成解释的一致更是不易。每个4yz号响应可能都有一个稍不同的时间值，但总体思想都是鼓励用户进程再一次重试。判断一个响应应该属于4yz号还是5yz号的一个规则是看这个命令是否可以不加修改并在相同的用户、服务器状态下（比如，命令使用同样的拼写使用同样的参数；用户不改变文件访问权限；服务器不产生新的实现。）再次重复。
5yz,永久拒绝状态
命令不被接受，请求动作不会发生。用户进程不能重复同样的请求（包括同样的命令顺序）。一些“永久的”错误状态可以被修正，因此人类用户也许希望控制用户进程在将来的某点上重新开始命令队列。（比如在拼写改变之后，或目录状态改变之后。）
下面为第二位数字的功能：
x0z 语法 - 这种响应指出了语法错误。给出的命令不存在、没有被实现、或多余。
x1z 信息 - 对于请求信息的响应，比如对状态或帮助的请求。
x2z 连接 - 关于控制连接和数据连接的响应。
x3z 身份验证和帐户 - 对登陆过程和帐户处理的响应。
x5z 目前还未使用。
x5z 文件系统 - 请求传输时服务器文件系统的状态或其他文件系统动作状态。
第三位数字为第二位数字指定的状态提供了更详细的意义。下面的响应列表会说明这一点。注意，每一个响应的对应文本只是推荐的，而非强制性的，可依照相应的命令而更改。另一方面，响应代码，必须严格的遵守最后部分的规范，也就是说，服务器实现不应该为与上面所描述的只有微小区别的状态发明新的代码，而应该使用已经定义的代码。
类似TYPE或ALLO这样的成功执行也不会给用户进程新信息的命令将产生200号响应。如果命令因为与本计算机系统无关而不必被服务器FTP进程支持的，例如ALLO在TOPS20站点上，应该回复一个完成状态的响应，来通知用户进程可以继续它的动作请求。202号响应用来处理这种情况，例如，响应文本为“No storage allocation necessary”（无需分配存储）。另外，如果，如果请求了一个并没有被实现的命令，将返回502。504，表明实现了此命令，但是请求的参数并未被实现。
4.2.1. 按功能分组的响应代码
200 Command okay. （命令OK）
500 Syntax error, command unrecognized. （语法错误，命令不能被识别）
可能包含因为命令行太长的错误。
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. （重新开始标记响应）
对于这种情况，文本应该是明确的，无需进行特殊实现；必须形如：
MARK yyyy = mmmm
yyyy是用户进程数据流标记，mmmm服务器的等效标记（注意，标记间的空格和“=“）
211 System status, or system help reply. （系统状态，或者系统帮助响应。）
212 Directory status. （目录状态）
213 File status. （文件状态）
214 Help message. （帮助信息）
关于如何如使用服务器，或者特殊的非标准的命令的意义。只对人类用户有用。
215 NAME system type. （系统类型名称）
这里的NAME指在Assigned Numbers文档中列出的正式名称。
120 Service ready in nnn minutes. （服务将在nnn分钟后准备完成）
220 Service ready for new user. （接受新用户服务准备完成）
221 Service closing control connection. （服务关闭控制连接）
已注消
421 Service not available, closing control connection. （服务不可用，关闭控制连接）
如果服务器知道它必须关闭，应该以421作为任何命令的响应代码。
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. （关闭数据连接）
请求文件动作成功（例如，文件传输或者放弃）
426 Connection closed; transfer aborted. （连接关闭，放弃传输）
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). （进入被动模式）
230 User logged in, proceed. (用户成功登录，继续）
530 Not logged in. （没有登录成功）
331 User name okay, need password. （用户名OK，需要密码）
332 Need account for login. （需要帐户才能登录）
532 Need account for storing files. （需要帐户来存储文件）
150 File status okay; about to open data connection. （文件状态OK，将打开数据连接）
250 Requested file action okay, completed. （请求文件动作OK，完成）
257 "PATHNAME" created. （创建了“PATHNAME”）
350 Requested file action pending further information. （请求文件动作需要进一步的信息）
450 Requested file action not taken. （请求文件动作没有执行）
文件不可使用（例如，文件忙）
550 Requested action not taken. (请求的动作没有执行）
文件不可用（例如，没有找到文件，没有访问权限）
451 Requested action aborted. Local error in processing. （请求动作放弃，处理中发生本地错误）
551 Requested action aborted. Page type unknown. （请求动作放弃，未知的页面类型）
452 Requested action not taken. （请求动作未执行）
系统存储空间不足。
552 Requested file action aborted. (请求文件动作被放弃)
超出存储分配空间（当前的路径或者数据集）
553 Requested action not taken. （请求动作未获得）
文件名不允许。
4.2.2. 按数字顺序排列的响应代码
110 Restart marker reply. （重新开始标记响应）
对于这种情况，文本应该是明确的，无需进行特殊实现；必须形如：
MARK yyyy = mmmm
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. （文件状态OK，将打开数据连接）
200 Command okay. （命令OK）
202 Command not implemented, superfluous at this site. （命令没有实现，对本站点冗余）
211 System status, or system help reply. （系统状态，或者系统帮助响应。）
212 Directory status. （目录状态）
213 File status. （文件状态）
214 Help message. （帮助信息）
关于如何如使用服务器，或者特殊的非标准的命令的意义。只对人类用户有用。
215 NAME system type. （系统类型名称）
这里的NAME指在Assigned Numbers文档中列出的正式名称。
220 Service ready for new user. （接受新用户服务准备完成）
221 Service closing control connection. （服务关闭控制连接）
已注消
225 Data connection open; no transfer in progress. （数据连接打开，没有传输）
226 Closing data connection. （关闭数据连接）
请求文件动作成功（例如，文件传输或者放弃）
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). （进入被动模式）
230 User logged in, proceed. (用户成功登录，继续）
250 Requested file action okay, completed. （请求文件动作OK，完成）
257 "PATHNAME" created. （创建了“PATHNAME”）
331 User name okay, need password. （用户名OK，需要密码）
332 Need account for login. （需要帐户才能登录）
350 Requested file action pending further information. （请求文件动作需要进一步的信息）
421 Service not available, closing control connection. （服务不可用，关闭控制连接）
如果服务器知道它必须关闭，应该以421作为任何命令的响应代码。
425 Can't open data connection. （不能打开数据连接）
426 Connection closed; transfer aborted. （连接关闭，放弃传输）
450 Requested file action not taken. （请求文件动作没有执行）
文件不可使用（例如，文件忙）
451 Requested action aborted. Local error in processing. （请求动作放弃，处理中发生本地错误）
452 Requested action not taken. （请求动作未执行）
系统存储空间不足。
550 Requested action not taken. (请求的动作没有执行）
文件不可用（例如，没有找到文件，没有访问权限）
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. (请求的动作没有执行）
文件不可用（例如，没有找到文件，没有访问权限）
551 Requested action aborted. Page type unknown. （请求动作放弃，未知的页面类型）
552 Requested file action aborted. (请求文件动作被放弃)
超出存储分配空间（当前的路径或者数据集）
553 Requested action not taken. （请求动作未获得）
文件名不允许。