項目中經過 InputStream 讀取文本文件數據時常常會遇到讀入的字符流中含有特殊首字符的狀況。這個標識在 Java 讀取文件的時候,不會被去掉,並且 String.trim() 也沒法刪除,致使讀入的數據比預期的長度大1,此時的特殊首字符有可能就是系統保存文本文件時添加的 BOM 標識。編輯器
BOM 即 Byte Order Mark,是 Unicode 規範中推薦的標記字節順序的方法。好比說對於 UTF-16,若是接收者收到的 BOM 是 \uFEFF,代表這個字節流是 Big-Endian 的;若是收到 \uFFFE,就代表這個字節流是Little-Endian的。在 UTF-8 中不須要 BOM 來代表字節順序,但能夠用其來代表 UTF-8 的編碼規則。BOM的 UTF-8 編碼是 EF BB BF(用 UltraEdit 打開文本並切換到16進制能夠看到)。因此若是接收者收到以 EF BB BF 開頭的字節流,就知道這是 UTF-8 編碼了。編碼
在 Windows 下用文本編輯器建立的文本文件,若是選擇以 UTF-8 等 Unicode 格式保存,會默認在文件頭(第一個字符)都會加入一個不可見的 BOM 標識。code
在讀入數據時,因爲 BOM 字符不會被忽略掉,並且 String.trim() 也沒法刪除,會致使咱們判斷首字符時出現沒必要要的麻煩,例如當咱們須要判斷讀入字符串以某個字符開頭時 BOM 字符就可能形成判斷失敗,須要針對 Unicode 格式保存的文件作特殊處理。字符串
可使用 Apache Commons IO 中的 BOMInputStream 去封裝下原始的 InputStream 便可得到一個過濾了 BOM 字符的輸入流,而後再繼續後續的操做便可。it