关于为何启用 GB18030 local 的说明

cjacker

亲爱的同志们：

为了这个问题，大家非斗个你死我活不行？

我来总结一下：

1，Magic要用GB18030，我不反对。
2，红旗可能要用UTF8，我也不反对。
3，我反对GB18030需要更少的patch，因为事实证明Utf8需要更少的patch。
4，用Utf8并没有大家想象的那么多的数据交换问题，只不过可以节省很多作dirty patch的时间。出现问题的可能是纯文本文件和包封装内部的文件名，比如压缩包以及无编码描述的协议。
5，用Utf8不代表不能使用gb18030了。
6，GB18030和Utf8都不能解决全部的中文字，至少是现在。
7，Utf8比GB18030多，这个也不用争论。
8，用Utf8一个很好的地方是可以同时支持多语言。
9，Utf8并不是仅仅为西文而设计的。
10，Utf8或者说Unicode现在存在一些中文问题并不是说Unicode本身有什么缺陷，而是由于我们国人不努力造成的。
11，你在任何时间都可以将你的系统修改成gb的locale

大家都休息休息吧，不要让我们把坛子的气氛搞坏了。

sunmingming

[quote:86d0d288ba="sejishikong"][quote:86d0d288ba="zhengphou"]狭隘的民族主义者。 呵呵![/quote]
呵呵，我可不是狭隘的民族主义者，虽然我是有点民族主义，但是我不拒绝日货，不反对美帝:D
这个是事实，如果中国是美国在世界上的地位，那么很多事情根本不用考虑，国际上的度量衡虽然有公制，可美国人就可以用美制，甚至在一些领域国际通用的就是美制，就是因为美国是老大。[/quote]

拒绝日货，反对美帝 就是狭隘了？

某些伪自由主义者的话语霸权而已。

sejishikong

[quote:a6e07c5a4d="sunmingming"][quote:a6e07c5a4d="sejishikong"][quote:a6e07c5a4d="zhengphou"]狭隘的民族主义者。 呵呵![/quote]
呵呵，我可不是狭隘的民族主义者，虽然我是有点民族主义，但是我不拒绝日货，不反对美帝:D
这个是事实，如果中国是美国在世界上的地位，那么很多事情根本不用考虑，国际上的度量衡虽然有公制，可美国人就可以用美制，甚至在一些领域国际通用的就是美制，就是因为美国是老大。[/quote]

拒绝日货，反对美帝 就是狭隘了？

某些伪自由主义者的话语霸权而已。[/quote]
狭隘在这儿没有贬义的意思，只是相对而言的，我不是单纯的拒绝日货，也不是单纯的反对美帝，所以说我不算狭隘的民族主义者。

cjacker

[quote:88b9d1474c="sejishikong"][quote:88b9d1474c="sunmingming"][quote:88b9d1474c="sejishikong"][quote:88b9d1474c="zhengphou"]狭隘的民族主义者。 呵呵![/quote]
呵呵，我可不是狭隘的民族主义者，虽然我是有点民族主义，但是我不拒绝日货，不反对美帝:D
这个是事实，如果中国是美国在世界上的地位，那么很多事情根本不用考虑，国际上的度量衡虽然有公制，可美国人就可以用美制，甚至在一些领域国际通用的就是美制，就是因为美国是老大。[/quote]

拒绝日货，反对美帝 就是狭隘了？

某些伪自由主义者的话语霸权而已。[/quote]
狭隘在这儿没有贬义的意思，只是相对而言的，我不是单纯的拒绝日货，也不是单纯的反对美帝，所以说我不算狭隘的民族主义者。[/quote]

同志，跑题了。

sejishikong

[quote:71de0dd7b8="cjacker"]
同志，跑题了。[/quote]
呵呵，公社一大景观，就是跑题。 :D
不说了。再跑就太远了。

jiangtao9999

cjacker, 我没有反对 RF 使用 utf8 ，而我是在疑惑 RF 如何解决兼容旧系统编码的问题！

因为目前 Linux ，都是基于 locale 来确定编码如何转换的。
如果 RF 使用 UTF8 作为 locale ，那么系统如何读取，保存 GB 编码文件？

你不要说 RF 将会提供软件，一次性把所有 GB 编码进行转换…………………………
你也不要说使用 RF 的软件的人，他们肯定就会使用 UTF8 。

