gvim下euc-cn与cp936编码的异同

[sarrow]

呃，可能我又打错字了吧。。。我是说，在 Windows 上使用 euc-cn 是一种奇怪的
行为。

不是你打字打错了，而是我的表述有问题。

windows，下面，我的gvim没有问题。

出问题，主要是中ubuntu下面——在ubuntu下面，我不知道怎么回事，new文档的时候，
euc-cn竟然是默认的编码方式，导致经常文本无法保存。

二进制上，我从euc-cn和cp936上，没看出什么不同来，所有才有了最开始的疑问。

至于为什么linux下面的gvim对中文编码，为什么要采用一个小字符集的enc-cn，而不是
cp936，还真有点想不通。

从理论上讲，还是utf8编码好。cp936、big5这些东西，本质上，都要在开头携带一个bom信
息，要不然，无法判断到底是何种编码。

用utf8作为常用的万国码真的不错。比4字节一个字的方式，要节约空间。就是编程上比较
费——如果自己写代码的话。

[lilydjwg]

不是你打字打错了，而是我的表述有问题。

windows，下面，我的gvim没有问题。

出问题，主要是中ubuntu下面——在ubuntu下面，我不知道怎么回事，new文档的时候，
euc-cn竟然是默认的编码方式，导致经常文本无法保存。

二进制上，我从euc-cn和cp936上，没看出什么不同来，所有才有了最开始的疑问。

至于为什么linux下面的gvim对中文编码，为什么要采用一个小字符集的enc-cn，而不是
cp936，还真有点想不通。

从理论上讲，还是utf8编码好。cp936、big5这些东西，本质上，都要在开头携带一个bom信
息，要不然，无法判断到底是何种编码。

用utf8作为常用的万国码真的不错。比4字节一个字的方式，要节约空间。就是编程上比较
费——如果自己写代码的话。

也是。反正我是不用 euc-cn 的。gb2312 也不用。

cp936、big5 等，都是没有也没办法有 BOM 的。BOM 只适用于 UTF-8、UTF-16LE、UTF-16BE 等。
为什么要自己写代码呢，直接拿 iconv 处理啊。如果是 Python 等脚本语言，就更不用纠结如何转码了。

[sarrow]

cp936、big5 等，都是没有也没办法有 BOM 的。BOM 只适用于 UTF-8、UTF-16LE、UTF-16BE 等。
为什么要自己写代码呢，直接拿 iconv 处理啊。如果是 Python 等脚本语言，就更不用纠结如何转码了。

恩，我的表述确实有问题。

我的意思是，为了比较准确地区分cp936、utf16、big5等长度为2的编码（CP936和big5都指
中文部分——其实还得加上日文、韩文的判断、区分等等），需要在字符编码流前面加上一
点标记信息，就像bom标记一样。必然，用程序来判断，失误率高。

另外，bom虽然叫byte order mask，但是对于utf8编码而言，这个bom的叫法其实是名不副
实的。所以，utf8的bom信息，一般来自windows的文档才有。

因此，utf8，比上述编码——包括utf16，都要优越一点——就国际化来说。

[sarrow]

如果是 Python 等脚本语言，就更不用纠结如何转码了。

确实，站的位置不同，看到的问题也不一样。