Issue 123 in vimim: 关于 标准字库 vimim.cjk.txt 的黑框问题

[vi...@googlecode.com]

Status: Accepted
Owner: maxiangjiang
Labels: Type-Defect Priority-Medium

New issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

Comment by suxp...@gmail.com:

Line-by-line comments:

File: /trunk/plugin/vimim.cjk.txt (r7493)
===============================================================================

Line 563: 倲㑈 321251 2529 dong1
-------------------------------------------------------------------------------
这儿有个小黑框。后面还有很多
Line 594: 偑㐽 323532 2721 feng1
-------------------------------------------------------------------------------
比如这里，
Line 825: 儸㑩 322522 2621 luo2
-------------------------------------------------------------------------------
这里，
Line 1168: 劏㓥 243452 9260 tang1
-------------------------------------------------------------------------------
这里，
Line 1179: 劚㔉 513241 7220 zhu2
-------------------------------------------------------------------------------
这里，
Line 2139: 噚㖊 251511 6704 xun2
-------------------------------------------------------------------------------
这里……
Line 3249: 媰㛀 531355 4742 zou1
-------------------------------------------------------------------------------
后面还有好多好多。至少我这边的表现是用Vim开这个文件，自动检测编码失败（跟原
来vimim.vim中Shift-2对应的符号无法识别时效果相同），只能手工设置enc=utf8才正
常显示，但对应的这些地方是黑色小方块；借着Firefox的力量，直接从Google Code上
开这个文件看了下，——果然也是小方块。

For more information:
http://code.google.com/p/vimim/source/detail?r=7493

[vi...@googlecode.com]

Comment #1 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

初步研究，发现这是GBK的问题，或者说是GBK和UNICODE和平共处的难题。
这个问题其实不是VimIM本身的问题，应该说与VimIM无关。

其一，我们希望支持的是全部20902个UNICODE汉字

开始：一 (u4e00) 100000 1000 yi1 a one 2
结束：龥 (u9fa5) 341251 8128 yu4


其二，这20902个UNICODE汉字，在utf8编码的英文OS中毫无问题。
就语言而言，英文OS应该是全世界最简单的OS

我的vimrc相关设置如下：

set keymodel=startsel,stopsel fo+=mM ambiwidth=double
set guifontwide=YaHei_Consolas_Hybrid
set enc=utf8
set fencs=ucs-bom,utf8,chinese
set gfn=Courier_New:h12:w7

其三，问题从 563 行开始出现。
line 563: 倲㑈 321251 2529 dong1

命令行测试如下：

head -562 vimim.cjk.txt > 562
iconv -f utf-8 -t gbk 562

head -563 vimim.cjk.txt > 563
iconv -f utf-8 -t gbk 563

iconv: 563:563:2: cannot convert

歪招：能不能把怪字找出来？或者分为二个版本:

vimim.cjk.txt
vimim.gbk.txt

[vi...@googlecode.com]

Comment #2 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt 的
黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

我也是英文系统，——当然编码是GBK（D了个Windows XP Pro en-n with SP3，这个OS简
单到连媒体播放器都没有），——我不知道Win下怎么设定默认编码为UTF8，这个系统安
装时如果不勾选东方语言支持连汉字字体(e.g., SimSun.ttf)都没有。

好吧幸好还有个更加无敌的系统可以用，进GNU/Linux看看是什么状况。嗯，看来果然
还是UTF8下比较正常，——相对而言。系统为Ubuntu 10.04，汉字字体自然是文泉驿，分
别在Firefox跟Vim里面打开文件，黑框问题确实不存在，并且汉字可以显示出来
（Vim编码检测或许也没有问题，但因为默认就是UTF8，谁知道呢）。问题在于，或许
文泉驿微米黑/正黑字体中没有这些字，于是Fallback到Bitmap Song还是怎么，显示效
果不一样。见附图。

也就是说GBK中本来没有这些字，所以才不能转换，然后Win下因为字体中没有这些字才
显示成黑框？

Attachments:
unicode_GBK.png 56.9 KB

[vi...@googlecode.com]

Comment #3 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123


我发现我太抬举Windows英文系统了。在缺省的设置下，Windows英文系统
应该不能显示我们的标准字库。若干年以前，我浪费过若干个小时，努力
学习如何“勾选东方语言支持”。最后一了百了，全部放弃。由此
产生VimIM, 原生原味的中文输入方式 :)

被迫拿到Windows英文系统之后，我需要做一件事，就是安装中文字体。
我发现最简单的方式就是下载ttf文件，而最好的字体是YaHei.Consolas.ttf
雅黑来自微软，微软居然有好东东，我实事求是发帖表扬过。

GBK应该是比中文字体还要大的一个概念。不过，还是应该可以安装
微软雅黑中文字体？能不能试一试？ 如果黑框依然存在，那就是GBK的
问题。GBK千好万好，如果不能完整显示20902个汉字，那就谈不上好。

也许，鬼姥不懂中国国情，不经过国务院批准，强行规定UNICODE, 拼凑
出太多的汉字？GBK才是王道，才是正宗。如果属实，我们可以删除所有
黑框条目，更新我们的标准字库，如何?

[vi...@googlecode.com]

Comment #4 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt 的
黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

初步确认，黑框跟GBK似乎无关，问题真的出在字体上。

首先我也想到的字体问题。由于Ubuntu中字体的表现不一样，跑到文泉驿上面准备看看
微米黑是不是真的没有这些汉字，虽然跑过去之后跑题了（在知道文泉驿之后就一直有
帮它造字的想法却一直没实施，正好这次借着这个时机，时隔多年后开始参与造
字，:)）

但是，在参与造字时发现那些扩展汉字我这里真的都显示不出来，——但接着在边上提示
说Windows下（可能）需要安装GB18030补丁，于是虽然我已经是SP3，按照上面的说法
SP2应该就不需要了，但还是安装了那个东西。——今天回来一看，咦？浏览器中竟然就
显示出来了！！

为了确定真的是字体问题，Vim开vimim.cjk.txt，:set enc=utf8，563G来到黑框面
前，重新设定字体（因为不知道有哪些字体能用，于是背着良心用图形对话框来换字体
了），发现似乎多了两个18030结尾的汉字字体，果断选择，显示正常。

据此猜测，显示成黑框是因为字体中没有，按照Linux风格似乎应该是显示成Hex编码的
黑框（事实上在浏览器中玩文泉驿造字我就看到那些东西了，以及曾经SCIM的内码输入
法乱敲时）但Win下显示成了黑框（或者干脆只是个方框）；而无法自动检测编码的原
因可能在于Vim本身的编码检测方法在遇到扩展汉字时失效？

若当真如此，——似乎应该说这个跟VimIM无关了。

[vi...@googlecode.com]

Comment #5 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt 的
黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

BTW 那个“勾选东方语言支持”在Control Panel->Regional and Language Options的
language标签中，Supplemental language support的第二个复选框就是，标准的说法
是"Install files for East Asian languages"，我因为记不得了所以就说成那样了。
这会安装上至少有宋体、黑体、新宋体这几款字体（事实上到现在我也只有这几款汉字
字体，——18030后缀的不算，那些楷体GB2312之类的是安装MS Office才会安装的，而到
Vista及Win7，字体便多了好多，比如雅黑，而且收录的汉字范围也大了，比如楷体
GB_2312改名叫楷体，已经不仅仅包含GB2312的汉字和符号了），以及输入法支持，如
果是安装完系统之后再勾选，会需要插入安装光盘。

[vi...@googlecode.com]

Comment #6 on issue 123 by pan.shi...@gmail.com: 关于 标准字库
vimim.cjk.txt 的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

我不知道你们的过程，不过我想说，建议对于所有的出现 gb2312或者gbk 相关的地
方，都使用 gb18030 代替，这样可以解决绝大部分编码相关问题。

不论gb2312还是gbk，都不包含unicode中的所有字符，因此在编码转换中经常可能出问
题。如果一定要用GB系的编码集，请使用 gb18030。

gb18030向下兼容gb2312和gbk的全部字符，同时与unicode中的全部字符拥有一一对应
关系。如果需要与 unicode 之间相互转换，请永远不要使用 gbk。直接使用 gb18030
即可。

对于 vimim 中提出的那个配置文件，我看到一个：
set fencs=ucs-bom,utf8,chinese
注意，这里chinese实际就会对应到cp936，然后它实际就是gbk，建议使用gb18030代
替，或者后缀增加gb18030，例如 set fencs=ucs-bom,utf8,chinese,gb18030

在使用 iconv 的时候，建议永远不要把 unicode 同 gbk 转换，永远只使用
gb18030。

