再论UTF8码locale应用是否方便
试用了一星期的Everest，感觉locale为UTF8在使用多语言支持完整的软件、编译器时是没问题的。但同时发现不少的应用程序没有zh_UTF8的概念，这些程序只用en_UTF8，对中文支持用的是GBK。中文编码的应用特别在linux下是很混乱的，你用UTF8会发现乱码，你用GBK一样也会遇到乱码，纠结编码问题还会泱及输入法，特别是SCIM。短期内应用WIN的用户仍远超过Linux用户，大量的资料文档也会继续使用GB18030，所以locale使用UTF8的麻烦似乎远超过使用GBK。 没有什么理性的认识 只是感觉utf8 好ooo 的文件和 doc 的文件都不受这个影响
纯文本转换过来就好 对于 utf8 ，你可以把你所有的文字全都转换过去。
这只是你一个人的工作。
如果继续 gb18030 ，那需要所有的程序都进行修改。
这是很多人的工作。
是你一个人干活好呢，还是一帮人干活好呢？
en.utf8 和 zh_cn.utf8 基本上没区别，你遇到的那些估计是支持 en.iso8859 的。
en.utf8 和 zh_cn.utf8 基本上没区别，你遇到的那些估计是支持 en.iso8859 的。
如果从编码上说自然没有什么错，但从中文支持上en.utf8也就是英文，你要的中文菜单却是GBK的。
当然我说的只是方便与否，仁兄认为与其让开发者去改程序还不如让用户们自己去适应和转换UTF8？
问题是如果国内对应用编码不能口径一致，后果就是更混乱。 这个说法不太对吧？
现在有哪些程序可以在utf-8下支持中文，但是在gb下需要“修改”才能用的？太少了吧，我知道的极少数几个也都是因为历史遗留问题。
如果继续 gb18030 ，那需要所有的程序都进行修改。
这是很多人的工作。
现在国外开源的程序基本上都支持utf8、gbk，但对zh_utf8的支持却并不到位，你可以把程序按utf8编译，但安装结束发现找不到中文支持。
唉，不讨论了，混乱的东西导致思唯也混乱，jiangtao9999兄原来是反对locale用utf8的。 我的看法是gb也好，utf-8也好，本质上一样，谁也不比谁更好。如果utf-8下应用有问题就用gb，如果gb下有问题就用utf-8，如果啥问题都没有就用默认的。 历史会说明一切，大家努力就好。 几位老大废话了一堆 ，，没讨论出个子丑寅卯来。。。
那个GB18030 在WIN下不是国家标准吗？忘记哪看来的了
LINUX下倒不清楚。。 TO haulm：
locale 是 utf8 ，菜单式 GBK 的话，那你是你的程序编写的问题。或者是 linux 基础库的问题。
目前所有的菜单，界面文字，都是 utf8 编码的。
你需要在编写程序的时候保证所有的源代码都是基于 utf8 编写的。
我现在也依然反对 locale 是 utf8 ，但这并不和系统内部使用 utf8 冲突。
utf8 是让全世界编码都一样的唯一的办法。但这需要所有的数据都从头开始，他不适用于原有的各种格式的，需要和旧有编码继续交换的情况。
对于程序员来说，使用 utf8 编写和 gbk 编写没有什么不同，因为他的源代码都是一种编码，而且转换后源代码就会编译成二进制程序，不存在文本文件还要进行数据交换的问题。因为系统内部就是 utf8 的。
并且，将文本进行源代码分离也是一个多语言编写的好习惯。
而本地保存的 gb 数据，不可能像有工程软件管理的源代码那么容易整理、转换，并且他需要和旧有程序进行交互，不可能完全变更编码。
内部运算，utf8 目前正好，数据保存，还是需要 gb 系列。
这两个不存在本质的冲突，唯一的问题就是程序编写缺乏详细的设计，导致编码混乱。
TO woolzey：
如果没有遗留问题，那么就不存在编码问题了。 的确程序内部基本都已采用 utf-8，我们翻译程序界面也是使用 utf-8，大量工具的输出也是 utf-8。但一定要做好协调和转换工作，要良好作到兼容现有的编码，否则就会给用户找麻烦。 事实上现在大量在内部使用utf-8的程序都是拿字符串当英文来处理，并不是真正的国际化。这样的程序绝大多数不需要处理文字，不需要理解字符串的含义，所以采用utf-8的话程序员可以偷懒沿用处理英文的方法。这并不说明utf-8真的适合作为内部编码。
真正需要处理不同语言的软件，大多在内部使用utf-16。除了商业软件以外，开源软件中openoffice, XeTeX，以及IBM做的国际化库ICU都是选择了utf-16。XeTeX的作者写过一篇文章，提到他为什么选用utf-16，而不是utf-8，里面说的还是很有道理的。IBM好像也有一个文档是关于ICU使用utf-16的原因。
utf-8的设计特点决定了它很适合作为交换编码，但是并不是代表它一定适合做内部编码，至少在有严肃的多语言支持需求的应用中不见得适合。今后，不需要真正处理文字的软件可能会逐渐在内部采用utf-8，以降低开发难度；需要处理文字的软件，会逐渐使用utf-16/32这样易于处理的编码。所以，不太可能所有程序都在内部统一使用utf-8。
的确程序内部基本都已采用 utf-8，我们翻译程序界面也是使用 utf-8，大量工具的输出也是 utf-8。但一定要做好协调和转换工作，要良好作到兼容现有的编码，否则就会给用户找麻烦。 正如楼上所说的，现在大量在内部使用utf-8的程序都是拿字符串当英文来处理，并不是真正的国际化，这是我使用Everest编译和使用不少程序后的感受，也谢谢jiangtao9999的提醒，不过win程序开发使用unicode和linux程序开发使用utf8我是知道的。 事实上现在大量在内部使用utf-8的程序都是拿字符串当英文来处理，并不是真正的国际化。这样的程序绝大多数不需要处理文字，不需要理解字符串的含义，所以采用utf-8的话程序员可以偷懒沿用处理英文的方法。这并不说明utf-8真的适合作为内部编码。
真正需要处理不同语言的软件，大多在内部使用utf-16。除了商业软件以外，开源软件中openoffice, XeTeX，以及IBM做的国际化库ICU都是选择了utf-16。XeTeX的作者写过一篇文章，提到他为什么选用utf-16，而不是utf-8，里面说的还是很有道理的。IBM好像也有一个文档是关于ICU使用utf-16的原因。
utf-8的设计特点决定了它很适合作为交换编码，但是并不是代表它一定适合做内部编码，至少在有严肃的多语言支持需求的应用中不见得适合。今后，不需要真正处理文字的软件可能会逐渐在内部采用utf-8，以降低开发难度；需要处理文字的软件，会逐渐使用utf-16/32这样易于处理的编码。所以，不太可能所有程序都在内部统一使用utf-8。
的确程序内部基本都已采用 utf-8，我们翻译程序界面也是使用 utf-8，大量工具的输出也是 utf-8。但一定要做好协调和转换工作，要良好作到兼容现有的编码，否则就会给用户找麻烦。
大家可以注意到主流商业软件基本都在用 utf-16。 停住这个问题在以前已经是最烂的问题,我的观点,服务器用utf8因为开发的多半用fc和debian,至于桌面以后把这个问题还是交给核心来处理,象win一样,高层的程序根本不要处理这个问题,象用locale来转换我看也是个暂时的方案.
http://www.linuxsir.org/bbs/showthread.php?t=180572
页:
[1]
2