UTF-8、BOM、<feff>的问题

最新推荐文章于 2021-04-12 11:41:50 发布

翟海飞

最新推荐文章于 2021-04-12 11:41:50 发布

阅读量1.2w

点赞数 2

分类专栏： C UTF-8 BOM 文章标签： utf-8 BOM feff

本文链接：https://blog.csdn.net/zhaihaifei/article/details/18843159

版权

C 同时被 3 个专栏收录

8 篇文章 0 订阅

订阅专栏

UTF-8

1 篇文章 0 订阅

订阅专栏

BOM

1 篇文章 0 订阅

订阅专栏

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

REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook

for FILE in $($SVNLOOK changed -t "$TXN" "$REPOS" | awk '/^[AU]/ {print $NF}'); do
    if $SVNLOOK cat -t "$TXN" "$REPOS" "$FILE" | grep -q $'^\xEF\xBB\xBF'; then
        echo "Byte Order Mark be found in $FILE" 1>&2
        exit 1
    fi
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 plain copy print ?

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/sh

REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook

FILES=`$SVNLOOK changed -t "$TXN" "$REPOS" | awk {'print $2'}`

for FILE in $FILES; do
    CONTENT=`$SVNLOOK cat -t "$TXN" "$REPOS" "$FILE"`

    if echo $CONTENT | head -c 3 | xxd -i | grep -q '0xef, 0xbb, 0xbf'; then
        echo "BOM!" 1>&2
        exit 1
    fi
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 `�')

翟海飞

关注

2
点赞
踩
3

收藏

觉得还不错? 一键收藏
1
评论
UTF-8、BOM、<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 |
复制链接

扫一扫

专栏目录