关于字体：注意新的字体都是 unicode 的，而 gbk 不包含所有 unicode，因此，GBK
是比中文字体还要“小”的概念。此时也同样应当换用 gb18030。

[vi...@googlecode.com]

Comment #7 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

说的还真是。命令行测试如下：

iconv -f utf-8 -t gb18030 vimim.cjk.txt > out
iconv -f utf-8 -t gbk vimim.cjk.txt > out #error: iconv: cannot convert

用上gb18030, 顺风顺水，没有用gbk的错误信息。

看来有必要通知Bram更新vim help, 因为我们找不到gb18030:

Supported 'encoding' values are: *encoding-values*

-------------------------------------------------------------------------
2 cp936 simplified Chinese (Windows only)
2 euc-cn simplified Chinese (Unix only)
2 cp950 traditional Chinese (on Unix alias for big5)
2 big5 traditional Chinese (on Windows alias for cp950)
2 euc-tw traditional Chinese (Unix only)
2 prc simplified Chinese: on Unix "euc-cn", on MS-Windows cp936
2 chinese same as "prc"
2 taiwan traditional Chinese: on Unix "euc-tw", on MS-Windows cp950
u utf8 same as utf-8

-------------------------------------------------------------------------

每次领到新手提电脑(Windows, English OS)以后，我只会做一件事。
下载YaHei.Consolas.ttf然后鼠标双击。这样，搞掂vim和firefox的中文显示。
我的Vim/VimIM缺省用的是utf8, 没有什么gb2313/gbk/gb18030之类的问题和要求。

问题：既然gb18030没有我们讨论的黑框问题，为什么gb18030不是缺省呢？

[pansz]

2011/4/6 <vi...@googlecode.com>:
>
> 问题：既然gb18030没有我们讨论的黑框问题，为什么gb18030不是缺省呢？
> --

这个问题可能是历史原因，因为发明 gb2312/gbk 的年代，unicode 还根本没有普及，那时不存在 unicode/gbk 之间的转换问题。

gb18030 是在有 unicode 之后才诞生的一种标准，他本身的目的就是在兼容 gbk 的前提下补充所有的 unicode 字符。他与
unicode 之间的转换是安全可靠的。

当然还有另外一个问题是，【据说】目前的操作系统都没有没有能够完整的支持
gb18030。不过这只是据说，因为我实际测试中，好像主要的操作系统处理 gb18030 都没有什么困难。

[vi...@googlecode.com]

Comment #8 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt 的
黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

set fencs=gb18030
开vimim.cjk.txt仍然无法检测出文本编码格式，显示乱码，需要手工设定……

这样看来，在这个扩展汉字的显示问题上，“不折腾”已经不太可能了，——至少需要设定
enc=utf8跟汉字字体为大字库（默认好像是Fixedsys）但set enc=utf8这个，在
Windows下仍有诸多不便（一旦设定这个便需要改很多，而且菜单就只好恢复原样
了，——虽然一般用不到菜单）

[vi...@googlecode.com]

Comment #9 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

我只用一个setting, 天下无敌：
set enc=utf8 guifontwide=YaHei_Consolas_Hybrid

至于Vim菜单，从来没有用过。
记得还琢磨过如何斩草除根，减少点gvim.exe的体重。

[vi...@googlecode.com]

Comment #10 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

可能只是在您的机器上无敌，达不到天下之广阔……

如果只set enc=utf8，如果language是中文而不是英文，需要重新设定一些东西才能让
比如Message之类正常，否则都是乱码。如果还有在Cmd下使用vim的需求（好吧我可能
是个案- -||）又需要N多设定，而且效果也不好……

正因为这些折腾很烦人，而且没多少效果，很久以前我已经不再在Windows下设定
enc=utf8了，——虽然似乎所有提到Vim配置的地方都在这么设定。我想也正是因为Win的
默认编码不是UTF8，所以Vim的Windows版本才默认成GBK。

[pansz]

2011/4/6 <vi...@googlecode.com>:

> Comment #10 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt 的黑框问题
> http://code.google.com/p/vimim/issues/detail?id=123
> 可能只是在您的机器上无敌，达不到天下之广阔……
> 如果只set
> enc=utf8，如果language是中文而不是英文，需要重新设定一些东西才能让比如Message之类正常，否则都是乱码。如果还有在Cmd下使用vim的需求（好吧我可能是个案-
> -||）又需要N多设定，而且效果也不好……

事实上你的案例确实非常之个案，例如安装的时候直接不安装语言支持就会强制使用英文message，又例如cygwin下面的vim比cmd 下的vim 靠谱得多。。。

当然，作为自由软件而言通常不应当强迫用户的使用习惯。所以你的使用方式仍然是可以支持的，虽然需要多一些折腾。（虽然vim其实并不是狭义上的自由软件）

不知道 tenc 之类的设定能不能解决你的问题。不过问题总是会有解决的办法的。

我相信最好的方式也许仍然是：把enc设定为
utf-8，然后勇敢的面对与解决这带来的一系列相关问题，毕竟vim_use列表还是非常活跃而友善的，而vim基本只在
enc=utf-8下进行了完善的测试。

[vimim]

>> 例如安装的时候直接不安装语言支持就会强制使用英文message

其实，所谓语言支持应该都是从英文强行翻译过来的。直接读英文可能
反而省时间。vim的英文写得相当的地道，而带着兴趣学习是最有有效的。

不过，学习总不是一件赏心悦目的美差。我曾下决心学拼音，一直没有学会。

感觉学习vim"语言支持"有关的英文应该比学拼音快，因为只要求"读"，
而学拼音要求"写"。漏掉一个g, 点石成金出来的不是金而是碘。

On Apr 5, 11:07 pm, pansz <pan.shi...@gmail.com> wrote:
> 2011/4/6 <vi...@googlecode.com>:
>
> > Comment #10 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt 的黑框问题
> >http://code.google.com/p/vimim/issues/detail?id=123

> > 可能只是在您的机器上无敌，达不到天下之广阔......

> > 如果只set
> > enc=utf8，如果language是中文而不是英文，需要重新设定一些东西才能让比如Message之类正常，否则都是乱码。如果还有在Cmd下使用vim的需求（好吧我可能是个案-

> > -||）又需要N多设定，而且效果也不好......

[vi...@googlecode.com]

Comment #11 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

> 事实上你的案例确实非常之个案，例如安装的时候直接不安装语言支持就会强制使用
> 英文message

凡是Windows中文版本安装Vim如果什么都不管（下一步下一步），自然而然就是这样
了。Vim检测locale为zh-cn自然不会默认成英文。具体步骤为：找一个中文Windows安
装光盘（或者Ghost镜像）安装到机器，（至少）安装网卡驱动，开IE进www.vim.org下
载Windows版本自安装文件gvim73_xx.exe，双击运行安装程序blahblah，完成，双击桌
面Vim图标，——您可以看看那个Vim长什么样，:no_such_command<CR>看看提示的
Message是不是E文……“不安装语言支持”在安装时确实可以选择，但默认的Typical安装
方案，这个是自动选取的，或者说，Vim的建议安装方案是会将Vim安装成我用的这个样
子的。

> 又例如cygwin下面的vim比cmd 下的vim 靠谱得多
我曾经用过一段时间的Cygwin，后来因为它太庞大而且太依赖于cygwin1.dll等模拟
层，于是弃暗投明转身MSYS阵营（mingw.org）——当然这俩的目的不同，不太具有可比
性。但我相信很多人都不会为了单纯一个vim来安装庞大的Cygwin（Msys的Vim没有开启
多字节支持，似乎目前也没有人编译过支持多字节的Vim for Msys，我也没折腾出来-
-||），况且Cygwin下Vim是不是真的正常了我也不清楚（已经忘了，但那下面好多都是
E文吧？E文的都是ASCII码无所谓转码问题，问题在于中文环境）

至于使用CMD下的Vim，我想应该也不止我一个人有这种需求，——毕竟vim.org也给了
CMD版本。这个问题主要在于Gvim里面运行外部程序（最简单的例子:make）会开
CMD，但CMD版本就不用那么麻烦，所以用起来跟Linux的Console很像，还是比较舒服的
（对，Cygwin下的也是这样）。

