linux 上的xml痛苦之處

如果選用utf8編碼的系統在linux上面開發,xml類庫採用libxml,那麼不說也罷,一切都顯得順氣自然。尤其libxml在xml處理效率方面的良好表現自然成了首選。

但如果系統架構編碼支持已開始就選定了gb2312,那麼噩耗將會接踵而來。當然所謂的噩耗,並非說libxml就不能解析gb2312編碼的xml數據。其實無論採用linux系統函數iconv或者libxml的系統自帶函數都可以正常讀入gb2312編碼的xml數據,唯一的區別就是使用編碼轉化帶來的效率問題以及其他問題。尤其是通信服務端解析來自客戶端的xml數據,在高併發的情況下,往往並非select,poll,epoll的關鍵字會如何造成數據處理的堆積,很大程度上取決於後臺業務處理的效率。xml數據編碼轉化甚至如同蝴蝶效應一樣可能給整個系統帶來效率和穩定性上的損耗。

好在libxml通過不停的完善之後,已經能夠支持gb2312編碼的xml數據輸入處理了,但是卻又給大家開了一個天大的玩笑。似乎libxml解析xml後的結果,輸出依然是utf8等類庫內核編碼。呵呵,這就如同某個男人進了一間黑屋子穿了一件帥氣的衣服出來後卻變成了女的。還是又不得不用iconv來進行處理。

呵呵,苦笑,本想去編譯libxml源碼,後來發現其內核編碼支持的非常有限,apache組織的xml解析庫也存在libxml的問題,無奈之下,選擇了小巧靈活的tinyxml。編碼也簡單多了,至少少了許多libxml驚心動魄的內存管理,唯一的付出,就是需要一些算法進行xml的特出的業務處理。

無奈,這個世界就這樣,沒有完美的東西。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章