有没有人遇到过类似的情形呢?
因为不是一直出现,而且尝试过最简单的代码也出问题,就没往代码方面去想,一直在纠结是不是
后来同事把bom去掉就好了,惊喜之余更多的是郁闷。。。太丢人了
虽然问题解决了,但具体是什么原因呢?
回复内容:
有没有人遇到过类似的情形呢?
因为不是一直出现,而且尝试过最简单的代码也出问题,就没往代码方面去想,一直在纠结是不是
后来同事把bom去掉就好了,惊喜之余更多的是郁闷。。。太丢人了
虽然问题解决了,但具体是什么原因呢?
Unicode是唯一的,但Unicode的编码方式不是唯一的。编码方式可能是唯一的,但大端小端在前还不一定是唯一的。光说打开一个“Unicode”文件,其实不太容易做。
BOM就是把一个Unicode保留字符U+FEFF,按照文件存储者的编码方式编码后,塞到文件内容的最前边。这样用不同的Unicode编码去解析文件头,就可以得知文件的编码方式和大小端顺序。结果就是文件头部多出来了两三个字节。
有了BOM所有的程序都必须为BOM作出修改,这无疑是一个“大折腾”的行为。所以一般不认为BOM是个好主意。BOM引发的问题,我能想起来两个:
- UNIX可执行脚本的Shabang标记(
#!
)不能识读
任何时候都采用无BOM的UTF-8编码的Unicode,绝对是一个引发麻烦最少的最实用策略。UTF-8是Unicode的最佳实践,没有之一。
必须指出的是,何弃疗的微软经常做出非要DOM不可的行为,最典型的例子就是那个记事本(存盘就加DOM)。所以任何时候,都千万别偷懒用记事本编辑
永远不要忘记:微软是技术落后,并且只会对超过自己的开源界冷嘲热讽,从不肯真正改正自己问题的业界毒瘤。话下的狠了点,不过就算没到这程度,也差不了多少。从一点一滴开始远离微软,让生活变得轻松些。
BOM: Byte Order Mark
UTF-8 BOM 又叫 UTF-8 签名,其实 UTF-8 的 BOM 对 UFT-8 没有作用,是为了支援 UTF-16,UTF-32 才加上的 BOM ,BOM 签名的意思就是告诉弱编辑器(记事本)当前文件采用何种编码,方便编辑器识别。
BOM 头是隐藏字符,非编辑字符,就像普通空文件一样,当我们写
登录后复制
当 file.
少年,珍爱生命,远离 BOM 。
一般的编辑器,是侦测不到utf8+bom的, 诸如记事本、写字板等等。 须使用editplus、ultraedit等文本编辑器进行侦测, 然后另存为utf8 no bom格式。
出现问题的原因可能是您用过记事本类的弱文本编辑器编辑过。