所有关于Vim的问题应该都算不得问题，问题出现在万恶的编码转换上，出在MS的CMD上
……CMD认识GBK却不怎么认识UTF8（貌似不是不支持，但我折腾许久没发现怎么用上
），于是如果设定vim的enc=utf8后，则需要:lan message=zh_CN.UTF-8将message编码
换过来防止乱码；需要delmenu再menu将菜单乱码搞定（但顺便自定义都不见了）；以
及tenc=GBK告诉Vim跟terminal沟通时要再翻译一下……等等一串都折腾好，Win+R CMD回
车，开Vim或者直接开Gvim，:make 你就会发现惊喜（而这个惊喜本人不才，找遍大江
南北只找到一个更加折腾人的方案，——给Vim打补丁，而补丁作者说那个补丁也不怎么
好用）。正是因为这一些原因，我果断放弃在Windows下set enc=utf8这件吃力不讨好
的事，即使现在换了个E文系统（伪英文，只有界面啊、帮助啊之类是英文，locale果
断zh-cn）。

Pan兄如果知道如何解决，请一定告诉我。谢谢！！

为了确认我都没有记错，特意找了台中文Windows系统，重新试了下。（我估计这个问
题跟tenc没什么关系，cmd的返回字符串交给Vim时Vim没有正确解码而已）有图有真
相：

Attachments:
vim_gbk.PNG 26.8 KB
vim_utf8.PNG 26.4 KB

[vi...@googlecode.com]

Comment #12 on issue 123 by pan.shi...@gmail.com: 关于 标准字库
vimim.cjk.txt 的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

我大致明白了你的意思，而你的问题似乎是：你需要使用vim，同时需要使用原生中文
Windows下的控制台命令。而原生中文Windows的控制台命令是GB系的。如果需要在
vim之内用utf-8而在vim之外使用gbk，并且需要与之交互，这确实会有问题。

试图去解决 windows cmd 中的问题比较麻烦，它的麻烦之处在于：那些乐于助人
的，有钻研精神的黑客们，大都对 windows cmd 根本不感兴趣，因为一个有缺陷的设
计无法使用任何补丁改善。如果你需要咨询这方面的问题，只能在有限的地方去寻求帮
助。Windows cmd 相关的讨论组肯定存在，不过这超出了 vimim 的范畴了，嗯，你可
以找找看，祝你好运。

我选择完全抛弃 Windows cmd，只使用 Cygwin bash 以及 cygwin 下的控制台命
令，并把 cygwin 的 locale设定为 utf-8

在 Windows 中我避免使用任何原生 Windows 的命令。因此不会存在任何问
题，Cygwin 的优势在于除了内核以外，它跟GNU/Linux的相似度非常高，所以很多命令
很操作都非常流畅没有异常。而在 msys 中或多或少经常容易出问题。

在市面上已经不可能买到 160G 一下硬盘的今天，不到 1G 的 Cygwin 我很难认为它算
是大，是的，既然选择完全抛弃 cmd ，你必然需要有个东西来代替它，cygwin 并不完
美，但它是目前最好的，(debian-interix 是有潜力超越 cygwin 的，但是目前看来这
个项目停掉了。)

从用户的角度，cygwin 比 msys 方便。绝大多数两者共有的软件，cygwin 版本都比
msys 版本更好用，中文支持更好，问题更少，例如同样是 mintty，cygwin 版本的
mintty 都比 msys 版本的 mintty 好用。

这里面的深层次原因是：cygwin 面向普通用户，而 msys 面向 Windows 开发者。

cygwin 假定客户是 GNU 的用户，使用它的目的是想要使用 GNU 环境中的软件。而
msys 假定客户是一个 Windows 开发者，他只是想借用 msys 编译出用于非 GNU 环境
的程序。

即使你根本不编译任何代码，cygwin 仍然有安装的价值，但是如果你自己不编译程序
的话，msys 就没有任何价值。面向用户的软件与面向开发者的软件，在用户使用体验
上自然会有显著差距。

[vi...@googlecode.com]

Comment #13 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

早就听说过微软视窗的危害，只是没想到危害如此之深，如此之烈。

从德智体各方面，无论怎么评估，suxpert同学都是民间高手。
一个民间高手居然被如此折腾，超乎我的想象。

Root Cause 是以微软为中心的心态，认为先有视窗，而后才有天下。
事实微软确实也出了一些好的东西，比如微软雅黑。

不过，微软视窗的精华在于如下applications:

(1) gvim.exe
(2) firefox.exe
(3) cygwin (mintty/hg/python/perl/screen/bash etc)

[vi...@googlecode.com]

Comment #14 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

呃～民间不假，高手谈不上。

刚又blah blah敲了一堆没发上来，说的什么却也被对方某的一腔怒火烧的记不清了
……好吧容我再回忆回忆～～

前面说到CMD对UTF8的支持，刚刚又测试了下chcp 65001，发现这个非但没有解决问题
反而引入了更多问题：批处理似乎都无法执行；甚至Vim.exe也变身乱码无法在Cmd里头
使用，除了空格其他都变成方块，或许又是字体问题Orz。chcp 54936也不能用。好吧
Cmd看来只有在cp936下正常，那就936吧～～

我总感觉，那个乱码问题是因为Vim在跟stdout通信时语言不通。Vim里面执行外部命令
用vimrun.exe，而显示的输出看上去应该是程序的输出跟Vim本身的信息糅合在一起
的。在cmd下，执行外部命令的输出传递给vim，vim添加自己的信息后试图显示出
来，于是将它们传递给cmd……我猜测vim得到stdout的数据后并没有检测编码，而是直接
追加了自己的信息，这样就造成了认为的编码格式跟实际的不同，于是显示乱码。对于
Gvim，对于:make而言特殊点，重定向到文件才在Gvim里面显示出来而造成乱码
（嗯，这也是个问题），但一般的程序会开cmd再输出，没有所谓编码转换的问题。

用cygwin的方案，抛弃cmd投身bash，似乎是在宣告(G)vim for windows没有必要存在
了么？

大可不必。

存在即合理，既然set enc=utf8会出很多很多问题，那如果不去设定它呢？事实上这些
“穷折腾”是不必要的，——Gvim上来已经默认了GBK编码，在enc=gbk时没有任何上述乱码
问题，折腾成utf8反而遇到各种无法妥协的问题，说明或许我们本就不该这么折
腾，——我也早已放弃了在Win下设定enc=utf8，而本着“不折腾”原则和最小惊讶原
则，Win下Vim用户采用这个比较“优秀”的默认设定的人必定很多。算是一种妥协吧，尽
管UTF8是正道，在解决上面那些问题之前，想要vim for windows 继续存在，保持默认
的gbk才是王道。

但默认GBK的问题，就在于最开始提到的，文件编码检测失效。对于那个UTF8编码的
vimim.cjk.txt，vim打开给当成gbk编码来显示于是乱码；但手工设定enc=utf8虽然会
暂时显示正确，——像前面说的，Windows下Vim一旦设定enc=utf8就会出现一堆问题，似
乎也不是个好的解决方法。

Pan兄又提到，GBK里面没有那些汉字所以无法转换，但是GB18030却可以。那么，如何
才能让这个文件打开时正常呢？（冒险试了下:set enc=gb18030，Vim告诉我这个无效
- -||）

[vi...@googlecode.com]

Comment #15 on issue 123 by pan.shi...@gmail.com: 关于 标准字库
vimim.cjk.txt 的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

Hmm, gvim for windows 还是有必要存在的，因为在 gvim for windows 里面也可以
把 shell 指定为 cygwin 的 bash （通常来说装 cygwin 的人都会这样指定的）。

当然，控制台版本的 vim for windows 没有必要存在了，直接用 cygwin 里面的那个
就好。

按照你的测试，比较良好的方案似乎是：让 vim 能支持 enc=gb18030 才是王道？这个
估计应该可以通过给 vim 搞个 patch 实现的。 vim 支持 fenc 等其他的值为
gb18030，为什么就不能支持 enc=gb18030 呢？

[vi...@googlecode.com]

Comment #16 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> 而本着“不折腾”原则和最小惊讶原则，

这是考核民间艺人职称的一个重要指标！

[vi...@googlecode.com]

Comment #17 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

> vim 支持 fenc 等其他的值为 gb18030，为什么就不能支持 enc=gb18030 呢？

我也想找下能不能支持，于是：
:h encoding-names<CR>
得到Vim关于多字节支持的相关信息，/18030无果，/54936也没有找到，好吧那手动翻
页人工寻找，终于发现了如下一行：
2 cp{number} MS-Windows: any installed double-byte codepage
嗯？看来只要系统中有相应代码页就可以将enc设成什么样？好吧让我们试试。
:set enc=cp54936<CR>
——无效代码页，好吧18030不算是double byte
再试试上面那行，:set enc=2byte-cp54936<CR> 嗯，竟然没报错，但此后Vim中什么都
显示不出来……OTL

