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

╰+攻爆jí腚メ 2022-08-24 14:08 297阅读 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_ 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’
       
         
       
        [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 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的根源][error_ stray _357_ in program]

![test.jsp_url_http_3A_2F_2Fimg.my.csdn.net_2Fuploads_2F201304_2F21_2F1366515375_2202.png][]

这次又遇到这个这种问题，想找到它的**根源**。找到一个表格：

## 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 \`**�**')

[Byte Order Mark]: http://en.wikipedia.org/wiki/Byte_order_mark
[zero width no-break space]: http://en.wikipedia.org/wiki/Zero-width_non-breaking_space
[UTF-8_ UTF-16_ UTF-32 _ BOM]: http://unicode.org/faq/utf_bom.html
[error_ stray _357_ in program]: http://www.cnblogs.com/yanzhenan/p/3421918.html
[test.jsp_url_http_3A_2F_2Fimg.my.csdn.net_2Fuploads_2F201304_2F21_2F1366515375_2202.png]: http://202.96.138.158/inc/test.jsp?url=http%3A%2F%2Fimg.my.csdn.net%2Fuploads%2F201304%2F21%2F1366515375_2202.png