QQ登录

只需一步,快速开始

 找回密码
 注册

QQ登录

只需一步,快速开始

查看: 3479|回复: 19

locale为zh_CN.UTF8的问题

[复制链接]
发表于 2004-10-18 14:25:03 | 显示全部楼层 |阅读模式
我用的是0801的版本,当locale为zh_CN.GBK时一切正常。可是改为zh_CN.UTF8的时候,控制台下zhcon不能显示汉字。在kde下,汉字可以正常显示,但是输入法却不能使用,调不出来。请问高手这两个问题如何解决呢?

现在linux都在大力进行国际化的支持,如mandrake、fedora都开始把zh_CN.UTF8作为中文的默认编码。而且把unicode作为系统的默认编码也有着莫大的好处,至少kde的应用也不用费力转换了,我现在的应用都采用了UTF8作为编码基础的。可是为什么ml还要逆潮流而动,采用gbk之类的的编码呢?
发表于 2004-10-18 17:05:24 | 显示全部楼层
如果不用 gbk ,那现在的 Windows 下建立的数据就都用不了了。

这是没办法的事:Windows 的目录名是 GB 的,文件内容是 GB 的,MP3 的 ID3 是 GB 的………………

而且:GB 是中国国家标准。UTF-8 似乎没中国什么事。
回复

使用道具 举报

 楼主| 发表于 2004-10-18 17:47:13 | 显示全部楼层
历史遗留问题啊,按说国家的唯一强制中文编码标准是GB18030,可是也没有哪个系统真的用它来作为文件内容编码。UNICODE是GBK的超集,可以用工具无损的将GBK的文件名、文本文件内容转换。最近做的应用都是采用这种方式转换的,采用UNICODE作为数据交换的标准,尤其和台湾公司的合作项目。而LINUX下最方便采用的就是UTF8了。还有ORACLE/MYSQL等数据库也都采用了UTF8来作为国际数据存储的格式,XML默认编码格式也是,OpenOffice的文档,office2003的xml文档等。做应用采用统一的格式也少了很多关于编码转换出的古怪问题。
回复

使用道具 举报

 楼主| 发表于 2004-10-18 17:49:10 | 显示全部楼层
请问utf8下scim出不来怎么解决啊,我看文档不是说scim和locale没有关系么?
回复

使用道具 举报

发表于 2004-10-18 22:00:13 | 显示全部楼层
为解决国际化问题,linux 很早以前就已采用 utf-8 作为内部编码,我们所做的翻译都是采用的这种编码。但是 对于大部分西方国家而言,他们对于支持 unicode 大字符集根本就不感兴趣,因为他们的字符集都很小,没有必要耗费巨大资源和精力支持庞大的 cjk 字符集。作为一种折中方案,现在 linux 下普遍使用 utf-8 编码。然而这只是一相情愿,因为互联网上普遍采用的是 ANSI 字符集,中文就是 GB2312。毕竟使用 windows 的人是绝大多数,windows 默认使用 GB2312,这是历史遗留问题,为了兼容现在的环境,采用 GBK 是理想的解决方案。否则就要处处转换。IE 6 的国际化内核现在还无人能比,基本上遇到什么编码都能正确显示出来。MagicLinux 1.2 从一开始就支持 UTF-8 和 GB18030,关键是我们没有开源的 GB18030 字体,如果没有大型公司或者政府出面,几个人是绝对不可能完成开发字体这么浩瀚的工程的,况且是兼容 unicode 的超大字符集。不要想当然,站着说话,你是不腰疼。如果支持,我们也会选择国家强制标准-- GB18030 编码,而不会采用 UTF-8 编码。如果使用中文控制台,请使用我们提供的 cce,支持到 utf-8。不要使用落后的 zhcon,这个东西最多支持到 gbk。作桌面,linux 还有太多不完美的地方等你去改进。
回复

使用道具 举报

发表于 2004-10-18 22:04:28 | 显示全部楼层
[quote:5fe2f4ae9c="liguangyi"]历史遗留问题啊,按说国家的唯一强制中文编码标准是GB18030,可是也没有哪个系统真的用它来作为文件内容编码。UNICODE是GBK的超集,可以用工具无损的将GBK的文件名、文本文件内容转换。最近做的应用都是采用这种方式转换的,采用UNICODE作为数据交换的标准,尤其和台湾公司的合作项目。而LINUX下最方便采用的就是UTF8了。还有ORACLE/MYSQL等数据库也都采用了UTF8来作为国际数据存储的格式,XML默认编码格式也是,OpenOffice的文档,office2003的xml文档等。做应用采用统一的格式也少了很多关于编码转换出的古怪问题。[/quote]
采用 gbk 的 locale 不等于不支持 utf-8,magiclinux 完全支持 utf-8。
回复

