FTP Ascii 传输 - 客户端或服务器是否去除回车符？
我在使用 FileZilla 3 将 ascii 文件从 Windows 7 计算机传输到 Unix Solaris 服务器时遇到问题。问题是文本文件最终在 Unix 计算机上带有 CR+LF 字符，而不仅仅是 LF 字符，导致奇怪的结果每行末尾的字符。
我理解这个问题 - CR 字符应该被删除。我的问题相当具体：客户端或服务器是否应该删除这个字符？
这个 fileZilla 页面 表示，ascii 文件总是通过以下方式传输： CR+LF，由客户端来确保发生这种情况。然后由服务器将其转换为主机的本机格式（在本例中为 Unix），因此它应该去除 CR 字符。
但是，我使用 WS_FTP 时没有遇到此问题，我很好奇 FileZilla 页面是否完全不正确，或者 WS_FTP 是否违反了 FTP 的 RFC 协议并实际传输没有 CR 字符的文件。也有可能 FileZilla 是正确的，问题出在 Unix 机器上的 FTP 服务器上。
再说一遍：是否由 FTP 客户端或服务器将 ascii 文件转换为正确的换行格式？
I have a problem transferring ascii files from a Windows 7 machine to a Unix Solaris server using FileZilla 3. The problem is that the text files end up on the Unix machine with CR+LF characters, instead of just the LF character, resulting in weird characters at the end of each line.
I understand the problem - the CR character should be stripped out. My questions is rather specific: Is the client or server supposed to strip this character?
This fileZilla page says the deal is that ascii files are always transferred with CR+LF, and it is up to the client to make sure that happens. It is then up to the server to convert it to the native format of the host machine, in this case Unix, so it should strip the CR characters.
However, I did not have this problem using WS_FTP, and I am curious if the FileZilla page is simply incorrect, or if WS_FTP was violating the RFC agreement for FTP and actually transferring the file without the CR character. It's also possible FileZilla is correct, and the problem is with the FTP server on the Unix machine.
Once again: Is it up to the FTP client or server to convert ascii files to the correct line-break format?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
来自 RFC：
该协议不指定 FTP 会话结束时在客户端或服务器上应存储的内容，仅指定会话应是什么样子。
From the RFC:
The protocol does not specify what should be stored at the end of an FTP session, on either the client or the server, only what the session should look like.