转-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