轉-java編譯時error: illegal character '\ufeff' 的解決辦法-https://blog.csdn.net/t518vs20s/article/details/808

原文連接：https://blog.csdn.net/shixing_11/article/details/6976900 最近開發人員經過SVN提交了xxx.java文件，因發佈時該包有問題須要回退，故SCM將該xxx.java文件用editplus打開刪除了新添的一行，刪除後從新編譯打包，卻報了以下異常： java:[1,0] illegal character: \65279 表面看着該文件確實沒錯，看不出來問題，後來從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格式就行了. 相關資料，網上摘抄： 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