当前时区为 UTC + 8 小时



发表新帖 回复这个主题  [ 24 篇帖子 ]  前往页数 1, 2  下一页
作者 内容
1 楼 
 文章标题 : vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-16 15:26 
头像

注册: 2008-01-22 23:24
帖子: 773
地址: 三亚
送出感谢: 1
接收感谢: 15
先说明下我的环境: windows xp + gvim 7.3
代码:
" 新建文件时文件编码默认为utf-8
set fileencoding=utf-8

" 打开文件时按照fileencodings指定的文件编码顺序进行检测
set fileencodings=ucs-bom,utf-8,cp936,gb18030,big5,euc-jp,euc-kr,latin1

上面的两行代码来自我vimrc文件,用于编码检测
附件:
vim_start.txt [109.7 KiB]
被下载 32 次


这个文件我用notepad++打开,显示的编码是ansi as utf-8,也就是utf-8 without bom。可是用vim打开却检测成了cp936,内容显示为乱码了。
我看了下fileencodings的说明,其中有这么一句:
引用:
Vim 尝试使用本列表第一个字符编码。如果检测到错误,使用列表的下一个。

我的疑问是:vim在使用utf-8的时候,为什么会出现错误,导致vim使用下一个编码?为什么vim在使用cp936的时候,竟然没有出现错误,导致vim设置fileencoding为cp936?


_________________
牛牛博客
linux 系统中 Chrome 地址栏输入卡顿的解决方法
Linux 下 MPV 和 VLC 播放器 VAAPI 显卡加速对比
---
using : openSUSE 13.2 ( 3.16.6-2 x86_64 ) , KDE 4.14.2


页首
 用户资料  
 
2 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-16 16:28 
头像

注册: 2009-04-11 23:46
帖子: 4130
系统: Arch Linux
送出感谢: 11
接收感谢: 124
rpwt。我这里 UTF-8 正常打开。


_________________
我的博客 https://blog.lilydjwg.me/
提问的智慧
Arch Linux 中文论坛

我的vimrc: https://git.io/vimrc


页首
 用户资料  
 
3 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-16 16:35 
头像

注册: 2005-08-14 21:55
帖子: 58428
地址: 长沙
送出感谢: 4
接收感谢: 274
说不定那win版本的vim。强制了cp936
你可以去irc问下。有人在win下用。


_________________
● 鸣学


页首
 用户资料  
 
4 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-16 17:26 
头像

注册: 2008-01-22 23:24
帖子: 773
地址: 三亚
送出感谢: 1
接收感谢: 15
lilydjwg 写道:
rpwt。我这里 UTF-8 正常打开。

如果说是rpwt,那我的理解就是vim的容错机制做的不好。有些程序在你这里跑得欢畅,在别人那里就错误百出,典型的对环境检测和容错不够。
eexpress 写道:
说不定那win版本的vim。强制了cp936
你可以去irc问下。有人在win下用。

这个应该不是了,因为我的机器上绝大多数utf8 without bom的文件都能正常显示。


_________________
牛牛博客
linux 系统中 Chrome 地址栏输入卡顿的解决方法
Linux 下 MPV 和 VLC 播放器 VAAPI 显卡加速对比
---
using : openSUSE 13.2 ( 3.16.6-2 x86_64 ) , KDE 4.14.2


页首
 用户资料  
 
5 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-16 17:29 
头像

注册: 2008-01-22 23:24
帖子: 773
地址: 三亚
送出感谢: 1
接收感谢: 15
我说下我现在的解决方法吧。
1,安装fencview.vim
2,拷贝tellenc.exe到$VIMRUNTIME目录下
3,做如下配置
代码:
" 打开文件时按照fileencodings指定的文件编码顺序进行检测
set fileencodings=ucs-bom,utf-8,cp936,gb18030,big5,euc-jp,euc-kr,latin1

" 通过fencview插件进行编码检测
let g:fencview_autodetect = 1
let g:fencview_auto_patterns = '*'

注意,这么设置后,vim内置的检测机制和fencview的检测都是在工作的,还能工作的很好,至少在我的机器上是这样的。


_________________
牛牛博客
linux 系统中 Chrome 地址栏输入卡顿的解决方法
Linux 下 MPV 和 VLC 播放器 VAAPI 显卡加速对比
---
using : openSUSE 13.2 ( 3.16.6-2 x86_64 ) , KDE 4.14.2


页首
 用户资料  
 
6 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-16 17:52 
头像

