在工作中，有一次需要讀取文件的內容，於是很自然地寫下這樣的讀取代碼：
BufferedReader readBuffer = new BufferedReader(new InputStreamReader(new FileInputStream(filePath)));
String s;
while ((s = readBuffer.readLine()) != null) {
//對字符串s進行解析
...
}
解析的過程，發現文件第一行總是無法正確解析。於是將第一行逐個字符打印出來，每個字符佔一行。發現第一行第一個字符是空字符。
起始，我以爲是首行開始多了一個空格，於是我對讀取出來的內容加一個trim()操作，再次打印，這個空字符還是沒有消除。
上網查了一翻，原來，首行的這個空字符是由於文件編碼UTF-8-BOM造成的。
UTF-8-BOM與UTF-8的區別，在於UTF-8-BOM的文件首會多一個空字符 “\uFEFF”。
所以，如果讀取以UTF-8-BOM爲編碼方式的文件，那麼第一行第一個字符會是空字符。
如果解析文件第一行的內容老是出錯時，可以查下是否是這個問題。
如果是，解決辦法是加上這樣一句代碼：
//把bom的空字符轉化爲空串
s = s.replace("\uFEFF", "");
那麼，bom是什麼？爲什麼UTF-8-BOM要在文件首加一個空字符？
首先，UTF-8-BOM除了文件首比UTF-8多了一個空字符外，其它和UTF-8是一樣的。
BOM ，全稱Byte Order Mark，翻譯爲“字節順序標記”，維基百科上的解釋如下：
當以UTF-16或UTF-32來將UCS/統一碼字符所組成的字符串編碼時，這個字符被用來標示其字節序。它常被用來當做標示文件是以UTF-8、UTF-16或UTF-32編碼的標記。
但其實，在UTF-8中，並不一定需要BOM，比如linux系統就沒有，但微軟系統就有。
是微軟系統故意跟Linux不兼容嗎？不是的。
看知乎上的一個解釋：
微軟爲什麼用帶 BOM 的 UTF-8，造成和多數系統的不兼容？ - pansz的回答 - 知乎 https://www.zhihu.com/question/42048612/answer/93747146
他的結論是：
其實各個操作系統對待utf8的方式，都是與自己的過往設計，與自己的舊版本兼容，linux/osx是爲了兼容unix的基礎設計，windows則是爲了兼容所有歷史版本的windows。至於與其他操作系統兼容，並不是最重要的。他們做出這樣的選擇，從技術上都是必然的，不存在任何一方刻意製造不兼容一說。
以上內容參考：
1. https://blog.csdn.net/weixin_39640298/article/details/85127197；
2. https://zh.wikipedia.org/wiki/%E4%BD%8D%E5%85%83%E7%B5%84%E9%A0%86%E5%BA%8F%E8%A8%98%E8%99%9F；
3. https://blog.csdn.net/weixin_39640298/article/details/84573546