如果使用 utf8 那很有可能在未来还需要再进行这么一次编码迁移工作。
这也是为什么 GB18030 出现的原因，他是为了兼容 GB2312 而出现的编码方案。可以认为是以前的 GB2312 编码的扩展，如果中国真的想更换编码方案，那么已经有现成的方案了，就是基于 unicode 3 的中国编码标准 GBK （好像还有个别的名字，似乎统一名称是 ISO10646 ），还能轮得到 utf8 ？。中国政府会苯到放弃一个已经成型、可以和未来兼容的编码方案，来支持另一个还没有定论的方案？
在当时，韩国和日本也同时按照 unicode 设计了自己的编码方案。
按cjacker 的方案，那么会出现 GB -> UTF8 -> unicode 的现象。
而如果使用 GB18030 ，那么就省去了 UTF8 的过程。
要知道 utf8 和 GB18030 都是基于未完成的 unicode 4 进行设计的，要知道 unicode 还没有完整包含亚洲文字编码。
难道 utf8 就能完整包含？
utf8 考虑了西方字符的统一。
GB18030 考虑了中国少数民族文字的统一。GB18030 预留了 unicode 4 里尚未包含的很多文字。
你以为中国只会闭门造车？
要知道我妹妹的各种证件上“ 江 * ”已经很久了。
连 GB18030 都只能算是应急的标准，那 UTF8 就能算正式的方案？
要真想全球统一，只能等 unicode 完成全部的亚洲文字编码。
或者只能等中文改为拼音了，就象韩文拼写方式和日本的拼写方式。
中文的表型方式文字进行完整编码似乎比 100% 识别转换字符串还要困难。
cjacker 的方案，就是拿来增加成本的！
"GB18030 都是基于未完成的 unicode 4 进行设计的，要知道 unicode 还没有完整包含亚洲文字编码。"
藏文字体用一个gb18030字库就够了吗？
蒙文字体有一个gb18030字库就够了吗？
彝文字体用一个gb18030字库就够了吗？
这就是对少数民族语言的支持？
GBK是国标扩展的意思，而不是什么ISO10646，也就是GB2312扩展，到此为止，汉字仍然是双字节的，GB18030是1,2,4字节组合，也就是兼容了原有的GBK原有全部字符，在此基础上再次进行扩展，由于2字节码位范围是有限的，所以扩展到了四个字节。但是即使是四字节的也未必够用，所以现在台湾人在搞不定长编码。
我一直讲，默认使用utf8不等于放弃gb18030 。
同时我很熟悉制定gb18030的前因后果
你说的那个什么GBK不是叫GBK，而是叫GB13000，这个才是ISO10646的等价引用。而ISO10646跟Unicode的关系从很多文档上都可以获得。
连18030的制定小组都多次讨论过要不要放弃的问题，你还辩解什么？更何况，用不用是你的自由，没有人强迫你。
GB18030仅仅考虑了一个问题就是兼容问题，这个兼容是纯文本兼容的问题。
凡是带编码描述的都不存在这个问题。
但是，多语言支持怎么办？我前面都讲了，XWindow的GB18030支持是怎么实现的？从unicode转过来的。这里就有一个问题了.
GB18030和Utf8现在谁表的意更多，当然是Utf8多了。
到任何时候都会遇到输不出来的汉字，这个问题是靠一个GB18030能够解决的吗? 上户口或者办证的时候派出所的人会告诉你改名字的。
我不相信现在GB18030没有包含“堃”字，但是，还是要改名字。
很多问题是政治问题，不是技术问题。
此帖到此为止，发现最近的论坛已经不是在讨论问题了，不再浪费时间了。
此帖到此为止，发现最近的论坛已经不是在讨论问题了，不再浪费时间了。
你才发现啊:mrgreen::mrgreen:
我不相信现在GB18030没有包含“堃”字，但是，还是要改名字。不用改，我亲眼见过某人的身份证，“X堃”，上海市公安局发的。
GBK 的扩展是有根据的，我要没记错就是就版本的 unicode 。
如果 GB18030 包含了全部的中文编码而且都可以显示，那么就表明 unicode 也已进完整包含了。
我不认为同属 unicode 分支的 GB18030 和 utf8 比起来， utf8 最优秀。
你说 utf8 表意最多，你告诉我多在那里？
多在支持外文？中文呢？
难道用 utf8 就能完美显示藏文、蒙文、彝文？
就为了支持显示德文、法文等普通人不常用的语言去支持 utf8 ，而不考虑已经使用了 20 多年的文档转换而产生的成本增加？
是的，你可以说你用 utf8 也可以完美打开 gb18030 的编码而且不需要进行任何设置。
但我问问：
你怎么把以前的许多 GB 编码的文件和新的 utf8 编码的文件进行区分？
你能保证 RF 可以完美实现，但别的系统呢？
地方税务局进行个人所得税申报所提交的文本方式的 csv 文件也能同时双编码任意？
交给银行的电子文档也能双编码？
我刻录一个光盘给别人也可以双编码？
你 locale 为 utf8 我没意见，但我问你：你怎么保证计算机里的 GB 编码和 utf8 编码进行区分？
要知道现在几乎全部的软件都要进行 locale -> utf8 的转换，在 GB18030 的环境里出问题的软件都忘记了 locale -> utf8 。
我对 cjacker 的想法感到严重不理解。
我也很不理解他在解决什么问题。
各位的观点没几个能看懂的。。。 :?:?
只从用户习惯来理解：尊重用户的习惯，默认不可能会用UTF8。
用UTF8只会带来更多的麻烦，包括服务器和数据库和日常应用，网上到处blog上解决的各种编程或使用的中文乱码问题全是把它转换成GB码。如何先进都没有实用性，所以才要兼容，用户习惯是很难改变的。就象五笔输入法，使用98版五笔的人就没几个。使用GB码是在WIN时就养下的习惯，到Linux也无法改变。
而且从地方主义出发，我是决对不肯用三个字节来取代(GBK)两个字节存储，我以前在群里交流的朋友还有喜欢直接用单字节的拉丁文来存储。使用哪种编码根本就不是开发者决定的，完全是用户决定的，如果一个系统默认用UTF8很可能会使一部份用户立马放弃使用这个系统。
gb 18030四字节编码可以容纳126*10*126*10个字符，Unicode是17*65536，明显gb18030多。目前理论上不可能出现Unicode中存在但是gb18030无法编码的。
我特地查了一下， Unicode 4中藏文的编码区域从U+0F00到U+0FFF，最多也就256个，事实上也不可能支持到600多个。
gb18030中没有的在Unicode中有？不应该啊。
举个例子：
藏文有600多个字符，但是gb18030中只有其基本集。
当然了，gb18030一共多少个字，Unicode有多少个字啊。
GBK 的扩展是有根据的，我要没记错就是就版本的 unicode 。
如果 GB18030 包含了全部的中文编码而且都可以显示，那么就表明 unicode 也已进完整包含了。
我不认为同属 unicode 分支的 GB18030 和 utf8 比起来， utf8 最优秀。
你说 utf8 表意最多，你告诉我多在那里？
多在支持外文？中文呢？
难道用 utf8 就能完美显示藏文、蒙文、彝文？
就为了支持显示德文、法文等普通人不常用的语言去支持 utf8 ，而不考虑已经使用了 20 多年的文档转换而产生的成本增加？
是的，你可以说你用 utf8 也可以完美打开 gb18030 的编码而且不需要进行任何设置。
但我问问：
你怎么把以前的许多 GB 编码的文件和新的 utf8 编码的文件进行区分？
你能保证 RF 可以完美实现，但别的系统呢？
地方税务局进行个人所得税申报所提交的文本方式的 csv 文件也能同时双编码任意？
交给银行的电子文档也能双编码？
我刻录一个光盘给别人也可以双编码？
你 locale 为 utf8 我没意见，但我问你：你怎么保证计算机里的 GB 编码和 utf8 编码进行区分？
要知道现在几乎全部的软件都要进行 locale -> utf8 的转换，在 GB18030 的环境里出问题的软件都忘记了 locale -> utf8 。
我对 cjacker 的想法感到严重不理解。
我也很不理解他在解决什么问题。
吃错药了？
解决让开发者少打补丁的问题，解决让开发者的代码规范起来，不要仅仅locale specific的问题，解决我们的努力能够被main stream接受的问题。
你因为我要解决身份证人名不够用？还是解决祖国灿烂文明的保留问题。
这些问题靠gb18030和utf8可以解决吗？都远远不够，即使都unicode了也远远不够，台湾人是这么做的，用图片。
没有人要否定gb18030，也没有人说必须要用utf8。
用utf8跑系统，可以减少很多bug出现的机会。
在utf8下面不能编写gb编码的文档吗?
我真的不理解你到底要表达什么,干掉utf8,坚决支持gb18030?
Unicode不是为了解决西文问题,西文也根本不需要Unicode这样的方案.
什么叫外文,英文算不算?怎么理解问题这么狭隘?
你的观点是我们的计算机能显示中文就好了.
我前面已经讲了,用户可能用不到多语言,但是,你不能因为用户用不到就给他显示成乱码,计算机应该做的是忠实的反应内容.
少点火气,多点理解,耐心讨论能死吗?
"要知道现在几乎全部的软件都要进行 locale -> utf8 的转换，在 GB18030 的环境里出问题的软件都忘记了 locale -> utf8"
要从哪里知道?你读了多少代码就敢下这个结论?我问你一句韩文,日文或者一句不凑巧的繁体中文你从那个Locale转成utf8?
GB18030?转换出来会是什么东西?你的意思是说中国人一辈子都收不到外文邮件了?
在Gb18030里的软件都忘记了Locale->utf8,这个问题kanker估计都会比你清楚.你说的这种情况仅仅是最弱智的也是最易修复的.
gb 18030四字节编码可以容纳126*10*126*10个字符，Unicode是17*65536，明显gb18030多。目前理论上不可能出现Unicode中存在但是gb18030无法编码的。
我特地查了一下， Unicode 4中藏文的编码区域从U+0F00到U+0FFF，最多也就256个，事实上也不可能支持到600多个。
gb18030中没有的在Unicode中有？不应该啊。
举个例子：
藏文有600多个字符，但是gb18030中只有其基本集。
当然了，gb18030一共多少个字，Unicode有多少个字啊。
知道这是为什么吗？
那是我们中国人英语不好，沟通能力差，得不到老外的尊重，折腾了半天也没把码位要回来。
18030-2000现在是29000多吧，具体不记得。
引用一句：
“UTF-8 编码字符理论上可以最多到 6 个字节长,然而 16 位 BMP 字符最多只用到 3 字节长”
你说谁更能装。
当然gb可以继续扩展，到时候再搞一个6字节，8字节的汉字出来都行。
各位的观点没几个能看懂的。。。 :?:?
只从用户习惯来理解：尊重用户的习惯，默认不可能会用UTF8。
用UTF8只会带来更多的麻烦，包括服务器和数据库和日常应用，网上到处blog上解决的各种编程或使用的中文乱码问题全是把它转换成GB码。如何先进都没有实用性，所以才要兼容，用户习惯是很难改变的。就象五笔输入法，使用98版五笔的人就没几个。使用GB码是在WIN时就养下的习惯，到Linux也无法改变。
而且从地方主义出发，我是决对不肯用三个字节来取代(GBK)两个字节存储，我以前在群里交流的朋友还有喜欢直接用单字节的拉丁文来存储。使用哪种编码根本就不是开发者决定的，完全是用户决定的，如果一个系统默认用UTF8很可能会使一部份用户立马放弃使用这个系统。
系统处理好了你根本不会感觉到什么gb18030还是utf8。
你看到的，输入的，处理的仅仅是你认识的中文罢了。
Redhat, SuSE，除了中国境内的版本，没有一个在乎GB18030的，用户少了吗？
如果真少了倒好了。
此帖到此为止，发现最近的论坛已经不是在讨论问题了，不再浪费时间了。
你才发现啊:mrgreen::mrgreen:
我不相信现在GB18030没有包含“堃”字，但是，还是要改名字。不用改，我亲眼见过某人的身份证，“X堃”，上海市公安局发的。
很遗憾，我侄子就改了。
那就不关gb 18030的事啊。不管哪个编码，就算用utf-8一样对藏文支持不好，所以为什么要把这个作为gb 18030弊端的论据呢？
要说gb 18030不好的地方实在太多了，只不过这条不应该扣到它头上。
知道这是为什么吗？
那是我们中国人英语不好，沟通能力差，得不到老外的尊重，折腾了半天也没把码位要回来。
那就不关gb 18030的事啊。不管哪个编码，就算用utf-8一样对藏文支持不好，所以为什么要把这个作为gb 18030弊端的论据呢？
要说gb 18030不好的地方实在太多了，只不过这条不应该扣到它头上。
知道这是为什么吗？
那是我们中国人英语不好，沟通能力差，得不到老外的尊重，折腾了半天也没把码位要回来。
这个问题确实是因为这个原因造成的，但是就是因为中国人没有本事，所以这个就丢掉了。
红旗 的qt里面有一个补丁，这个补丁就是将一个码位范围给了藏文，以保证藏文的正常使用。
即使现有规模，GB18030目前明确定义的有3万不到吧.
至于码位范围，我引用一句话：
# UTF-8 编码字符理论上可以最多到 6 个字节长, 然而 16 位 BMP 字符最多只用到 3 字节长.
你说utf8和gb18030谁更大。
3万是目前有定义的汉字，Unicode中也是这个数目。事实上gb18030包括了Unicode的所有字符，还有一些自己的保留区。
UTF-8可以完全编码UCS-4，所以理论上可以到2^31。但是目前Unicode只有17个平面，而ISO也承诺不会使用U+10FFFF以上的空间。所以可以预见的将来，UTF-8不会用到5字节，gb18030也绰绰有余。当然很遥远的将来会怎样，那就谁都不知道了。
18030-2000现在是29000多吧，具体不记得。
引用一句：
“UTF-8 编码字符理论上可以最多到 6 个字节长,然而 16 位 BMP 字符最多只用到 3 字节长”
你说谁更能装。
当然gb可以继续扩展，到时候再搞一个6字节，8字节的汉字出来都行。
3万是目前有定义的汉字，Unicode中也是这个数目。事实上gb18030包括了Unicode的所有字符，还有一些自己的保留区。
UTF-8可以完全编码UCS-4，所以理论上可以到2^31。但是目前Unicode只有17个平面，而ISO也承诺不会使用U+10FFFF以上的空间。所以可以预见的将来，UTF-8不会用到5字节，gb18030也绰绰有余。当然很遥远的将来会怎样，那就谁都不知道了。
18030-2000现在是29000多吧，具体不记得。
引用一句：
“UTF-8 编码字符理论上可以最多到 6 个字节长,然而 16 位 BMP 字符最多只用到 3 字节长”
你说谁更能装。
当然gb可以继续扩展，到时候再搞一个6字节，8字节的汉字出来都行。
届时我们又如何解决一堆从其他Linux系统诞生的utf8文本呢?
为什么我们一定要自己玩而不能跟大家一起玩呢?
韩国人有本事把他们的组合字都放到Unicode,为什么中国人做不到?
这才是我们要考虑的问题.
RedHat就是不支持gb18030,不是照样在中国销售服务器产品吗?
如果只考虑linux，选择反而简单了，utf-8的优势要大很多。但是现在操作系统的主流是windows，它的输入输出还是gb，上面的软件对utf-8的支持也比linux少的多。
其实我的观点是，为了兼容传统，gb18030是不可少的，这个包括文档、源码、软件、系统等等。gb18030在国际化、本地化、多语言这些方面并没有特别的困难。如果对兼容的要求不高，采用utf-8是很不错的，毕竟一是接轨国际，二是编码方法优秀。
对桌面系统，我其实没有能力和资格来判断该默认采用哪种locale。不过，就我个人来看，采用utf-8可能会给售后带来很大的压力，如果有售后服务的话。redhat 8还是9刚刚默认utf-8的时候，太多人抱怨乱码问题了。所以考虑到一般用户，默认utf-8可能不是个好选择。对有经验的用户来说，默认什么都好说，大不了自己改嘛。
说到底，这是个远忧和近虑的权衡，看设计者怎么把握了。
届时我们又如何解决一堆从其他Linux系统诞生的utf8文本呢?
为什么我们一定要自己玩而不能跟大家一起玩呢?
韩国人有本事把他们的组合字都放到Unicode,为什么中国人做不到?
这才是我们要考虑的问题.
RedHat就是不支持gb18030,不是照样在中国销售服务器产品吗?
大家不要无为的争论,现在我们要的是解决方案,无论是上层的应用程序还是内核,能说一下原理?