问题：在项目开发中，遇到文件开头有<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。

如上所示，前三个字节分别是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的命令为：

[plain] view plaincopyprint?

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

UTF-8编码中BOM的检测与删除

所谓 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: #!/bin/sh: No such file or directory
PHP: Warning: Cannot modify header information – headers already sent

在详细讨论UTF-8编码中BOM的检测与删除问题前，不妨先通过一个例子热热身：

# 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。

# curl -s http://phone.10086.cn/ | head -1 | xxd
0000000: efbb bf3c 2144 4f43 5459 5045 2068 746d  ...<!DOCTYPE htm
0000010: 6c20 5055 424c 4943 2022 2d2f 2f57 3343  l PUBLIC "-//W3C
0000020: 2f2f 4454 4420 5848 544d 4c20 312e 3020  //DTD XHTML 1.0
0000030: 5472 616e 7369 7469 6f6e 616c 2f2f 454e  Transitional//EN
0000040: 2220 2268 7474 703a 2f2f 7777 772e 7733  " "http://www.w3
0000050: 2e6f 7267 2f54 522f 7868 746d 6c31 2f44  .org/TR/xhtml1/D
0000060: 5444 2f78 6874 6d6c 312d 7472 616e 7369  TD/xhtml1-transi
0000070: 7469 6f6e 616c 2e64 7464 223e 0d0a       tional.dtd">..

如上所示，前三个字节分别是EF、BB、BF，这就是十六进制的BOM。

注：用到了第三方网站的页面，不能保证例子结论始终正确。

实际做项目开发时，可能会面对成百上千个文本文件，如果有几个文件混入了BOM，那么很难察觉，如果没有带BOM的UTF文本文件例子，可以用vi 杜撰几个，相关命令如下：

#设置UTF-8编码
:set fileencoding=utf-8
#添加BOM
:set bomb
#删除BOM
:set nobomb
#查询BOM
:set bomb?

如何检测UTF-8编码中的BOM呢？

shell> grep -I -r -l $'\xEF\xBB\xBF' /path

如何删除UTF-8编码中的BOM呢？

shell> grep -I -r -l $'\xEF\xBB\xBF' /path | xargs sed -i 's/^\xEF\xBB\xBF//;q'

推荐：如果你使用SVN的话，可以在pre-commit钩子里加上相关代码，从源头杜绝BOM。

#!/bin/shREPOS="$1"
TXN="$2"SVNLOOK=/usr/bin/svnlookFILES=`$SVNLOOK changed -t "$TXN" "$REPOS" | awk {'print $2'}`for FILE in $FILES; doCONTENT=`$SVNLOOK cat -t "$TXN" "$REPOS" "$FILE"`if echo $CONTENT | head -c 3 | xxd -i | grep -q '0xef, 0xbb, 0xbf'; thenecho "BOM!" 1>&2exit 1fi
done

篇幅所限，恕不详述，未尽事宜大家就请自己搜索吧。

**************************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’

两种方法：

tail -c +4 11.1.c.orig> 11_1.c

第2种
sed -i '1 s/^\xef\xbb\xbf//' *.txtsing GNU sed (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的问题相关推荐

UTF-8的BOM头
字符编码相关信息 http://baike.baidu.com/view/1204863.htm UTF-8 编码的文件可以分为no BOM 和 BOM两种格式. 有bom头的存储或者字节流,它一定 ...
精述字符编码（读这篇就够了）
文章目录 1.导语 2.ASCII 3.Latin1 4.ANSI 5.GB2312,GB13000,GBK,GB18030,BIG5 6.Unicode 与 BMP 7.UCS.UCS-2 与 UC ...
追本溯源：字符串及编码
转载:https://zhuanlan.zhihu.com/p/73917931 开始先考虑下边的问题. let s = "js" console.log(s.length) s ...
一种字符编码猜测工具的实现方法
2019独角兽企业重金招聘Python工程师标准>>> 摘要自从进入计算机时代后,人们创造了许多编码,来表示各国的语言文字.这些编码从一开始设计时,就没有考虑到要和其它编码兼容,它 ...
C++ 字符编码知识转载
基本常识 1.位和字节说起编码,我们必须从最基础的说起,位和字节(别觉得这个过于简单不值一说,我还真见过很多个不能区分这两者的程序员).位(bit)是指计算机里存放的二进制值(0/1),而8个位组合 ...
编码(ACSII unicod UTF-8)、QT输出中文乱码深入分析
总结: 1. qt输出中文乱码原因分析 qt的编程环境默认是utf-8编码格式(关于编码见下文知识要点一): cout << "中文" << endl; 程 ...
计算机字符编码详尽讲解
文章来源:http://www.guokr.com/blog/763017/ 下载一个文档,一打开发现是乱码,不抓狂才怪--你们都知道,这都是字符编码闯的祸.ASCII.ANSI.GB18030.Un ...
App工程从Eclipse迁移到Android Studio的问题总结
这段时间把一个App工程从原来的ADT环境(即Eclipse)迁移到Android Studio环境,发现并处理了一系列迁移问题,兹记录如下.把ADT工程迁移到AS,通常的做法是打开Android S ...
idea Error:(1, 10) java: 需要class, interface或enum, 未结束的字符串文字，Error:(55, 136) java: 非法字符: \65533...
1.未结束的字符串文字,Error:(55, 136) java: 非法字符: \65533 这些乱七吧八遭的错误如果很多的话 , 尝试重新修改下生成目录修改下语言等级上述方法都不行 ,还报错 ...
UTF-8编码和UTF-8-BOM编码的区别和处理
软件程序打开xml文件,在开发系统和部分用户计算机正常,在一个客户计算机出现xml解析错误,百思不得其解.后来突然想到了编码问题,用专业记事本编辑工具打开文件,发现文件的编码是UTF-8-BOM,另存 ...

UTF-8、BOM、feff的问题

文件头出现的BOM问题

The characters at a glance

UTF-8、BOM、feff的问题相关推荐

最新文章

热门文章