注册: 2009-04-11 23:46
帖子: 4130
系统: Arch Linux
送出感谢: 11
接收感谢: 124
redhatlinux10 写道:
lilydjwg 写道:
rpwt。我这里 UTF-8 正常打开。

如果说是rpwt,那我的理解就是vim的容错机制做的不好。有些程序在你这里跑得欢畅,在别人那里就错误百出,典型的对环境检测和容错不够。


请问这和容错机制有什么关系?人家 Windows 下的 iconv.dll 就是不支持你文件 243 行的制表字符你让 Vim 怎么办?难道你让 Vim 默认 Windows 下 iconv.dll 有 bug?有 bug 又怎么办?怎么容错?明明出错了却当作什么错误都没有发生?


_________________
我的博客 https://blog.lilydjwg.me/
提问的智慧
Arch Linux 中文论坛

我的vimrc: https://git.io/vimrc


页首
 用户资料  
 
7 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-16 17:57 
头像

注册: 2009-04-11 23:46
帖子: 4130
系统: Arch Linux
送出感谢: 11
接收感谢: 124
另外说下,那些制表字符无法转换到 cp936。再说下,你那些 cp936 之后 latin1 之前写的编码名完全无用的。别哪天发现你的 big5 文件在 Vim 下被识别成了 cp936 又怪 Vim 的中文支持不好!


_________________
我的博客 https://blog.lilydjwg.me/
提问的智慧
Arch Linux 中文论坛

我的vimrc: https://git.io/vimrc


页首
 用户资料  
 
8 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-16 23:22 
头像

注册: 2007-03-24 23:45
帖子: 2357
送出感谢: 0 次
接收感谢: 9
没事多看看手册
还有, 最好别乱用特殊字符, ascii 码最高


页首
 用户资料  
 
9 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-17 9:39 
头像

注册: 2008-01-22 23:24
帖子: 773
地址: 三亚
送出感谢: 1
接收感谢: 15
lilydjwg 写道:
redhatlinux10 写道:
lilydjwg 写道:
rpwt。我这里 UTF-8 正常打开。

如果说是rpwt,那我的理解就是vim的容错机制做的不好。有些程序在你这里跑得欢畅,在别人那里就错误百出,典型的对环境检测和容错不够。


请问这和容错机制有什么关系?人家 Windows 下的 iconv.dll 就是不支持你文件 243 行的制表字符你让 Vim 怎么办?难道你让 Vim 默认 Windows 下 iconv.dll 有 bug?有 bug 又怎么办?怎么容错?明明出错了却当作什么错误都没有发生?

我们假定我这个问题是由于iconv.dll引起的。
根据我的了解,iconv.dll是gnu项目的,非windows系统自带
我也没有给vim安装这个iconv.dll
那如果问题真是iconv.dll引起,那就说明了vim自带了iconv.dll,说明了iconv.dll是vim自带的第三方组件。
好了,我来打个比喻:
我的A产品中使用到了apache项目的dbcp连接池组件,刚开始的时候,dbcp工作的很好,客户也很开心,狠狠地赞美了一番我们产品,我心中暗自窃喜;后来dbcp出问题啦,出现了很多连接没有正常关闭导致数据库资源被大量消耗的现象,客户急了,说你们这是什么破产品,把我的数据库都搞死了,这时我委屈的说:这不关我的事情呀,我们用的是dbcp,是apache组织的,你要问责你找他们去!
看,有功劳的时候,自己揽下了;出问题的时候,推到第三方组件身上。我做的很不厚道呀。

lilydjwg 写道:
另外说下,那些制表字符无法转换到 cp936。再说下,你那些 cp936 之后 latin1 之前写的编码名完全无用的。别哪天发现你的 big5 文件在 Vim 下被识别成了 cp936 又怪 Vim 的中文支持不好!

感谢指出在vim中存在的cp936和big5的问题!
我另外搜索参考了一些文章:
tellenc.exe作者的文章 http://www.ibm.com/developerworks/cn/linux/l-tip-vim1/
滇狐的文章 http://edyfox.codecarver.org/html/vim_f ... ction.html
这两篇文章中都直接或者间接的指出了fileencodings检测机制的不足(尝试使用某一个编码来解码文件,看是否报错),特别是Vim 不能识别 8 比特编码中的错误,使得vim不能区分big5和gb编码,这不能不说是vim的不足之处。
坦率地说,尝试解码,失败再换下一个,这个方式,在我看来,并不是一个好的方式;这种方式失败率太高;而基于词频统计的检测机制则好很多,比如mozilla项目的chardet,但终究也会有失手的时候;在我经手的项目中就出现过,编码检测,本质上来说,都是不精确的。

