隨筆檔案

??????前兩天剛發(fā)了一篇關(guān)于Resin3下Spring的啟動(dòng)問題的文章（在Resin3下配置SpringSide的HelloWorld示例程序碰到的問題和解決方法），我把持久層框架換成iBATIS后又出現(xiàn)了解析SqlMap文件的新問題，并且花了很長(zhǎng)時(shí)間才找到解決方法（也可能是我了解的太少，還要加強(qiáng)修煉，呵呵），不管怎么樣還是寫出來和大家分享，希望對(duì)大家有所幫助。

??????Struts+Spring+Hibernate是目前J2EE企業(yè)級(jí)開發(fā)絕對(duì)Killer級(jí)的框架組合，相當(dāng)輕量，優(yōu)雅，但毫不影響它的強(qiáng)大。雖然因?yàn)楝F(xiàn)在各種表示層框架發(fā)展異常活躍，Struts受到了前所未有的挑戰(zhàn)和沖擊，但是就目前使用面而言這三種框架的組合是JAVA程序員不得不深入的經(jīng)典。他們相關(guān)的資料也比較多，實(shí)際運(yùn)用中也最成熟。但是諸如JSF,iBATIS等后起之秀（說他們后起并不代表他們的歷史，只是流行程度）也漸漸的占據(jù)自己的一席之地成為某些場(chǎng)合下開發(fā)的不二選擇。在web服務(wù)器方面也是一樣，除了Tomcat我們還有了更多好的選擇（Resin ，Jetty等）。雖然各種框架都聲稱自己可以無縫集成各種其他框架，不需要任何修改運(yùn)行在各種服務(wù)器上面，但是我在我最近的一些經(jīng)驗(yàn)發(fā)現(xiàn)把一些平時(shí)比較少組合在一起的東西放在一起后確實(shí)存在很多想不到的意外，排除起來也頗費(fèi)一些周折。這可能也是開源和商業(yè)的差距，不完善的文檔，沒有足夠覆蓋面和嚴(yán)格的測(cè)試等，不過我們都要以一個(gè)寬容的態(tài)度對(duì)待開源，因?yàn)殚_源需要我們每個(gè)人的參與和貢獻(xiàn)，從而真正達(dá)到Richard. M. Stallman心中的軟件自由。

??????我會(huì)不斷的把在各種非常用的組合使用中遇到的的問題貼出來與大家分享，總有人會(huì)需要，呵呵。

??????言歸正傳，今天的主題是在Resin3下使用Spring和iBATIS的組合開發(fā)時(shí)碰到的SqlMap文件解析問題，和開頭提到的我的另一篇文章一樣，也是一個(gè)xml配置文件的解析問題。使用的仍然是SpringSide的HelloWorld示例，這里順便說個(gè)題外話SpringSide是一個(gè)我比較欣賞和推薦的國(guó)人自己打造的企業(yè)級(jí)快速開發(fā)框架，特別是他的wiki真是一個(gè)非常好的各種相關(guān)技術(shù)的學(xué)習(xí)資料，但是他發(fā)布的示例中含有不少的錯(cuò)誤，特別是“非主流的”（非Tomcat下，iBATIS等）模式下有很多問題，希望SpringSide的大俠們能夠更加完善。我是你們忠實(shí)的支持者。

??????上篇文章? 中提到了Resin3下使用Spring必須要更換默認(rèn)的xml解析器，換成xerces后就可以正常啟動(dòng)了，然后把持久層框架由Hibernate換為iBATIS后又出現(xiàn)了新的問題，啟動(dòng)時(shí)一切正常，Spring和Struts的初始化都沒有問題，但是當(dāng)?shù)谝淮涡枰B接數(shù)據(jù)庫(kù)時(shí)就出現(xiàn)了問題，因?yàn)檫@個(gè)時(shí)候需要解析SqlMap文件來提供對(duì)應(yīng)的Sql語句進(jìn)行查詢RDB，從異常信息來判斷問題出在文件解析的時(shí)候，錯(cuò)誤信息如下（因?yàn)楹荛L(zhǎng)，所以只貼了最底層的異常）：



??????異常提示是Content is not allowed in prolog.意思就是說文件開頭的時(shí)候有問題。。。我E文不好不能解釋的“信，雅，達(dá)”，見諒，呵呵。還是跟我為了Spring而換上的xerces有關(guān)。。。狂暈，google了一番發(fā)現(xiàn)是一個(gè)叫BOM的東西搞的鬼，而xerces確實(shí)有BOM的問題，在Apache的論壇里看到一個(gè)帖子也提到xerces的BOM問題（可是借助靈格斯 一個(gè)單詞一個(gè)單詞翻譯的看的。。。，順便吐血推薦“靈格斯”，一款比金山詞霸好用X倍速度快Y倍資源占用少Z倍的免費(fèi)軟件，注意是無插件，無廣告，完全免費(fèi)?。。〗鹕浆F(xiàn)在為了反D版，所有裝了D版金山的XP老是無緣無故死機(jī)，大家應(yīng)該都很郁悶吧。被我推薦用靈格斯的人都說好，群眾的眼睛是雪亮的啊。支持面向個(gè)人用戶的軟件免費(fèi)！靠好質(zhì)量好服務(wù)賺錢才是王道?。。。靥钦f換掉xerces用其他解析器，可是我不能換，換了Spring還指望它呢，我也不知道換成什么比它更好。。。，還有的說給xerces的如果是stream就可以接受BOM，如果是reader就不行（我默認(rèn)大家都對(duì)JAVA的IO有一定了解能夠理解stream和reader?。y道我跑去把iBATIS里的源代碼改了，然后重新編譯？？？這樣也不好吧，總有簡(jiǎn)單點(diǎn)的方式解決吧。

