有关 utf8 字符集的讨论请进这里！

qchem

Post by hua_jacky1977
但是例如我们在公司里面开发一个项目,其中有人使用linux有人用windows,如果使用linux的人编码或者写文档的时候都是用utf-8,而windows下面的兄弟都使用gbk,那你说会有什么问题发生?所以我想以前那么多的使用gbk,gb2312的文档我们还是要保护的,转向utf-8不是我们一两个人说转就能够转的,如果有人说约定一个时间点一起转,那么还有希望,但是你觉着这个事情谁能来做呢?毕竟,gb2312和gbk是国家的标准呀.不知楼上的兄弟怎么想?

gbk好象不算是国家标准吧，GB18030到是的
国家的标准说实话我觉得一个字“土”
制定标准的人真是“土”的无解了

hua_jacky1977

Post by qchem
gbk好象不算是国家标准吧，GB18030到是的
国家的标准说实话我觉得一个字“土”
制定标准的人真是“土”的无解了

GB码是按照国家标准GB2312-80编排的，包括全部简体字及常用符号。
GBK码是国家技术监督局1995年为中文Windows95所制定的新的汉字内码规范（其中GB表示国标，K表示扩展）。该规范在字汇一级上支持ISO10646和GB13000中的全部中日韩（CJK）汉字，并与国家标准GB2312-80信息处理交换码相兼容。如果在中文简体版的Windows 95/98/2000下看到繁体中文，那么多半这些中文是用GBK编码的。

hua_jacky1977

Post by bbbush
我们就是这样啊，我们用 eclipse 和 cvs 来工作，平台不一样，但是 eclipse 可以为每个项目设置默认字符编码。UTF-8 还是很爽的。你用过 rh9 的 KDE 没有？当时不是 UTF-8，假如你用不同的语言登录一次系统，那么桌面上会重新生成一个 “主目录” 图标，而原来的图标文字是乱码。这个图标是不可能删掉的，除非将整个桌面目录都删掉。发生过几次这样的事情之后，我对 KDE 和 GB* 编码的好感就一点也没有了。再想想假如你要给国外的朋友写信，中文信件，但是他们可能只有 UTF-8 中文，没有 GB* 中文

即使你们使用linux下面的eclipse和cvs来开发，但是我想如果你们teamn中有一个是windows下面的开发人员，那么就需要他(她)也将windows的默认字符集改为utf-8，不然在eclipse下面编辑注释或者通过其它编辑工具改代码的时候，输入的汉字还是gb编码的(除非eclipse中的cvs plugin支持gb编码到utf-8的自动转换)。我的意思还是说，如果使用utf-8，就需要大家(范围小到一个team，大到一个公司)一起使用，不然只要有一个member不使用那么就会问题。所以我认为目前使用utf-8还不适合，因为我们不能强制别人转换到这下面来。
另外现在的fc3的主目录应该不存在以前的问题了吧。
顺便谈谈我对utf-8现在的个人理解，我认为现在utf-8尚不适合大规模使用，但是在某些特殊领域比较适合，例如对于有多国语言支持的应用程序，例如一个bbs，有中文讨论组，英文讨论组，韩文讨论组等等，这样数据库的存储字符集就比较适合用utf-8，这样可以保持我们在整个程序运行和数据库之间这块区域都是utf-8编码，不管是那种语言，但是输出到特定区域browser的时候，可以根据需要转换成相应的本地编码。
不过我不会仇视utf-8，以上只是我个人的观点，仅供参考:-)

qchem

Post by hua_jacky1977
GB码是按照国家标准GB2312-80编排的，包括全部简体字及常用符号。
GBK码是国家技术监督局1995年为中文Windows95所制定的新的汉字内码规范（其中GB表示国标，K表示扩展）。该规范在字汇一级上支持ISO10646和GB13000中的全部中日韩（CJK）汉字，并与国家标准GB2312-80信息处理交换码相兼容。如果在中文简体版的Windows 95/98/2000下看到繁体中文，那么多半这些中文是用GBK编码的。

gbk是不错
但好象没有作为标准执行吧
那些银行、邮局、教育等很多部门还在用gb2312，这根本不够用
导致人的名字都用框框来代替都20xx年了，还要让这种状态延续？
反正我就用utf8
我用到别人的东东我去适应它
别人要用我的东东，那你来适应我吧，搞不定是你自己的事，谁让你不用utf8

bbbush

Post by hua_jacky1977
即使你们使用linux下面的eclipse和cvs来开发，但是我想如果你们teamn中有一个是windows下面的开发人员，那么就需要他(她)也将windows的默认字符集改为utf-8，不然在eclipse下面编辑注释或者通过其它编辑工具改代码的时候，输入的汉字还是gb编码的(除非eclipse中的cvs plugin支持gb编码到utf-8的自动转换)。我的意思还是说，如果使用utf-8，就需要大家(范围小到一个team，大到一个公司)一起使用，不然只要有一个member不使用那么就会问题。所以我认为目前使用utf-8还不适合，因为我们不能强制别人转换到这下面来。
另外现在的fc3的主目录应该不存在以前的问题了吧。
顺便谈谈我对utf-8现在的个人理解，我认为现在utf-8尚不适合大规模使用，但是在某些特殊领域比较适合，例如对于有多国语言支持的应用程序，例如一个bbs，有中文讨论组，英文讨论组，韩文讨论组等等，这样数据库的存储字符集就比较适合用utf-8，这样可以保持我们在整个程序运行和数据库之间这块区域都是utf-8编码，不管是那种语言，但是输出到特定区域browser的时候，可以根据需要转换成相应的本地编码。
不过我不会仇视utf-8，以上只是我个人的观点，仅供参考:-)