lilydjwg你也莫急,你那么多的感叹号,让我感觉你情绪波动了。对不起,我的错。你解答了我很多的vim疑问,我应该感谢你,而不是惹怒你。你莫生气,我的贴你以后还会回的,是吧 :em06
我也算是vim的爱好者,你看我在本坛发达帖子多数都是和vim有关的就知道了。我也不是在派vim的不是,只是有问题我们应该正视。

补充一下:我那个问题应该和iconv.dll没有关系的,因为我的系统上没有这个文件呀。如理解有误,还望指正。


_________________
牛牛博客
linux 系统中 Chrome 地址栏输入卡顿的解决方法
Linux 下 MPV 和 VLC 播放器 VAAPI 显卡加速对比
---
using : openSUSE 13.2 ( 3.16.6-2 x86_64 ) , KDE 4.14.2


页首
 用户资料  
 
10 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-17 9:42 
头像

注册: 2005-08-14 21:55
帖子: 58428
地址: 长沙
送出感谢: 4
接收感谢: 274
恩,不激动。点点事情。

我还是怀疑版本问题。 lol


_________________
● 鸣学


页首
 用户资料  
 
11 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-17 10:27 
头像

注册: 2008-03-28 20:52
帖子: 1470
系统: QNX
送出感谢: 12
接收感谢: 2
一般没问题.字幕经常会一会正常一会乱码


_________________
missing is i missing you...


页首
 用户资料  
 
12 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-17 13:09 
头像

注册: 2009-04-11 23:46
帖子: 4130
系统: Arch Linux
送出感谢: 11
接收感谢: 124
redhatlinux10 写道:
这两篇文章中都直接或者间接的指出了fileencodings检测机制的不足(尝试使用某一个编码来解码文件,看是否报错),特别是Vim 不能识别 8 比特编码中的错误,使得vim不能区分big5和gb编码,这不能不说是vim的不足之处。
坦率地说,尝试解码,失败再换下一个,这个方式,在我看来,并不是一个好的方式;这种方式失败率太高;而基于词频统计的检测机制则好很多,比如mozilla项目的chardet,但终究也会有失手的时候;在我经手的项目中就出现过,编码检测,本质上来说,都是不精确的。

要词频检测的话你给 Vim 打补丁吧,他们那群人似乎对此毫不在意。
引用:
lilydjwg你也莫急,你那么多的感叹号,让我感觉你情绪波动了。对不起,我的错。你解答了我很多的vim疑问,我应该感谢你,而不是惹怒你。你莫生气,我的贴你以后还会回的,是吧 :em06
我也算是vim的爱好者,你看我在本坛发达帖子多数都是和vim有关的就知道了。我也不是在派vim的不是,只是有问题我们应该正视。

补充一下:我那个问题应该和iconv.dll没有关系的,因为我的系统上没有这个文件呀。如理解有误,还望指正。


我可没用感叹号,那是是问号!

应该不会没有 iconv.dll 的呀。不过后来我想了想,确实不是 iconv 的问题。Vim 在尝试 UTF-8 解码时,它会把编码转换到 'enc' 选项指定的编码,而那些字符是无法转换成 cp936 的。所以 iconv.dll (或者其它转码机制)告诉 Vim 转码失败了。于是 Vim 尝试下一项。整个过程中,Vim 没有错,iconv 也没有错。非要说谁错了,那只能说是你的 'enc' 设置错了。Vim 默认为系统所使用的编码,我想这点应该没什么问题吧?

不过在我这里即使把 'enc' 设成 'utf-8' 那些字符显示得还是不对。这个要么是字体的问题,要么是 Windows 的 Unicode 支持的问题。


_________________
我的博客 https://blog.lilydjwg.me/
提问的智慧
Arch Linux 中文论坛

我的vimrc: https://git.io/vimrc


页首
 用户资料  
 
13 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-17 15:37 
头像

注册: 2011-03-18 17:42
帖子: 59
送出感谢: 0 次
接收感谢: 0 次
redhatlinux10 写道:
lilydjwg 写道:
redhatlinux10 写道:
lilydjwg 写道:
rpwt。我这里 UTF-8 正常打开。

如果说是rpwt,那我的理解就是vim的容错机制做的不好。有些程序在你这里跑得欢畅,在别人那里就错误百出,典型的对环境检测和容错不够。