使用道具 举报

发表于 2004-10-18 22:16:06 | 显示全部楼层
[quote:9b1b53dace="jiangtao9999"]如果不用 gbk ,那现在的 Windows 下建立的数据就都用不了了。

这是没办法的事:Windows 的目录名是 GB 的,文件内容是 GB 的,MP3 的 ID3 是 GB 的………………

而且:GB 是中国国家标准。UTF-8 似乎没中国什么事。[/quote]

是呀!如果你在 utf-8 的 locale 下打开一个windows 下创建的文本文件,满屏幕都会是乱码。事实上,各个国家基本都是采用自己的编码,只有 windows 能做到一律通吃。windows 打开 linux 下的 utf-8 编码的文件之后,你需要指定编码为 utf-8 才能显示。但是这样一来它会在文件头部添加三个字节的 unicode 署名,导致在 linux 下使用可能出问题。
回复

使用道具 举报

发表于 2004-10-18 23:21:49 | 显示全部楼层
容量有限、残缺不全的 UTF-8 编码???
回复

使用道具 举报

发表于 2004-10-18 23:50:11 | 显示全部楼层
gb18030 毕竟是国家标准。
回复

使用道具 举报

发表于 2004-10-19 09:56:53 | 显示全部楼层
呵呵,不明白
gb18030 是只有部分字符才是 4 字节的
而 UTF-8 是 1-4 字节变长编码的,按理说 UTF-8 这种编码方式可以表示的字符集容量并不会很小啊,呵呵
回复

使用道具 举报

发表于 2004-10-19 10:53:25 | 显示全部楼层
KDE还是改不了睁眼说瞎话的习惯啊
回复

使用道具 举报

 楼主| 发表于 2004-10-19 10:56:44 | 显示全部楼层
gb18030采用了1/2/4字节的编码,容量100多万。utf8四字节编码也是容量100多万,没有质的区别。而且utf8六字节编码可以达到21亿的容量!
最可气的是gb18030不知怎么考虑的,第二字节可以采用0x40 ~ 0x7E编码,BIG5中著名的许盖功问题,都骂了这么多年了,18030中不是照样还犯?!说它脑子进水了不过分吧。
回复

使用道具 举报

 楼主| 发表于 2004-10-19 11:06:03 | 显示全部楼层
微软的记事本确实可以打开gbk  gb18030   utf8  utf16等编码的文件,可是这是它根据文件内容的编码范围进行大致判断那种编码格式的。文件字数很少的时候,记事本也是犯晕啊。像这样的功能,我们也完全可以实现的,例如给kedit之类的源代码基础上加一个编码转换就行了。windows不也是采用ucs2的内码,然后各种编码在它的基础上进行转换。
回复

使用道具 举报

 楼主| 发表于 2004-10-19 11:14:36 | 显示全部楼层
最近查资料,发现台湾已经有了将big5编码的目录文件名,转换成utf8的格式的小工具了。
中国的国家推linux就是典型的只嚷嚷不干实事,制定这个标准那个标准的,可是谁里她?一碰见硬查intel/micro的就玩完。做一个中文linux标准没人里,现在又推中文办公文件格式标准?真是有心的话做几套漂亮的unicode/18030的字体来,做些个好用的输入法多好。
另外谢谢kde, 我正在学习cce怎么用呢,有没有现成的ml下的rpm包?
回复

使用道具 举报

 楼主| 发表于 2004-10-19 11:33:06 | 显示全部楼层
找到了
http://www.magiclinux.org/people/kde/magic/rpms/cjk-console/cce-0.51-1mgc.i686.rpm

http://www.linuxfans.org/nuke/modules.php?name=Forums&file=viewtopic&t=85093&highlight=cce
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

GMT+8, 2024-11-26 10:23 , Processed in 0.093672 second(s), 15 queries .

© 2021 Powered by Discuz! X3.5.

快速回复 返回顶部 返回列表