encoding-names里面只有三类：1，2，u，GB18030似乎不能按照这样分类；Google
windows下GB18030相关信息，发现原来GB18030这样的东西竟然是爹不疼娘不爱……

依本人拙见，看来似乎只能想方设法走正道，让Vim在enc=utf8时可以正常跟stdout通
信了～～

[vi...@googlecode.com]

Comment #18 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> 发现原来GB18030这样的东西竟然是爹不疼娘不爱……

记得好几年前也研究过18030.

我的印象是，18030是作为一个真正独立自主的民族品牌来立项的。
18030不但兼容GBK, 而且涵括整个UNICODE, 现在的和未来的。

18030空前绝后。一夜之间，普天下所有之文字，全归于大汉王朝之下。
因为是天朝强制标准，蛮夷之邦不敢不从，除非他们不想赚钱。

不过，如果仔细研究实施细则，好像没有全般照收的。
蛮夷给的大多是些不痛不痒的承诺，而承诺正是朝廷最需要的。

作为强制标准，可为不可为并不是最重要的。
忧国忧民反对18030的其实不懂什么叫博大精深。

[vi...@googlecode.com]

Comment #19 on issue 123 by pan.shi...@gmail.com: 关于 标准字库
vimim.cjk.txt 的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

把 Windows 的 stdout 直接修改成 utf-8 可能是更简单的方案：

C:\XP\system32>chcp
Active code page: 1251

C:\XP\system32>chcp 65001
Active code page: 65001 <------- UTF-8

google 搜了一下上述结果，貌似有效。也就是说，先进行 chcp 到 utf-8 然后再启
动 windows 版本的 vim ，可能可以解决问题？

[vi...@googlecode.com]

Comment #20 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

关于chcp的问题，我在
14楼：http://code.google.com/p/vimim/issues/detail?id=123#c14 已经提到了。
XP下的测试是CMD无法运行批处理脚本，而Vim本身出现乱码（界面疯掉了）；然后换了
Microsoft“最新最好”的Windows 7，批处理倒是可以运行，用type输出UTF8文本也没问
题，但Vim仍然界面疯掉。

我所感受到的chcp管用好像只有用type打印UTF8编码的文本文件时能显示正常。不知道
是哪个步骤出现问题，具体操作是，Win+R输入CMD回车打开命令提示符窗口，chcp
65001切换代码页，Alt+Space开系统菜单选择属性进入设置对话框，更改字体为
Lucida Console。cd到某目录下type utf8.txt显示效果基本正常（除去滚动引起的界
面刷新导致显示半个汉字等Bug）。开始测试，运行CLI版本的Vim，发现界面疯掉；修
改vimrc中的编码设置，再次运行vim，界面疯掉；从chcp后的CMD开Gvim，:make，输出
仍然乱码……

mxj 兄测试过么？是通过怎样的途径能够使它们正常的？

[vi...@googlecode.com]

Comment #21 on issue 123 by pan.shi...@gmail.com: 关于 标准字库
vimim.cjk.txt 的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

如果chcp不好用，那么这个
http://en.wikipedia.org/wiki/AppLocale
不知有没有用？

我想，总会有一种办法能够让Windows给自己的应用程序提供一个utf-8（或者任何其他
种类的unicode）环境的。

[vi...@googlecode.com]

Comment #22 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

托你的福，三年来第一次用上微软视窗CMD...

大家都用的也许肯定应该不会错，更何况CMD是世界上用得最多的console呢。
安慰完自己，开始在我的Vista上学习：

(1) Win+R => 不灵
(2) 老鼠+R+CMD => 出现记忆中的DOS, 而且是反斜杠，一如所料
(3) chcp 65001切换代码页 => 灵
(4) Alt+Space进入对话框，更改字体为Lucida Console => 灵
(5) cd到某目录下type utf8.txt => 不灵。乱码
(6) 放弃试验，回归自然。

我的操作方式应该是最简单的，从来没有被Vim折腾过。
我的vimrc只有一个，同时管gvim.exe和vim.exe
而且名字就是vimrc五个字母。

特show两个Use Cases 玩玩：

用gvim.exe的一个Use Case范例
(1) firefox 读新闻八卦，比如一夜八万“陪睡门”
(2) copy
(3) 单键（注意，不用双键）敲gvim徽标
(4) 新闻八卦自动进入没有菜单的gvim
(5) 如果有时间，敲gggwG排版
(6) 一个热键，发布至我的新闻列表 http://groups.google.com/group/9a6c

用vim.exe的一个Use Case范例
(1) 单键（注意，不用双键）敲mintty徽标
(2) 如果高兴，敲screen, 出五个Tab
(3) bash 提示下，敲 vim -p liumang*.txt
(4) 目录下liumang小说全部打开，一个Tab一篇小说
(5) 敲 :split new
(6) vimimpoem<tab> 玩诗歌旋转游戏。

[vi...@googlecode.com]

Comment #23 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

(1) Win+R => 不灵
(2) 老鼠+R+CMD => 出现记忆中的DOS, 而且是反斜杠，一如所料
(3) chcp 65001切换代码页 => 灵
(4) Alt+Space进入对话框，更改字体为Lucida Console => 灵
(5) cd到某目录下type utf8.txt => 不灵。乱码

-----------
囧rz, Win+R不灵还是Windows系统么……PC兼容键盘上都有个“Windows徽标键”，上面飘
着微软大旗的那个东东，一般躲在键盘Ctrl跟Alt键中间（笔记本键盘暂且忽略其中的
Fn功能键）
如果chcp 65001灵，切换字体也灵而UTF8显示仍然乱码，——好吧，可能mxj兄的系统就
只有一个汉字字体，没跟Lucida搭上边所以选这个也输出不了中文，——于是我猜测即使
不chcp，mxj兄在CMD下也是看不到中文的。要解决这个问题，只好刨根问底深入
Windows数据库文件，Win+R输入regedit打开注册表编辑器Blah blah，手工指定字体链
接以解决CMD下选择字体问题：http://support.microsoft.com/kb/247815

确实很折腾人，但折腾这么久，最直观的印象就是，CMD只有在GBK下好用。
Pan兄说的那个还没试，有空测试下，但感觉也不是好的方案……

我的想法是，CMD就GBK了，最好别改；Vim如果要改enc=utf8，就让Vim本身将stdout的
GBK转码成UTF8就O了，——目前的问题看似是Vim/vimrun之间没配合好。或者不如
说，(G)vim, vimrun, cmd的stdout三者的关系在set enc=utf8时有些混乱，沟通有些
问题。（类似的是在Linux下set enc=GBK，也会引发混乱）

[vi...@googlecode.com]

Comment #24 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> (G)vim, vimrun, cmd的stdout三者的关系在set enc=utf8时有些混乱，
>> 沟通有些问题。

不明白。

我的OS是有名的微软视窗Vista, HP MODEL 6530b
我的vimrc setting 是set enc=utf8
我的gvim 是7.3
我发现我的gvim.exe用的shell是cmd.exe
我发现我的vim.exe 用的shell是bash
用了N年，从来不知道混乱是个什么概念。 :)


PS: part of my vimrc:

" =====================
if has("gui_win32")
" =====================
if argc()<1|sil!exe 'New'|sil!0put +|endif
com! -nargs=0 Line sil!exe 'sil!match Search /\%'.line(".").'l.*/'
set path+=/home/vimim/pinyin
set mousemodel=popup mouse=nicr
set shell=cmd.exe sp=2>&1\|tee
set ballooneval guitabtooltip=%f\ \ \ %y\ \ %L
com! -range=0 Getclip :put! +
com! -nargs=? -range=% WW <line1>,<line2>w ++enc=utf8 <args>|e!
com! -nargs=? -range=% Ww <line1>,<line2>w ++enc=ansi <args>|e!
com! -nargs=? Start sil!exe 'sil!!start <args>'
com! Win sil!exe 'Start explorer /e,'.substitute(getcwd(),'/','\\','g')
com! IE sil!exe 'Start C:/Progra~1/intern~1/iexplore '.xhtml
map<silent><C-C> :Y +<CR>
xn<silent><C-V> c<C-R>+<Esc>
nn<silent> z0 :sil!let @0=@+<CR>:Echo len(@0)<CR>
nn<silent> z+ :sil!let @+=@0<CR>:Echo len(@0)<CR>
nn<silent><F12> :sil!let &columns=190-&columns<CR>
nn<silent><F11> :sil!let &lines=60-&lines<CR>
:sil!let &lines=60-&lines
" ------------------------------------------------
set keymodel=startsel,stopsel fo+=mM ambiwidth=double
set guifontwide=YaHei_Consolas_Hybrid,NSimSun-18030
set enc=utf8 fencs=ucs-bom,utf8,chinese,gb18030 gfn=Courier_New:h12:w7
" ------------------------------------------------
endif