你是不是要说 RF 会设计桥接库，自动区分编码？保存的时候自动转换？
做到编码与系统无关？

发现每次和红旗的人讨论问题，对方都不能明白我什么意思………………………………

fingster

水贴，留名

cjacker

[quote:f97aec4e41="jiangtao9999"]cjacker, 我没有反对 RF 使用 utf8 ，而我是在疑惑 RF 如何解决兼容旧系统编码的问题！

因为目前 Linux ，都是基于 locale 来确定编码如何转换的。
如果 RF 使用 UTF8 作为 locale ，那么系统如何读取，保存 GB 编码文件？

你不要说 RF 将会提供软件，一次性把所有 GB 编码进行转换…………………………
你也不要说使用 RF 的软件的人，他们肯定就会使用 UTF8 。

你是不是要说 RF 会设计桥接库，自动区分编码？保存的时候自动转换？
做到编码与系统无关？

发现每次和红旗的人讨论问题，对方都不能明白我什么意思………………………………[/quote]

wo kao，打击面太大，或许仅仅是我听不懂。

我在前面的帖子已经详细的讲过从gb到utf8可能会发生的问题。

其中：
带格式，带编码描述的文件没有问题。(邮件，html,doc等等)

带编码描述的协议没有问题。(samba)

文件系统没有问题。

那么剩下的就是纯文本，无编码描述的协议和封包内部的文件名(比如压缩包)。

纯文本，你可以选择用工具转换，你也可以选择在打开时进行编码选择。

这里我可以反问你一个问题：你在gb环境下又是怎么读utf8纯文本的？

无编码描述的协议，比如ftp，最好默认设置为gb18030，为什么呢？考虑到用户可能遇到更多的ftp站点是gb的。

封包内部的文件名，我前面也讲过了，他其实是依赖与两个平台之间的工具实现的。

rar，各平台都没有问题。

如果你用gb，那么你的tar包发给fedora或者SuSE用户会有什么问题？不一样是乱码。你发tar给Linux的机会大还是给Windows的机会大？


编码切换，不应该让用户明显的感觉到，这一点对用户来讲应该是透明的。
编码切换，也不是要彻底放弃一个，采用另一个。难道Linux只能gb18030 locale吗？

不是我没听懂，而是你讨论问题的时候根本不看前面的帖子，你以为大家一拍脑袋就决定要切换了？这个东西要进行很仔细的论证，充分考虑各种情况的发生，谁也不能保证绝对没有问题，但是要考虑那种选择的代价更低，更有意义。

为了gb支持，我们已经给KDE做了太多ugly hack，因为有些问题实际上是没有办法用正确的方式修复的。

此外，我上面提到了，我再重复一遍，没有任何一个库能够实现对编码的100％准确的探测。所以，希望100%编码探测库解决问题的就死了心吧。

那么，我还要问你一个问题：

gb locale下的一段文本，我应该通过什么方式转换？

你前面提到的是locale->utf8。

如果是日文怎么办，如果是韩文呢，或者其他的语言呢？

你又从什么locale下去转换？

这个问题，我们进行了大量的论证和历史补丁的分析，你做了多少了，一切都靠假设和想象？

jiangtao9999

这里我可以反问你一个问题：你在gb环境下又是怎么读utf8纯文本的？

我根本就没有 utf8 编码的文本文件。
因为像我这种普通用户，根本就不需要用 utf8 。
我只要保证我机器里所有编码都是 GB ，而且别人要求的也都是 GB 编码（比如税务局，民政局，别人的机器）。

我可以不可以认为：RF 默认 utf8 ，之后根据需要默认打开某些软件的 gb -> utf8 编码功能？
但这样如果我安装一个原版的、基于 locale 识别的软件会有什么结果？

不是我不看前面的帖子，是前面的帖子影响了我的问题。（公社跑题严重是众所周知的）
我在开始就是在质疑 RF 使用 utf8 会导致 utf8 和 GB 混乱，因为毕竟在中国 GB18030 还是常用的。

PS：kuye 也不能理解我的意思。

haulm

其实就是纯文本和文件名的乱码问题，我相信大家接触纯文本和文件名要更多一些，默认用UTF8对老鸟是没影响，但对新手会多了好多的乱码疑问。系统完全用UTF8的好处就是使得编程得以解脱，免得一遇到中文字就要转换编码。

