有意思，使用FtpClient上傳文件，上傳後的文件老是會莫名奇妙的變大

今天在寫代碼而後調試的時候發現了這個問題。

代碼主要是從手機上選擇照片上傳到服務端，具體實現邏輯中，服務端會先將上傳請求中的文件數據放到服務端機器的緩存目錄，而後再從緩存目錄挪到另一臺FTP服務其中。

測試的時候發現，將在Android機器上選擇並上傳到FTP服務器的文件再從FTP服務器上下載下來，加上原來的擴展名（在強迫證的驅使下，我統一了上到FTP服務器的文件的命名，所有用數據庫生成的惟一主鍵，前綴年月日，一共16位數字，問題就出在這兒），在windows上嘗試用照片查看器打開，會提示文件已損壞。而在iOS機器上選擇並上傳到FTP服務器上的相同一張照片文件（jpg）格式的，從新從FTP服務器上面下載下來，儘管能用windows上的照片查看器打開，但照片顯示的一團糟，開始感受很詭異。

上網查了下使用commons-net-2.0.jar包中的FtpClient類上傳文件變大的問題，廣泛的答案是要加上以下一行代碼：

ftpClient.setFileType(FTPClient.BINARY_FILE_TYPE);

並無什麼用。由於原來這段代碼就加上了啊。

爲這個問題折騰了一天啊！！！

最後，多虧了二進制文件對比工具的幫忙，發如今16進制視圖下面，源文件跟FTP上面down下來的文件相比，後者將前者不少空位替換成了「0D」（我百度了一下，0D貌似表明的是回車符號），這樣就解釋了爲何上傳的文件打開會出問題，並且空位佔的空間比0D符號要小得多，這種替換會致使上傳的文件越大，源文件跟上傳以後的文件大小差別越大。

還有就是，一樣一張照片，從Android上傳的再下載下來打開會報錯，但從iOS上傳的再下載下來確仍然能夠打開，但現實亂碼（色塊）。我一樣將服務端緩存目錄中文件同FTP上下載下來的問價作而十六進制對比，仍是隻是空位變成了0D符。通過一番折騰，我發現同一張照片文件，iOS機器上的比Android機器上的要大了一些，他們都是從Window上copy過去的，我猜想多是複製到iOS機器上，iOS系統會自動對圖片文件進行優化，這種優化就會致使文件變大一些，好處就是上面提到的空位被0D符號替換並不會形成文件不能打開的問題，具體的原理我就不清楚了。

那麼空位被0D替換的問題怎麼解決呢？通過n屢次嘗試，發現只要加上後綴名就行了，也就是說不要將沒有後綴名的文件從本機上傳到FTP服務器上。應用程序的服務端開在我本機，windows系統，而FTP服務器搭在一臺Linux服務器上，興許是操做系統的差別，致使了二進制文件中某些特殊符號的自動被替換。

而爲何加上後綴名，就不會發生這種替換，並不清楚，我很懶，還但願能有高手幫忙解釋一下。

最後由此聯想到之前看過的一篇介紹回車和換行歷史的文章《回車和換行》，以爲興許跟這個有關，放到這裏備忘。

2016-08-25 補充

        今天瞭解了一種解決辦法，那就是先以帶後綴的文件名的形式上傳到FTP服務器上，而後調用FtpClient的API對已經上傳到FTP服務器上面的文件重命名爲文件服務器統一的命名格式，這樣再下載下來的文件也不會出問題，通過嘗試有效。

2016-10-17 補充

        今天發現，貌似這個跟操做系統有關係，老的測試環境（RedHat）上面就算使用了 8 月 25 號的方法也會出現圖片文件中字節位被替換成 ‘0D’ 的現象，但是生產上面（CentOS）是沒有問題的。