FTP设计之初为何要自动转换文件中的换行符

这个问题问到了根子上！捕捉到了FTP设计中最核心的一个"历史遗留"矛盾。

FTP之所以要设计"自动转换换行符"这个功能，根本原因在于：FTP诞生于1971年，那时候还没有"个人电脑"和"互联网"，只有各种互不兼容的"大型主机系统"。

让我把这个看似"多此一举"的设计缘由拆解开：

1. 历史根源：不同的系统，不同的"回车"定义

在计算机早期（1960s-1980s），不同厂商的电脑对"换行"的物理定义完全不一样：

操作系统	换行符（十六进制）	英文缩写
Unix / Linux	0x0A	LF（换行）
Windows / DOS	0x0D 0x0A	CRLF（回车+换行）
经典 Mac OS（版本9以前）	0x0D	CR（回车）
IBM 大型机（Mainframe）	0x15	NL（新行，完全不同）

FTP的设计初衷：让一台UNIX服务器上的文本文件，传送到IBM大型机上，打开后依然能正确换行显示，而不是打印出一堆乱码或挤在一起。

2. 当时的"文本文件"占据绝对主导

在1970s-1980s：

    没有图片、视频、压缩包（带宽太窄，存不起）。

    几乎所有的文件都是纯文本（源代码、论文、邮件、配置文件）。

    FTP的主要用途就是传输这些人类可读的字符。

因此，FTP的设计者默认认为：用户传输的就是"文本"。于是他们想当然地加了"翻译器"——让不同系统的文本能互相看懂。

3. 为什么这个设计现在成了"鸡肋"甚至"毒药"？

个人电脑崛起后：我们传的不再只是文字，而是海量的二进制文件（exe、jpg、zip）。

FTP协议没变：它依然默认"先翻译一下"。

结果：当它遇到图片里的 0x0A 字节，误以为"这是换行符"，强行篡改，导致文件损坏。

4. 更深层的矛盾：协议为什么不在设计时就区分类型？

FTP协议规范（RFC 959）里其实定义了 TYPE 命令：

TYPE A（ASCII）：进行换行符转译。

TYPE I（IMAGE / Binary）：不转译。

问题是：FTP把"区分类型"的责任甩给了用户。

设计者认为："用户传输前应该知道自己传的是文本还是非文本，并手动敲命令切换。"

现实是：普通用户根本分不清 0x0A 和 0x0D，也懒得记，于是就出现了"图片传坏了还莫名其妙"的悲剧。

5. 打个形象的比喻

这就像一个翻译官：

    ASCII模式：这位翻译官负责把"美式英语"翻译成"英式英语"（换行符转换）。但如果你递给他一张中文书法作品（图片），他不懂中文，强行按照"英语语法"去修改笔画，结果把字改成了四不像。

    Binary模式：就是"快递员"，你给什么包裹，他原封不动地送到，绝不拆开修改。

总结：FTP为何这样设计？

初心是好的：为了解决不同系统间纯文本的显示兼容问题。

败给了时代：它诞生在"文件=文本"的年代，没预料到未来会有海量的多媒体二进制文件。

设计失误：把"文件类型判断"这种理应自动化的事，变成了一个需要用户手动开关的按钮。