[vi...@googlecode.com]

Comment #25 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

- -|| 敢情上面发了这么多都白说了……

我的 OS 是更加有名的 Windows XP，在 cmd 下写过程序（cl.exe && gcc.exe）、写
过论文、课件（LaTeX），vim 目前用 7.3，因为曾经折腾 enc=UTF8 铩羽而归所以保
持默认的 GBK 不敢动。

作为一个“伪程序员”，作为一个没有编译过 Vim 的“伪”Vimmer，根据使用时的表
现等做出如下猜测（Windows 平台）：
1. Gvim 要通过 vimrun.exe 来执行外部程序；
2. vimrun.exe 将通过启动 Cmd 进程/线程来运行外部命令（cmd /c command）；
3. vimrun.exe 在启动命令时会接管它的 stdout，然后(混合自己的信息?)输出到
stdout；
4. (G)vim 中 :make 等会通过将 cmd 的输出重定向到某个临时文件来给 Quickfix 使
用；
5. vim 中由于跟 cmd 共用窗口所以直接将输出传递给 cmd 来显示；

下面分情况讨论如下假想实验并实际操作来验证：
1. Gvim set enc=gbk（默认），执行 :make，此时根据 vim 里面相关变量的设定，
Gvim 执行 !make，将输出重定向到临时文件（嗯，编码自然应该是 GBK 了，由于这
个临时文件太临时，试了 N 次没有顺利得到临时文件的内容，但通过直接 cmd /c
make > tmp.txt 2>&1，可以测试输出结果确实是 GBK 编码），过滤到 quickfix 缓
冲区，Gvim 的末行根据 language 的设定显示相应 message（目前也是 GBK 编码）
，其中加入执行命令的返回值，从而显示出：第一行执行的命令；第二行返回值；
第三行添加行号等的错误信息；末行Vim本身的提示信息。由于编码都是 GBK 所以无
所谓转码，也就没出现乱码问题，见附图 1；

2. Gvim set enc=utf8, 同时设定其他选项修正提示信息的乱码问题（:lan mes
zh_CN.UTF-8），再次执行 :make，依然是上面的步骤：Gvim执行 !make，输出重定向
到临时文件（应该仍然是 GBK 编码），过滤到 quickfix 缓冲区，Gvim末行显示
UTF8 的 message：第一行执行的命令；第二行 shell 返回值；第三行添加行号后追
加 quickfix 缓冲区的错误信息（这儿跟其他三行不同，错误信息是 GBK 编码），最
后一行 Vim 的提示信息。由于 quickfix 缓冲区没有转码成 UTF8，从而第三行会将
GBK 的字串按照 UTF8 方式显示出来，——于是乱码。见附图 2 以及作为对比的以
UTF8 方式显示 GBK 字串的附图 3。（由于 Gvim 执行外部命令会开 cmd，实际上是
vimrun 的窗口，在 cmd 内部也无所谓转码问题，因而这种实验就没有必要“做”了
，——即使做了自然也是正常，没乱码）。

3. vim set enc=gbk（默认），执行 :make，没所谓转码问题，无乱码，第一屏显示
shell 返回值，提示信息“请按 Enter 或其他命令继续”，但不知何故该提示信息不
是在最下面，而且光标的位置有点反常，见附图 4（更加诡异的问题在于，当 :make
之前没有 cls 清屏，输出信息跟光标的位置将无所定位，原因不明）。按 Enter 或
者 Space 后，显示第二屏，前面的输出仍然保留，下面显示 quickfix 缓冲区的错误
信息及行号等，末行是 Vim 提示信息，见附图 5。

4. vim set enc=gbk（默认），执行 :!dir，第一屏显示执行结果及提示信息“请按
Enter 或其他命令继续”（附图 6），按 Enter 或者 Space 后退回 Vim 界面，无乱
码。

5. vim set enc=utf8, lan mes zh_cn.utf-8, set tenc=gbk，执行 :make，第一屏
仍然是显示 shell 返回值跟提示信息（那个诡异的定位问题依然存在），由于这些信
息由 Vim 输出，根据设定应该是 UTF8 的文本，——而 CMD 将他们当作 GBK 输出，
于是成了这个样子：附图 7。作为对比，附图 8 跟 9 分别演示了在 Gvim 中开 UTF8
文件并 set enc=gbk，以及在 cmd 中直接 type 一个 UTF8 的文件时的表现。第二屏
，上面的信息依然存在，下方显示 quickfix 行号跟错误信息，末行 Vim 本身的提示
信息，见附图 10。这里 quickfix 看上去仍然是前面的问题，实际上 Vim 因为
tenc=gbk 的原因，本身将字串按照 utf8 编码先转换到 GBK 才传给 CMD 显示出来，
但令人疑惑的是，为什么前面的 shell 返回值没有转码？（或许 Vim 认为那个不属
于自己的窗口而只是简单的将 UTF8 的字串输出？）

6. 同上设定，执行 :!dir，由于 dir 本身的输出是 GBK，所以前面的输出结果正常
；后面 Vim 会添加自己的信息，这个信息就不正常了，——依然是 cmd 中 type
utf8 编码的文件那种问题，见附图 11。

猜测/结论：
1. Gvim 执行外部命令通过 vimrun.exe 并获取返回值，vimrun.exe 作为一个简单的
Win32 console 应用程序，本身输出是 GBK 编码（它的作用似乎仅限于后面追加一个
暂停功能）；Gvim 本身的编码转换处理没太大问题，但在 Quickfix 中不作编码转换
而是直接使用字串，于是造成 Gvim 中 :make 时的那个乱码；

2. vim 本身没有窗体，“寄生”在 cmd 上，似乎也不需要 vimrun 这个追加暂停以
用于让用户看见命令输出的鸡肋，直接通过启动它的 shell 运行命令。在 enc 跟
tenc 不同时，vim 会将自身窗体的所有内容进行转码再传递，但是对于直接输出到
stdout 的信息，Vim 没做任何手脚，——直接按照 language message 的设定来输出
，于是会看到 cmd 中显示乱码。对 Quickfix，跟 Gvim 一样。

如何解决？

1. Quickfix 为什么不可以做编码转换？
2. vim 在 print message 时为什么不按照 tenc 的设定来做必要的转换？

以上两点解决，那么我认为 set enc=utf8 时 Vim 完全有能力显示正常，不再有乱
码。

当然上面大部分仍然是我的猜测，具体是否真的如此，有待大牛爆料。

Attachments:
gvim-gbk-make.png 25.1 KB
gvim-utf8-make.png 30.3 KB
gvim-utf8-on-gbk-file.png 18.3 KB
vim-gbk-make-1.png 23.2 KB
vim-gbk-make-2.png 24.0 KB
vim-gbk-dir-1.png 26.4 KB
vim-utf8-make-1.png 23.0 KB
gvim-gbk-on-utf8-file.png 17.6 KB
cmd-type-utf8-file.png 25.0 KB
vim-utf8-make-2.png 24.4 KB
vim-utf8-dir-1.png 26.5 KB

[vi...@googlecode.com]

Comment #26 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

测试中，顺带发现了更加严重的问题：
本来 Google 输入法在 Cmd 中会偶尔出点问题（Windows XP SP3 en-n 个人使用经验
，Win7 下不太清楚），但至少 Vim 中使用 Google 拼音输入法是可以输入汉字的；
当 vim set enc=utf8 之后（Windows 7 zh-cn 下测试），Ctrl+Space 开启输入法，
输入时 conime 也依然可以显示出来，如附图 1 所示。但数字或者空格确认输入时，
本该插入到 Vim中的汉字串竟然变身无法识别的一串问号（附图 2，ga 告诉我那都是
实实在在的英文半角'?'，ASCII 码 63 的那个东东）……好吧这个或许是因为输入法
没有提供 UTF8 的支持，暂且不去管它，我们还有 VimIM 这样具有“超级牛力”的东
东呢～～

满怀信心，输入字串 Ctrl-6 试图转换，——咦怎么没有云出东西来？强制入云都没
有效果（附图 3），只有 vimim.cjk.txt 的声母返回值，然后按 n 出现全拼返回……
难道是没有进入“中文模式”的原因？Ctrl-\ 开启中文模式，——好家伙，吓我一跳
，状态条全部乱掉，而且依然没有云的结果（附图 4）。作为对比，set enc=gbk 时
的效果如图 5、6 所示。当然，对于通过本地词库输入时没有影响，——至多在
Chinese mode 时感官不是很好而已～

