locale为zh_CN.UTF8的问题
我用的是0801的版本，当locale为zh_CN.GBK时一切正常。可是改为zh_CN.UTF8的时候，控制台下zhcon不能显示汉字。在kde下，汉字可以正常显示，但是输入法却不能使用，调不出来。请问高手这两个问题如何解决呢？现在linux都在大力进行国际化的支持，如mandrake、fedora都开始把zh_CN.UTF8作为中文的默认编码。而且把unicode作为系统的默认编码也有着莫大的好处，至少kde的应用也不用费力转换了，我现在的应用都采用了UTF8作为编码基础的。可是为什么ml还要逆潮流而动，采用gbk之类的的编码呢？ 如果不用 gbk ，那现在的 Windows 下建立的数据就都用不了了。
这是没办法的事：Windows 的目录名是 GB 的，文件内容是 GB 的，MP3 的 ID3 是 GB 的………………
而且：GB 是中国国家标准。UTF-8 似乎没中国什么事。 历史遗留问题啊，按说国家的唯一强制中文编码标准是GB18030，可是也没有哪个系统真的用它来作为文件内容编码。UNICODE是GBK的超集，可以用工具无损的将GBK的文件名、文本文件内容转换。最近做的应用都是采用这种方式转换的，采用UNICODE作为数据交换的标准，尤其和台湾公司的合作项目。而LINUX下最方便采用的就是UTF8了。还有ORACLE/MYSQL等数据库也都采用了UTF8来作为国际数据存储的格式，XML默认编码格式也是，OpenOffice的文档，office2003的xml文档等。做应用采用统一的格式也少了很多关于编码转换出的古怪问题。 请问utf8下scim出不来怎么解决啊，我看文档不是说scim和locale没有关系么？ 为解决国际化问题，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 还有太多不完美的地方等你去改进。 历史遗留问题啊，按说国家的唯一强制中文编码标准是GB18030，可是也没有哪个系统真的用它来作为文件内容编码。UNICODE是GBK的超集，可以用工具无损的将GBK的文件名、文本文件内容转换。最近做的应用都是采用这种方式转换的，采用UNICODE作为数据交换的标准，尤其和台湾公司的合作项目。而LINUX下最方便采用的就是UTF8了。还有ORACLE/MYSQL等数据库也都采用了UTF8来作为国际数据存储的格式，XML默认编码格式也是，OpenOffice的文档，office2003的xml文档等。做应用采用统一的格式也少了很多关于编码转换出的古怪问题。
采用 gbk 的 locale 不等于不支持 utf-8，magiclinux 完全支持 utf-8。 如果不用 gbk ，那现在的 Windows 下建立的数据就都用不了了。
这是没办法的事：Windows 的目录名是 GB 的，文件内容是 GB 的，MP3 的 ID3 是 GB 的………………
而且：GB 是中国国家标准。UTF-8 似乎没中国什么事。
是呀！如果你在 utf-8 的 locale 下打开一个windows 下创建的文本文件，满屏幕都会是乱码。事实上，各个国家基本都是采用自己的编码，只有 windows 能做到一律通吃。windows 打开 linux 下的 utf-8 编码的文件之后，你需要指定编码为 utf-8 才能显示。但是这样一来它会在文件头部添加三个字节的 unicode 署名，导致在 linux 下使用可能出问题。 容量有限、残缺不全的 UTF-8 编码？？？ gb18030 毕竟是国家标准。 呵呵,不明白
gb18030 是只有部分字符才是 4 字节的
而 UTF-8 是 1-4 字节变长编码的,按理说 UTF-8 这种编码方式可以表示的字符集容量并不会很小啊,呵呵 KDE还是改不了睁眼说瞎话的习惯啊 gb18030采用了1/2/4字节的编码，容量100多万。utf8四字节编码也是容量100多万，没有质的区别。而且utf8六字节编码可以达到21亿的容量！
最可气的是gb18030不知怎么考虑的，第二字节可以采用0x40 ~ 0x7E编码，BIG5中著名的许盖功问题，都骂了这么多年了，18030中不是照样还犯？！说它脑子进水了不过分吧。 微软的记事本确实可以打开gbkgb18030 utf8utf16等编码的文件，可是这是它根据文件内容的编码范围进行大致判断那种编码格式的。文件字数很少的时候，记事本也是犯晕啊。像这样的功能，我们也完全可以实现的，例如给kedit之类的源代码基础上加一个编码转换就行了。windows不也是采用ucs2的内码，然后各种编码在它的基础上进行转换。 最近查资料，发现台湾已经有了将big5编码的目录文件名，转换成utf8的格式的小工具了。
中国的国家推linux就是典型的只嚷嚷不干实事，制定这个标准那个标准的，可是谁里她？一碰见硬查intel/micro的就玩完。做一个中文linux标准没人里，现在又推中文办公文件格式标准？真是有心的话做几套漂亮的unicode/18030的字体来，做些个好用的输入法多好。
另外谢谢kde, 我正在学习cce怎么用呢，有没有现成的ml下的rpm包？ 找到了
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
页:
[1]
2