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

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

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

      最近一直在開發(fā)湖北現(xiàn)場的割接工具，工具的執(zhí)行流程貫穿到系統(tǒng)多個(gè)模塊。和同事一起配合，同事開發(fā)的工具從現(xiàn)場的系統(tǒng)A中將數(shù)據(jù)導(dǎo)出到文本，然后由我的工具來將這些文本導(dǎo)入到現(xiàn)場的項(xiàng)目B中，也就是我們常說的數(shù)據(jù)割接，原因是項(xiàng)目升級，運(yùn)營商已經(jīng)商用的數(shù)據(jù)需要在新平臺上繼續(xù)使用。

      開發(fā)環(huán)境：SUSE Linux + Oracle

      測試環(huán)境：HP + Oracle

      FTP上傳工具：FlashFXP

      注：在windows下編寫完程序后FTP至SUSE或HP下進(jìn)行調(diào)試和測試

      開發(fā)自測完，代碼提交CC，書寫操作手冊，自測完畢工具打包，程序的整個(gè)流程都按照需求描述成功走完，并能順利將各個(gè)流程連貫起來。以為這次應(yīng)該是沒問題的，拿到現(xiàn)場應(yīng)該是能順利進(jìn)行使用的，但沒預(yù)料，還沒發(fā)到現(xiàn)場，在測試部測試這一環(huán)節(jié)就出現(xiàn)了問題，本定于昨天早上8：30發(fā)到現(xiàn)場，但由于測試沒有通過，頂著現(xiàn)場和領(lǐng)導(dǎo)們的壓力，拉上我?guī)熜郑蛱煲徽炫阄以跍y試部整代碼，反復(fù)調(diào)試和測試。終于在下午5點(diǎn)鐘找到問題的根源：

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