我倒是很仇视 gb* 似的。我们做好了 man-pages-zh_CN 但是因为技术水平不够不知道怎么让 groff 和 less 支持 gb*，结果只有在 utf8 的环境中才能看 man 手册页文档。http://sf.linuxforum.net/projects/cmpp 还放着那些 rpm，你可以下载回来看看。

你是不是没有用过 eclipse 和 cvs 啊？还是根本没用过 windows？ windows 的默认字符集并不像 linux 这样说换就换的。执行字符编码转换的，是输入时的文本框控件。cvs 不管文件的内容，不过因为大多数 unix 工具处理的是字节，utf8 编码是变长的，最长用到六个字节，每个字节单独拿出来都有特定的意义，因此可以适应得很好。而 gb* 编码是双字节，单独拿出一个字节是无法判定意义的，在处理中增加了很多负担。就冲着这一点就不喜欢。开发人员没有精力处理不同编码的特殊情况

utf8 不适合大规模使用？你知道 google 用的是什么吗？大概没人会注意到自己在用 utf8
兄弟们讨论的，不过是因为编码的技术改进了，应用程序却没有同时跟上罢了。无论是 acrobat reader 还是 xmms 都要处理两项事情，一个是访问硬盘上的文件，一个是访问文件中的数据。这两项都得到正确的数据之后，还要处理显示模块。xmms 还要额外多做一项，就是读取界面翻译的资源文件，同样需要显示出来。如果文件名编码，ID3tag 编码还有 LC_CTYPE 的值都相同，字体也配置得合适，那么无论是 utf8 还是 gb* 都不会出错。但是如果有一项或两项出错，那么组合起来的错误类型就会有很多种

虽说强制别人做什么事情不好，但是实际上因为两种编码无法调和，redhat 利用自己老大的地位，不遗余力地推行 utf8，就和大家对兼容 windows 的要求相矛盾了。现在应当做的是提供一种转换的机制，例如界面翻译的资源文件会根据 LC_CTYPE 的值来自动转码。bmp 播放器支持对 mp3 文件的 ID3tag 自动转码。对于文件名编码，可以通过挂载时的选项来指定。等到大部分人使用 utf8 之后，这些转换反而不再有用处，因此现在做的是“曲线救国”。坚持只用 utf8 就会简化很多事情。

开发者的体会要更深一些。普通用户只会抱怨，在过渡中出现了乱码。可是，开发者已经忍了很久了。他们会等待只用 utf8 那天到来，而不会再去为某个特定的字符集而改进程序。等到大家发现 ID3lib 不再支持除 utf8 之外的编码时再去找工具，再想办法为自己的mp3数据转码，倒不如趁早转换。

要我说，这些播放器是用来放歌的，又不是用来看的，乱码没有关系，一点关系都没有
另外，现在的系统中，除了 xmms 或者 mplayer 这种使用 X core font 的 gtk1 程序会乱码，其他的程序都非常完善了。换用 bmp 吧

bbbush

http://id3lib.sourceforge.net/id3/id3v2.4.0-structure.txt

   If nothing else is said, strings, including numeric strings and URLs
   [URL], are represented as ISO-8859-1 [ISO-8859-1] characters in the
   range $20 - $FF. Such strings are represented in frame descriptions
   as <text string>, or <full text string> if newlines are allowed. If
   nothing else is said newline character is forbidden. In ISO-8859-1 a
   newline is represented, when allowed, with $0A only.

   Frames that allow different types of text encoding contains a text
   encoding description byte. Possible encodings:

     $00   ISO-8859-1 [ISO-8859-1]. Terminated with $00.
     $01   UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
           strings in the same frame SHALL have the same byteorder.
           Terminated with $00 00.
     $02   UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
           Terminated with $00 00.
     $03   UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.

   Strings dependent on encoding are represented in frame descriptions
   as <text string according to encoding>, or <full text string
   according to encoding> if newlines are allowed. Any empty strings of
   type $01 which are NULL-terminated may have the Unicode BOM followed
   by a Unicode NULL ($FF FE 00 00 or $FE FF 00 00).

hua_jacky1977

Post by bbbush
我倒是很仇视 gb* 似的。我们做好了 man-pages-zh_CN 但是因为技术水平不够不知道怎么让 groff 和 less 支持 gb*，结果只有在 utf8 的环境中才能看 man 手册页文档。http://sf.linuxforum.net/projects/cmpp 还放着那些 rpm，你可以下载回来看看。

