本文出處：http://blog.csdn.net/chaijunkun/article/details/17279565，轉載請註明。由於本人不定期會整理相關博文，會對相應內容作出完善。因此強烈建議在原始出處查看此文。
距離上次寫技術博客已經有半年時間了，年尾我覺得有必要寫點東西總結一下經驗，分享給大家。近期在做一個數據同步的項目，從數據中心拿到定時分發的導出文件後，按照固定字段的含義再逐行解析，然後進一步分析後倒入到我這邊的數據庫。需求簡單就是這樣，我們來看個例子：
2013-09-29^_^21635265^_^測試標題^_^10^_^20^_^15假設上面的例子是文本數據的其中一行。在這個例子中，列分隔符采用的是^_^（注意，是多字符的），字段定義分別是
發佈日期^_^文章ID^_^文章標題^_^評論數^_^點擊數^_^頂數考慮到對數據中心的信任，我們忽略了“發佈日期”、“文章ID”、“評論數”、“點擊數”和“頂數”這些字段的非法情況，而將重點放在了分析標題上，因爲標題是用戶指定的，而可以輸入任何可見字符，因此我們還考慮到了在文章中包含我們的分隔符的情況，所以在data.splite()之後採用了掐頭去尾的算法，前兩個字段正常分析，然後倒着來，從“頂數“，”點擊數”和“評論數”分析，剩下的就是標題了。可是我們只考慮了標題中如下形式：
測試標題^_^、測試^_^標題、^_^測試標題而沒有考慮到這樣的情況：
測試標題^_也就是說標題中的末尾帶有一半分隔符，這樣從邏輯上和真正分隔符的前一半正好能拼成一個合理的分隔符，如：
2013-09-29^_^21635265^_^測試標題^_^_^10^_^20^_^15所以在拆分字段的時候評論數字段就被拆成了“_^10”，這種情況下是沒有辦法將其轉換爲Integer類型的，故而報錯。
說起來在這個項目中採用什麼樣的分隔符還是很早前其他同事定的，直到發生這個問題才覺得有必要改成單個字符，這樣就不會產生歧義了。
後來在我用Excel導入其它數據進行分析的時候發現它早就注意到這個問題了，在指定自定義分隔符的時候只允許採用單字符：
