我想我理解常规 FTP 传输中 ASCII 模式和二进制模式之间的区别 - 在二进制模式下，文件被精确复制，而在 ASCII 模式下，客户端可以修改行结尾(从 Windows -> UNIX 中删除回车符)或以另一个方向添加)。然而，我认为SFTP协议(protocol)只支持二进制模式风格的传输；源文件不会被修改。
但是，当使用 JSch 库将文件从 Windows 复制到 UNIX 时，Windows 样式的行结尾会被删除。这是有问题的，因为这些文件是由其他人使用各种方法在 Windows 计算机上检索的，并且我不能保证他们的客户端会在每个换行符之前重新添加回车符。
Properties properties = new Properties();
properties.setProperty("StrictHostKeyChecking", "no");
Session session = jsch.getSession(UserName, Address, Port);
session.setPassword(Password);
session.setConfig(properties);
session.connect();
ChannelSftp channel = (ChannelSftp)session.openChannel("sftp");
channel.connect();
channel.
channel.cd(SCPDir);
channel.put(new ByteArrayInputStream(WindowsStyleString.getBytes()), FileName);
channel.disconnect();
session.disconnect();
我可以做些什么来确保 JSch 准确地传输文件吗？令人沮丧的是它缺乏文档，所以我不确定是否有它的一些参数或者我可以指定一些额外的 SSH 属性来确保逐字传输。当 ASCII 模式样式修改不是 SFTP 标准的一部分时，为什么会首先发生这种情况？
最佳答案
又一个误导案例；对于所有这些令人不满意的问题，我深表歉意。
事实证明，在我可以调试的 Windows 上，Java 无处不在的 toString 返回带有回车符和换行符 (\r\n) 的行结尾。在 Linux 生产服务器上，toString 仅返回\n。然而，我对这些 toString 对象的每次使用，无论是通过 FTP 上传(即使主机也是 Linux 机器)、通过电子邮件发送，还是在 SQL 查询中使用，要么自动附加\r，要么不需要它。但 SFTP 没有。
所以我想这里的教训是 toString 可能返回一个适合平台的行结束格式，ASCII 模式下的 org.apache.commons.net.ftp.FTPClient 会在\n 之前添加\r，即使 FTP 服务器是托管在 Linux 上(或者该服务器可能伪装成 Windows)，并且电子邮件和 SQL 并不特别关心它们具有哪些行结尾。
关于java - JSch sftp 传输剥离 Windows 行结尾，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4038902/