你是不是没有用过 eclipse 和 cvs 啊？还是根本没用过 windows？ windows 的默认字符集并不像 linux 这样说换就换的。执行字符编码转换的，是输入时的文本框控件。cvs 不管文件的内容，不过因为大多数 unix 工具处理的是字节，utf8 编码是变长的，最长用到六个字节，每个字节单独拿出来都有特定的意义，因此可以适应得很好。而 gb* 编码是双字节，单独拿出一个字节是无法判定意义的，在处理中增加了很多负担。就冲着这一点就不喜欢。开发人员没有精力处理不同编码的特殊情况

utf8 不适合大规模使用？你知道 google 用的是什么吗？大概没人会注意到自己在用 utf8
兄弟们讨论的，不过是因为编码的技术改进了，应用程序却没有同时跟上罢了。无论是 acrobat reader 还是 xmms 都要处理两项事情，一个是访问硬盘上的文件，一个是访问文件中的数据。这两项都得到正确的数据之后，还要处理显示模块。xmms 还要额外多做一项，就是读取界面翻译的资源文件，同样需要显示出来。如果文件名编码，ID3tag 编码还有 LC_CTYPE 的值都相同，字体也配置得合适，那么无论是 utf8 还是 gb* 都不会出错。但是如果有一项或两项出错，那么组合起来的错误类型就会有很多种

虽说强制别人做什么事情不好，但是实际上因为两种编码无法调和，redhat 利用自己老大的地位，不遗余力地推行 utf8，就和大家对兼容 windows 的要求相矛盾了。现在应当做的是提供一种转换的机制，例如界面翻译的资源文件会根据 LC_CTYPE 的值来自动转码。bmp 播放器支持对 mp3 文件的 ID3tag 自动转码。对于文件名编码，可以通过挂载时的选项来指定。等到大部分人使用 utf8 之后，这些转换反而不再有用处，因此现在做的是“曲线救国”。坚持只用 utf8 就会简化很多事情。

开发者的体会要更深一些。普通用户只会抱怨，在过渡中出现了乱码。可是，开发者已经忍了很久了。他们会等待只用 utf8 那天到来，而不会再去为某个特定的字符集而改进程序。等到大家发现 ID3lib 不再支持除 utf8 之外的编码时再去找工具，再想办法为自己的mp3数据转码，倒不如趁早转换。

要我说，这些播放器是用来放歌的，又不是用来看的，乱码没有关系，一点关系都没有
另外，现在的系统中，除了 xmms 或者 mplayer 这种使用 X core font 的 gtk1 程序会乱码，其他的程序都非常完善了。换用 bmp 吧

我想不管是windows还是linux它的核心使用的字符集应该都不能改变吧，这两种系统都是通过修改配置文件，环境变量的方式来让其输入程序和显示程序按照某种编码工作。你一直说你是用eclipse和cvs作为开发环境，但是我说得是你这样做就必然要求和你一起工作的人都使用同样的环境，例如在windows下面的同志就需要也将字符集设成utf-8，不然它写的程序注释，properties文件是gb编码，你写的是utf-8编码，那能行吗？我说的是现实问题，而不是跟你在讨论谁优谁劣的问题，请兄台搞清楚。再一次声明我对utf-8没有仇视。
我是linux的爱好者，但是我不会强制别人使用linux，或者强制别人使用utf-8，因为每个人的生活和工作的环境以及想法都不一样，这就决定了每个人都有自己使用linux的方式，毕竟linux本来就是自由王国的奇葩嘛。

ogog

不知什么原因？

安装时选了简体中文和美国英语。

默认简体中文，这样我在locale是zh_CN.UTF-8.

后来转为美国英语，locale变为en_US-UTF-8

再转为简体中时，locale就变为zh_CN.GB18030了（REDHATr的locale就是这个）

真是怪。

lincomet

真不知道该怎么协调utf8和我国的强制标准GB18030。

有一个问题不是很明白（也许是我比较弱智），为什么我把locale是utf8（是suse中默认——最近测试了suse。），fat分区的中文文件名就可以显示，而把fc（包括以前的rh）的默认就不行呢，一定要改成gbk才可以显示中文，否则乱码。而好像有人在/etc/fstab里面挂fat分区，设置iochrset＝utf8也可以使fc的中文正常显示呢？

bbbush

Post by lincomet
真不知道该怎么协调utf8和我国的强制标准GB18030。

有一个问题不是很明白（也许是我比较弱智），为什么我把locale是utf8（是suse中默认——最近测试了suse。），fat分区的中文文件名就可以显示，而把fc（包括以前的rh）的默认就不行呢，一定要改成gbk才可以显示中文，否则乱码。而好像有人在/etc/fstab里面挂fat分区，设置iochrset＝utf8也可以使fc的中文正常显示呢？

挂载 fat 文件系统时需要指定一个编码。suse 的内核设置了默认值，所以用户不必再设置了。fedora 的内核也这样做过，但是据说会出错 (有些 utf8 中的字符不允许出现在 vfat 中，但是如果设置为默认值，那么就不会做检查)。中文用户使用 vfat 文件系统就必须加参数。你遇到的问题是参数不正确。iocharset 必须和 locale 的值匹配。