简而言之 , fileencoding是Vim中当前编辑的文件的字符编码方式 , Vim保存文件时也会将文件保存为这种字符编码方式 (不管是否新文件都如此) 。
(4)fileencodings
编码的自动识别是通过设置fileencodings实现的 , 注意是复数形式 。fileencodings是一个用逗号分隔的列表 , 列表中的每一项是一种编码的名称 。当我们打开文件的时候 , VIM按顺序使用fileencodings中的编码进行尝试解码 , 如果成功的话 , 就使用该编码方式进行解码 , 并将fileencoding设置为这个值 , 如果失败的话 , 就继续试验下一个编码 。
因此 , 我们在设置fileencodings的时候 , 一定要把要求严格的、当文件不是这个编码的时候更容易出现解码失败的编码方式放在前面 , 把宽松的编码方式放在后面 。例如 , latin1是一种非常宽松的编码方式 , 任何一种编码方式得到的文本 , 用latin1进行解码 , 都不会发生解码失败——当然 , 解码得到的结果自然也就是理所当然的“乱码” 。因此 , 如果你把latin1放到了fileencodings的第一位的话 , 打开任何中文文件都是乱码也就是理所当然的了 。
以下是网上推荐的一个fileencodings设置:
set fileencodings=ucs-bom , utf-8 , cp936 , gb18030 , big5 , euc-jp , euc-kr , latin1
其中 , ucs-bom是一种非常严格的编码 , 非该编码的文件几乎没有可能被误判为ucs-bom , 因此放在第一位 。
utf-8也相当严格 , 除了很短的文件外(例如许多人津津乐道的GBK编码的“联通”被误判为UTF-8编码的经典错误) , 现实生活中一般文件是几乎不可能被误判的 , 因此放在第二位 。
接下来是cp936和gb18030 , 这两种编码相对宽松 , 如果放前面的话 , 会出现大量误判 , 所以就让它们靠后一些 。cp936的编码空间比gb18030小 , 所以把cp936放在gb18030前面 。
至于big5、euc-jp和euc-kr , 它们的严格程度和cp936差不多 , 把它们放在后面 , 在编辑这些编码的文件的时候必然出现大量误判 , 但这是Vim内置编码探测机制没有办法解决的事 。由于中国用户很少有机会编辑这些编码的文件 , 因此我们还是决定把cp936和gb18030放在前面以保证这些编码的识别 。
最后就是latin1了 。它是一种极其宽松的编码 , 以至于我们不得不把它放在最后一位 。不过可惜的是 , 当你碰到一个真的latin1编码的文件时 , 绝大部分情况下 , 它没有机会fall-back到latin1 , 往往在前面的编码中就被误判了 。不过 , 正如前面所说的 , 中国用户没有太多机会接触这样的文件 。
如果编码被误判了 , 解码后的结果就无法被人类识别 , 于是我们就说 , 这个文件乱码了 。此时 , 如果你知道这个文件的正确编码的话 , 可以在打开文件的时候使用 ++enc=encoding 的方式来打开文件 , 如:
:e ++enc=utf-8 myfile.txt
上面就是Linux解决Vim显示utf-8文档乱码的方法介绍了 , 出现该乱码问题后 , 可通过重新设置fileencodings来解决 , 希望对你有所帮助 。
推荐阅读
- 在Linux上如何安装使用SoundCloud
- Ubuntu安装PlayOnLinux的步骤
- Linux各版本安装BleachBit的命令大全
- 如何在Linux下使用Git
- Linux无网络安装GCC的技巧
- word显示绿色调回白色
- Linux SVN工具命令汇总
- Linux系统中strace操作实例汇总
- iphone12显示电量百分比
- 苹果xr没有显示电量百分比