??????于是繼續(xù)google，隨著對(duì)BOM進(jìn)一步的了解發(fā)現(xiàn)把SqlMap文件里的BOM給刪除調(diào)應(yīng)該是最快最方便的方式，因?yàn)锽OM在UTF-8里面并不起什么作用，本來是可有可無的。下面先讓大家對(duì)BOM有個(gè)大概的認(rèn)識(shí)（細(xì)節(jié)可以參考官方網(wǎng)站?），然后告訴大家怎么樣快捷的刪掉文件里的BOM。

??????我們這里提到的BOM并不是制造業(yè)管理中料表（Bill of Material）的概念，而是UCS（Unicode的學(xué)名是"Universal Multiple-Octet Coded Character Set"，簡(jiǎn)稱為UCS）編碼中有一個(gè)叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應(yīng)該出現(xiàn)在實(shí)際傳輸中。UCS規(guī)范建議我們?cè)趥鬏斪止?jié)流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。這樣如果接收者收到FEFF，就表明這個(gè)字節(jié)流是Big-Endian（big endian和little endian是CPU處理多字節(jié)數(shù)的不同方式。例如“漢”字的Unicode編碼是6C49。那么寫到文件里時(shí)，究竟是將6C寫在前面，還是將49寫在前面？如果將6C寫在前面，就是big endian。還是將49寫在前面，就是little endian。我們一般將endian翻譯成“字節(jié)序”，將big endian和little endian稱作“大尾”和“小尾”。）的；如果收到FFFE，就表明這個(gè)字節(jié)流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被稱作BOM。

??????UTF-8是以8位為單位來表示UCS，其實(shí)不存在什么尾序的問題，其實(shí)BOM是沒有什么作用的，不過可以用BOM來表示編碼方式，字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF，所以如果接受到以EF BB BF開頭的字節(jié)流就可以判斷是UTF-8編碼了。

??????如果上面提到的一些名詞你不是很清楚可以google一下，找到相關(guān)的解釋。追根究底是個(gè)好習(xí)慣?。如果對(duì)BOM的概念還不清楚或者想了解更多也可以搜索相關(guān)資料來研究。

??????下面重點(diǎn)來說一下怎么去掉BOM：
??????首先windows自帶的記事本會(huì)在保存UTF-8編碼的文件時(shí)不管是否含有BOM一律加上BOM，所以千萬別用記事本。我的程序跑不起來也是因?yàn)橛糜浭卤敬蜷_過。。。有段時(shí)間非常流行的“聯(lián)通”問題就是跟windows記事本處理BOM的機(jī)制有關(guān)，就是把“聯(lián)通”兩字寫進(jìn)記事本保存后再打開時(shí)就會(huì)是黑點(diǎn)。。。如果你有興趣可以到網(wǎng)上找到相關(guān)文章詳細(xì)解釋給你聽，呵呵。

??????比較新版本的UltraEdit（以下簡(jiǎn)稱UE，大家都是這么叫的）都對(duì)BOM支持比較好，所以推薦使用新版本的UE來解決這個(gè)問題。我用的版本是UltraEdit-32 10.20d+中文版（網(wǎng)上可以下的到，如果你比較懶可以聯(lián)系我，留下郵箱，呵呵）。首先打開UE，選擇菜單欄“高級(jí)”－“配置”，出現(xiàn)一個(gè)選項(xiàng)卡窗口，在“常規(guī)”選項(xiàng)卡中找到“保存時(shí)對(duì)所有UTF-8文件頭標(biāo)記（BOM）”和“對(duì)在UltraEdit里創(chuàng)建的新文件寫入U(xiǎn)TF-8文件頭標(biāo)記（如上面）”，把它們的復(fù)選框都取消不選，然后確定。這個(gè)時(shí)候UE默認(rèn)情況下就不會(huì)對(duì)沒有BOM的文件加入BOM，注意如果不執(zhí)行上述操作UE默認(rèn)也是會(huì)加的！那已經(jīng)含有BOM的文件如何清除BOM呢？下面演示給大家。首先打開文件，選擇菜單欄“文件”－“格式轉(zhuǎn)換”－“UTF-8 轉(zhuǎn) ASCII”，這樣文件會(huì)被轉(zhuǎn)為ASCII編碼，BOM就不會(huì)存在了，因?yàn)樯厦嬲f過BOM是在UCS編碼的頭部的，然后再選擇菜單欄“文件”－“格式轉(zhuǎn)換”－“ASCII 轉(zhuǎn) UTF-8（Unicode編輯）”，這個(gè)時(shí)候文件會(huì)被轉(zhuǎn)回為UTF-8編碼，因?yàn)槲覀兩厦孢x了不自動(dòng)加BOM，所以這個(gè)時(shí)候的文件是不帶BOM的，然后保存文件。整個(gè)操作過程就完畢了。（如果仍然有什么疑問給我留言吧）

??????我去掉BOM后重新啟動(dòng)服務(wù)器，訪問數(shù)據(jù)庫(kù)一切正常，問題果然解決了。當(dāng)然在我碰到的這個(gè)問題中干脆把文件轉(zhuǎn)成ASCII直接用也可以，汗！不知道為什么，請(qǐng)大家指教！