2010-10-28 59 views
2

我想我理解在常規FTP傳輸的ASCII模式和二進制模式之間的區別 - 在二進制模式下,文件被完全複製,並且在ASCII模式下,客戶端可以修改行結束符(剝離從Windows返回 - > UNIX或將其添加到其他方向)。不過,我認爲SFTP協議只支持二進制模式風格的傳輸;源文件不會被修改。JSch sftp傳輸剝離Windows行結束

但是,當使用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標準的一部分時?

+0

我感覺這個問題可能與我在這裏問的問題有關:http://superuser.com/questions/234527/how-to-fix-windows-new-line-character-on-sftp-synchronization -in-蝕-PDT。除了在我的情況下增加CR而不是剝離! :( – denormalizer 2011-06-17 00:31:19

回答

1

SFTP僅支持二進制模式,直到版本4和版本4及更高版本(5,6)二進制模式仍然是默認模式,儘管ASCII模式也可用。無論JSh如何處理你的文件都是自己的主動。也許它本身剝離CR,或者服務器可以這樣做,我不能肯定地說沒有看到Jsh或服務器公開的任何類型的日誌。

+0

我掩蓋了JSch代碼,並沒有看到任何修改源字符串的東西,但我實際上並未實現它直到現在。並且果然......它沒有取代任何東西! 我開始感覺像一個糟糕的堆棧交換器,因爲這是我第三次回答我自己的問題。我沒有意識到toString在UNIX系統上返回一個沒有\ r的字符串,並且恰好如此我用所有其他模塊(FTP,SQL,EMAIL)已經可以自動添加,或並不需要它,所以我不認爲直接檢查源字符串,因爲它在所有其他形式合作。 – 2010-10-28 16:35:03

+0

我是否理解正確,你在調試器中看到了字符串,它讓你感到困惑? – 2010-10-28 17:32:43

1

誤導的另一種情況;我對所有這些不滿意的問題表示歉意。

事實證明,在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並不特別關心他們擁有哪些行結尾。

+1

有點晚,但是如果你談到'toString()',那麼你也應該說你正在講的是哪一個類。默認的'Object.toString )'結果不包含任何內容行結束。 – 2011-06-01 13:34:25