FTP传输时为何要使用binary方式

在传输文件时，模式有以下

binary：切换为二进制传输模式（用于传输图片、视频、压缩包等非文本文件，强烈建议上传下载前先执行此命令）。

ascii：切换为文本传输模式（用于传输 .txt、.html 等纯文本，防止换行符混乱）

但是现在都建议直接用binary，为啥？

这是一个非常经典且重要的问题。简单来说：如果不使用 binary（二进制）模式，你的文件很可能会损坏，变得无法使用。

要理解这一点，需要先分清 FTP 的两种传输本质：

    ASCII（文本）模式：FTP 会“翻译”文件内容。它会根据操作系统的不同，自动转换文件中的换行符（行尾符）。

    Binary（二进制）模式：FTP “原封不动”地逐字节复制文件，不做任何修改。

以下是强烈建议使用 binary 的具体原因：

1. 非文本文件会直接“报废”

如果你用 ASCII 模式传输图片（.jpg）、压缩包（.zip）、可执行程序（.exe）、视频（.mp4）或文档（.pdf），FTP 客户端会误以为它们是文本，并尝试查找并修改其中的“换行符”。

因为图片/压缩包的二进制数据中，随机包含了和换行符代码相同的字节（如 0x0A 或 0x0D）。

当 FTP 把这些字节“翻译”掉后，文件的内部结构就被破坏了。

结果：你下载的图片只能打开一半，压缩包解压报错“CRC校验失败”，程序无法运行。

2. 即使是纯文本，跨系统也会出乱子（历史原因）

即使在传输 .txt 文件时，ASCII 模式看似有用，但在现代环境下也很容易出问题：

Windows 的换行符是 CRLF（回车+换行，即 \r\n）。

Linux/Unix 的换行符是 LF（换行，即 \n）。

Mac（早期） 的换行符是 CR（回车，即 \r）。

当你用 ASCII 模式从 Windows 上传文本到 Linux 服务器时：FTP 会把 Windows 的 CRLF 转为 Linux 的 LF。这本来没问题，但当你再用 Binary 模式下载回来（或者反过来操作），换行符就会错乱，导致配置文件报错、Shell 脚本无法执行（出现 ^M 字符）或日志文件挤成一行。
3. 为什么 binary 是“万能解药”？

Binary 模式是“机械式的拷贝”：它把文件当作一串纯粹的 0 和 1，不做任何字符集或换行符的转换。

上传什么，下载下来就是什么，保证了文件的 MD5 哈希值完全一致。

对于现代文本文件（如 JSON、XML、程序代码），绝大多数编辑器（如 VSCode、Notepad++）都支持自动识别并显示各种换行符，所以即使传输纯文本，用 Binary 模式也通常不会出错。

现代实践的共识

正因为 ASCII 模式带来的混乱远大于便利，现在的行业最佳实践是：

永远在连接 FTP 后，第一时间输入 binary 命令。
除非你明确知道自己在传输纯文本，且目标服务器是老旧的大型机（Mainframe），否则一律用 Binary。

补充：SFTP 为什么不需要这个命令？

如果你现在使用 SFTP（SSH 文件传输协议），你会发现根本没有 binary 或 ascii 命令。因为 SFTP 在设计之初就抛弃了这种“翻译”机制，默认且强制使用二进制传输，保证了所有文件的完整性。这也是 SFTP 取代 FTP 的重要原因之一。