摘要

  • FTP的ACCT不是第二个用户名。它让服务器在身份和密码之外，另行索取登录或特定文件操作所需的本地账户信息。
  • 332是正向中间状态：前一步已被接受，但还缺资料；对后续文件命令而言，它还表示服务器保留了该命令。532则表示命令已被丢弃，补交账户后必须重发。
  • 这套设计没有规定账户一定代表计费、项目或权限，也没有证明任何现代服务器仍使用它；它规定的是谁有权解释本地账户，以及客户端如何知道自己的意图是否仍在服务器手里。

密码没有失败，登录却没有完成

设想一段控制连接。客户端发送USER，服务器要求密码；客户端发送PASS，密码步骤成功。若服务器不需要更多登录资料，RFC 959规定下一状态可以是230 User logged in。但若站点还要求账户，答复是332 Need account for login。

这不是“密码错误”的委婉说法。三位回复码的第一位是3，表示命令已被接受，请求的动作暂时搁置，等待另一条命令补足信息。客户端下一步应发送ACCT，而不是不断重试同一个密码。

今天的登录界面往往只留下用户名和密码两个格子，于是任何非230回复都容易被压缩成认证失败。FTP保留了一项较旧却仍精确的制度事实：证明某个用户秘密，与选择这项工作应计入或受控于哪个本地账户，不一定是同一个决定。

第三个字段来自异构主机，而不是抽象身份学

1972年7月的FTP规范RFC 354还没有这条标准化命令。一个月后的RFC 385提出ACCT，理由很具体：TENEX之类的系统除了用户和密码，还要求单独的账户说明。文档甚至指出，同一用户传输不同文件时可能使用不同账户。

因此ACCT与PASS不同。密码紧跟USER，服务于那次身份序列；账户未必与用户名绑定，可以在稍后到达。它可能参与登录，也可能只在写入等特定操作前才需要。

这段历史不能反向证明“账户”必然是费用中心。协议只把参数定义成一条Telnet字符串，把意义留给远端系统。项目代码、资源配额、访问分区和计费归属都可能是合理的本地解释；RFC没有选中其中一个，更没有创造跨站点通用的账户身份。

回复号码曾经改变，问题没有消失

RFC 542在1973年把ACCT纳入访问控制命令。当时的回复表用331 Enter account表示登录还缺账户，用433表示文件操作没有有效账户、应补交后重发。后来熟悉的331尚未固定为“用户名可以，需要密码”。

1974年的RFC 640重新设计回复码。目标是让程序只看数字就能判断结果和下一状态，不必解析每个站点可自由措辞的人类文本。第二位为3的回复被归入认证与账户处理；332成为登录还需账户，532成为存储文件还需账户。

这次编号变化很重要。阅读旧跟踪记录时，不能把RFC 542的331按今天的含义解释。标准演进保留了同一个控制问题，却调整了机器语法，使“缺密码”和“缺账户”成为不同分支。

332和532还说明服务器是否握着那条命令

RFC 765与RFC 959把后续操作写得尤其清楚。用户可能已经登录，随后发出STOR，服务器才发现这次存储需要账户信息。此时服务器有两个选择。

若服务器保存了那条待执行命令，就回332。客户端发送ACCT后，服务器仍知道此前被搁置的工作。若服务器丢弃了命令，就回532。账户信息到达后，不会凭空复活已经丢掉的STOR；客户端必须重新发送操作。

所以两条回复都在说“缺账户”，却承担不同的意图保管合同。332表示前一动作仍悬而未决；532表示这次请求已结束。把两者统称为“需要账户”会丢掉自动化最需要的信息：究竟应只补一个字段，还是补字段后还要重发原命令。

532不是磁盘满了

数字也容易诱发另一种误读。532 Need account for storing files位于文件操作的失败路径，但它不是容量计量。RFC 959另有452表示系统存储不足，552表示超过当前目录或数据集的存储分配。

缺账户上下文、系统没有空间、超过既定配额是三个不同事实。第一个要求补充控制信息；第二个要求系统容量改变；第三个可能要求分配或策略改变。若监控把它们都显示为“上传失败”，恢复动作会完全相反。

登录状态也有边界

FTP允许在一条控制连接中再次发送USER。RFC 959说，这会清除已经提供的用户名、密码和账户资料，并重新开始登录序列；传输参数不变，已经进行中的传输仍在旧访问控制参数下完成。

这不是一个整齐的全局切换。新身份不会追溯改写正在传输的文件，旧账户也不会自动附着在下一次登录上。REIN则在不关闭控制连接的情况下清除用户和账户状态，并把其他参数恢复默认。连接还活着，并不等于访问上下文还活着。

这种分层让审计必须携带时间和状态。仅看到某条连接曾经成功ACCT，不能证明之后的操作仍使用同一账户；中间的USER、REIN或重连都可能已经改变边界。

标准要求理解命令，不要求每个站点都索取账户

RFC 1123把ACCT列进服务端和客户端应支持的最低命令集合，同时保留底层文件系统或操作系统无法支持特定命令时的例外。这项要求关乎互操作：客户端不应因为界面只画了两个输入框就无法表达第三状态。

它不表示所有服务器都必须要求账户。对某站点没有意义的已识别命令，可以用正向的202表示在此处多余。要求理解一个协议槽位，与要求每次会话都使用它，是两件事。

今天的IANA FTP命令与扩展登记表仍把ACCT记录为基础访问控制命令，并引用RFC 959。登记证明语法位置和规范来源；它不统计部署，不说明各站点给字符串赋予什么意义，也不证明某次操作成功。

协议真正保存的是未完成事实

FTP没有替各主机统一账户制度。它做了更小的事：允许服务器明确说，用户名已知、密码这一步已被接受，但另一个本地上下文仍未满足；若这个缺口在文件命令之后出现，还允许服务器说明自己是否保留了调用者的意图。

这正是回复状态机的价值。一个二选一登录界面可以更简单，却会把“密码错误”“还需账户”“命令已保留”“命令已丢弃”和“磁盘不足”挤成同一种失败。协议越老，未必越含糊；有时是后来的抽象丢掉了它原本明确表达的第三种状态。

来源与证据边界

证据集由RFC 385、RFC 542、RFC 640、RFC 765、RFC 959、RFC 1123与IANA登记表构成。它们建立命令语义和历史，不建立当代普及率、某个实现的行为或任何账户参数的真实含义。