请问这和容错机制有什么关系?人家 Windows 下的 iconv.dll 就是不支持你文件 243 行的制表字符你让 Vim 怎么办?难道你让 Vim 默认 Windows 下 iconv.dll 有 bug?有 bug 又怎么办?怎么容错?明明出错了却当作什么错误都没有发生?

我们假定我这个问题是由于iconv.dll引起的。
根据我的了解,iconv.dll是gnu项目的,非windows系统自带
我也没有给vim安装这个iconv.dll
那如果问题真是iconv.dll引起,那就说明了vim自带了iconv.dll,说明了iconv.dll是vim自带的第三方组件。
好了,我来打个比喻:
我的A产品中使用到了apache项目的dbcp连接池组件,刚开始的时候,dbcp工作的很好,客户也很开心,狠狠地赞美了一番我们产品,我心中暗自窃喜;后来dbcp出问题啦,出现了很多连接没有正常关闭导致数据库资源被大量消耗的现象,客户急了,说你们这是什么破产品,把我的数据库都搞死了,这时我委屈的说:这不关我的事情呀,我们用的是dbcp,是apache组织的,你要问责你找他们去!
看,有功劳的时候,自己揽下了;出问题的时候,推到第三方组件身上。我做的很不厚道呀。

lilydjwg 写道:
另外说下,那些制表字符无法转换到 cp936。再说下,你那些 cp936 之后 latin1 之前写的编码名完全无用的。别哪天发现你的 big5 文件在 Vim 下被识别成了 cp936 又怪 Vim 的中文支持不好!

感谢指出在vim中存在的cp936和big5的问题!
我另外搜索参考了一些文章:
tellenc.exe作者的文章 http://www.ibm.com/developerworks/cn/linux/l-tip-vim1/
滇狐的文章 http://edyfox.codecarver.org/html/vim_f ... ction.html
这两篇文章中都直接或者间接的指出了fileencodings检测机制的不足(尝试使用某一个编码来解码文件,看是否报错),特别是Vim 不能识别 8 比特编码中的错误,使得vim不能区分big5和gb编码,这不能不说是vim的不足之处。
坦率地说,尝试解码,失败再换下一个,这个方式,在我看来,并不是一个好的方式;这种方式失败率太高;而基于词频统计的检测机制则好很多,比如mozilla项目的chardet,但终究也会有失手的时候;在我经手的项目中就出现过,编码检测,本质上来说,都是不精确的。

lilydjwg你也莫急,你那么多的感叹号,让我感觉你情绪波动了。对不起,我的错。你解答了我很多的vim疑问,我应该感谢你,而不是惹怒你。你莫生气,我的贴你以后还会回的,是吧 :em06
我也算是vim的爱好者,你看我在本坛发达帖子多数都是和vim有关的就知道了。我也不是在派vim的不是,只是有问题我们应该正视。

补充一下:我那个问题应该和iconv.dll没有关系的,因为我的系统上没有这个文件呀。如理解有误,还望指正。


楼主你那个tellenc.exe哪里来的?要编译???
另外你的编码问题确认完全正常吗?
你的gvim能显示这个字吗?四个龍字叠在一起的字,在这里:http://www.zdic.net/zd/zi3/ZdicF0ZdicAAZdic9AZdicA5.htm 你复制一个到你的gvim里面看看。
如果能正常显示就太好了。因为这个问题我问了很多人都没解决。。。同时编译gvim的那位国人兄弟好像对此并没有兴趣。。。
windows下的notepad或其他编辑器是显示正常的。linux下也是显示正常的。。。


页首
 用户资料  
 
14 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-17 16:01 
头像

注册: 2008-01-22 23:24
帖子: 773
地址: 三亚
送出感谢: 1
接收感谢: 15
lilydjwg 写道:
redhatlinux10 写道:
这两篇文章中都直接或者间接的指出了fileencodings检测机制的不足(尝试使用某一个编码来解码文件,看是否报错),特别是Vim 不能识别 8 比特编码中的错误,使得vim不能区分big5和gb编码,这不能不说是vim的不足之处。
坦率地说,尝试解码,失败再换下一个,这个方式,在我看来,并不是一个好的方式;这种方式失败率太高;而基于词频统计的检测机制则好很多,比如mozilla项目的chardet,但终究也会有失手的时候;在我经手的项目中就出现过,编码检测,本质上来说,都是不精确的。

