通过 FTP 的 Apple DMG 文件为何损坏？
我正在尝试通过 FTP 传输一些苹果 DMG 文件，如果我们通过 Safari 或 IE 手动执行此操作，它最终会完好无损地到达目的地。 但是，如果我使用我们已经在 zip 和 exe 方面取得巨大成功的免费软件 FTP 客户端，或者如果我使用我完成的 Powershell 脚本（改编自另一个 stackover flow 的问题答案），那么我会丢失大约 1/2 Mb 10.5 Mb 文件且 dmg 已损坏。 有人知道可能出什么问题吗？ 我可以做些什么来预防它？ 到目前为止，我所尝试的只是在发送之前对 dmg 进行 gzip 压缩，但没有任何效果。 再说一次，除了伤害以外的任何东西都可以正常传输。
仅供参考，我正在使用二进制模式传输，所以不是这样..thx
I am trying to FTP some apple DMG files, if we do it by hand through Safari or IE it ends up at the destination just fine and uncorrupted. However, if I use a freeware FTP client that we had been using with great success for zip's and exe's or if I use a Powershell script I finished off (adapted from another stackover flow's question's answer) then I lose about a 1/2 Mb on a 10.5 Mb file and the dmg is corrupted. Does anyone have anyclues what could be going wrong? Things I could do to prevent it? So far all I have tried is gzipping the dmg before sending and that accomplished nothing. Again, anything but a dmg gets transmitted just fine.
FYI I am using binary mode transfers, so that is not it..thx though
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
看来您的客户端将 dmg 文件视为文本文件。
在 ftp 客户端中设置二进制传输模式，它将按原样进行 ftp。
我一直认为 ftp 中的 ascii 传输模式简直就是愚蠢的。 它造成的麻烦比它值得的还要多。
Seems like your client treats dmg file as text file.
set Binary transfer mode in your ftp client and it will ftp it as is.
I always thought that ascii transfer mode in ftp is just plain stupid. It causes more trouble then it is worth.
您确定除 DMG 之外的所有内容都已正确转移吗？ 听起来像是传输编码的问题。 FTP 支持二进制和 ASCII 传输类型，这主要是由于历史包袱。 在过去，当带宽比较匮乏时，保留高位（ASCII 不使用）是一个很好的节省时间的方法。 然而，如果你有任何设置了位的字节，ASCII 传输模式将丢失它们 - 因此是“二进制”模式，它不会截断任何内容。
通常，切换传输模式的命令是“bin”或“ascii”。
Are you sure everything except a DMG gets transferred correctly? It sounds like a problem with the transfer encoding. FTP supports both binary and ASCII transfer types, mainly due to historical baggage. In ye old days, when bandwidth was scarer, leaving off the high bit (which ASCII doesn't use) was a good time saver. However, if you have any bytes with the bit set, ASCII transfer mode will lose them - hence "binary" mode, which truncates nothing.
Typically, the command to switch transfer modes is "bin" or "ascii".
就这样大家都知道了。 我使用的客户端肯定与我的 PowerShell 脚本有完全相同的问题。 我使用 StreamReader 来获取传输字节，它假设编码不正确。 我切换到了 BinaryReader，但它不支持，现在它可以工作了。
Just so everyone knows. It must have been the client I was using had the exact same issue as my PowerShell script. I was using StreamReader to get the bytes for transfer and it was assuming an encoding which was not correct. I switched to a BinaryReader which does not, and it now works.