我有一个 100kb 的 PDF 文件，我们称之为Test.pdf. 我正在使用 FTP 放在Test.pdf我的网站上。但是，PDF 到达网站时已损坏。因此，作为诊断测试，我运行了：
$ md5sum Test.pdf
[md5sum a]
$ [ftp 上传Test.pdf]
$ [ftp 下载Test.pdf]
$ md5sum Test.pdf
[md5sum b]
因此，在上传过程中的某个时刻，文件已损坏！这让我很困惑。我从来没有遇到过任何其他文件类型的问题。我也尝试使用我的网站提供商的手动上传客户端，但遇到了同样的问题。这里发生了什么？
你已经自我回答了，但我认为我可以做得比Apparently certain types of files need to be uploaded in binary.
首先是一些小的背景信息：
计算机中信息的最小部分是一点。位为真或假，) 或 1，高压或接地，...
这些位被分组为小集合。适用于几乎所有八人一组的现代计算机。我们称其为字节。
一组 8 位/1 字节，可以有 256 个不同的值，从
00000000开始表示 0
00000001 表示 1
00000010 表示 2
00000011 表示 3（2+1 都设置了）
00000100 表示 4
... 1511 表示 12 ...
1111
ASCII是一组 128 个字符，编号为 0 到 127。为此您只需要 7 位。在过去，这就是您进行交流所需的全部内容。只是西方字母表中的常规 26 个字母、数字 0 到 9 和一些特殊的代码，如 7：按响铃或哔哔声。
这些天我们定义了更多的字符。我们使用UTF-16和 unicode，允许中文、日文、从右到左的语言等。在过去，我们还没有在常见的地方对此提供支持。
当您知道只需要 7 个位来表示文本时，我们将所有 8 个位发送到目的地？如果您以聪明的方式做事，您可以节省 1/8 的带宽。
这在今天听起来可能不太好用，但在欧洲和美国连接 1200 波特拨入线路（大约 0.1KB/秒！）的时代，每一点都有帮助。
所以假设我想写“你好”。
我可以在 ASCII 表中查找它，我会发现您的计算机会将其存储在包含以下内容的四个字节中：
H e l l o
01001000 01100101 01101100 01101100 01101111
请注意，所有字母的第一位都是 0。我不妨记住这部分：
H e l l o
1001000 1100101 1101100 1101100 1101111
第一个示例有 32 位（4 个字节，每个 8 位信息）。
第二个例子只有 28 位。它更有效率。
这使其成为传输文本的首选方法。但是，省略第一位会破坏任何不是文本的内容。因此，FTP 协议被设计为具有两个选项：ASCII 模式（对文本有效）和 BINary 模式（按原样传输）。
您以 ASCII 模式传输二进制文件（例如 PDF），它不会传输所有信息。因此，生成的文件到达目的地时已损坏
要传输纯旧文本以外的任何内容，请在 FTP 提示符下使用“bin”命令或勾选使用 GUI 的“bin”选项。
我希望这能回答“这里发生了什么？” :)