又是夸张的谎言……关于GB18030、GBK、UTF8
100jackyjkchen]
编辑：www.fx114.net
本篇文章主要介绍了"又是夸张的谎言……关于GB18030、GBK、UTF8
100jackyjkchen]"，主要涉及到又是夸张的谎言……关于GB18030、GBK、UTF8
100jackyjkchen]方面的内容，对于又是夸张的谎言……关于GB18030、GBK、UTF8
100jackyjkchen]感兴趣的同学可以参考一下。
本帖最后由 jackyjkchen 于
07:56:23 编辑
引用1，GB2312是很老的东西了，早就发现不够用了。
2，94年（还是之前）国家推出了建议性标准gb13000，这个标准其实就是utf-8标准（除了名字，完全一样），同时也建议微软公司采纳。－－（据说是1993年，GB13000，应该是ISO10646）
3，微软借口说gb18000还不成熟，为了取得中国市场的垄断地位，自己搞了一套汉字标准，于是它就随着win95和office之类的流行起来了，国家看生米已经煮成了熟饭，只好把这套标准定为国标GBK标准。－－（其实只是指导性标准，并非强制性，GB18030是强制性标准）
4，微软到了99年（前后吧），又说GBK已经落伍了，现在流行utf-8标准，准备全盘转换成utf-8，这些把有关部门惹怒了。NND，当年我们推utf-8你说不成熟，自己搞了一套，现在赚得盆满钵满了又自己说要推utf-8了，你丫微软分明就没把政府放在眼里。
5，于是政府怒了，强制推行gb18030标准（这个标准前面兼容GBK，其他码位兼容utf-8），算是过渡标准吧。要求微软强制执行，否则产品不得在大陆买。于是基本搞死了微软的WindowsMe，差点搞死了Office2000（据说发行前几个月，微软除了改字符编码就没干其他什么事情）－－（确实，WinMe是我认为的最差的Windows版本，而office2k也是前不着村，后不着店，前后兼容性都差）
6，由于以上历史原因，现在就是GB2312，GBK，GB18030，UTF-8并存了。
7，如果不是万恶的微软，我们早就用上UTF-8了。
8，所以说微软和政府关系一直很僵，不是说着玩的，微软太目中无政府了。
9，以上是我从其他地方看来的，可能记得不是太真切了，说的不对请大家指正。
某网站上看来的，看似有板有眼，但是漏洞很多
1.GBK由微软制定，政府接受，这个还有可能，虽然说法比较搞
2.后面的就搞笑了，说Windows&Me是国家强推GB18030搞死的，office&2000也是这样搞废的，言下之意，Windows&Me和office&2000先期都采用了UTF8编码——只有这一种解释，因为GB18030对GBK兼容，GBK不需要大改动的，而这明显不符合现实，而且，此文最大的漏洞应该是“瞎编”故事的人根本就没有过其他语言版本的Windows和office，如果中文都采用UTF8了（UTF8在各语种中对中文应该是最不友好了），那其他语言版本应该也是UTF8，但实际上其他语言版本的Windows也都是当地标准或UTF16的子集UCS2来实现当地语言的，Windows内核都是UTF16的，使用UCS2、GBK、GB18030都没有额外的运算负担，使用UTF8却有额外负担，就和用ANSI一样（MSDN文档多次强调使用ANSI会造成明显性能损失，如果用UTF8的话性能损失更大）。另一个附加的证据……VC、Windows&SDK等并没有直接提供用于UTF8的接口，如果有某种Windows语言版本用UTF8，将会非常麻烦（得先用API转）。
结论：说政府要求微软用GB18030否则不给上市很不靠谱，微软应该属于自愿（或者说政府有要求，微软也很愿意，你情我愿），GB编码和Windows的核心UTF16以及其他语言区域的编码是风格统一的，微软没有在任何Windows版本中默认UTF8，中国政府管得了微软中国，别告诉我中国政府连微软总部也能管，连微软发行日文、韩文、阿拉伯文的Windows也能管？……当然，此文最大的“亮点”，就是将Windows&Me的失败归结于中国政府……第二大“亮点”，自己都搞不清楚GB18030，还什么其他码位来源于UTF8……另外gb13000也和UTF8一点关系没有吧，而是UTF16的基本平面映射！如果GB130000等于UTF8不成立，这篇文章整个的脉络（中国政府VS微软，GBK&VS&UTF8）就是完全编造的了！
这篇文章的材料最早源于部分用户为UTF8鸣不平，用来“解释”UTF8如此优秀却不被中国人广泛使用的原因……我不否认UTF8在网页编程中的优点，不过再次重复我的观点——用谎言辩论，夸张宣传，适得其反！此文要我指正，我便指正给他看。
此文观点流传很广，极具误导性。
再看看相对权威的观点，1998年的文章，GB18030没有诞生，但是对GB13000和GBK作了具体介绍，看看与引用文的不同。
http://linux./~ltguo/linuxbyte/3300-/%BA%BA%D7%D6%B1%E0%C2%EB%B1%EA%D7%BC%D3%EB%CA%B6%B1%F0(%D2%BB).htmutf8对中文编码的兼容性最差.
目前最新的gb18030编码收录的中文,utf8那点编码范围根本不够用.
没有老外搞中文编码,由中国人自己搞也许比现在好,最起码不像现在这么乱.
gb2312,gb13000,gb18030是中文编码的国家标准.
gbk是中文编码的行业标准.顶一下up没觉得utf-8优秀，用起来很麻烦。&&&&*&總體
&&&&&&&&&&o&優點
&&&&&&&&&&&&&&&&+&UTF-8是ASCII的一個超集。因為一個純ASCII字元串也是一個合法的UTF-8字元串，
&&&&&&&&&&&&&&&&&&所以現存的ASCII文本不需要轉換。為傳統的擴展ASCII字符集設計的軟體通常可以
&&&&&&&&&&&&&&&&&&不經修改或很少修改就能與UTF-8一起使用。
&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&+&使用標準的面向位元組的排序常式對UTF-8排序將產生與基於Unicode代碼點排序相
&&&&&&&&&&&&&&&&&&同的結果。（儘管這隻有有限的有用性，因為在任何特定語言或文化下都不太可能有
&&&&&&&&&&&&&&&&&&仍可接受的文字排列順序。）
&&&&&&&&&&&&&&&&+&UTF-8和UTF-16都是可擴展標記語言文檔的標準編碼。所有其它編碼都必須通過顯式
&&&&&&&&&&&&&&&&&&或文本聲明來指定。[2]
&&&&&&&&&&&&&&&&+&任何面向位元組的字元串搜索演算法都可以用於UTF-8的數據（只要輸入僅由完整的
&&&&&&&&&&&&&&&&&&UTF-8字元組成）。但是，對於包含字元記數的正則表達式或其它結構必須小心。
&&&&&&&&&&&&&&&&+&UTF-8字元串可以由一個簡單的演算法可靠地識別出來。就是，一個字元串在任何其它
&&&&&&&&&&&&&&&&&&編碼中表現為合法的UTF-8的可能性很低，並隨字元串長度增長而減小。舉例說，字元
&&&&&&&&&&&&&&&&&&值C0,C1,F5至FF從來沒有出現。為了更好的可靠性，可以使用正則表達式來統計非法
&&&&&&&&&&&&&&&&&&過長和替代值（可以查看W3&FAQ:&Multilingual&Forms上的驗證UTF-8字元串的正
&&&&&&&&&&&&&&&&&&則表達式）。
&&&&&&&&&&o&缺點
&&&&&&&&&&&&&&&&+&一份寫得很差（並且與當前標準的版本不兼容）的UTF-8解析器可能會接受一些不同的
&&&&&&&&&&&&&&&&&&偽UTF-8表示並將它們轉換到相同的Unicode輸出上。這為設計用於處理八位表示的校
&&&&&&&&&&&&&&&&&&驗常式提供了一種遺漏信息的方式。UTF8存汉字比GBK更大，GBK2字节可以存储一个汉字了，UTF8往往需要3字节,
对某些带宽吃紧，空间吃紧，中文文本密集型的web站点来说，GBK可以省不少流量和空间UTF-8,&UTF-16,&UTF-32，都是Unicode的存储方式，经常看到有人说Unicode好，说UTF-XX不好我也没觉得utf-8&好
呵呵没觉得utf-8优秀，用起来很麻烦。GB系列的标准首先是为了满足计算机处理汉字的需要。GB18030覆盖的汉字基本上够科研工作者使用了。
GB18030应该不是强制标准，但如果要使用的话，必须得付费。
utf系列是国际标准，是为了兼容多国语言的字符。引用&10&楼&whg01&的回复:GB系列的标准首先是为了满足计算机处理汉字的需要。GB18030覆盖的汉字基本上够科研工作者使用了。
GB18030应该不是强制标准，但如果要使用的话，必须得付费。
utf系列是国际标准，是为了兼容多国语言的字符。
付费？！没有吧？
要说“不使用这个标准就得付费”可能更靠谱一点&:p顶一下！引用&7&楼&do_fork&的回复:UTF-8,&UTF-16,&UTF-32，都是Unicode的存储方式，经常看到有人说Unicode好，说UTF-XX不好
就是。无知者无罪嘛。呵呵win7没这个问题了顶起来引用&7&楼&do_fork&的回复:UTF-8,&UTF-16,&UTF-32，都是Unicode的存储方式，经常看到有人说Unicode好，说UTF-XX不好
微软有相当的责任，他将UTF16直接命名为Unicode，因此可见某些人说微软倾向于UTF8但是为了兼容性而放弃根本是扯淡，UTF16是微软主动的战略性选择这些扯淡东西,从来不关心,什么编码标准都行,最好全世界统一起来,别他吗折腾n多标准,叫写代码的人写起来不爽.这些扯淡东西,从来不关心,什么编码标准都行,最好全世界统一起来,别他吗折腾n多标准,叫写代码的人写起来不爽.让老外来做汉字标准，本来就是很奇怪的事情，我没什么国际化思维，中国的事情就应该自己来处理，汉字是中国的，不是世界的！&jf引用&5&楼&do_fork&的回复: & &*&總體
& & & & &o&優點
& & & & & & & &+&UTF-8是ASCII的一個超集。因為一個純ASCII字元串也是一個合法的UTF-8字元串，
& & & & & & & & &所以現存的ASCII文本不需要轉換。為傳統的擴展ASCII字符集設計的軟體通常可以
& & & & & & & & &不經修改或很少修改就能與UTF-8一起使用。
& & & & & & &
& & & & & & & &+&使用標準的面向位元組的排序常式對UTF-8排序將產生與基於Unicode代碼點排序相
& & & & & & & & &同的結果。（儘管這隻有有限的有用性，因為在任何特定語言或文化下都不太可能有
& & & & & & & & &仍可接受的文字排列順序。）
& & & & & & & &+&UTF-8和UTF-16都是可擴展標記語言文檔的標準編碼。所有其它編碼都必須通過顯式
& & & & & & & & &或文本聲明來指定。[2]
& & & & & & & &+&任何面向位元組的字元串搜索演算法都可以用於UTF-8的數據（只要輸入僅由完整的
& & & & & & & & &UTF-8字元組成）。但是，對於包含字元記數的正則表達式或其它結構必須小心。
& & & & & & & &+&UTF-8字元串可以由一個簡單的演算法可靠地識別出來。就是，一個字元串在任何其它
& & & & & & & & &編碼中表現為合法的UTF-8的可能性很低，並隨字元串長度增長而減小。舉例說，字元
& & & & & & & & &值C0,C1,F5至FF從來沒有出現。為了更好的可靠性，可以使用正則表達式來統計非法
& & & & & & & & &過長和替代值（可以查看W3&FAQ:&Multilingual&Forms上的驗證UTF-8字元串的正
& & & & & & & & &則表達式）。
& & & & &o&缺點
& & & & & & & &+&一份寫得很差（並且與當前標準的版本不兼容）的UTF-8解析器可能會接受一些不同的
& & & & & & & & &偽UTF-8表示並將它們轉換到相同的Unicode輸出上。這為設計用於處理八位表示的校
& & & & & & & & &驗常式提供了一種遺漏信息的方式。
这么长，看着累啊。顶引用&20&楼&jackyjkchen&的回复:让老外来做汉字标准，本来就是很奇怪的事情，我没什么国际化思维，中国的事情就应该自己来处理，汉字是中国的，不是世界的！
应该这样，中国人制定标准，中国籍公民免费使用，老外要用，对比起，拿钱来。引用&25&楼&do_fork&的回复:引用&20&楼&jackyjkchen&的回复:
让老外来做汉字标准，本来就是很奇怪的事情，我没什么国际化思维，中国的事情就应该自己来处理，汉字是中国的，不是世界的！
应该这样，中国人制定标准，中国籍公民免费使用，老外要用，对比起，拿钱来。
不光中文，整个东亚文字这帮老外都会排到后面（说白了就是西方文明优越论），有人说汉字太多，双字节排不下，但别忘了GB18030和UTF16是怎么处理的，常用汉字双字节（20000多个，绝对够用了），冷僻字另行处理……软硬件业中国没有发言权，但汉字还是应该我们说了算的。每次为了兼容linux转成utf8，看到多出来的字节，说真的，开销倒还真是小事，但那种“恶心”的感觉却挥之不去。
能说UTF8编码的创建过程完全不含“歧视”么？我想，每个人心理应该都知道是怎么回事！引用&26&楼&jackyjkchen&的回复:引用&25&楼&do_fork&的回复:
&引用&20&楼&jackyjkchen&的回复:
&让老外来做汉字标准，本来就是很奇怪的事情，我没什么国际化思维，中国的事情就应该自己来处理，汉字是中国的，不是世界的！
&应该这样，中国人制定标准，中国籍公民免费使用，老外要用，对比起，拿钱来。
&不光中文，整个东亚文字这帮老外都会排到后面（说白了就是西方文明优越论），有人说汉字太多，双字节排不下，但别忘了GB18030和UTF16是怎么处理的，常用汉字双字节（20000多个，绝对够用了），冷僻字另行处理……软硬件业中国没有发言权，但汉字还是应该我们说了算的。每次为了兼容linux转成utf8，看到多出来的字节，说真的，开销倒还真是小事，但那种“恶心”的感觉却挥之不去。
&能说UTF8编码的创建过程完全不含“歧视”么？我想，每个人心理应该都知道是怎么回事！
UTF-8最多可能用6字节表示一个字符，虽然我没遇到过这种字符
UTF-8的好处还是很多的，不用考虑字节序，完全兼容ASCII字符串，
处理ASCII字符串的算法，可以不加修改的应用到UTF-8字符串，
有一些web相关的库，不支持GBK更不支持GB18030，只支持UTF-8，
UTF-8字符串，损坏某字节的时候，不会引起整行乱码
UTF-16英文也要2字节，英文在计算机中比中文要多的多，
所以UTF-8跟UTF-16选择一个的时候，英语国家的人会更倾向于UTF-8。引用&27&楼&do_fork&的回复:引用&26&楼&jackyjkchen&的回复:
引用&25&楼&do_fork&的回复:
引用&20&楼&jackyjkchen&的回复:
让老外来做汉字标准，本来就是很奇怪的事情，我没什么国际化思维，中国的事情就应该自己来处理，汉字是中国的，不是世界的！
应该这样，中国人制定标准，中国籍公民免费使用，老外要用，对比起，拿钱来。
不光中文，整个东亚文字这帮老外都会排到后面（说白了就是西方文明优越论），有人说汉字太多，双字节排不下，但别忘了GB18030和UTF16是怎么处理的，常用汉字双字节（20000多个，绝对够用了），冷僻字另行处理……软硬件业中国没有发言权，但汉字还是应该我们说了算的。每次为了兼容linux转成utf8，看到多出来的字节，说真的，开销倒还真是小事，但那种“恶心”的感觉却挥之不去。
能说UTF8编码的创建过程完全不含“歧视”么？我想，每个人心理应该都知道是怎么回事！
UTF-8最多可能用6字节表示一个字符，虽然我没遇到过这种字符
UTF-8的好处还是很多的，不用考虑字节序，完全兼容ASCII字符串，
处理ASCII字符串的算法，可以不加修改的应用到UTF-8字符串，
有一些web相关的库，不支持GBK更不支持GB18030，只支持UTF-8，
UTF-8字符串，损坏某字节的时候，不会引起整行乱码
UTF-16英文也要2字节，英文在计算机中比中文要多的多，
所以UTF-8跟UTF-16选择一个的时候，英语国家的人会更倾向于UTF-8。
UTF8本来就是照顾老外的嘛，敢在内核用UTF16的貌似只有微软和一些办公软件……linux下好像有点极端了，内核用UTF8精打细算，但wchar_t却直接来个四字节，不明白，linux里wchar_t这东西有人用么……还不如直接int得了引用&28&楼&jackyjkchen&的回复:UTF8本来就是照顾老外的嘛，敢在内核用UTF16的貌似只有微软和一些办公软件……linux下好像有点极端了，内核用UTF8精打细算，但wchar_t却直接来个四字节，不明白，linux里wchar_t这东西有人用么……还不如直接int得了
Java&算一个吧？引用&28&楼&jackyjkchen&的回复:引用&27&楼&do_fork&的回复:
&引用&26&楼&jackyjkchen&的回复:
&引用&25&楼&do_fork&的回复:
&引用&20&楼&jackyjkchen&的回复:
&让老外来做汉字标准，本来就是很奇怪的事情，我没什么国际化思维，中国的事情就应该自己来处理，汉字是中国的，不是世界的！
&应该这样，中国人制定标准，中国籍公民免费使用，老外要用，对比起，拿钱来。
&不光中文，整个东亚文字这帮老外都会排到后面（说白了就是西方文明优越论），有人说汉字太多，双字节排不下，但别忘了GB18030和UTF16是怎么处理的，常用汉字双字节（20000多个，绝对够用了），冷僻字另行处理……软硬件业中国没有发言权，但汉字还是应该我们说了算的。每次为了兼容linux转成utf8，看到多出来的字节，说真的，开销倒还真是小事，但那种“恶心”的感觉却挥之不去。
&能说UTF8编码的创建过程完全不含“歧视”么？我想，每个人心理应该都知道是怎么回事！
&UTF-8最多可能用6字节表示一个字符，虽然我没遇到过这种字符
&UTF-8的好处还是很多的，不用考虑字节序，完全兼容ASCII字符串，
&处理ASCII字符串的算法，可以不加修改的应用到UTF-8字符串，
&有一些web相关的库，不支持GBK更不支持GB18030，只支持UTF-8，
&UTF-8字符串，损坏某字节的时候，不会引起整行乱码
&UTF-16英文也要2字节，英文在计算机中比中文要多的多，
&所以UTF-8跟UTF-16选择一个的时候，英语国家的人会更倾向于UTF-8。
&UTF8本来就是照顾老外的嘛，敢在内核用UTF16的貌似只有微软和一些办公软件……linux下好像有点极端了，内核用UTF8精打细算，但wchar_t却直接来个四字节，不明白，linux里wchar_t这东西有人用么……还不如直接int得了
这就是utf-8的最大好处了，用char的代码，往往也能处理UTF-8，即使程序并不知道UTF-8的存在，
大量的Linux程序，处理文本的时候，仅仅把它当作字节流，没有考虑它是什么编码，
内核也没有很多的考虑UTF-8的存在，只是在文件系统驱动中用了一些，
内核中wchar_t也不是4字节，是2字节，只在nls和fs中用到了它，核心没有使用
/*&Plane-0&Unicode&character&*/
typedef&u16&wchar_t;
#define&MAX_WCHAR_T&0xffff
/*&Arbitrary&Unicode&character&*/
typedef&u32&unicode_t;
php中只有不到5处地方使用了wchar_t，用的非常有限
gcc支持两种长度的wchar_t，使用-fshort-wchar修饰，就跟short&int一样了那是
一、不得利用本站危害国家安全、泄露国家秘密，不得侵犯国家社会集体的和公民的合法权益，不得利用本站制作、复制和传播不法有害信息！
二、互相尊重，对自己的言论和行为负责。
本文标题：
本页链接：- 涓撴敞浜嶹in7鏃楄埌鐗堢郴缁熶笅杞斤紒
鐑?棬鎼滅储锛}