要词频检测的话你给 Vim 打补丁吧,他们那群人似乎对此毫不在意。
引用:
lilydjwg你也莫急,你那么多的感叹号,让我感觉你情绪波动了。对不起,我的错。你解答了我很多的vim疑问,我应该感谢你,而不是惹怒你。你莫生气,我的贴你以后还会回的,是吧 :em06
我也算是vim的爱好者,你看我在本坛发达帖子多数都是和vim有关的就知道了。我也不是在派vim的不是,只是有问题我们应该正视。

补充一下:我那个问题应该和iconv.dll没有关系的,因为我的系统上没有这个文件呀。如理解有误,还望指正。


我可没用感叹号,那是是问号!

应该不会没有 iconv.dll 的呀。不过后来我想了想,确实不是 iconv 的问题。Vim 在尝试 UTF-8 解码时,它会把编码转换到 'enc' 选项指定的编码,而那些字符是无法转换成 cp936 的。所以 iconv.dll (或者其它转码机制)告诉 Vim 转码失败了。于是 Vim 尝试下一项。整个过程中,Vim 没有错,iconv 也没有错。非要说谁错了,那只能说是你的 'enc' 设置错了。Vim 默认为系统所使用的编码,我想这点应该没什么问题吧?

不过在我这里即使把 'enc' 设成 'utf-8' 那些字符显示得还是不对。这个要么是字体的问题,要么是 Windows 的 Unicode 支持的问题。

我的系统上确实是没有iconv.dll的。
附件:
截图01.jpg
截图01.jpg [ 58.1 KiB | 被浏览 2282 次 ]


我的机器上,gvim的encoding为系统默认的cp936
另外我特意用notepad++和ultraedit试了下,对于243行当几个字符,他们也是显示不正常的。


_________________
牛牛博客
linux 系统中 Chrome 地址栏输入卡顿的解决方法
Linux 下 MPV 和 VLC 播放器 VAAPI 显卡加速对比
---
using : openSUSE 13.2 ( 3.16.6-2 x86_64 ) , KDE 4.14.2


页首
 用户资料  
 
15 楼 
 文章标题 : Re: vim内置的文件编码检测机制好像不完善呀
帖子发表于 : 2011-06-17 16:27 
头像

注册: 2008-01-22 23:24
帖子: 773
地址: 三亚
送出感谢: 1
接收感谢: 15
小小输入法 写道:
楼主你那个tellenc.exe哪里来的?要编译???
另外你的编码问题确认完全正常吗?
你的gvim能显示这个字吗?四个龍字叠在一起的字,在这里:http://www.zdic.net/zd/zi3/ZdicF0ZdicAAZdic9AZdicA5.htm 你复制一个到你的gvim里面看看。
如果能正常显示就太好了。因为这个问题我问了很多人都没解决。。。同时编译gvim的那位国人兄弟好像对此并没有兴趣。。。
windows下的notepad或其他编辑器是显示正常的。linux下也是显示正常的。。。

http://wyw.dcweb.cn/download.asp?path=&file=tellenc.zip
vim_start.txt这个文件在我这边的gvim里面,整体上是可以显示的,但是243行那些字符还是问号

三个龍字叠在一起的字,我用搜狗拼音,谷歌拼音我打不出来,极品五笔(UEGD)也不行呀,郑码可以打出来。gvim是可以显示的,保存后再打开也是可以的。
附件:
截图02.jpg
截图02.jpg [ 52.63 KiB | 被浏览 2274 次 ]



_________________
牛牛博客
linux 系统中 Chrome 地址栏输入卡顿的解决方法
Linux 下 MPV 和 VLC 播放器 VAAPI 显卡加速对比
---
using : openSUSE 13.2 ( 3.16.6-2 x86_64 ) , KDE 4.14.2


页首
 用户资料  
 
显示帖子 :  排序  
发表新帖 回复这个主题  [ 24 篇帖子 ]  前往页数 1, 2  下一页

当前时区为 UTC + 8 小时


在线用户

正在浏览此版面的用户:没有注册用户 和 2 位游客


不能 在这个版面发表主题
不能 在这个版面回复主题
不能 在这个版面编辑帖子
不能 在这个版面删除帖子
不能 在这个版面提交附件

前往 :  
本站点为公益性站点,用于推广开源自由软件,由 DiaHosting VPSBudgetVM VPS 提供服务。
我们认为:软件应可免费取得,软件工具在各种语言环境下皆可使用,且不会有任何功能上的差异;
人们应有定制和修改软件的自由,且方式不受限制,只要他们自认为合适。

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
简体中文语系由 王笑宇 翻译