Attachments:
vim-utf8-ime-list.png 22.3 KB
vim-utf8-ime-input.png 18.9 KB
vim-utf8-vimim-no-cloud.png 26.6 KB
vim-utf8-vimim-chinesemode-cloud.png 27.5 KB
vim-gbk-vimim-cloud.png 29.2 KB
vim-gbk-vimim-chinesemode-cloud.png 30.8 KB

[vi...@googlecode.com]

Comment #27 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

以上，并不只是 vim 的问题，刚测试了下，Gvim 在 set enc=utf8 时也有同样问
题，见附图

Attachments:
gvim-utf8-vimim-no-cloud.png 17.0 KB
gvim-utf8-vimim-chinesemode.png 21.6 KB

[vi...@googlecode.com]

Comment #28 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

呃……“云不出来”跟“状态条乱码”等问题是因为我在 set enc=utf-8 时偷了个懒
，直接开 vim 修改而不是在 vimrc 中保存所造成的，这两条基本可以无视了…… 懒
看来还是有坏处的～～Orz

BTW 为什么就必须是启动前设定好才有效？开启 vim 在 vimim 使用之前的一些设定
貌似能够部分影响 vimim，而 vimim 一旦用过，只有重新开 vim 才能将新的更改反
应出来……有没有修改设定后直接可以影响到它的表现的方法？

[vi...@googlecode.com]

Comment #29 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> 因为曾经折腾enc=UTF8 铩羽而归所以保持默认的 GBK 不敢动

问题的根源。

GBK 既不能冲出亚洲，更不能走向世界，与国足一个概念。
GBK 自己其实已经被朝廷抛弃，取而代之的是18030.
18030 既不冲出也不走向，自成世界，我们曾经讨论过。

既然冲不出也走不向，何苦被折腾? 还记得Poet兄的真知灼见？
何不从我做起，从UTF8做起，把颠倒的世界颠倒过来？

>> 1. Gvim 要通过 vimrun.exe 来执行外部程序；

这是我的理解。

Gvim以前必须配vimrun.exe才不报错。
为此我曾经请教过革命导师Bram.
导师好像从不用微软视窗，凭感觉，修改报错逻辑。
现在的Gvim没有vimrun.exe也可以跑，只要不用外部命令。
这点有时非常重要。
比如接手一支裸机，只要下载Gvim.exe一个程式就可以治病救人，起死回生。

>> 2. vimrun.exe 将通过启动 Cmd 进程/线程来运行外部命令（cmd /c command）；

这也是我的理解，仅仅对Gvim.exe而言。

>> 3. vimrun.exe 在启动命令时会接管它的 stdout，然后(混合自己的信息?)输出到
>> stdout；

这也是我的理解。

>> 4. (G)vim 中 :make 等会通过将 cmd 的输出重定向到某个临时文件来给
>> Quickfix 使 用；

这也是我的理解。

>> 5. vim 中由于跟 cmd 共用窗口所以直接将输出传递给 cmd 来显示；

似是而非。Gvim.exe? vim.exe? vimrun.exe?


>> 如何解决？

参见以上“问题的根源”。

>> 测试中，顺带发现了更加严重的问题：

貌似问题不严重了，或者说，问题不是问题了?

>> BTW 为什么就必须是启动前设定好才有效？

(G)vim 本身的启动就不简单，各种不和谐的因素都得考虑。
维稳办并不是吃素的。如果有兴趣，可以参见 :help startup

>> 有没有修改设定后直接可以影响到它的表现的方法？

VimIM 依附 (G)vim, 不敢在那个方面造次。
江山来之不易，稳定压倒一切。

>> 开启 vim 在 vimim 使用之前的一些设定貌似能够部分影响 vimim

>> 而 vimim 一旦用过，只有重新开 vim 才能将新的更改反应出来……

这个嘛，好歹列举一些证据。不然，VimIM 貌似也被“经济犯罪”啦！
理论上，VimIM的一举一动都有中纪委的指导：

:VIM: 不被和谐!
:memory: 不超过词库尺寸
:speed: 不低于最高要求
:encoding: 不受限制
:options: 不强行要求设置
:internet: 不联网照样敲中文
:datafile: 无词库可以云输入
:internal: 无词库无联网用内码输入

[vi...@googlecode.com]

Comment #30 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> 囧rz, Win+R不灵还是Windows系统么……PC兼容键盘上都有个“Windows
>> 徽标键”，上面飘着微软大旗的那个东东，一般躲在键盘Ctrl跟Alt键中间

在Firefox上读VimIM错误报告 http://code.google.com/p/vimim/issues/list

读到上述描述，忍不住再次按“飘着微软大旗的那个东东”，
来到 "Add a comment and make changes" 窗口，顺手写下。

微软大旗也许并不是随便可以飘的。

[vi...@googlecode.com]

Comment #31 on issue 123 by pan.shi...@gmail.com: 关于 标准字库
vimim.cjk.txt 的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

说实话 25 楼已经折腾的太过分了。。。

我一向坚持 Windows 就是 Windows，Linux 就是 Linux，适合在哪个系统中跑的就到
哪个系统中跑。这是最终极的“不折腾”原则。

我不知道 suxpert 折腾 LaTeX，vim, make, msys 等等玩意在 Windows 里面需要花多
大精力，但是至少那对我来说，折腾得太过。。。在 Debian-Linux 或者 Ubuntu 中用
这些东西是轻轻松松弹指一挥间的事情。

当然同时我也很奇怪一些人为了把一些 Windows-only 的程序跑到 Linux 下费九牛二
虎之力的折腾，在我看来，既然要这么折腾，不如就用 Windows 去做。

iPhone的流行不就说明这个问题么？它虽然贵，但是它能解决问题，所以很多人就不折
腾。

有句俗话叫做：钱能够解决的问题都不是问题。因为Linux/Windows双修是钱能够解决
的（多买台电脑就解决了），所以它就不是问题。

当然，事实上据我测试，在当今的主流配置下，Windows host + Linux虚拟机
guest，里面 gcc 编译代码的速度比直接在 Windows host 中使用 cygwin 或者 msys
编译的速度还要快得多。只要本机内存足够，真的没必要费工夫整这些，直接上虚拟机
可能更靠谱。

[vi...@googlecode.com]

Comment #32 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

>> 因为曾经折腾enc=UTF8 铩羽而归所以保持默认的 GBK 不敢动
问题的根源。
GBK 既不能冲出亚洲，更不能走向世界，与国足一个概念。
GBK 自己其实已经被朝廷抛弃，取而代之的是18030.
18030 既不冲出也不走向，自成世界，我们曾经讨论过。

--------------------
关于这个观点，由于 18030 属于变字节编码，大部分程序的支持好像不是很好（况且
18030 跟 GBK 不完全兼容）。这个是国家标准，而且也仅仅是个国家标准而已，——
国家标准制定出来，普天之下又有多少去遵守的呢？若真去遵守，那些可怜的地震中
、毒奶粉中……消逝的生命，又何苦会如此悲惨……呃，话题敏感，暂且避过～～

问题的根源在于，Windows 系统下，大部分应用程序在 GBK 下表现最好，——尤其是
Win32 Console Application。切换代码页引起的问题将很严重，——如此折腾，也只
不过是为了一个set enc=utf8 而已，对我而言，大部分情况下使用默认的 GBK 完全
没有问题（这也是我放弃 vimrc 中 set enc=utf8 的一个重要原因，折腾反而没有不
折腾的效果好）。换一种说法可以这样说，保持默认的 GBK 这种不需要折腾，最简单
最便捷，什么都不用管，在 80+% 的情况下不会遇到任何问题。

但是当然，正如 mxj 兄所说，GBK 实在上不得台面，要想走出国门走向世界，utf8
神马的才是正道（18030 这样的国标实际上没多少吸引力，无非是个国家标准而已）
，于是才有了后面的一通折腾，试图让走正道的 (G)vim 跟走独木桥的 Win32
Console Applications 们和平共处互不干涉独立自主，自然需要 (G)vim 派遣外交官
跟翻译，——翻译我们聘请了 GNU 的 iconv，但何时翻译、翻译哪些这样的问题，还
应该由外交官来决定，——不巧根据我在 25 楼提到的折腾或曰测试效果看来，这个
外交官对外交事务的了解或许不够深刻，因而造成了沟通困难，甚至造成误会。具体
的表现就是，——

1. Quickfix 为什么不可以做编码转换？
2. vim 在 print message 时为什么不按照 tenc 的设定来做必要的转换？

