Magic Linux 2.1 正式发布
面向中文用户的本土 Linux 发行版 Magic Linux 经过两年的开发最终于昨日发布了 2.1 的正式版。Magic Linux 2.1 包含 Linux Kernel 2.6.25.20、Qt 3.3.8、KDE 3.5.10、glibc 2.3.6、Xorg 1.5.2 等主要组件，自 RC 3 以来的主要更新为：
1.更新内核到2.6.25.20 2.更新xorg-server到1.5.2，同时更新配套软件包。 3.更新kfuseiso，修正中文支持问题。 4.更新ffmpeg，打开swscale支持。 5.更新fcitx到Girldog，修正了一些bug 6.更新wine到1.1.8，修正部分中文的显示问题 7.更新konversion 8.更新cmake 9.更新hal，修正普通用户挂载需要输入密码的问题。 10.更新udev，修正hal不能挂载移动硬盘的问题。
下一个版本
据开发者在发布通告中表示，Magic Linux 下一步将转向 2.5 的开发。Magic Linux 2.5 开发代号为"Jingyou"（景佑），将同时有 KDE 4 和 KDE 3 两个版本，但以 KDE 4 为主。编译器将采用 GCC 4.2，glibc 将使用 2.7 或更高版本。在元旦前后，Magic Linux 团队将放出供开发人员使用的 2.5 Snapshot 版本，明年 3 月将出 Alpha 测试版，6 月出 Beta 测试版，10 月进入 RC 阶段，正式版预计 12 月可以抵达。
更多信息，可见 Magic Linux 2.1 发布通告。
Magic Linux 2.1 提供 CD、DVD 及兼容内核版本，可从以下地址下载：
MagicLinux-2.1.Houyuan.cd-1.iso (CD) MagicLinux-2.1.Houyuan.dvd-1.iso (DVD) MagicLinux-2.1.Houyuan.uni-1.iso (兼容内核版本，内核为 2.6.23.17，Wine 为 1.0) MD5SUM
Read More:
magic不容易，项目主持sejishikong也不容易。 大家有空多去linuxfans逛逛，毕竟是中国最纯粹的社区版本。
希望magic2.5能够重振magic的辉煌！
默认字符集不是采用UTF－8有点不爽，毕竟国际化是大势所趋的
中国人当然支持自己的中文标准了
@f@UTF-8.uck:
GB是M$的标准还差不多。 就算是“自己的标准”，那又怎样？如果ML自己搞一个汉字编码，你会去用么？编码这种东西，就是要统一了才好。
GB这种过去存储器紧缺时代的产物早就该淘汰了。
同意楼上
同意楼上
同意楼上
同意楼上
别扯什么自己的中文标准,做张身份证生僻字都打不出，还让人家改名，全国还刮起了改生僻地名的臭风气，这是什么狗屁标准
难道我们解决的乱码问题还少么？
现在身边大家都utf-8了。问题就没有了。多爽。
我用过一年，觉得桌面做的非常体贴。 "景佑"?一休中的“景佑卫门”？
关于编码，我觉得只要一般的软件（比如文本编辑器、浏览器、音乐播放器）能自动识别和支持GB就行了，系统默认应该还用UTF-8，目前乱码比较多的还是MP3标签吧，而事实上新型的MP3标签例如APEv2之类的也开始流行起来了，老式的ID3应该是时候淘汰了
@yang: 我记得是“西佑卫门”吧。。。
我说一下，linux用户可能utf8是标准，但是不可否认，linux用户只是一小撮而已。 只要windows坚持gb，那么gb就是事实上的标准。 magic这么做，就是使和windows共享数据的用户，没有任何乱码的切换系统。 我敢说，99%的linux用户，电脑里都有一个windows。 在linux版本越来越一致化的时候，magic坚持用gb编码正好给不喜欢编码转换的用户提供了一个选择。反正utf8版本满大街跑，GB编码linux 却极少见
首先谢谢大家的支持……
@wangping: 竟然连GB编码这种鸡肋都舍不得放弃，那么这些事实标准呢？ M$ Office, QQ, IE, VB, 以及Windows。。。
@alen: 我怎么记得是“新佑”？
@ f@UTF-8.uck 中国人的最新标准gb18030,实际上就是个垃圾。 现在世界上都是unicode的了，当时就应该直接从gbk到unicode。
utf-8 毕竟是趋势，这个是无法否认的。utf-8有效的解决了乱码问题。在windows下打开utf8的文件是没有问题的。这个是历史遗留问题，如果gb这么好的话，ms就不会支持utf-8了。
@toy 我刚才的话怎么发不上去。
unicode有效的解决了，乱码问题。不论是文档，网页，数据库。 对大家的好处是太多了。 gb是一个历史遗留问题，可以说是中文网页乱码的根源。
最新的中文标准gb18030，就是个rubbish， 当时就应该直接从gbk直接到Unicode。那个时候已经有cjk了。 但是很讽刺的是cjk是外国人搞的。作者好像是freetype的维护者。
发现好像有关键词屏蔽。希望有人出个列表。
还行
mp3id v1 不支持utf8, 但是id v2 已经支持了。用mutagen转换一下就好。
@gcell: 貌似是 "新右卫门"
@ginkgo: 抱歉，被系统自动挡了，已经恢复。
一群人连自己说的是什么东西都不知道 还说的这么振振有词 真是令人哭笑不得
utf-8不是字符集，是unicode的一种编码方式 GB2312、GBK是字符集，也是编码方式 但是现在我们说的GB18030也是一种Unicode的编码方式，不是字符集 和utf-8没有什么收字多少的区别
不要说UTF-8，就算Unicode都还不能称为足够完善 只是因为UTF-8是Latin-1兼容，所以拉丁文字系的欧美偏好它而已 其中的CJK部分至今有严重的问题，因而日韩至今不接受Unicode
@ginkgo： 我听不懂你在说什么 能介绍一下CJK是什么东西吗？
那个……景佑是个宋朝年号吧 怎么和一休和尚扯上了？
中国人越来越没自己的东西了
@Perus:
GB18030是建立在ANSI基础上的编码方式，与Unicode是完全不同的 而Unicode可以分成很多种表现方式，我们说的UTF-8是可变长度的，即：一个字节1-127和ANSI是完全一样的，而之后用两个，三个(汉字都是三个字节的)、甚至更多的字节表示一个UNICODE的字符，这样实际上可以包含全世界所有的字符！ 而微软从WinNT开始，默认采用UTF－16编码方式，即所有字符统一采用两个字节，即使是1-127这些ANSI字符也一样，所以它只能表现65536个字符，当然就不能很好的支持东亚的文字了！这就是Perus所说的为何日韩至今不接受Unicode的原因，这完全是针对微软的双字节的UTF16而言的 UNICODE从UTF-8到UTF-16是可以用一个简单的算法进行转换的，大家可以搜索一下utf2ucs，此函数在c函数库里可以查到，具体名称可能有所不同。
而GBK，或者GB2312，GB10830等也是变长的，只有1-127是一样的字符，之后的汉字表示方法而完全不一样，其中GB2312最早，当时用两个字节就把一级和二级汉字都包含了，但随着更多繁体字以及其它语言文字的应用，发现两个字节不够了，所以扩展到了GB10830，也就是用更多的字节来表示字符，虽然想法和UTF8类似，但编码方式完全不一样！
所以从UTF-8到GBK，GB2312，GB10830，或者CJK，BIG5等转换就需要一个巨大的对应码表了！这些码表在libc里都有！
再补充两句：UNICODE是全球很多家大公司共同提出的标准，它给全世界每种文字都规定了固定的编码方式，而GBK、GB18030则是中国在满足了自己汉字的需求以后再把东亚甚至其它国家的文字规定了编码方式！ 所以从“中国不是软件老大”这样一个事实来证明，其它国家是根本不可能采用中国提示的这样一种标准的，能支持你和转换你就不错了。。。
@alen: 谢谢 不过你还是没有弄明白， 就Unicode本身而言，UTF-8、UTF-16、GB18030三种编码方式都覆盖了这一字符集，不存在什么只能表示BMP的65536字符的问题，三者之间都是可以互转换的 请参阅Wikipedia
日韩不接受Unicode的原因不在于那个 而是由于IRG的字符收录原则十分混乱 迄今用Unicode方案印不出一本大汉和辞典 北大中文论坛上有很多相关讨论 你可以看一下
btw 我没有鼓励谁去用GB18030 因为问题的根子在Unicode上 即使Unicode是“是全球很多家大公司共同提出的标准，它给全世界每种文字都规定了固定的编码方式” 很抱歉我对任何形式的政治正确都不感兴趣
@Perus:
我想我说的够清楚了，本身我也是个程序员，也写过很多win上的程序，自从搞清楚unicode是怎么回事以后，我就把unicode作为了vc编程的默认编码方式
写过程序的都知道：微软的VC中对于UNICODE字体符串都是统一采用两个字节的，而GCC中则是四个字节，这也是GNU的先进表在！
至于unicode标准，我也没有带政治色彩，本身这些大公司（我记得好像包括IBM，MS）也是软件行业的老大，他们共同提出了一个可以让全世界通行无阻的编码方式，单从一点来说就是非常有建设性和开放性的
“是全球很多家大公司共同提出的标准，它给全世界每种文字都规定了固定的编码方式” 这句话本身就有问题 1、Unicode本身有几种不同的实现方式，所以不可能有什么“固定的编码方式” 2、其他文字不论，Unicode采用给数十万汉字逐一编码的方式本身就很成问题，论效率比不过台湾中研院的中央研究院漢字部件檢字系統 http://www.sinica.edu.tw/~cdp/cdphanzi/ 论字符集的科学性不及CCCII 单就在收字数目上，它至今赶不上日本90年代的超汉字（你下个今昔文字镜就知道了） 3、Unicode确实是“是全球很多家大公司共同提出的标准”，但汉字部分主要还是东亚人自己搞， 问题在于这批人一开始没有考虑完善，现在只能慢慢补尾巴。
我最上面所说的“默认字符集不是采用UTF－8有点不爽“，是指在开源世界已经为全球多语种在计算机上完整而又能同时显示作出了如此巨大的努力和贡献之后，国内的发行版还在用本国自己的编码标准，难道不是一种讽刺吗！
实在是看不下去了。 那些满嘴都是“中国垃圾”的人，你们有没有首先想到自己是中国人？
Linus觉得Minix不是很好用，做出了个Linux。在google的Minix的邮件列表上保存在当时的邮件，在渺渺无几的几个邮件中linus提到了Minix，就算在"Linux is obselete"充满挑衅的邮件中也没有说Minix垃圾之类的。
如果你们觉得什么不好用，满足不了你们，请自己动手，完善它甚至做出一个东西取代它。
喋喋不休，光说不做，指手划脚，有何意义？
我并不是程序员，而是搞语言文字的 我也知道Unicode至少统合了先前的各种地域性编码的字符集， 对程序设计工业生产信息交换等等方面善莫大焉 但从我的专业的角度来看，Unicode可以说是做得不是很好 当然，对大多数人来说是无所谓的。
好了，谢谢alen 这个话题到此为止
@Perus:
Perus,我前面就说的很清楚了，不同的unicode编码方式的转换是很容易也很快速的，只是为了不同的系统来使用而已，比如WIN用的是16位的，而LINUX用的是8位的，但它们的本质，也就是某个具体字符在UNICODE中的位置是不变的，而你说的汉字太多还没完整收录其中那可能确实存在，但既然UTF-8是可以变长的，那四个字节甚至更多字节来完整的收录这个星球甚至这个银行系中的文字都是足够的，不够的只是MS目光短浅的UTF－16方式。。。
@alen： 这不光是收字多少的问题， 还有字符集的科学性的问题， 举例： 劍劎劒剣剱劔剑、户戸戶、兌兑 你叫文献检索时对这些字如何判定？ 当然，我说了这个只是对某些领域的人影响大
好了，不多说了， 晚上不要生气，睡个好觉。
btw， “目光短浅”的是UCS-2 不是UTF-16， UTF-16也可以表示辅助平面的字符
unicode 和 iso10646 现在统一了，干得就是一个同一个事。这个可是为了解决文字交流问题的国际标准。unicode最先设计的时候是用的4个字节，前两个是bmp（基本文字面） 现在cjk-extB才用到 bmp=2。
cjk 就是中日韩三国的文字，统一编码。 因为里面有相当多的重复的字形。为了节约空间所以统一定义。
utf8 是unicode的一种编码方式。主要是如果直接用unicode直接网络传输会产生一些问题。具体如何编码请去看rfc-2279。所以说支持utf8,其实本质上说就是支持unicode.
cjk 最基本的是从U4E00-U9FC3, cjk-extA 是从U3400-U4DB5, 这里bmp是0。 也就是说用两个字节可以表示。(都是16进制) cjk-extB是从U20000-U2A6D6开始，这里bmp是2， 这里面有非常多的子形。主要是生僻字。才用到3个字节。
微软在vista中就是提供了extB的宋体。如果说unicode不重要，他为什么要提供这些字形。
unicode 在2.0 中就有双字节的定义了。也就是说从2.0开始就可以把汉字加进去。但是直到4.1。cjk cjk-extA 才正式成为标准。这个和国家参与国际标准不积极也有关系。
btw. 说gb18030设计的不好，是我在latex cjk宏包的邮件列表中看 Lemberg, Werner 提到的，他说里面分区设计的很乱。如果有研究的人就知道了。同时网上查了一下，的确提到转换gb18030是比较复杂。所以latex cjk从gbk支持然后就直接到utf8支持了。
现在可以说gb18030,在国际上都公认unicode的情况下，实际上已经成了一个摆设。（虽然说的有点难听，但是是事实。)他只会有一个转换工具
Perus: 1，我没有生气 2，你可能并不了解文字是如何用计算机语言来描述的
对于编码方式来说，重要的不是文字的量有多大，而在于有了这么无限大的空间，哪些区域给哪些语种来使用才是比较头疼的，就好像排队一样，排在最前面的是英文26个字母并且大小写，之后可能是其它一些西方文字，再后面是一些最基本一二级的汉字，再排下来可能又被日文或其它文字排上了，就因为当初汉字占的位置不够多，当需要把更多的繁体汉字收录进去的时候，发现只能排在队尾了，这样就导致了汉字被其它语种给隔离了，可能从语言工作者来说这样的队伍实在太糟糕了。这种问题不单单只有汉字存在，可能日文等也存在，但对于计算机来说，某个字排在哪里都是一样的，要找某个字的速度和它排在队首和队尾没有什么区别。
unicode当时设计的时候是4个字节，但是bmp=0的就是ucs-2了。如果一开始都把4个字节用上，前面的2个字节都是0,存在浪费。unicode中的汉字部分对一些生僻字的方面，的确存在者不足，我认为这个是我们参与少的原因。他有不合理的地方，我们参与了才能改进。 对一些古文字典，有些字没有定义。
utf-8, utf-16 都是转换后的形式。他们主要是编码后的表现形式。
unicode解决的是字形，也就是说有这种字形，他就给你定义一个位置。如果说多个字形是同样的意思，用计算机程序处理是非常方便的。只要在程序中注意就好。但是你参与的越多，你得到的好处就越多。
看来我属于那个1%的用户了：电脑中没有windows系统。
谢谢关注， 我说的并不是这么个问题， 我们这一行批评的不是编码方式 而是字符集本身 我上面的例子 户-大陆 戸-日韩 戶-港台
兌-港、台、韩 兑-大陆、日本
从这些户、兑的字也有这些问题 説-大陆、日本 說-港、台、韩
在跨语种文献检索中已经造成了无数的麻烦 http://www.pkucn.com/viewthread.php?tid=170974&extra=page%3D1&page=1
CCCII一开始就将同源字分了类 http://zh.wikipedia.org/w/index.php?title=CCCII&variant=zh-cn 这样的设计就比较好 Unicode在这方面考虑欠妥
@yetiboy 汉字标准这个一定是国家来做的，个人搞别人是不会来认可的。就像原来windows下有自造字一样。到其他电脑上就不行了。
我的观点是说当有好的国际标准，中国可以参加，并从中收益的时候。我们不参加，非要自己搞一个，最后被抛弃。这样造成的浪费是很可惜的。 如果中国很早参加unicode的汉字的制定，可以很早把一些中文的生僻字加进去，对中文的汉字研究，古文的计算机化都是非常有帮助的。最起码一些字典的全面计算机化是没有问题的。
如果我的言语有过激之处，请谅解。在此道歉。
认同ginkgo的看法，国内很多所谓的标准其实是为了保护自己的利益，比如WIFI、高清电视等一些对应的国家标准，完全是为了不让国外垄断，但这样的后者显然是不方便使用者
CJK是字符集，由CJK统一汉字 CJK统一汉字扩充A CJK统一汉字扩充B CJK兼容汉字等等字集组成（国家的标准），Unicode, gbk , gb18030等编码均采用这一字符集
Perus可能是taiwan的朋友？当然我也相信taiwan制定的字符集和编码肯定是相当不错的,但现状是由产业界推动的unicode,utf-8等几乎要成为事实标准了,如果从方便信息交流,储存,减少转换的麻烦来看使用unicode无疑是唯一选择。然而国家从自身考虑（尤其是像汉字那么多文字）也会提出自己的标准,如ISO/IEC 10646和相应的国家标准GB13000,这几乎是最早的类似unicode的一种编码体系。当然还有其他包括两岸各自对中华文化信息化和保护保存的努力。
如果大家对gb2312, gb13000, gb18030等国标（gbk似乎应该是m$搞出来的）和unicode等相关信息有兴趣的话可以先看下以下一个连接
http://www.nits.gov.cn/sc2/jishufile1-1.asp
@seeit： 不好意思，那是Unicode的用词，不是国家标准的一部分，否则不会有“统一”说法 CJK一般来说是指Unicode中的CJK Unified Ideographs，是其一部分，不是单独的一个字符集。
@ginkgo： Unicode中国很早就参加了，但是整合汉字字符集时出了问题，这个不全是中国的责任，而是各方共同造成的。
其次Unicode的字形判别标准是混乱的，他们首先提出了“字源分离原则”，也就是只看字形，不看字源。 但如果这样，即使再细微的字形区分也要分别编码，于是他们又提出某些字形区别可由不同地区的具体字型表示。 结果就是Tetralet发现的这种问题： http://tetralet.luna.com.tw/index.php?op=ViewArticle&articleId=208&blogId=1 这两个标准是互相抵触的，现在你去问IRG的负责人，他们的标准是什么， 他们肯定还是说不清楚。
要是不以字源和构形來区分汉字，以後若提及Unicode，将成为汉字浆糊的象征。
要我说，爱用什么用什么。。我电脑里也没windows哈
@alen
国内的发行版还在用本国自己的编码标准,难道有错吗？ 中国人自己出的东西，自己不支持，结果国际上自然就更不睬了。 很多东西都是国际上推出了一个标准，没有中国的广泛反馈就强行推广，中国自己订出一个标准就遭到广泛抵制。不要说中国订出的标准都是垃圾，国外的标准就是适用。 只要gb18030编码能解决我们中国的问题，就应该允许这个标准存在。
转载一段： GB 18030是我国独立研制的编码字符集标准，目的是满足我国国内对文字编码的需要。标准的修订和解释由我国有关管理部门和技术专家掌握，根据技术发展和使用需要，我们随时可以修订该标准，具有很高的自主权。 ISO/IEC 10646是在ISO/IEC JTC1领导下由各国专家共同制定的国际标准。自八十年代中期以来，我国一直积极参加该标准的研制和修订工作。特别是在该标准汉字部分的研制和修订工作中，我国担任着汉字工作组的召集人和主编，具有很大的影响力。 Unicode规范是一个由产业界部分有影响的公司起草的规范性文件，它的研制和修订由Unicode组织掌握。换句话说，少数国外大公司完全控制了Unicode规范的制定和产品实现的进程。我国的信息技术和信息产业尚未发展成熟，对Unicode规范施加影响是十分困难的，即使是在汉字部分，我们的影响力也十分有限
@alen 国内的发行版还在用本国自己的编码标准，难道还有错？
如果一个国家，连自己的文字编码权都在国外手中，那这个国家真是要处处受制了。
@wangping: Unicode的汉字部分主要是中国主导的， 何况Unicode也是ISO/IEC制定公开的产业标准 说“受制于人”乃是杞人忧天
现在Unicode汉字部分最大的问题是它的设计不够合理 至少我们的论文、著作的出版印刷要仰赖Adobe、方正等公司的专有方案。
编码方面讨论得很专业啊, 学习一下
该发言了吧： 谢谢大家对magicLinux的关心，评论这么多。估计magic小组看到了不给气炸了。
我补充一下： “现在cjk-extB才用到 bmp=2” 这个说法不对 Ext-B已经用到第二辅助平面,又称表意文本补充平面（Supplementary Ideographic Plane，缩写SIP，或简称Plane 2）了，Ext-C和Ext-D也计划使用该平面 http://zh.wikipedia.org/w/index.php?title=%E8%BE%85%E5%8A%A9%E5%B9%B3%E9%9D%A2&variant=zh-cn#.E7.AC.AC.E4.BA.8C.E8.BC.94.E5.8A.A9.E5.B9.B3.E9.9D.A2 目前，Unicode的：
基本多文种平面（Basic Multilingual Plane, BMP），或称第零平面（Plane 0） http://zh.wikipedia.org/w/index.php?title=%E5%9F%BA%E6%9C%AC%E5%A4%9A%E6%96%87%E7%A8%AE%E5%B9%B3%E9%9D%A2&variant=zh-cn 第一辅助平面（Supplementary Multilingual Plane，缩写SMP，或简称Plane 1） http://zh.wikipedia.org/w/index.php?title=%E8%BE%85%E5%8A%A9%E5%B9%B3%E9%9D%A2&variant=zh-cn#.E7.AC.AC.E4.B8.80.E8.BC.94.E5.8A.A9.E5.B9.B3.E9.9D.A2 第十四辅助平面（Supplementary Special-purpose Plane，简称SSP） http://zh.wikipedia.org/w/index.php?title=%E8%BE%85%E5%8A%A9%E5%B9%B3%E9%9D%A2&variant=zh-cn#.E7.AC.AC.E5.8D.81.E5.9B.9B.E8.BC.94.E5.8A.A9.E5.B9.B3.E9.9D.A2 都已基本用完 没有使用的是 第三至十三辅助平面 http://zh.wikipedia.org/w/index.php?title=%E8%BE%85%E5%8A%A9%E5%B9%B3%E9%9D%A2&variant=zh-cn#.E7.AC.AC.E4.B8.89.E8.87.B3.E5.8D.81.E4.B8.89.E8.BC.94.E5.8A.A9.E5.B9.B3.E9.9D.A2 但第三辅助平面已经确定用来摆放甲骨文、金文、小篆、战国古文等。 剩下的第十五至十六辅助平面是私人使用区。
补充一下 @ginkgo： Ext-B已经用到第二辅助平面了， 第二辅助平面又称为表意文本补充平面（Supplementary Ideographic Plane，缩写SIP，或简称Plane 2），整个范围在 U+20000～U+2FFFD 它可不是基本多文种平面（Basic Multilingual Plane, BMP），或称第零平面（Plane 0）的一部分。 参见 基本多文种平面： http://zh.wikipedia.org/w/index.php?title=%E5%9F%BA%E6%9C%AC%E5%A4%9A%E6%96%87%E7%A8%AE%E5%B9%B3%E9%9D%A2&variant=zh-cn 辅助平面： http://zh.wikipedia.org/w/index.php?title=%E8%BE%85%E5%8A%A9%E5%B9%B3%E9%9D%A2&variant=zh-cn
@Pepino 感谢指正，我的说法错了，但是意思就是你说的这里个。
@Perus： UTF-8也不是Latin-1兼容，它的单字节部分最高位必须是0。即单字节只用了7位，这只可能和7位的ASCII兼容，不可能和8位的Latin-1兼容，ASCII以外的西欧字符需用两字节表示。
UTF-8的话， 在BMP里面的字符，也就是用UTF-16基本的两个字节，或UTF-32的后两个字节表示的字符，它要用1-3个字节储存,因为它的 1字节：0xxxxxxx 2字节：110xxxxx 10xxxxxx 3字节：1110xxxx 10xxxxxx 10xxxxxx 以避免与其他多字节编码方式混淆（个别时候还是会混，那个Windows记事本的“联通”变“■”的问题就是这么来的），所以实际上每个字节都没用全。两个字节以上的部分，就要用到4-6字节编码了： 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
@alen： UTF-16是可以支持Unicode中码位在两字节以上，也就是BMP以外的字符的，这些在辅助平面定义的字符，UTF-16会以代理对（surrogate pair）的形式，以两个2字节的值来储存。 WinNT的UTF-16（其实是UCS-2）只能支持基本的两字节字符，那是因为当时的Unicode还没有收录到两字节以上，这是Unicode3.1以后的事情。
PS 最初ISO 10646设计时是用4个字节表示一个字符，这个就是UCS-4，和Unicode合并之后又称为UTF-32. 但是所谓4字节的码位大多有位无字，因为目前已经计划了的只有16个平面，也就是16个2字节，其中的4-13字节目前还不知要放什么东西，而且我看到之前的0、1、13平面有许多reserved位（预留备用的空白），2平面也还没用完，3平面只是预备要用(-_-#),而4字节的码位等于65536个2字节，目前看不出什么地方用的上这么多。
你们都错了，是 肥嘟嘟左卫门
支持!!!!!!!!!!!!!!
改正： PS 最初ISO 10646设计时是用4个字节表示一个字符，这个就是UCS-4，和Unicode合并之后又称为UTF-32. 但是所谓4字节的码位大多有位无字，因为目前已经计划了的只有16个平面，也就是16个2字节，其中的第4-13平面目前还不知要放什么东西，而且我看到之前的第0、1、14平面有许多reserved位（预留备用的空白），第2平面也还没用完，第3平面只是预备要用(-_-#),而4字节的码位等于65536个平面/2字节，目前看不出什么地方用的上这么多。
@yang：
谢谢大家对magicLinux的关心，评论这么多。估计magic小组看到了不给气炸了。
我是magic那边打进来的内鬼～～嘿嘿
@Perus： 我同意你的看法，建议大家去看看youtube上的苏哲在google开发者大会上关于字符编码的讨论。
另外也说两句，别总骂中国的东西不好，任何一个产品的从发展到成熟，都是不断改进，从低级到高级的过程，这个过程是要人来用的，你用了多少？别说我们的东西落后，人家上世纪中期都就登月了，我们才出舱，怎么不落后，你以为所谓的公开标准就是好的？那老美怎么不公开登月标准也让你共享共享，很多东西我们为什么要搞出自己的一套标准，里面有很多因素，而不仅仅是技术因素。
呵呵 這個問題原來很多人都還沒有弄明白 我在Windows下用過一個英國人寫的編輯器Babelpad 裡面Save as an Unicode text下面有四個Option： UTF-8(8bit Unicode Transformation Format) UTF-16(16bit Unicode Transformation Format) UTF-32(32bit Unicode Transformation Format) GB18030(Unicode-mapped superset of GB2313)
很明顯西方人也認為GB18030是Unicode的編碼方式之一 只是這個GB18030是考慮GB2312\GBK的向後兼容而設計出來的 UTF-8呢 就像Pepino說的，是和8位ASCII向後兼容的
@ginkgo: “但是很讽刺的是cjk是外国人搞的。作者好像是freetype的维护者”
此話令人不解 CJK作為Unicode字符集的一部分，和Unicode整體都是由ISO/IEC和Unicode聯盟共同設計的 ISO國際標準組織、IEC國際電信聯盟都是各國政府組成的國際組織 Unicode聯盟則有來自多個國家政府和各大軟體商的代表參與 同時他們還和萬維網聯盟 (W3C)、互聯網工程工作小組 (IETF) 和歐洲計算機製造協會 (ECMA) 等標準制訂機構合作 這裡面牽扯到的個人和組織何止一二 如何會是由某個程式員個人維護的？
@Perus: 我剛才搜索了一下 Unicode貌似已經打算把今昔文字鏡的字符收錄了 看來這個已經不成問題 只是其@收錄漢字數量: 實在太大，還包括西夏文、甲骨文、篆書，總共17萬以上 很可能在現在用掉的四個平面之外還要再吃掉兩個平面才夠用 至於超漢字，那似乎是軟銀的一個Tron系的操作系統 和今昔文字鏡沒什麽關係
唉，为什么要有GB18030？ 这里说了半天居然还是没有人说到点子上 我来举台湾的政府标准CNS 11643 做例子吧 这个编码方式与GB2312/GBK/GB18030很相似，以前是单独字符集、单独编码 Unicode出来以后，它也扩大字符集，保持和Unicode的对应转换关系 这种编码的使用范围很窄，即使在台湾政府部门里也只有户政系统使用 按说为了“世界潮流”“大势所趋”，是不是也要全部转用UTF-8？ 那敢情好，你就必须将户政系统的数据中心、服务器、业务前台、终端机从原有软件（包括人员的培训）、数据资料（累积了几十年）、甚至硬件（终端机的软硬件往往是结合在一起的）在一夜之间（字面意思，因为户政系统是一天都不能停止运转的！）全部换掉， 且不说里面的人力、物力、财力有多大消耗，这事可能办到否？
再举一个日本的Shift-JIS做例子 这个编码之前有一个JIS X 0201，是一个模仿ISO/IEC_8859的8位编码，JIS往ASCII占用码位外的剩下一半空间里面灌了日文50个片假名，也就是所谓“半角片假名”。后来双字节编码方式流行，于是搞出来JIS X 0208/Shift-JIS，给日文汉字和假名都编了码，其中片假名又用双字节编了一次，称“全角片假名”。同时这个编码保留/绕开了原来的“半角片假名”的位置，所以是“Shift”JIS，这有何必要？ 也一样啊，如果你说将原来的东西直接淘汰，那么全国的银行、电信的终端机还有别的很多设备是不是也要直接送回收站？
同样，反过来说，我也可以问，为什么要有UTF-8？ Unicode设计时是用4个字节表示一个字符，也就是UTF-32/UCS-4 对，这样很浪费储存空间，所以有了2/4字节混合编码的UTF-16 那还要UTF-8干什么？ 很简单啊，之前有大量的ASCII码编码的数据，尤其是英语系和拉丁系地区，这些语言的信息占了全球的大半，比如美国政府的所有信息化数据，按法律规定都是以ASCII编码的纯文本文档储存的。UTF-8就是为和他们向后兼容而设计的，它的单字节部分和8位ASCII一模一样。（对于东亚用户来说UTF-8实际上不省空间，因为东亚原有编码方式中的双字节字符，UTF-8很可能要3个字节，原因见60楼）
总之，在计算机世界里 除了“大势所趋”“世界潮流”这两个很狗血的词以外 还有一个“更”狗血的词“向后兼容” 这个在现实中往往更TM要命 GB18030的出台，其实就是如此
楼上各位太强了，建议 Toy 把此文加为精华～吼吼~
其实CJK已经落伍啦，应该是cjkv，v是越南。 另外cjkv不是什么外国货，中国有专家参与，起重要作用。
cjkv最恶心的地方，个人愚见，其实是它的排序方式。典型政治手段。 汉字排序， 用部首排序？不好用，很多字部首难以判断。 用笔划笔顺排序？不好用，笔划笔顺不少有争议，而且中日韩三国不少常用字还不一样。 读音？靠，多音字就不说了，汉字方言都解决不了，不要说要韩国人日本人学普通话，是不是还要学四声？ 最后，居然用康熙字典为排序依据。呕吐。
@lion: 麻烦用词文明一点 什么叫“恶心""呕吐”？ 康熙字典就是部首排序的字典 你用找个什么字符映射表看一下，Unicode的汉字是不是按部首排的？ 而且我还要告诉你 康熙字典字形是过去汉字圈国家共用的印刷字形标准 直到二战后各地分头搞文字改革才改变了 但是即使是现在，规范字形的参考标准主要也就两本书 说文解字、康熙字典 不懂文字学不要胡说 http://www.pkucn.com/viewthread.php?tid=144689&page=1#
这样的排序结果就是废料一个
十几亿中文用户，多少人读过康熙字典说文解字？有多少人知道康熙字典大概有多少偏旁部首？ 我当然知道康熙字典是部首检字，和新华字典现代汉语词典辞海词源等等或者相同或者不同的另外一个部首检字法。 所以我知道unicode的排序对用户没有任何价值。 实际使用时就当它是随机排序好了。 反正没法用。
政治上正确 大家妥协 然后，谁都没有损失什么，谁都没有得到什么
哦 那你输入汉字是在字符映射表里一个一个找？
想想还是不对 我想你的意思是说用GB系编码那样用常用读音排的话 可以用简单的正则表达式列出某一读音的汉字？
那个办法是好，问题是汉字是多音字 除非像韩国编码那样 以谚文读音为基准收汉字 龜有三個讀音，就收了三個龜
Unicode只好照收不誤 加上中文的俗體刀頭“龜”，朝鮮的古體龜，以及大陸簡化“龟”日本简化“亀” IRG已經收了八九個龜了 只能叫龟子龟孙
例如，英文维基，词条会按首字母在catalogy中排序，
中文维基呢，康熙字典排序啊。
于是乎，要手动在词条中额外指定一个英文字母作为排序index。 悲夫 中文
@lion: 哈 看来我误会你的意思了 这个我倒是没想到 不过日韩也有这个问题吧 他们就是不管三七二十一 都按实际读音的音序排 不过这样…… 汉字写的词条也要注出音才能排序 Orz……
唉 看看那个unicode:（已经5.1版了） UTF-7 | UTF-8 | UTF-16 / UCS-2 | UTF-32 / UCS-4|BMP|SMP|SIP 和CJK那一档一混合
我当初刚有点明白unicode时，还感觉不错，觉得自己脑子还凑合，居然能勉强把这么复杂的东西搞个大概，还是自己看资料。 可是一转念，天，我不过是想正常在计算机上用母语，全球第一大母语文字，汉字，要这么折腾！
有句话，不知各位听说过没有： 割草的不要和放牛的一起玩，耽误事啊
@lion: 建议你用ctrl-f来搜索。
@ahtya: 这有什么用，问题是排序啊？
@Pepino: 其实UTF-8的这个设计不光是为了和别的编码进行区分,而是为了方便编程: 1. 兼容传统程序,使用7位ASCII的程序可以继续使用,传统的库(用一个字节0来结束字符串)也可以继续使用. 2. 当操作字符串的时候,可以根据当前字节的内容来确定这个是字的开头还是中间的部分(0xxxxxxx是单字节,10xxxxxx是一个字的中间,其它的情况可以根据前面1的位数来确定后面需要几个字节来组成一个字).
这篇文章的回复的确是相当不错, 可以说比这篇文章本身要好了 :D
@LanEast: 明白了 谢谢指正
看到上面的一堆脑残的评论 我对一群sb无语了 人家magiclinux坚持gb，方便了windows用户也推行了国标 一群自以为是 认为自己是代表潮流的sb都跳出来了 什么叫潮流 大家用的叫潮流 你一小绰人自己YY的不叫潮流 再说了潮流有个锤子用 现实远远压过潮流 靠