由于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

[plain]  view plain  copy
  1. test bomb or nobomb  
  2. ~  
  3. ~  
  4. ~  
  5. ~  
  6. ~  
  7. ~  
  8. ~  
  9. ~  
  10. ~  

查询BOM结果:(set bomb ?)

[plain]  view plain  copy
  1. ~  
  2. ~  
  3. ~  
  4. ~  
  5. ~  
  6. nobomb  

更改BOM结果:(set bomb)

[plain]  view plain  copy
  1. ~  
  2. ~  
  3. ~  
  4. ~  
  5. ~  
  6. ~  
  7. bomb  

保存后再次打开就会发现如下图所示:


而且我们对于上传过来的源代码没法做修改,网上有人说可以删除BOM(grep -I -r -l $'\xEF\xBB\xBF' * | xargs sed -i 's/^\xEF\xBB\xBF//;'),我试过了不行,不知哪位大牛指点下?检查文件中是否含BOM的命令为:

[plain]  view plain  copy
  1. grep -I -r -l $'\xEF\xBB\xBF' *  

这个命令是有效的。

既然没法靠在linux下有什么命令删除BOM,那咱们只能从源头处理了,编码更改为无BOM的UTF-8编码格式。Notepad++有转换此格式的选项:


转换过后保存下然后再传到linux服务器上,问题就解决了!!

另:这个问题在sun环境和Hp环境下没有此问题,我不清楚如果忽略这个问题在编译时或程序运行时是否会产生异常,网上有人反映是有的,所以还是建议麻烦些也不要忽略此问题,谁晓得它会惹出什么麻烦呢微笑

GitHub 加速计划 / li / linux-dash
10.39 K
1.2 K
下载
A beautiful web dashboard for Linux
最近提交(Master分支:2 个月前 )
186a802e added ecosystem file for PM2 4 年前
5def40a3 Add host customization support for the NodeJS version 4 年前
Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