在博文之前，先介紹一下文本模式和二進制模式的差別，兩者主要是在回車換行的處理上，不同系統對回車換行的處理不一致。

      CR：  Carriage Return,   0X0D,   “\r”
      LF：  Line Feed,         0X0A,   “\n”

      Dos和Windows采用回車+換行(CR+LG)表示下一行
      UNIX采用換行符 (LF)表示下一行
      MAC機采用回車符(CR)表示下一行

      最近一直在開發湖北現場的割接工具，工具的執行流程貫穿到系統多個模塊。和同事一起配合，同事開發的工具從現場的系統A中將數據導出到文本，然后由我的工具來將這些文本導入到現場的項目B中，也就是我們常說的數據割接，原因是項目升級，運營商已經商用的數據需要在新平臺上繼續使用。

      開發環境：SUSE Linux + Oracle

      測試環境：HP + Oracle

      FTP上傳工具：FlashFXP

      注：在windows下編寫完程序后FTP至SUSE或HP下進行調試和測試

      開發自測完，代碼提交CC，書寫操作手冊，自測完畢工具打包，程序的整個流程都按照需求描述成功走完，并能順利將各個流程連貫起來。以為這次應該是沒問題的，拿到現場應該是能順利進行使用的，但沒預料，還沒發到現場，在測試部測試這一環節就出現了問題，本定于昨天早上8：30發到現場，但由于測試沒有通過，頂著現場和領導們的壓力，拉上我師兄，昨天一整天陪我在測試部整代碼，反復調試和測試。終于在下午5點鐘找到問題的根源：

       windows下的文本文件是的換行處理是采用回車+換行(0D0A)的方式，linux下的文本文件的換行處理是采用換行(0A)的方式。在windows本地通過二進制方式從windows xp上傳FTP到suse liunx后，windows下的回車換行符"\r\n"到了suse linux下并沒有變為linux下的換行符"\n"，也就是文本文件以二進制FTP到liunx下時，在文本記錄中每行末尾追加了"\r\n"，而通常如果以ASCII文本方式上傳到suse linux后，文本每行的"\r"在suse會過濾掉的。于是部署在suse linux上的shell腳本在調用sqlldr函數將上傳后的文本導入到系統B中，sqlldr總是提示字段值過長的異常信息，顯然文本數據沒有導入成功,因為oracle表中的字段定義為char(14)，而上傳后的文本文件的最后一個字段本來是14位，但加了"\r\n"后就變為16位。于是針對這個文本字段sqlldr到oracle時就會提示字段過長而插入不成功了。問題定位后，轉而將文件以ASCII方式FTP至服務器上后，程序運行完全正常,問題解決。
      同時測試發現，通過jsp流從windows上傳文本文件到suse linux上時，文本文件中的"\r\n"到suse上后還是存在"\r\n"，也沒有轉換為"\n"。