这个是一个诡异的问题，主要是由于文件的的编码格式所引起的，在用eclipse开发项目的时候这个问题是不会报任何错误的，而且我给测试部的大的war包的时候也没有问题。就是在最后在Linux下打包工具打包的时候就出现了这个问题。
问题如下：
rui/allsource/src/com/rtdev/otp/adminui/api/util/ZBOtpClientImpl.java:1: illegal character: \65279
查看文件属性错误的情况如下：
如果是编译正常的文件是这样的：
看来问题出在 Byte Order Mark is UTF-8 (BOM)上。因为看不出来问题，所以用UltraEdit打开两个文件，并用16进制格式显示
有问题的文件头：
无问题的文件头：
看来有问题的文件头前面多了三个字节EF BB BF。
具体原因如下：
某些编辑器会往utf8文件中添加utf8标记（editplus称其为签名），它会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM），它的表示的是 Unicode 标记（BOM）。 因此要解决这个问题的关键就是把这个标记选项去掉，可按如下方法操作。
用editplus打开这个文件，然后另存为，修改文件的编码如图：
相关资料：
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