外交官如果“把工作落实”，彻底解决这样的问题，那么“我认为 set enc=utf8 时
Vim 完全有能力显示正常，不再有乱码”。当然由于后面提到的“更加严重的问题”
，set enc=utf8 之后，vim 中不再可以使用 Google 拼音（其他输入法没有测试），
但对于习惯 VimIM 的 Vimmer 而言，这个问题倒算不上严重。

mxj 兄似乎肯定了我的那些理解，只在“

>> 5. vim 中由于跟 cmd 共用窗口所以直接将输出传递给 cmd 来显示；
似是而非。Gvim.exe? vim.exe? vimrun.exe?

”这里。按照某种“惯例”，vim 此处狭义的仅代表 Win32 Console Application，
而 Gvim 代表 Windowed Application，vimrun.exe 自然就是那个用于创建外部程序
进程/线程并添加暂停功能的一个 Win32 Console Application。这句话我想表达的意
思是，Console 版本的 Vim 本身没有维护一个窗口界面，而是通过 cmd 将自己显示
出来，所需要显示的东西利用 cmd 的接口传递过去。显示成什么样子不归 vim 本身
管。

Pan 兄说我已经折腾的太过分了，我接受批评，不过，对于一个大部分时间没有自己
机器的“伪”程序员而言，Linux 不是想用就能用的 :) 我没有权限给别人的电脑装
Linux 系统，——甚至有时候连重启机器进入 Live CD 都属于越权行为，——所以偏
爱绿色软件，比如可以装在 U 盘里的 Portableapps.com，MikTeX Portable，以及
Martin 维护的 MSYS-CN。

那些折腾倒也没花多少精力，因为要用到所以就摸索下，“摸着石头过河”，等河过
得差不多下次再过，石头们在什么地方就比较清楚了，——况且水不深，看也能看见
一些 :) 。

LaTeX 是受 Linux 影响，以及 OpenOffice 不够优秀的输出效果等诸多因素共同作用
下决定要用的，——况且作为一个数学专业出身的人，这个东西似乎也必不可少（MS
Office 中排版数学公式的糟糕状况尤其是 PowerPoint 实在是给了我一个抛弃它的足
够充分的理由）。自然，在 GNU/Linux 平台用这个东西是很不错的（不只是这个），
问题仍然是前面提到的，我大部分时间只能在 Windows 平台下（国内的形式如此）。

Vim 我第一次用是在 Cygwin 下，真正学会是在 FreeDOS 下（好吧我折腾 - -|| ）
，自此一发不可收拾，变身 Vim 控，凡文本文件二话不说用 Vim 开，甚至二进制也
经常丢给 Vim……这个不知算是折腾还是算控了 :) ；

make 是因为用在小型项目管理上，这东西忒好使；

msys 这个有点来历了，当年学 C 用的是 TC，后来换 VC98，但后来控 Vim 的本性使
得我一直想用 Vim 写代码而不是那个不怎么好用的 IDE，由于当时不知道如何将 vim
跟 VS 搭配起来，况且 IDE 个头太大不便于放在 U 盘里面，于是从 VC 中将cl.exe，
c1.dll，c2.dll，nmake.exe等等，连同头文件、库文件都提取出来，自己组装个精简
版本的 SDK 开发环境，然后搭配 Vim，ctags 等来写程序。正是这个时期，发觉有时
候 Gvim 不及 vim 用着舒服，虽然 cmd 长得很丑。然后才经常性在 cmd 下写东西了
。那时候甚至经常性开一个 vim 半天不出来，有种 Emacs 的错觉（当然 Emacs 我不
会用，学了好多次学不会 - -||）之后偶然发现了 MinGW 这么神奇的东西，竟然是个
原生的 Windows 版 gcc，于是此后抛弃 cl 投身 gcc，变身 MinGW 用户，当然为了
用一些 GNU 工具，自然就开始用 MSYS，这时开始有种抛弃 cmd 的冲动了（用 RXVT
或者后来的 MinTTY 配合 bash，界面更加漂亮），直到后来发现 RXVT 跟 MinTTY 都
会有将 stdout 缓存的问题，于是又回到 cmd 下（或者 cmd 下的 bash）。

钱能够解决的问题都不是问题，但问题是没钱。没钱所以没有台自用电脑，于是就需
要大部分时间呆在 windows 下；没钱买不起 VS 这么贵的工具，也买不起足够好的硬
件能支持 VS 这么庞大的系统，于是只好用 gcc……

Windows 下由于进程开销的问题等原因，不论是 Cygwin 也好，MinGW 也好，都达不
到 Linux 系统下对应软件的速度和效率，但 Cygwin 不是 Linux，它的目的是提供一
个 Windows 版本的 GNU 环境，进行“源代码移植”的跨平台编程；MinGW 也不是
Linux，它给了我们 VC、Borland C++ 等之外，进行 Windows 应用程序开发的另一个
选择，我感觉这些算不得折腾吧 :)

[vi...@googlecode.com]

Comment #33 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> 我不知道 suxpert 折腾 LaTeX，vim, make, msys 等等玩意在 Windows
>> 里面需要花多大精力，但是至少那对我来说，折腾得太过。。。

同感。不过精神可嘉，可以作为如何把简单问题复杂化的一个范例。

>> 在Debian-Linux 或者 Ubuntu 中用这些东西是轻轻松松弹指一挥间的事情。

hmmm 有必要为微软说一句公道话。

笔者一直使用微软视窗。在微软视窗里面使用 LaTeX，vim, make, 等等玩意也是
“轻轻松松弹指一挥间的事情”，犯不着安装 Debian-Linux 或者 Ubuntu ...

完全使用 Linux 的麻烦是不能接触 Outlook/Powerpoint/Excel/VPN 等等神奇的兵
器。
之所以神奇，是因为那些兵器是许许多多fortune 50强大公司的缺省装配。

前面提过，微软视窗的精华之一是cygwin.
使用微软视窗，我们既可以操常规武器，也可以玩特种兵器。

当然最重要的是，我们可以“轻轻松松弹指一挥间”用VimIM点石成金。:)

[vi...@googlecode.com]

Comment #34 on issue 123 by pan.shi...@gmail.com: 关于 标准字库
vimim.cjk.txt 的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

> 翻译我们聘请了 GNU 的 iconv，但何时翻译、翻译哪些这样的问题，还
> 应该由外交官来决定，——不巧根据我在 25 楼提到的折腾或曰测试效果看来，这个
> 外交官对外交事务的了解或许不够深刻，因而造成了沟通困难，甚至造成误会。具体
> 的表现就是，

从某种程度上说，我不认为 GB18030 是个糟糕的设计。因为如果需要保护 GBK 这种由
历史局限产生的编码集（以及曾经的大量GBK资源），同时又要保证 unicode 兼容的
话，这个编码可能是必须的。GB18030 对 GBK 确实是完整的向下兼容的，这个问题体
现在：任何一个合法的 GBK 文件都是一个合法的 GB18030 文件，当然反之不成立，不
过向下兼容通常都是单向的。

iconv 的重要问题是：当目标编码集涵盖的字符量比来源编码集小的时候，遇到不能转
换的编码会直接报错退出。而这一点就意味着：如果一个应用程序需要处理从
unicode 转换到 GBK 的行为，就必须大量考虑可能出现的异常，而通常来说，异常处
理将占用编程的大部分精力。在软件工程里面学习过：把处理正常流程的两倍精力花在
异常处理上，才能作出产品级别的程序。换句话说，做一个产品级别的程序，要花掉【
做一个刚好能用的程序】的三倍精力。

不知道是为了是省事还是什么原因，常见应用程序在很多自动转换的环节都把这种大编
码集到小编码集的转换视为非法，不予支持。所以你的研究到这里卡壳了：在你的工具
链中的部分环节，有程序不愿意把 utf-8 转换为 gbk。

实际上，如果让你去写 iconv，恐怕你也很难定义一个好的方法去处理这件事情，把无
法转换的字符全部转换成空格是我现在能想到的最好方案，因为他不改变转换前后的有
效字符数量。但是严肃的黑客也许不愿意接受我这样的方案。

GB18030 的出现是为了让任何 unicode 文本能够与 GB18030 自由的反复的双向转换。
它的问题是变长，但 utf-8 不也同样是变长么？既然变长编码到极致的 utf-8 都能够
被广泛支持，gb18030 不被广泛支持只能认为是一些【技术之外的原因】。

