我有一个 100kb 的 PDF 文件，我们将其称为Test.pdf。我使用 FTP 将其上传Test.pdf到我的网站上。但是，PDF 在到达网站时已损坏。因此，作为诊断测试，我运行了：
$md5sum Test.pdf
[md5sum a]
$[ftp上传Test.pdf]
$[ftp下载Test.pdf]
$md5sum Test.pdf
[md5sum b]
所以在上传过程中的某个时刻，文件被损坏了！这让我很困惑。我从未遇到过其他文件类型的问题。我也尝试使用我的网站提供商的手动上传客户端，但遇到了同样的问题。这是怎么回事？
答案1
你已经自己回答了，但我认为我可以做得更好Apparently certain types of files need to be uploaded in binary。
首先介绍一些背景信息：
1：计算机、位和字节。
计算机中信息的最小部分是位。一个位要么是真要么是假，）或 1，高压或接地，...
位被分成小组。几乎所有现代计算机都是以 8 个为一组。我们称之为字节。
一组 8 位/1 字节，可以有 256 个不同的值，从
00000000 开始，表示
0，00000001 表示 1，00000010
表示 2，00000011
表示 3（2+1 均设置），
00000100 表示 4
...
11111111 表示 255
2：ASCII。
ASCII是一组 128 个字符，编号为 0 到 127。您只需要 7 位即可。在过去，这就是您进行通信所需的全部内容。只需西方字母表中的常规 26 个字母、数字 0 到 9 和一些特殊代码（例如 7）：按铃或发出哔哔声。
如今我们定义了更多的字符。我们使用UTF-16和unicode，允许中文、日文、从右到左的语言等等。在过去我们还没有在公共场所支持这一点。
3：最后：带宽现在/曾经很昂贵。
我们把一个位的所有 8 位发送到目的地，而你知道你只需要其中的 7 位来表示文本？如果你在聪明的方法您可以节省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”命令，或者勾选“bin”选项以使用 GUI。
我希望这能回答“这里发生了什么事？”:)
答案2
问题在于我使用Test.pdf的是ascii mode，而不是binary mode。显然，某些类型的文件（例如 .pdf、.zip）需要以二进制模式上传，而不是 ascii 模式。（这可能与文件的系统级表示有关。）这个问题很容易解决，只需使用 ftp 命令将上传模式更改为二进制即可，binary如下所示：
$ ftp [我的服务器]
ftp>二进制
ftp>put Test.pdf
这里是一个很有帮助的参考。