解壓文件出錯解決方法（invalid compressed data--format violated）

今天要在特殊的狀況下傳文件，用ftp命令傳的，可是每次解壓到時候都報錯，搞得我一臉矇蔽。無可奈何，去百度，才知道傳輸文件的時候是默認按照netascii的格式進行傳輸的，沒有按照二進制文件的形式傳輸。在傳輸以前，使用命令ftp> bin指定傳輸格式能夠解決。
每天這樣踩坑，踩過的坑和走過的路差很少。

FTP中傳輸模式：BIN與ASC的差異

相關驗證性實驗已經作過了。採用ascii模式下載下來的圖片確實沒法正常打開，可是binary的就正常。linux的redhat的 vsftp默認是binary，ascii默認關閉，其他服務器可能要在下載或者上傳前注意檢查設置，若是能夠請設置爲binary方式傳輸，以避免發現數據被更改，形成沒法使用的狀況。

FTP可用多種格式傳輸文件，一般由系統決定，大多數系統(包括UNIX系統)只有兩種模式：文本模式和二進制模式。文本傳輸器使用ASCII字符，並由回車鍵和換行符分開，而二進制不用轉換或格式化就可傳字符，二進制模式比文本模式更快，而且能夠傳輸全部ASCII值，因此係統管理員通常將FTP設置成二進制模式。

　　通常來講： 若是你用錯誤的模式傳輸你的圖片，你將會沒法看到圖片，看到的會是亂碼。 若是你用錯誤模式上傳CGI腳本，那麼就將沒法運行你的腳本，會看到相似Server 500 Error的出錯信息。

　　因此你必須使用正確的模式，圖片和執行文件必須用BINARY模式，CGI腳本和普通HTML文件用ASCII模式上傳.

　　ASCII 和BINARY模式區別：

　　用HTML 和文本編寫的文件必須用ASCII模式上傳，用BINARY模式上傳會破壞文件，致使文件執行出錯。

　　BINARY模式用來傳送可執行文件，壓縮文件，和圖片文件。

　　若是你用ASCII模式傳，會顯示一堆亂碼，你必須從新用BINARY模式傳。

　　對於第二種狀況，是由於有不少ftp服務器和客戶端軟件能自動識別文件類型，並採起相應的傳輸方式。

　　ftp是應用層協議，和具體操做系統無關 .

　　ASCII 模式和BINARY模式的區別是回車換行的處理，binary模式不對數據進行任何處理，asci模式將回車換行轉換爲本機的回車字符，好比Unix下是n,Windows下是rn，Mac下是r

　　ascii模式下會轉換文件

　　不能說是不一樣系統對回車換行解釋不一樣

　　而是不一樣的系統有不一樣的行結束符

　　unix系統下行結束符是一個字節，即十六進制的0A

　　而ms的系統是兩個字節，即十六進制的0D0A

　　因此當你用ascii方式從unix的ftp server下載文件時(不論是二進制或者文本文件)，每檢測到一個字節是0A，就會自動插入一個0D，因此若是你的文件是二進制文件好比可執行文件、壓縮包什麼的，就確定不能用了。若是你的文件就是unix下的文本文件，你用 ascii模式是正確的，要是誤用了binary模式，你在windows上看這個文件是沒有換行的，裏面是一個個的黑方塊。

　　通常來講，咱們最好都用binary方式，這樣能夠保證不出錯。若是有文本格式轉換的問題，即unix格式的文本和dos格式的文本之間的轉換，有不少工具能夠作的，不要在ftp傳輸的時候冒險，尤爲是你若是對這些東西不是很是清楚的話。可使用MIME，把全部的字符，轉換成0~128之間的字符，而後傳送，在接受方再將接收到的字符MIME反向轉換。一般咱們發送郵件，就是使用這樣的字符轉換方式

　　------------------------------------------------------------------

　　補充：文本模式和二進制模式傳文本文件的具體區別能夠經過在linux下使用cat -A 文件名看到二者的區別，固然前提是在windows下上傳的文本爲dos格式，這個能夠用高級的文本編輯器看如ultraedit等。二者的區別是二進制模式上傳的文本比文本模式多一個^M符號，這個就是windows下dos格式的/r回車符號，也就是上面提到的十六進制的0D，在vi下使用全局替換:%s/^M//g¹去掉全部的回車符或者使用dos2unix file進行轉換，這樣保存後或者生成後的文件就和文本模式上傳的文件同樣了。。。

http://blog.sina.com.cn/s/blo...

---

1. M使用Ctrl+V+M而不是直接輸入^M ↩