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

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

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

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

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

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

      FTP上傳工具：FlashFXP

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

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

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