本文主要是介绍UTF-8、BOM、feff的问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
问题:在项目开发中,遇到文件开头有<feff>的标识,
[zhaihf@localhost zhaihf]$ grep -I -r -l $'\xEF\xBB\xBF' *
codingstdutf8.txt
解决方法:用shell命令删除
[zhaihf@localhost zhaihf]$ grep -I -r -l $'\xEF\xBB\xBF' codingstdutf8.txt | xargs sed -i 's/^\xEF\xBB\xBF//;q'
[zhaihf@localhost zhaihf]$
[zhaihf@localhost zhaihf]$ grep -I -r -l $'\xEF\xBB\xBF' codingstdutf8.txt | xargs sed -i 's/^\xEF\xBB\xBF//g'
[zhaihf@localhost zhaihf]$
[zhaihf@localhost zhaihf]$
以下是我参考的资料
________________
所谓BOM,全称是Byte Order Mark,它是一个Unicode字符,通常出现在文本的开头,用来标识字节序(Big/Little Endian),除此以外还可以标识编码(UTF-8/16/32),如果出现在文本中间,则解释为zero width no-break space。 注:Unicode相关知识的详细介绍请参考UTF-8, UTF-16, UTF-32 & BOM。 对于UTF-8/16/32而言,它们名字中的8/16/32指的是编码单位是多少位的,也就是说,它们的编码单位分别是8/16/32位,换算成字节就是1/2/4字节,如果是多字节,就要牵扯到字节序,UTF-8以单字节为编码单位,所以不存在字节序。 UTF-8主要的优点是可以兼容ASCII,但如果使用BOM的话,这个好处就荡然无存了,除此以外,BOM的存在还可能引发一些问题,比如下面错误便都有可能是BOM导致的:
- Shell: No such file or directory
- PHP: Warning: Cannot modify header information – headers already sent
在详细讨论UTF-8编码中BOM的检测与删除问题前,不妨先通过一个例子热热身:
shell> curl -s http://phone.10086.cn/ | head -1 | sed -n l
\357\273\277<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional\
//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r$
如上所示,前三个字节分别是357、273、277,这就是八进制的BOM。
shell> curl -s http://phone.10086.cn/ | head -1 | hexdump -C
00000000 ef bb bf 3c 21 44 4f 43 54 59 50 45 20 68 74 6d |...<!DOCTYPE htm|
00000010 6c 20 50 55 42 4c 49 43 20 22 2d 2f 2f 57 33 43 |l PUBLIC "-//W3C|
00000020 2f 2f 44 54 44 20 58 48 54 4d 4c 20 31 2e 30 20 |//DTD XHTML 1.0 |
00000030 54 72 61 6e 73 69 74 69 6f 6e 61 6c 2f 2f 45 4e |Transitional//EN|
00000040 22 20 22 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 |" "http://www.w3|
00000050 2e 6f 72 67 2f 54 52 2f 78 68 74 6d 6c 31 2f 44 |.org/TR/xhtml1/D|
00000060 54 44 2f 78 68 74 6d 6c 31 2d 74 72 61 6e 73 69 |TD/xhtml1-transi|
00000070 74 69 6f 6e 61 6c 2e 64 74 64 22 3e 0d 0a |tional.dtd">..|
如上所示,前三个字节分别是EF、BB、BF,这就是十六进制的BOM。 注:用到了第三方网站的页面,不能保证例子始终可用。 实际做项目开发时,可能会面对成百上千个文本文件,如果有几个文件混入了BOM,那么很难察觉,如果没有带BOM的UTF-8文本文件,可以用vi杜撰几个,相关命令如下:
设置UTF-8编码:
:set fileencoding=utf-8
添加BOM:
:set bomb
删除BOM:
:set nobomb
查询BOM:
:set bomb?
如何检测UTF-8编码中的BOM呢?
shell> grep -r -I -l $'^\xEF\xBB\xBF' /path
如何删除UTF-8编码中的BOM呢?
shell> grep -r -I -l $'^\xEF\xBB\xBF' /path | xargs sed -i 's/^\xEF\xBB\xBF//;q'
推荐:如果你使用SVN的话,可以在pre-commit钩子里加上相关代码用以杜绝BOM。
#!/bin/bashREPOS="$1" TXN="$2"SVNLOOK=/usr/bin/svnlookfor FILE in $($SVNLOOK changed -t "$TXN" "$REPOS" | awk '/^[AU]/ {print $NF}'); doif $SVNLOOK cat -t "$TXN" "$REPOS" "$FILE" | grep -q $'^\xEF\xBB\xBF'; thenecho "Byte Order Mark be found in $FILE" 1>&2exit 1fi done請注意此指令將會把檔案中第一行之外的全數清除。
grep -r -I -l $’^\xEF\xBB\xBF’ /path | xargs sed -i ‘s/^\xEF\xBB\xBF//;q’
可用以下指令嘗試之:
grep -r -I -l $’^\xEF\xBB\xBF’ /path | xargs sed -i ‘s/^\xEF\xBB\xBF//g’
mac 下批量删除UTF8 BOM: grep -r -I -l $'^\xef\xbb\xbf' ./ | xargs sed -i '' $'s/^\xef\xbb\xbf//'
1. mac下的sed要加上一个空串参数才能本地替换 2.处理\x这种hex串,需要加$前缀.
文件头出现的BOM问题
问题描述:在使用EditPlus等文本编辑工具,在windows下修改编码格式为UTF-8的文档时,会在文件的开头阐产生<feff>的字符。
问题影响:用IE浏览页面时,顶部会出现一行空白,查看页面的DOM结构,会发现其中的<link><script>标签会被解析到<body>标签下,在IE下,<meta>标签页会被解析到<body>标签下。
问题原因:在Windows标准下的UTF-8编码文档,是以<feff>开头来标识的,成为BOM(Byte Order Mark,字节序标记)。
文档摘录:
Q: What is a BOM?
A: A byte order mark (BOM) consists of the character code U+FEFF at the beginning of a data stream, where it can be used as a signature defining the byte order and encoding form, primarily of unmarked plaintext files. Under some higher level protocols, use of a BOM may be mandatory (or prohibited) in the Unicode data Western union customer service stream defined in that protocol.
解决方案:
- 配置EditPlus,删除BOM:“工具->首选项->文件->UTF-8标识->总是删除签名”,对应的英文版EditPlus路径为“Tools->Preferences->Files->UTF-8 signature->Always remove signature”
- 改用其他编辑工具,推荐VIM
- 转换为ASCII格式
linux下feff的问题
由于linux下vi无法直接写入中文注释,所以只能在windows下将写好注释的代码传到linux服务器上,但是问题也就出现了,我在windows下用的是Notepad++这款编辑器(感觉还挺不错,有语法高亮识别)编辑源代码的,加过注释后上传到linux上无论什么语言环境(LANG)都是乱码,然后看了一下Notepad++的设置,发现默认为ANSI格式,于是就转换为UTF-8格式编码(因为linux里有这个格式的嘛),然后再上传到linux服务器上,linux也设为UTF-8语言环境,可以看到中文注释了!但是发现每个文件第一行都会有“<feff>”这个字符串。google了下发现问题的所在了。
原来这是个被称作BOM(Byte Order Mark)的不可见字符,是Unicode用来标识内部编码的排列方式的,在UTF-16、UTF-32编码里它是必需的,而在UTF-8里是可选的。因 此,才会出现有的编辑器在文件头部添加添加BOM、而有的语法解析器又不作处理的的混乱情况。所谓 BOM,全称是Byte Order Mark,它是一个Unicode字符,通常出现在文本的开头,用来标识字节序 (Big/Little Endian),除此以外还可以标识编码(UTF-8/16/32),如果出现在文本中间,则解释为zero width no-break space。
这个BOM可以在编辑文本时设置的,但是,只能在第一次编辑时才能设置它为bomb还是nobomb,编辑完并保存后就无法再更改编码格式了。有关bomb命令:
#设置UTF-8编码 :set fileencoding=utf-8#添加BOM:set bomb#删除BOM:set nobomb#查询BOM:set bomb?
如下例子:
用vi编辑一个测试文本test.txt
- test bomb or nobomb
- ~
- ~
- ~
- ~
- ~
- ~
- ~
- ~
- ~
test bomb or nobomb ~ ~ ~ ~ ~ ~ ~ ~ ~
查询BOM结果:(set bomb ?)
- ~
- ~
- ~
- ~
- ~
- nobomb
~ ~ ~ ~ ~ nobomb
更改BOM结果:(set bomb)
- ~
- ~
- ~
- ~
- ~
- ~
- bomb
~ ~ ~ ~ ~ ~ bomb
保存后再次打开就会发现如下图所示:
而且我们对于上传过来的源代码没法做修改,网上有人说可以删除BOM(grep -I -r -l $'\xEF\xBB\xBF' * | xargs sed -i 's/^\xEF\xBB\xBF//;'),我试过了不行,不知哪位大牛指点下?检查文件中是否含BOM的命令为:
- grep -I -r -l $'\xEF\xBB\xBF' *
grep -I -r -l $'\xEF\xBB\xBF' *
这个命令是有效的。既然没法靠在linux下有什么命令删除BOM,那咱们只能从源头处理了,编码更改为无BOM的UTF-8编码格式。Notepad++有转换此格式的选项:
转换过后保存下然后再传到linux服务器上,问题就解决了!!
另:这个问题在sun环境和Hp环境下没有此问题,我不清楚如果忽略这个问题在编译时或程序运行时是否会产生异常,网上有人反映是有的,所以还是建议麻烦些也不要忽略此问题,谁晓得它会惹出什么麻烦呢
UTF-8、BOM、<feff>的问题
有些编辑器,比如M$ Windows的记事本,在创建UTF8编码文件时会在头部添加一个不可见字符。这个字符可以通过vim查看到,而且如果是一个php文件,php4、php5在解析时均会有输出。
原来这个被称作BOM(Byte Order Mark)的不可见字符,是Unicode用来标识内部编码的排列方式的,在UTF-16、UTF-32编码里它是必需的,而在UTF-8里是可选的。因 此,才会出现有的编辑器在文件头部添加添加BOM、而有的语法解析器又不作处理的的混乱情况。
根据w3c里FAQ的建议,解决方法就是,删无赦!
**************************
http://apps.hi.baidu.com/share/detail/35382688
**************************
linux下处理windows utf8文件,发现vim头会多一个<feff>
一般默认创建的文件都是ANSI编码的。用记事本打开这个文件,点"另存为",最下面有个"编码(Encoding)"可以选择,里面有"ANSI,utf8"等选项。
下面介绍用直接使用perl创建一个UTF-8的文件
open( OUT, ">:utf8", "a.txt" ) or die "a.out: $!"; print OUT "\x{feff}"; print OUT "aaaa\n"; close OUT;反过来,删除文件中的<feff>头
open (FH, '<:utf8',"$_" ) or die $!;
...
s/\x{feff}//;
...
BOM 清除
[root@test3 11]# gcc 11.2.c
11.2.c:1: 错误:程序中有游离的 ‘\357’ 8进制,相当于16进制 ef
11.2.c:1: 错误:程序中有游离的 ‘\273’
11.2.c:1: 错误:程序中有游离的 ‘\277’
[root@test3 11]# head -1 11.2.c|hexdump -C
00000000 ef bb bf 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 |...#include <std|
00000010 69 6f 2e 68 3e 0a |io.h>.|
00000016
两种方法:
tail -c +4 11.1.c.orig> 11_1.c
第2种
sed -i '1 s/^\xef\xbb\xbf//' *.txtsing GNUsed
(on Linux or Cygwin):On FreeBSD or Mac OS X:
sed -i .bak '1 s/^\xef\xbb\xbf//' *.txt
出现error: stray ‘\357’ in program的根源
这次又遇到这个这种问题,想找到它的根源。找到一个表格:
The characters at a glance
Here are all the printable characters, in collating order:
! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @A B C D E F G H I J K L M N O P Q R S T U V W X Y Z[ \ ] ^ _ `a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � � � � � ��� � � � � � ��� � � � � � � � � � � � � � � � � � � � � � ��� � � � � � �
The first six rows are the ASCII character set.
Note the ordinary ASCII space (before `!') and the ISO Latin-1 non-breaking space (before `�')
这篇关于UTF-8、BOM、feff的问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!