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

java:[1,10] class, interface, or enum expected表面看著該文件確實沒錯，看不出來問題，后來從SVN上更新下代碼以后，發(fā)現(xiàn)本地也不報錯，后來通過Eclipse查看了該xxx.java類的屬性，才發(fā)現(xiàn)玄機所在：
編譯有問題的文件屬性：（注意最下面一行 Byte Order Mark is UTF-8  (BOM)）
編譯正常的文件屬性：
看來問題出在 Byte Order Mark is UTF-8  (BOM)上。因為看不出來問題，所以用UltraEdit打開兩個文件，并用16進制格式顯示：
有問題的文件頭：
無問題的文件頭：
看來有問題的文件頭前面多了三個字節(jié)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 下操作的菜單結構如下: 文檔->參數(shù)設置->文件->UTF-8簽名->總是移除簽名->確定 ，這樣就設置了UTF-8格式不需要在文件前面加標記，最后把文件另存為utf-8格式就好了.
     方式二：用Notepad++ 打開xx.Java ，選擇菜單欄的 格式 —以 UTF-8無ＢＯＭ格式編碼，保存提交即可
相關資料，網上摘抄：
         UTF-8以字節(jié)為編碼單元，沒有字節(jié)序的問題。UTF-16以兩個字節(jié)為編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的字節(jié)序。例如收到一個“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節(jié)流“594E”，那么這是“奎”還是“乙”？Unicode規(guī)范中推薦的標記字節(jié)順序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法：在UCS編碼中有一個叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的編碼FEFF。而FFFE在UCS中是不存在的字符，所以不應該出現(xiàn)在實際傳輸中。UCS規(guī)范建議我們在傳輸字節(jié)流前，先傳輸字符”ZERO WIDTH NO-BREAK SPACE”。這樣如果接收者收到FEFF，就表明這個字節(jié)流是Big-Endian的；如果收到FFFE，就表明這個字節(jié)流是Little-Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被稱作BOM。UTF-8不需要BOM來表明字節(jié)順序，但可以用BOM來表明編碼方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BB BF開頭的字節(jié)流，就知道這是UTF-8編碼了。Windows就是使用BOM來標記文本文件的編碼方式的。原來BOM是在文件的開始加了幾個字節(jié)作為標記。
擴展閱讀：
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