如果能很好地处理纯文本和文件名，那就没这么多争论－－最容易想到的是开发一个GUI工具来解决编码问题，对指令iconv和mv，入门LINUX的朋友都会用，但层层目录并且批量转换就不行了。

也就是说，如果有一档子非常简单、方便并且不会太占用时间的编辑解决方案，用什么编码都是一回事，大家争了这么久，用什么编码还是各有各的道理，真正决定用什么的是用户而不是开发者。

这样的争论还不如投票好了。

jiangtao9999

忘了说了，我的疑问是所有软件 locale -> utf8 ，之后根据用户需要自己修改软件的转换编码成本低；
还是 patch 程序让系统支持 utf8 下自动 gb 转换成本低；
还是全转换本地文件到 utf8 成本低？

我认为，软件自己 locale->utf8 成本最低（似乎 GB18030 的设计组也是这么考虑的）。
对于外国编码的支持问题，可以用程序进行设置编码转换功能来解决。

毕竟中国人用 GB18030 的多。

除了自动识别，还能从 Windows 那里学到别的方法么？
似乎 Windows 很少遇到这个问题。

sunmingming

首先声明我对汉字编码技术知识没什么了解。

但现在看来，还没有完美的方案出现。 或许cjacker说的对，我们努力的不够。但是不是在unicode上面，而是在国标上。

我们首要的是对自己的语言系统进行完整的编码。中国自己文字的编码问题还没有完全解决，去抢那个还没定型的unicode码位作甚？完全解决之后，什么问题都搞清楚了，再谈码位分配的问题。

注意，我说的是搞清楚文字的编码，并没有说一定采用某种编码格式来搞。你用unicode可以做一套完整的，我用GB也可以做一套完整的。重要的是汉字等中国所用的文字编码的确定性的东西搞清楚，而这种东西是不随编码而转移的。

基于现实情况，搞这些东西的基本都是语言所属国的人。因此，一般会形成本国语言的国标版本。一般来说，国标是受外界影响最小，最能体现本国文字特点的标准。国标是全球统一编码的基础。再次注意，我没有说国标一定就区别与现有的unicode编码。没准以后国标用了unicode编码。但是一个优秀的国标是重要的。

文字编码直接影响到历史与文化的传承。 如果有某一本古籍中的某个字没有编码，那那本书就不能原样重现在计算机上。全球统一编码是趋势，但其最终的全球统一编码应当是各个优秀的国标的协商结果。用那种编码无妨，但对国标编码不能持无所谓的态度。

对Magiclinux的编码选择，我没什么建议。我用magic以来，除了邮件乱码之外，还没有碰到什么编码问题。而前面有朋友说utf8也没什么问题。技术上二者可能都可行。

对我个人来说，我希望用GB。因为我在windows下有不少txt，htm。懒得装了之后再改locale。况且我现在还不知道怎么改。

haulm

尊重使用习惯是开发首先要考虑的，而不能单纯从技术上考虑如何减少麻烦。GB码不但是国家强制的编码，也是中国计算机用户长期正在使用的编码，默认的编码如果是一种大多数用户都不能一时适应的编码等同于强制性推广新的编码，减少开发成本的同时增加了用户的成本，并且这个编码并非被中国政府所推荐的编码，其结果就是完全和国家的文化政策背道而驰，结果不用多说。

KDE

到此为止，我想说的是，我们无论如何不能脱离中国当前的大环境，本着一切以用户为中心的原则，尊重用户的使用习惯，减少他们使用上的麻烦和困惑，尽可能做到与 win 平台的无缝衔接，是 magic linux 这个社区版本的中心工作宗旨。

就目前而言，尚无法完全明确到底什么编码对用户而言最舒适的情况下，冒然对底层的任何基础架构作出重大改动都可能带来意想不到的风险。在 2.x 系列里，务必以追求稳定、可靠、易用性为前提，以修正 BUG、改进用户体验为工作中心。

所以当前不宜变更 local，毕竟我们在它上面调试了一年时间。未来会不会改变，还要看国家政策，还要开发组同志们的讨论，还要征求社区的意见。或许红旗走在前头，前方是鲜花还是雷池，红旗先趟了，有益的经验教训我们会吸取。

superman

我感觉公社的人尽量些学生，而像我的社会青年不多