部署项目的时候报下面错误
- java: [1, 10] class,
- interface,
- or enum expected
编译有问题的文件属性:(注意最以下一行 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 无BOM格式编码,保存提交就可以
相关资料,网上摘抄:
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
来源: http://www.bubuko.com/infodetail-2213233.html