关于UTF-8签名导致的编译失败问题
2013-03-18 13:04
260 查看
今天在使用hudson构建的时候,出现了下面这样的一个错误
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /持续集成/maven_hudson/.hudson/jobs/reportmis2013/workspace/src/com/runqianapp/flexdesigner/vo/SQLDataSet.java:[1,0] illegal character: \65279
从SVN上面down下了SQLDataSet.java,发现本地编译并不报错,查看了这个类的属性,这个类的编码是UTF-8(BOM),因此才会在[1,0]的位置上标示出了头文件有问题。
具体原因如下:
某些编辑器会往utf8文件中添加utf8标记(editplus称其为签名),它会在文件开始的地方插入三个不可见的字符(0xEF 0xBB 0xBF,即BOM),它的表示的是 Unicode 标记(BOM)。 因此要解决这个问题的关键就是把这个标记选项去掉,可按如下方法操作。
首先用editplus打开这个文件,从Doucument菜单中选择Permanet Settings,有三个分类,分别是General,File, To
ba2d
ols.点击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是在文件的开始加了几个字节作为标记。
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /持续集成/maven_hudson/.hudson/jobs/reportmis2013/workspace/src/com/runqianapp/flexdesigner/vo/SQLDataSet.java:[1,0] illegal character: \65279
从SVN上面down下了SQLDataSet.java,发现本地编译并不报错,查看了这个类的属性,这个类的编码是UTF-8(BOM),因此才会在[1,0]的位置上标示出了头文件有问题。
具体原因如下:
某些编辑器会往utf8文件中添加utf8标记(editplus称其为签名),它会在文件开始的地方插入三个不可见的字符(0xEF 0xBB 0xBF,即BOM),它的表示的是 Unicode 标记(BOM)。 因此要解决这个问题的关键就是把这个标记选项去掉,可按如下方法操作。
首先用editplus打开这个文件,从Doucument菜单中选择Permanet Settings,有三个分类,分别是General,File, To
ba2d
ols.点击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是在文件的开始加了几个字节作为标记。
相关文章推荐
- 关于utf8编码文件导致编译失败的问题
- 解决使用libpq时提示一系列SSL相关函数没有定义导致编译失败的问题
- 关于新建Android Studio项目时默认的编译sdk版本导致的兼容问题
- cudnn版本问题导致tensorflow GPU源码编译失败
- 关于流量升高导致TIME_WAIT增加,MySQL连接大量失败的问题
- 关于gcc编译后的带中文输出的utf-8的c文件输出乱码问题
- linux 编译 kernel 3.3 以上关于 bnx2 网卡加载失败问题 bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.2.1b.fw"
- 关于UTF-8编码导致网页解析出现空白的问题
- 一个签名导致的APK编译不过问题
- 【问题汇总】在C/C++中使用Android Log导致编译失败的问题
- 关于vs2010编译的问题#debug编译成功release编译失败#
- 关于idea编码问题,如微信支付签名失败
- 关于流量升高导致TIME_WAIT增加,MySQL连接大量失败的问题
- 修正lua_path导致luac编译失败的问题
- [转]关于流量升高导致TIME_WAIT增加,MySQL连接大量失败的问题
- Ubuntu 16.04编译Android,make 版本过高导致编译失败的问题
- 关于Ubuntu编译Qt失败问题
- DEBUG_NEW 导致编译失败的问题
- 关于Xcode编译时编译失败但是没有报错的问题!
- Qt问题记录: 关于继承顺序不同导致编译不过