为什么在当今的软件和 FTP 实现中普遍使用的 FTP 中存在 ASCII 模式？为什么不总是使用二进制而不考虑数据？
答案1
如有疑问，请阅读请求函数：
如果未使用 STRUcture 命令，则默认采用文件结构，但所有 FTP 实现都必须接受“文本”文件（即 TYPE 为 ASCII 或 EBCDIC 的文件）的文件和记录结构。文件的结构将影响文件的传输模式（请参阅传输模式部分）以及文件的解释和存储。
文件的“自然”结构取决于哪个主机存储该文件。源代码文件通常以固定长度的记录形式存储在 IBM 大型机上，但在 DEC TOPS-20 上则以字符流形式存储在 DEC TOPS-20 上，这些字符流被分成几行，例如按 <CRLF> 划分。如果要在如此不同的站点之间传输文件，就必须有某种方法让一个站点识别另一个站点对文件的假设。
等等等等...简而言之，这是为了确保一种编码的文本表示在使用不同编码传输到主机时能够正确转换。
答案2
因为不同的操作系统（Windows，UNIX，VAX）对简单文本文件使用不同的行结束方法。
Windows (DOS) 使用 CR/LF 对，UNIX 仅使用其中一个。ASCII 模式转换 CRLF 对，而 BIN 模式不转换。
罗恩
答案3
你必须明白 FTP 是一个非常古老的协议。当前版本RFC959，可以追溯到 1985 年；早期版本定义为RFC7651980 年，RFC114早在 1971 年，互联网就与现在大不相同。如今，互联网主要由 Windows 和各种类 Unix 系统（Linux、Android、macOS、iOS 等）主导；当时有许多大型机和小型机系统，其中许多系统所做的事情（甚至一些非常基本的事情，例如文件存储方式）与 Windows 和类 Unix 系统所做的事情非常不同——大型机和小型机仍然存在于互联网上，但它们已经从少数群体，甚至在某些时候是多数群体，变成了微不足道的群体。FTP 有很多功能在它最初开发的环境中是有意义的，但今天却不那么有意义了。您所说的“ASCII 模式”就是其中之一；还有许多其他功能，其中大多数很少实现。
“ASCII 模式”是一个误称，尽管它非常常见——FTP 协议标准实际上指的是 TYPE——ASCII (A)、EBCDIC (E)、IMAGE (I) 和 LOCAL BYTE (L n)。严格来说，“模式”一词是指三种传输模式——STREAM (S)、BLOCK (B) 和 COMPRESSED (C)。Windows 和类 Unix 平台上的 FTP 客户端和服务器仅实现 STREAM 模式；BLOCK（以及更罕见的 COMPRESSED）模式用于传输记录型文件在大型机和小型机系统上。虽然 Unix 和 Windows 将文本文件存储为带有行终止符（无论是纯 LF 还是 CRLF）的字节流，但许多大型机或小型机系统将每行存储为平面文件数据库记录，每行都是固定长度（通常选择 80 个字节，用空格填充），或者每行都以长度字节为前缀。块模式传输文件时，记录边界被标记为带外，这在大型机/小型机文件系统中效果非常好。
早在 20 世纪 70 年代和 80 年代，FTP 就被广泛用于在站点之间传输文本文件。纯文本是一种流行的最低公分母格式，可在系统之间轻松传输。FTP 最初的主要用例之一是传输电子邮件；直到后来发明了 SMTP 并从 FTP 接管了这项任务。IBM 大型机和小型计算机非常常见，它们本身就使用 EBCDIC，因此在这种情况下将 ASCII-EBCDIC 转换放入 FTP 客户端/服务器是有意义的。事实上，IBM 大型机操作系统（z/OS、z/VSE、z/TPF）和 IBM 小型机操作系统（IBM i，以前称为 OS/400）的 FTP 客户端和服务器仍然内置了这种 ASCII-EBCDIC 支持。但今天，当普通互联网用户不再与基于 EBCDIC 的大型机或小型机进行任何交互时，在协议中提供 ASCII-EBCDIC 转换支持就不那么重要了。
您还必须意识到，我们并不总是使用 8 位字节。在计算机行业的早期（20 世纪 50 年代、60 年代初），关于字节应该有多大尺寸存在很多争论，6 位字节和 9 位字节都是很常见的选择。直到 20 世纪 60 年代中期推出 IBM System/360 大型机系列后，业界才开始将 8 位字节标准化；但是，在 20 世纪 70 年代甚至 80 年代初，不使用 8 位字节的机器（如 Unisys 大型机和 DEC PDP-10）仍然相当常见。事实上，后者在早期的互联网上得到了广泛使用，这就是为什么 FTP 协议对它们的文件传输需求有特殊支持的原因。“TYPE L n”可用于传输由非 8 位长度的字节组成的文件。通常通过设置“TYPE L 36”在 PDP-10 之间传输文件，以 36 位字（由 6 个 6 位字节、4 个 9 位字节或 5 个 7 位字节和一个填充位组成）传输文件。在 8 位字节机器（Windows、类 Unix，甚至 IBM 大型机和小型机）上运行的 FTP 客户端/服务器通常不实现这一点，但它们通常支持“TYPE L 8”作为“TYPE I”（IMAGE）的同义词。IMAGE 类型基于以 8 位字节发送任意二进制数据，这就是大多数人所知道的“二进制模式”FTP。
TYPE A 和 TYPE E 都支持三种子类型，称为格式 - 非打印（TYPE AN、TYPE EN）、TELNET（TYPE AT、TYPE ET）、ASA（TYPE AA、TYPE EA）。大型机行式打印机有一些原始的格式控制，称为“托架控制“，这实际上声明了回车控制信息在文件中是如何编码的。目前大多数 FTP 客户端/服务器仅支持非打印（TYPE AN、TYPE EN），这声明了缺少回车控制信息。
无论如何，所有这些复杂的功能都存在于 FTP 协议中，但它们在几十年前被发明时就很有意义，其中一些功能至今仍被少数仍在使用大型机或小型计算机的用户使用。Unix/Windows 上的大多数 FTP 客户端/服务器现在默认使用 TYPE I 而不是 TYPE A，这避免了大多数二进制文件被 ASCII 传输破坏的旧问题。如果有人正在编写 FTP 客户端/服务器，完全删除 TYPE A 甚至可能有意义。但仍然有一些罕见的情况，“TYPE A”对某些人来说很有用。假设您想从 IBM 大型机 FTP 服务器下载文本文件；如果您指定“TYPE A”，您将获得 ASCII 格式的文件，如果您指定“TYPE I”，您可能会获得 EBCDIC 格式的文件。现在自己将 EBCDIC 转换为 ASCII 并不是那么难，但如果您不知道如何操作，您只需使用“TYPE A”，FTP 服务器就会为您完成此操作（它甚至可能做得更好，因为它很可能知道正在使用哪个特定的 EBCDIC 代码页，而人们经常通过使用错误的 EBCDIC 代码页来搞砸 EBCDIC 到 ASCII 的转换。）
答案4
ASCII 模式在字符和 EOL 编码真正存在问题的时代曾占有一席之地，但我希望 ftp 客户端今天能够删除或隐藏此选项。如今，系统之间大多只是 EOL 约定混乱，但我发现大多数不错的文本编辑器都不再关心这个问题。因此，为了避免损坏二进制文件（甚至一些基于文本的文件），我建议对所有内容都使用二进制模式。