java:[1,0] illegal character: \65279

部署項目的時候報以下錯誤

java:[1,0] illegal character: \65279
java:[1,10] class, interface, or enum expected

表面看着該文件確實沒錯，看不出來問題，後來從SVN上更新下代碼以後，發現本地也不報錯，後來通過Eclipse查看了該xxx.java類的屬性，才發現玄機所在：

編譯有問題的文件屬性：（注意最下面一行 Byte Order Mark is UTF-8  (BOM)）

編譯正常的文件屬性：

看來問題出在 Byte Order Mark is UTF-8  (BOM)上。因爲看不出來問題，所以用UltraEdit打開兩個文件，並用16進制格式顯示：

有問題的文件頭：

無問題的文件頭：

看來有問題的文件頭前面多了三個字節EF BB BF。

具體原因如下：

        某些編輯器會往utf8文件中添加utf8標記（editplus稱其爲簽名），它會在文件開始的地方插入三個不可見的字符（0xEF 0xBB 0xBF，即BOM），它的表示的是 Unicode 標記（BOM）。 因此要解決這個問題的關鍵就是把這個標記選項去掉，可按如下方法操作。 
       方式一： 首先用editplus打開這個文件，從Doucument菜單中選擇Permanet Settings,有三個分類，分別是General,File, Tools.點擊File,右邊會有一項是 UTF-8 signature: 選擇 always remove signature. 點擊OK 。中文版本的 Editplus 下操作的菜單結構如下: 文檔->參數設置->文件->UTF-8簽名->總是移除簽名->確定 ，這樣就設置了UTF-8格式不需要在文件前面加標記，最後把文件另存爲utf-8格式就好了.

     方式二：用Notepad++ 打開xx.Java ，選擇菜單欄的 格式 —以 UTF-8無ＢＯＭ格式編碼，保存提交即可

相關資料，網上摘抄：

         UTF-8以字節爲編碼單元，沒有字節序的問題。UTF-16以兩個字節爲編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的字節序。例如收到一個“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節流“594E”，那麼這是“奎”還是“乙”？Unicode規範中推薦的標記字節順序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法：在UCS編碼中有一個叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的編碼FEFF。而FFFE在UCS中是不存在的字符，所以不應該出現在實際傳輸中。UCS規範建議我們在傳輸字節流前，先傳輸字符”ZERO WIDTH NO-BREAK SPACE”。這樣如果接收者收到FEFF，就表明這個字節流是Big-Endian的；如果收到FFFE，就表明這個字節流是Little-Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被稱作BOM。UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。Windows就是使用BOM來標記文本文件的編碼方式的。原來BOM是在文件的開始加了幾個字節作爲標記。

擴展閱讀：

UTF-8, UTF-16, UTF-32 & BOM：http://www.unicode.org/faq/utf_bom.html#BOM

W3C官方說明：http://www.w3.org/International/questions/qa-utf8-bom