我说【折腾得太过分】其实不是批评，因为这个行为跟当年在学校的我其实没有什么区
别。我曾经一直坚定的在 Windows 环境中折腾大部分自由开源软件，包括 LaTeX。直
到毕业后因工作关系全面转向 Linux，用了四五年 Linux 下来，才明白以前在
Windows 中的一些折腾多少有些自虐。----如果一个需要用自由开源软件的公司让员工
把时间精力花在折腾怎么顺利在 Windows 下运行原本为 Linux 写的软件，那将是产出
比较低的行为。Fortune 500 公司的行为在这里其实没有什么代表性，因为世界上有
60多亿人口，在 Fortune 500 工作的人数远远不到 6 千万（参考维基百科），换句话
说，远远不到百分之一。

[vi...@googlecode.com]

Comment #35 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

> 可以作为如何把简单问题复杂化的一个范例
恰恰相反，我喜欢全面掌控项目细节，需要对它全面细致的了解（嗯，当然都是小型
），IDE 的自动生成代码功能或许对很多人而言是很方便的，但这样造成的效果是程
序员不知道自己的程序当中很大部分代码长什么样。——我感觉这是不好的。“把简
单问题复杂化的一个范例”是各大软件公司为了防盗版所采取的注册码或者激活机制
，——直接自由软件，开放代码怎么可能有盗版；范例是 C++ 等通过将过程屏蔽起来
不让人看到，“看上去简单”而实际上用更加复杂的实现方法来解决本来简单的问题
；范例是

而实际上那些所谓的“折腾”根本也算不得折腾，只要你试过一两次就知道，非常简
单，甚至简单到只有我这样的菜鸟才会去“折腾”其他人不屑，——对于像我这样的
懒人、笨人而言，太复杂的东西学不会（比如 Emacs）也不愿意学。mxj 兄也说了，
Windows 系统中用这些也不过是“弹指一挥间”的事，没必要把它说的那么吓人。实
际上我确实也没折腾什么，——东西都在那儿，拿过来用而已。真正的折腾比如 LFS
什么的，我从来没敢尝试也自认为折腾不了。

25 楼的折腾，旨在测试各种设定下 (G)vim 的不同表现，这个是故意这么折腾的，为
了让您二位了解其具体现象。

PS 为什么我总感觉有种歪楼的味道……问题不在于我折腾不折腾（何况我也没折腾
- -||），在于 Vim 的外交官处理外交事务有问题。如果我呆在 GBK 下自然用不到
外交官，这个最不折腾，我也一直是这么干的（本不喜欢折腾，一切从简，用最简单
的东西/工具解决问题），但走向世界就不折腾不行，我英语不够好所以对全英文设定
保留意见，况且那只是逃避问题而不是解决问题。

[vi...@googlecode.com]

Comment #36 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> gb18030 不被广泛支持只能认为是一些【技术之外的原因】

我的印象是，gb18030的设计是“【技术之外的原因】”占压倒因素。

gb18030出炉之后，好像没有办法全般支持这个标准。就算蛮夷的软件和标准全部
都是废物，天朝自己总得出几个拿得出手的应用支持自己的标准。不知道
现在有没有奇迹？至少两年前没有。

记得SUN是第一个跳出来支持gb18030的，但是仔细研究细节，好像是点到
为止，说是现在绝对支持GBK, 今后不遗余力支持gb18030云云。

软件也好，标准也好，应该以实际为准。gb18030的制定似乎是以过干瘾为主。

另外，以人的数量来参考，是微软最喜欢的。事实上，微软视窗是世界上
使用最多的OS, Linux/Unix简直可以忽略不计。难道只有微软视窗才有代表性？

免责声明：对gb18030 的评论完全基于我二年前的研究。

[vi...@googlecode.com]

Comment #37 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> 对全英文设定保留意见，况且那只是逃避问题而不是解决问题。

绝对正确！

经这么一提醒，我忽然发现我自己是逃避问题专家。

电脑问题多如牛毛，无法解决的问题太多。遇到有人问我微软视窗的问题，
我的标准答案是切断电源，重新启动。虽说不是百发百中，却也帮不少人
解了燃眉之急。:)

[vi...@googlecode.com]

Comment #38 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

>> 我一向坚持 Windows 就是 Windows，Linux 就是 Linux，适合在哪个系
>> 统中跑的就到哪个系统中跑。这是最终极的“不折腾”原则。

如果非要吹毛求疵，这有点理想主义。像vim这个软体，究竟适合哪个
系统呢？事实上，我发现gvim在微软视窗上跑比在Xwindow上跑顺多了，
当然在console跑vim，Linux永远优于Windows.

而且，cygwin不伦不类，不知被划分为那个阶级？

自从发现我是逃避问题专家以后，好多观点忽然有条有理了。总而言之，
只要好用不折腾就行，管他是Windows还是Linux ...

我的gvim在Windows上跑，我的vim在bash上跑（那个在DOS上跑的vim坚决回避！）
把cygwin当Linux用也是八九不离十，反正我不怎么写程式，除VimIM以外。

那个gb18030之所以不看好，是因为用不上。道理也许都对，但是连
vimim.cjk.txt 都读不出来，何用之有？按理，gb18030出炉好几年了，一
般的程式也该跟上“形势”上。不过，事实上，我们把“楼”都吹歪了，
gb18030也没有解决我们的黑框问题。

[vi...@googlecode.com]

Comment #39 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

废话讲了一大堆，没有提及“理想”的18030标准, 特补充一句。

“理想”的18030, 或者叫GBK+, 应该是像GBK那样的二字节，涵盖
Unicode的20902个汉字，也许还可多几百个字。这样，即可以保护gbk资源，
又可以毫不费力解决我们的黑框问题。

当然，“理想”是不现实的，所以还是废话。

[vi...@googlecode.com]

Comment #40 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

好吧，将我上面所有的发言 ggdG 掉，然后按照某种更加“规范”的方式，重新描述
如下：

1. 一切使用默认设置（GBK），大部分时间不会遇到问题，不论是 Gvim 还是 vim，
——只要不去接触 GBK 表示范围以外的字符。既然是默认设置，自然不需要任何折腾
，属于拿来就用，拿来就可以用的状态（这也是我目前的状态 :D ）。当然，这时一
旦遇到 GBK 无法表示的字符就会出问题，这个问题既然是因为 GBK 的表示范围太小
，自然无解，除非——

2. 选择表示范围足够大的编码，与世界接轨，set enc=utf8（嗯，对支持不够多、表
现也不够好的 18030 没感觉，无视之，况且 utf8 很优秀～～）。这样，(G)vim 作
为一个外来户，跟土著们语言不通，需要外交官跟翻译官。翻译官虽然不知道怎么将
utf8 翻译成土著语，但是只要能把土著语翻译成 utf8 应该就够了（嗯，既然大家都
不喜欢 cmd，让我们暂且无视它吧 - -||），而且 utf8 这么富有表现力的语言，似
乎可以将所有土著语能表达的意思都表达出来。但现在的问题是，外交官的工作没有
做好，有些地方该翻译时没让翻译官去翻译。所以只要换个更加敬业的外交官，或者
给这个外交官再培训一下，utf8 下的 gvim 正常似乎应该难度不大（让我们继续无视
cmd 跟 vim，cmd 正常工作状态实在没有本事将超越 GBK 范围之外的字符显示出来，
而能显示时却不能正常工作，这个问题由于微软不会去解决所以没人能搞定了看来。
那就彻底无视，甚至鄙视 cmd 跟 vim 吧～～Orz）

3. 于是，解决问题的两种途径：
A. 老老实实呆在围城里头，自娱自乐悠然自得得过且过自给自足，这个甚至简单到不
用去解决就已经解决了。
B. 想去看看精彩的“外面的世界”，换个得力的外交官。

PS. 关于 GB18030，特意又去 wikipedia 确认了下，说法是：“与 GB 2312-1980 完
全兼容，与 GBK 基本兼容”，具体情况不清楚，好像是有几个字没对应起来。

[vi...@googlecode.com]

Comment #41 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

Issue 121 has been merged into this issue.

[vi...@googlecode.com]

Updates:
Status: Done

Comment #42 on issue 123 by maxiangjiang: 关于 标准字库 vimim.cjk.txt 的黑框
问题
http://code.google.com/p/vimim/issues/detail?id=123

(No comment was entered for this change.)

[vi...@googlecode.com]

Comment #43 on issue 123 by suxp...@gmail.com: 关于 标准字库 vimim.cjk.txt
的黑框问题
http://code.google.com/p/vimim/issues/detail?id=123

一年多过去了，我仍然不知道“微软的大旗不是随便飘的”原因，——孤陋寡闻了，我见过
的所有机器凡是【没有自己重新定义】 WIN 键的，Windows 下的表现彻底到无以言表
的一致，——即使是还没出笼的 Windows 8（只是跑出来的东西名字变了），而且左右
WIN 键华丽丽的表现一致。
@ #30