当我用本地副本覆盖远程文件时，FileZilla 成功传输并覆盖了文件，但我注意到新的远程副本大小比实际的本地副本小几 KB。为什么会发生这种情况？
答案1
也许这与“大小”和“磁盘大小”之间的差异有关：
大小是文件的实际大小（以字节为单位）。
磁盘上的大小是实际占用的磁盘空间量。
因此，如果您的扇区大小为 512 字节，而您的文件实际上为 513 字节，则磁盘上的大小将为 1024 字节，因为它占用了两个扇区。
由于不同的操作系统或磁盘可能使用不同的扇区大小，如果报告的大小是“磁盘上的大小”，则大小会有所不同。
答案2
我认为 meder 指的是 Linux 和 Windows 之间的不同换行符。*NIX 仅使用一个字符 (ASCII 10) 来换行，而 Windows 则使用两个字符 (ASCII 13 + ACII 10)。
FTP 程序通常具有“文本传输”或“ASCII 传输”模式（与“二进制传输”模式相比），如果需要，可以自动转换这些字符。
因此，如果您的文件有 1000 行，则它在 Win 上比在 *NIX 系统上大 1kB。
在Filezilla中您可以通过菜单栏中的Transfer->来确定传输模式。Transfer Mode
我能想到的可能还有其他原因，尽管这种可能性极小。如果计算千字节，则可以设置 1kB = 1024 字节（SI 单位），也可以设置 1KiB = 1000 字节（IEC 单位，请注意“Ki”而不是“k”）。这也会导致大小不同，但在所有情况下，我都知道连接两端的大小计算结果相同。
答案3
如果服务器是不同的操作系统，那么这就是原因（例如服务器 = Linux，本地 = Windows）。或者可能是由于您的操作或文本编辑器（不同编辑器对空格的处理方式不同）导致某些字节被删除。这将是一个不错的猜测，而无需真正看到它们之间的差异。
答案4
我在将文件从类unix DOMAIN/OS系统复制到Windows时注意到了这种差异，但由于我总是使用二进制传输（即使使用文本文件）我不得不到别处寻找解释。
我注意到，在我的系统上，原始文件大小表示为缓冲区的整数倍：32kB 的倍数，并且在传输文件时，仅计算文件的实际字节数。
但是我使用了一个奇怪的、古老的系统，我认为 meder 的解释更有可能是正确的。