有关汉字部件和部首的编码……(TR)

[centrish]

有关汉字部件和部首的编码……
W
发表于 2005-12-27 21:14:18 |只看该作者 凯文君 |倒序浏览

[table=98%]
[tr][td]近日根据《香港增补字符集－2004》里面的资料，得知Unicode里面编码空间在2E00-2FFF这一段的字符是康熙部首。我因此去查了Unicode 4.1 版标准的文档。在标准里面，2E80这个平面（2E80-2EF3）被注明为CJK增补部首，而2F00平面（2F00-2FD6）才是康熙部首。

这我就糊涂了，那到底2E80-2EF3这些字符是不是康熙部首呢。如果是，Unicode好像没有必要特别注明它们是CJK部首吧？另外，康熙部首到底有多少个啊？Unicode里面收录的2F00-2FD6这一段215个字符是不是全部的康熙部首呢？还请语言文字方面的行家朋友不吝赐教！

另外个人感觉汉字的编码还是有欠考虑的地方。比如在CJK统一汉字（Unicode 的说法是CJK统一表意字符）里面，实际上有不少的字符并不是汉字，而是汉字部首或部件。为什么不能把汉字部件（包括部首）和汉字分开编码（我指的是分在不同的编码平面，而不是用不同的编码标准）呢？因为现在这种混合编码的方式给实际中的应用造成了很大的不便。最典型的，我国很早以前就制定了汉字偏旁部首规范和汉字部件标准，但目前的GB编码体系中并没有将所有这些部首和部件编码进去，而且编码时汉字和部件不分，这样我们做中文信息处理软件的时候想有关分别对部首和部件类型的字符及汉字字符进行处理是很麻烦的。如果部件和部首能单独地编码在一个区间内，编程时只要校验字符所属的编码区间就能知道一个字符是汉字还是部件了。但现在显然不行，我们还必须自己额外地建立一个有关汉字部首和部件的数据库。而且收集这个数据库的数据也是很麻烦的，因为现有的大多数输入法都不能很好或很完整地对这些部件进行编码。程序员总不能自己浏览一遍所有的字符来挑出这些部件字符吧。

因此强烈建议国家能尽快确定汉字偏旁部首和部件规范的正式标准，并真正的与计算机汉字编码标准和字型标准制定的工作结合起来。总感觉我国语言文字规范的制定工作和汉字编码工作似乎缺乏必要的合作和交流，因做出来的东西总是不太搭调。让我们这些处在边缘的”中文信息处理软件“开发作者感到十分的不痛快。不知大家以为如何？[/td][/tr]
[/table]

[centrish]

发表于 2005-12-27 22:07:11 |只看该作者 采采卷耳

[table=98%]
[tr][td]小弟所知不多，以下仅供参考。

2F00-2FD6是全部的康熙部首。
2E80-2EF3则是康熙部首的异体写法/简化字写法。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-27 23:22:51 |只看该作者 凯文君

请教采采卷耳[table=98%]
[tr][td]嗯～好像差不多是这样了，谢谢采采卷耳兄！
那么能不能再请你详细解释一下2E80-2EF3里面哪些是异体写法，哪些又是简化字写法呢？另外，这些异体/简化字写法又分别和2F00-2FD6里面哪些字符对应呢？[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 01:10:52 |只看该作者 谢振斌

[table=98%]
[tr][td]Unicode已经乱得很了。
很多部件还是没有收进来，收进来得又重复很多份。
拥有三份编码的部件可以举出好多例子，两份的就更多。
编码区域划分也很乱。
部首很多也归错位置。

1）要是按照字频先划几个区，然后再按部首排就对了。
2）然后允许每个区不断增补，随着版本增加而增补。而不是去别的新建区域去扩充。
3）可以分为：
部首、部件区(512)，常用字区(4000), 次常用字区(4000),罕用字, 异体字,垃圾字。
做一下字频统计又不难。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 01:32:27 |只看该作者 凯文君

认同以使用频度、类型分区编码的观点[table=98%]
[tr][td]我和谢兄有相同的观点。目前的编码的方法只关注了符号和表意文字的区别，但它忽略了实际上中表意文字中有很多也是需要分类的，不能一概的以单一的笔画、读音来排列，而应该综合考虑如使用频度、字符的类型（汉字还是汉字部件）等来分类，进而在编码时体现出这种分类。而且这种分类在技术上来说并没有什么代价，一旦确定了一个编码标准的大体框架，其中某一个字符不管分配什么码位对该编码标准而言并不是很重要的事。但对文字处理程序或者说使用这个程序的人来说可不一样了，就像我上面举的那个例子。如果编码中真能实现分类分区编码，那程序就能直接根据编码来处理字符而不是还要在额外的数据库中来匹配，这两者是有很大的性能差别的。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 01:47:53 |只看该作者 谢振斌

[table=98%]
[tr][td]U+2E9C的Unicode名称是"CJK RADICAL SUN“，也就是“日”， 可以看字形应该是冒字头。
U+2E9D是月。
U+5183冃, 字形也像月，紫光输入法拼音为mao4, 说明是看作“冒字头”。可以Unicode对这个字没有定音，不知到这个字到底是不是“冒字头”。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 02:34:10 |只看该作者 采采卷耳

至於準確定義真的很不好解釋，對不起。
因爲Unicode的標準和字書不完全相同(我懷疑是Unicode做錯了)。

[table=98%]
[tr][td][冃]是[帽]的古字。
冒 最 曼 冑…………都是從這個部首。[/td][/tr]
[/table]

[table=98%]
[tr][td]U+2E9C的字形是[冃]，但事實上[冃]和[日]是兩個字。
只能解釋為Unicode亂來了。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 02:59:18 |只看该作者 凯文君

个人观点，请讨论[table=98%]
[tr][td]呵呵，GB13000.1 汉字部件规范早在97年就公布了，但相应的部件名称规范直到2003年才确定－－这滞后也忒大了些。
根据这两份规范文档，U+2E9C的那个字符形制扁而宽，正是97部件规范中的10号部件，例字有“冒”、“冕”等，但10号部件只是附形部件，它的主形部件是8号部件－－“日”，这两个都是第5组的部件。U+5183的“冃”字符的形制长而宽，例字有“冃”和“胄”，在97部件规范中的序号是11，也是第5组的一个附形部件。而U+2E9D的这个月在97部件规范中的序号是19，例字有“胖”、“朋”、“朗”和“服”等，月是第11组部件的主形部件。
至于这几个部件的名称，根据2003部件名称规范，U+2E9C那个字符的名称已经被确定为“冒字头”。而U+5183的“冃”似乎应该是“肖字底”，例字有“肖”、“肩”、“前”、“婿”。但如果冃就是肖字底的话，在部件名称规范里它已经是部件月的附形部件了。而在97部件规范里面它应该是和部件日一组的一个附形部件啊。在这里好像被合并了。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 06:36:24 |只看该作者 采采卷耳

[table=98%]
[tr][td]U+5183的“冃”似乎应该是“肖字底”

這個字不能這樣看吧。
您的［肖字底］就是［月（肉的變體）］，而［冃］是單獨的一個字。注意兩橫左右是不封口的。封口就寫錯了。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 07:48:36 |只看该作者 nirvana104722

[table=98%]
[tr][td][indent]原帖由 采采卷耳 于 2005-12-28 02:34 发表
[冃]是[帽]的古字。
冒 最 曼 冑…………都是從這個部首。[/indent]

卷耳老弟，這箇“從”字，要改爲“从”字。

凱文君，您可以買一本《康熙字典》來查閱。必要時，可以對照《說文解字》。沒有這方面的知識，有時候會鬧笑話。

《康熙字典》，一定得買影印版，現代的什麼整理點校本沒用。《說文解字》也一樣。

[ 本帖最后由 nirvana104722 于 2005-12-28 07:50 编辑 ][/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 11:48:19 |只看该作者 有女同车

[table=98%]
[tr][td][indent]原帖由 谢振斌 于 2005-12-28 01:10 发表
Unicode已经乱得很了。
很多部件还是没有收进来，收进来得又重复很多份。
拥有三份编码的部件可以举出好多例子，两份的就更多。
编码区域划分也很乱。
部首很多也归错位置。

1）要是按照字频先划几个区，然后再按部首排就对了。
2）然后允许每个区不断增补，随着版本增加而增补。而不是去别的新建区域去扩充。
3）可以分为：
部首、部件区(512)，常用字区(4000), 次常用字区(4000),罕用字, 异体字,垃圾字。
做一下字频统计又不难。
[/indent]

Unicode 的CJK统一表意字符集部分（CJK unified ideographs)大体上就是像你设想的那么排的。CJK基本区、扩展A、扩展B都是按《康熙字典》部首笔画序排列的，部首和笔画都相同的，传统汉字在前简化字在后。

基本区、扩展A、B区三个字集实质上也是先收录字频高的，后收录字频低的。

至于是不是应该将所有汉字都按部首、笔画、字频序排列这个问题：我想，一来是不具备可操作性——A）字频的特征不象部首和笔画那么明确，字频的统计数据在不同空间、时间和应用领域中有着很大的随意性；B）部首和笔画的相互兼容是绝对的（在特定的字体中），也就是说，一个特定的字符，其部首、刨除部首的笔画數都是唯一确定的值，因而它在特定字集中的编码位置也是唯一确定的。而字频——我们姑且假定每个汉字的字频也是唯一确定的——但它和部首笔画没对应关系，即便是在特定的字集中也无法在编码位置和字频、部首、笔画之间建立函数关系。正因为如此，CJK的基本集才没有考虑加入字频因子。又因为CJK汉字的总集迄今为止还不可确知，而分区增补才是唯一可行的办法。

如果对每个部首+剩余笔画的的编码片段都预留空间的话，谁也无法确定数千（乃至上万）处预留空间的合适大小，况且尚有不少部首+剩余笔画的片段还没有找到相应的汉字，是否该预留，预留多大都是很棘手的问题（这里尚未考虑到同部首同剩余笔画数的汉字排序问题）。

部件（components）虽然有中华人民共和国的国家标准支持，但unicode不是中华人民共和国的专利，是否应给zh部件劃定特殊的分区必须得获得unicode协会的认可。我个人认为有为部件独立建区的可能性和必要性。但是就如同kanxi radicals 区、CJK radicals supplement 区一样，成字的zh部件必须遵守cjk unified ideographs的编码准则，不能从统一表意字集中剥离出去。

我们必须明确，unicode首要目的是为所有可能出现的字符提供唯一确定的编码。为了实现这一目的，对编码的可扩展性的要求远远高于针对某一项具体应用的要求。Unified,universal and unique ,只要认识到这一思想的重要性，就能够最大限度地利用它所提供的优势。比如，你对信息学领域字频感兴趣的话，你可以建立信息学领域2005字频统计数值to unicode的映射表。你可以拿它和“生物学领域2005字频统计数值 to unicode的映射表”做比较研究。如果你比较中意《新华字典》的部首体系，你可以建立《新华字典》部首 to unicode的影射表，同样的，你可以拿它和《辞海》97 to unicode的影射表做比较研究。设想一下，如果没有unicode的存在，将大陆、台湾和日本的通用汉字字频统计作比较研究是多么困难的事情。而现在只要建立gb to unicode-传统汉字 big5 to unicode-传统汉字 和 JIS to unicode-传统汉字的映射，这一切就很容易实现。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 18:22:37 |只看该作者 凯文君

[table=98%]
[tr][td]采采卷耳:的确,冃不是"肖字底".我所不明白的是,那为什么在部件名称标准里面已经没有了冃这个部件,在部件标准里面是有这个的呀?另外又不得不发一下牢骚了,部件名称标准里面的部件定义和一些部件的序号,组号等细节已经和原来的部件标准有所不同了,那应用中到底哪个才是标准?!

nirvana104722,《康熙字典》和《说文解字》有时间我会去翻翻看–但不是现在，呵呵–毕竟语言文字研究不是我的专业。作为一个软件作者，我渴望的是一些确定，无歧义的规范和标准。我希望去遵守规范，并从自己的应用领域的角度出发，对规范提出一些合理化的建议。但深入研究所有涉及到的规范的制定工作所需的理论和背景知识，则是没有必要的了。

有女同车，我也知道制定Unicode的目的就是为了给所有可能出现的字符提供唯一确定的编码。但你所说的“对编码的可扩展性的要求远远高于针对某一项具体应用的要求”这一句似乎有可商榷之处。我不知您所说的某一项具体应用指的是什么。但我从一个程序员的角度来理解，Uncode当然首先是一种计算机字符的编码方案，这个编码方案跟它之前曾出现过的所有字符编码方案如ASCII，GB，BIG5，JIS一样，都是为了在计算机里面处理语言文字信息而服务的。而我所说的字符应该尽量分类编码，就是从计算机文本字符处理这个根本角度出发的。因为对计算机来程序来说，它所看到的字符只是一个个的二进制数据（也就是字符的编码）。而字符的分类也是文本信息处理的一个基本的功能模块，打个很简单的比方：如果程序连一个字符是英文字母还是汉字都分不清，你还能指望它能干些什么？那么字符分类功能实现所需的基本技术是什么，那肯定是字符的编码特征–也就是某个字符的编码属于那个字符种类的编码区间里面。如果Unicode无视这种来自实际应用的需求，它绝不可能实现其“统一字符集”的雄心壮志。[/td][/tr]
[/table]

[centrish]

[indent]原帖由 凯文君 于 2005-12-28 18:22 发表
有女同车，我也知道制定Unicode的目的就是为了给所有可能出现的字符提供唯一确定的编码。但你所说的“对编码的可扩展性的要求远远高于针对某一项具体应用的要求”这一句似乎有可商榷之处。我不知您所说的某一项具体应用指的是什么。但我从一个程序员的角度来理解，Uncode当然首先是一种计算机字符的编码方案，这个编码方案跟它之前曾出现过的所有字符编码方案如ASCII，GB，BIG5，JIS一样，都是为了在计算机里面处理语言文字信息而服务的。而我所说的字符应该尽量分类编码，就是从计算机文本字符处理这个根本角度出发的。因为对计算机来程序来说，它所看到的字符只是一个个的二进制数据（也就是字符的编码）。而字符的分类也是文本信息处理的一个基本的功能模块，打个很简单的比方：如果程序连一个字符是英文字母还是汉字都分不清，你还能指望它能干些什么？那么字符分类功能实现所需的基本技术是什么，那肯定是字符的编码特征–也就是某个字符的编码属于那个字符种类的编码区间里面。如果 Unicode无视这种来自实际应用的需求，它绝不可能实现其“统一字符集”的雄心壮志。 …[/indent]
发表于 2005-12-28 21:06:34 |只看该作者 有女同车

具体是哪一项应用，我没有具体指出那就是泛指的意思。
Unicode 跟GB ASCII BIG5 JIS相比最大的优点就是建立了groups <–planes <–rows <–cells的模型，提供了（迄今为止）最大限度的可扩展性能。相对而言，GB、BIG5之类都是“死”编码或者说是僵硬的编码体系。
对字符的分类不是也不应该是UNICODE的职责。因为分类可以从不同角度进行，无数种特定应用要求无数种分类方案。GB系列编码本身就是自相矛盾的产物，如GB2312-1用普通话音序，-2用新华字典部首+笔画序，GBK跟GB2312又采用了不同的页面格式等等。如果分类方法前后矛盾的话，我宁可不要分类，君以为如何？

针对凯君所提出了问题，我以为。第一，UNICODE的区间划分划分非常清晰，并没有互相杂厕的地方，因此不可能出现分不清哪个编码是汉字，哪个编码是拉丁字母的情况。（详下表一）unicode]的码位安排不是随意的,实用的编码特征就是字符的线性坐标，unified中的CJK字符的214部首和部首外笔画数可以通过一个简单的函数求得，见下表二
[indent]

表一

平面,區名,首編碼,尾編碼,編碼的數,指定字,加入統一碼的版本
0,Basic Latin,000000,00007F,128,128,1.0.0
0,Latin-1 Supplement,000080,0000FF,128,128,1.0.0
0,Latin Extended-A,000100,00017F,128,128,1.0.0
0,Latin Extended-B,000180,00024F,208,194,1.0.0
0,IPA Extensions,000250,0002AF,96,96,1.0.0
0,Spacing Modifier Letters,0002B0,0002FF,80,80,1.0.0
0,Combining Diacritical Marks,000300,00036F,112,112,1.0.0
0,Greek and Coptic,000370,0003FF,144,124,1.0.0
0,Cyrillic,000400,0004FF,256,248,1.0.0
0,Cyrillic Supplement,000500,00052F,48,16,3.2
0,Armenian,000530,00058F,96,86,1.0.0
0,Hebrew,000590,0005FF,112,86,1.0.0
0,Arabic,000600,0006FF,256,235,1.0.0
0,Syriac,000700,00074F,80,77,3.0
0,Arabic Supplement,000750,00077F,48,30,4.1
0,Thaana,000780,0007BF,64,50,3.0
0,Devanagari,000900,00097F,128,106,1.0.0
0,Bengali,000980,0009FF,128,91,1.0.0
0,Gurmukhi,000A00,000A7F,128,77,1.0.0
0,Gujarati,000A80,000AFF,128,83,1.0.0
0,Oriya,000B00,000B7F,128,81,1.0.0
0,Tamil,000B80,000BFF,128,71,1.0.0
0,Telugu,000C00,000C7F,128,80,1.0.0
0,Kannada,000C80,000CFF,128,82,1.0.0
0,Malayalam,000D00,000D7F,128,78,1.0.0
0,Sinhala,000D80,000DFF,128,80,3.0
0,Thai,000E00,000E7F,128,87,1.0.0
0,Lao,000E80,000EFF,128,65,1.0.0
0,Tibetan,000F00,000FFF,256,195,2.0
0,Myanmar,001000,00109F,160,78,3.0
0,Georgian,0010A0,0010FF,96,83,1.0.0
0,Hangul Jamo,001100,0011FF,256,240,1.1
0,Ethiopic,001200,00137F,384,356,3.0
0,Ethiopic Supplement,001380,00139F,32,26,4.1
0,Cherokee,0013A0,0013FF,96,85,3.0
0,Unified Canadian Aboriginal Syllabics,001400,00167F,640,630,3.0
0,Ogham,001680,00169F,32,29,3.0
0,Runic,0016A0,0016FF,96,81,3.0
0,Tagalog,001700,00171F,32,20,3.2
0,Hanunoo,001720,00173F,32,23,3.2
0,Buhid,001740,00175F,32,20,3.2
0,Tagbanwa,001760,00177F,32,18,3.2
0,Khmer,001780,0017FF,128,114,3.0
0,Mongolian,001800,0018AF,176,155,3.0
0,Limbu,001900,00194F,80,66,4.0
0,Tai Le,001950,00197F,48,35,4.0
0,New Tai Lue,001980,0019DF,96,80,4.1
0,Khmer Symbols,0019E0,0019FF,32,32,4.0
0,Buginese,001A00,001A1F,32,30,4.1
0,Phonetic Extensions,001D00,001D7F,128,128,4.0
0,Phonetic Extensions Supplement,001D80,001DBF,64,64,4.1
0,Combining Diacritical Marks Supplement,001DC0,001DFF,64,4,4.1
0,Latin Extended Additional,001E00,001EFF,256,246,1.1
0,Greek Extended,001F00,001FFF,256,233,1.1
0,General Punctuation,002000,00206F,112,106,1.0.0
0,Superscripts and Subscripts,002070,00209F,48,34,1.0.0
0,Currency Symbols,0020A0,0020CF,48,22,1.0.0
0,Combining Diacritical Marks for Symbols,0020D0,0020FF,48,28,1.0.0
0,Letterlike Symbols,002100,00214F,80,77,1.0.0
0,Number Forms,002150,00218F,64,49,1.0.0
0,Arrows,002190,0021FF,112,112,1.0.0
0,Mathematical Operators,002200,0022FF,256,256,1.0.0
0,Miscellaneous Technical,002300,0023FF,256,220,1.0.0
0,Control Pictures,002400,00243F,64,39,1.0.0
0,Optical Character Recognition,002440,00245F,32,11,1.0.0
0,Enclosed Alphanumerics,002460,0024FF,160,160,1.0.0
0,Box Drawing,002500,00257F,128,128,1.0.0
0,Block Elements,002580,00259F,32,32,1.0.0
0,Geometric Shapes,0025A0,0025FF,96,96,1.0.0
0,Miscellaneous Symbols,002600,0026FF,256,175,1.0.0
0,Dingbats,002700,0027BF,192,174,1.0.0
0,Miscellaneous Mathematical Symbols-A,0027C0,0027EF,48,35,3.2
0,Supplemental Arrows-A,0027F0,0027FF,16,16,3.2
0,Braille Patterns,002800,0028FF,256,256,3.0
0,Supplemental Arrows-B,002900,00297F,128,128,3.2
0,Miscellaneous Mathematical Symbols-B,002980,0029FF,128,128,3.2
0,Supplemental Mathematical Operators,002A00,002AFF,256,256,3.2
0,Miscellaneous Symbols and Arrows,002B00,002BFF,256,20,4.0
0,Glagolitic,002C00,002C5F,96,94,4.1
0,Coptic,002C80,002CFF,128,114,4.1
0,Georgian Supplement,002D00,002D2F,48,38,4.1
0,Tifinagh,002D30,002D7F,80,55,4.1
0,Ethiopic Extended,002D80,002DDF,96,79,4.1
0,Supplemental Punctuation,002E00,002E7F,128,26,4.1
0,CJK Radicals Supplement,002E80,002EFF,128,115,3.0
0,Kangxi Radicals,002F00,002FDF,224,214,3.0
0,Ideographic Description Characters,002FF0,002FFF,16,12,3.0
0,CJK Symbols and Punctuation,003000,00303F,64,64,1.0.0
0,Hiragana,003040,00309F,96,93,1.0.0
0,Katakana,0030A0,0030FF,96,96,1.0.0
0,Bopomofo,003100,00312F,48,40,1.0.0
0,Hangul Compatibility Jamo,003130,00318F,96,94,1.0.0
0,Kanbun,003190,00319F,16,16,1.0.0
0,Bopomofo Extended,0031A0,0031BF,32,24,3.0
0,CJK Strokes,0031C0,0031EF,48,16,4.1
0,Katakana Phonetic Extensions,0031F0,0031FF,16,16,3.2
0,Enclosed CJK Letters and Months,003200,0032FF,256,242,1.0.0
0,CJK Compatibility,003300,0033FF,256,256,1.0.0
0,CJK Unified Ideographs Extension A,003400,004DBF,6592,6582,3.0
0,Yijing Hexagram Symbols,004DC0,004DFF,64,64,4.0
0,CJK Unified Ideographs,004E00,009FFF,20992,20924,1.0.1
0,Yi Syllables,00A000,00A48F,1168,1165,3.0
0,Yi Radicals,00A490,00A4CF,64,55,3.0
0,Modifier Tone Letters,00A700,00A71F,32,23,4.1
0,Syloti Nagri,00A800,00A82F,48,44,4.1
0,Hangul Syllables,00AC00,00D7AF,11184,11172,2.0
0,Private Use Area,00E000,00F8FF,6400,6400,1.0.0
0,CJK Compatibility Ideographs,00F900,00FAFF,512,467,1.0.1
0,Alphabetic Presentation Forms,00FB00,00FB4F,80,58,1.1
0,Arabic Presentation Forms-A,00FB50,00FDFF,688,595,1.1
0,Variation Selectors,00FE00,00FE0F,16,16,3.2
0,Vertical Forms,00FE10,00FE1F,16,10,4.1
0,Combining Half Marks,00FE20,00FE2F,16,4,1.1
0,CJK Compatibility Forms,00FE30,00FE4F,32,32,1.0.0
0,Small Form Variants,00FE50,00FE6F,32,26,1.0.0
0,Arabic Presentation Forms-B,00FE70,00FEFF,144,141,1.0.0
0,Halfwidth and Fullwidth Forms,00FF00,00FFEF,240,225,1.0.0
0,Specials,00FFF0,00FFFF,16,5,1.0.0
1,Linear B Syllabary,010000,01007F,128,88,4.0
1,Linear B Ideograms,010080,0100FF,128,123,4.0
1,Aegean Numbers,010100,01013F,64,57,4.0
1,Ancient Greek Numbers,010140,01018F,80,75,4.1
1,Old Italic,010300,01032F,48,35,3.1
1,Gothic,010330,01034F,32,27,3.1
1,Ugaritic,010380,01039F,32,31,4.0
1,Old Persian,0103A0,0103DF,64,50,4.1
1,Deseret,010400,01044F,80,80,3.1
1,Shavian,010450,01047F,48,48,4.0
1,Osmanya,010480,0104AF,48,40,4.0
1,Cypriot Syllabary,010800,01083F,64,55,4.0
1,Kharoshthi,010A00,010A5F,96,65,4.1
1,Byzantine Musical Symbols,01D000,01D0FF,256,246,3.1
1,Musical Symbols,01D100,01D1FF,256,219,3.1
1,Ancient Greek Musical Notation,01D200,01D24F,80,70,4.1
1,Tai Xuan Jing Symbols,01D300,01D35F,96,87,4.0
1,Mathematical Alphanumeric Symbols,01D400,01D7FF,1024,994,3.1
2,CJK Unified Ideographs Extension B,020000,02A6DF,42720,42711,3.1
2,CJK Compatibility Ideographs Supplement,02F800,02FA1F,544,542,3.1
14,Tags,0E0000,0E007F,128,97,3.1
14,Variation Selectors Supplement,0E0100,0E01EF,240,240,4.0
15,Supplementary Private Use Area-A,0F0000,0FFFFF,65536,65534,2.0
16,Supplementary Private Use Area-B,100000,10FFFF,65536,65534,2.0
[/indent]

[indent]
表二–tabel ：radical
index A1 A2 B1 B2 C1 C2
1 一 丧 㐀 㐂 𠀀 𠁠
2 丨 丵 㐃 㐄 𠁡 𠁻
3 丶 举 丶 举 𠁼 𠂅
4 丿 乘 㐅 㐆 𠂆 𠃈
5 乙 亄 㐇 㐦 𠃉 𠄋
6 亅 事 㐧 㐨 𠄌 𠄝
7 二 亟 㐩 㐩 𠄞 𠅀
8 亠 亹 㐪 㐯 𠅁 𠆡
9 人 儾 㐰 㒪 𠆢 𠑵
10 儿 兤 㒫 㒯 𠑶 𠓚
11 入 兪 㒰 㒴 𠓛 𠓿
12 八 冁 㒵 㒹 𠔀 𠔻
13 冂 冕 㒺 㒿 𠔼 𠕲
14 冖 冪 㓀 㓄 𠕳 𠖫
15 冫 凟 㓅 㓗 𠖬 𠘦
16 几 凴 㓘 㓘 𠘧 𠙳
17 凵 凿 㓙 㓙 𠙴 𠚢
18 刀 劚 㓚 㔒 𠚣 𠠱
19 力 勸 㔓 㔧 𠠲 𠣋
20 勹 匔 㔨 㔪 𠣌 𠤍
21 匕 匙 㔫 㔮 𠤎 𠤫
22 匚 匷 㔯 㔶 𠤬 𠥬
23 匸 區 㔷 㔸 𠥭 𠥺
24 十 卛 㔹 㔼 𠥻 𠧑
25 卜 卨 㔽 㔽 𠧒 𠨌
26 卩 厁 㔾 㕁 𠨍 𠨫
27 厂 厵 㕂 㕔 𠨬 𠫒
28 厶 叇 㕕 㕙 𠫓 𠬙
29 又 叢 㕚 㕢 𠬚 𠮘
30 口 囖 㕣 㘜 𠮙 𡆟
31 囗 圞 㘝 㘥 𡆠 𡈻
32 土 壪 㘦 㚂 𡈼 𡔚
33 士 夁 㚃 㚄 𡔛 𡕑
34 夂 変 㚅 㚅 𡕒 𡕝
35 夊 夔 㚆 㚇 𡕞 𡖃
36 夕 夦 㚈 㚍 𡖄 𡗑
37 大 奲 㚎 㚡 𡗒 𡚥
38 女 孏 㚢 㜼 𡚦 𡤻
39 子 孿 㜽 㝈 𡤼 𡦸
40 宀 寷 㝉 㝲 𡦹 𡬜
41 寸 導 㝳 㝷 𡬝 𡭓
42 小 尡 㝸 㝻 𡭔 𡯀
43 尢 尷 㝼 㞊 𡯁 𡰢
44 尸 屭 㞋 㞡 𡰣 𡳽
45 屮 屰 㞢 㞥 𡳾 𡴬
46 山 巚 㞦 㠨 𡴭 𡿥
47 巛 巤 㠩 㠩 𡿦 𢀐
48 工 巰 㠪 㠮 𢀑 𢀲
49 己 巽 㠯 㠱 𢀳 𢁑
50 巾 幱 㠲 㡪 𢁒 𢆈
51 干 幹 干 幹 𢆉 𢆮
52 幺 幾 㡫 㡮 𢆯 𢇖
53 广 廳 㡯 㢞 𢇗 𢌖
54 廴 廽 㢟 㢠 𢌗 𢌫
55 廾 弊 㢡 㢣 𢌬 𢍹
56 弋 弒 㢤 㢦 𢍺 𢎖
57 弓 彏 㢧 㣆 𢎗 𢑎
58 彐 彠 㣇 㣈 𢑏 𢑿
59 彡 彲 㣉 㣓 𢒀 𢒻
60 彳 忂 㣔 㣹 𢒼 𢖨
61 心 戇 㣺 㦭 𢖩 𢦋
62 戈 戵 㦮 㦽 𢦌 𢨣
63 戶 扊 㦾 㧂 𢨤 𢩤
64 手 攮 㧃 㩹 𢩥 𢺴
65 支 攳 㩺 㩾 𢺵 𢻪
66 攴 斆 㩿 㪮 𢻫 𣁀
67 文 斖 㪯 㪱 𣁁 𣁫
68 斗 斣 㪲 㪻 𣁬 𣂐
69 斤 斸 㪼 㫂 𣂑 𣃖
70 方 旟 㫃 㫏 𣃗 𣄬
71 无 旤 无 旤 𣄭 𣄺
72 日 曯 㫐 㬭 𣄻 𣌠
73 曰 朇 㬮 㬲 𣌡 𣍜
74 月 朧 㬳 㭀 𣍝 𣎲
75 木 欟 㭁 㰜 𣎳 𣡿
76 欠 歡 㰝 㱎 𣢀 𣥁
77 止 歸 㱏 㱘 𣥂 𣦴
78 歹 殲 㱙 㱻 𣦵 𣪁
79 殳 毊 㱼 㲊 𣪂 𣫫
80 毋 毓 毋 毓 𣫬 𣬁
81 比 毚 㲋 㲋 𣬂 𣬚
82 毛 氎 㲌 㲲 𣬛 𣱄
83 氏 氓 㲳 㲳 𣱅 𣱔
84 气 氳 㲴 㲷 𣱕 𣱰
85 水 灪 㲸 㶠 𣱱 𤆁
86 火 爩 㶡 㸑 𤆂 𤓮
87 爪 爵 㸒 㸕 𤓯 𤕍
88 父 爺 㸖 㸙 𤕎 𤕛
89 爻 爾 㸚 㸚 𤕜 𤕩
90 爿 牆 㸛 㸜 𤕪 𤖧
91 片 牘 㸝 㸥 𤖨 𤘄
92 牙 牚 㸦 㸧 𤘅 𤘓
93 牛 犫 㸨 㹛 𤘔 𤜙
94 犬 玃 㹜 㺧 𤜚 𤣤
95 玄 玈 玄 玈 𤣥 𤣨
96 玉 瓛 㺨 㼈 𤣩 𤫩
97 瓜 瓥 㼉 㼖 𤫪 𤬥
98 瓦 甗 㼗 㽍 𤬦 𤮹
99 甘 甞 㽎 㽑 𤮺 𤯒
100 生 甧 㽒 㽔 𤯓 𤰂
101 用 甯 用 甯 𤰃 𤰑
102 田 疊 㽕 㽯 𤰒 𤴒
103 疋 疑 㽰 㽰 𤴓 𤴤
104 疒 癵 㽱 㿜 𤴥 𤼤
105 癶 發 癶 發 𤼥 𤼼
106 白 皭 㿝 㿩 𤼽 𤿅
107 皮 皾 㿪 㿺 𤿆 𥀾
108 皿 盭 㿻 䀍 𥀿 𥃣
109 目 矚 䀎 䂅 𥃤 𥍜
110 矛 矡 䂆 䂎 𥍝 𥎥
111 矢 矲 䂏 䂕 𥎦 𥐔
112 石 礹 䂖 䃻 𥐕 𥘄
113 示 禷 䃼 䄥 𥘅 𥜺
114 禸 禽 禸 禽 𥜻 𥝋
115 禾 穳 䄦 䆐 𥝌 𥤡
116 穴 竊 䆑 䇁 𥤢 𥩔
117 立 竸 䇂 䇕 𥩕 𥫖
118 竹 籲 䇖 䉹 𥫗 𥸤
119 米 糷 䉺 䊴 𥸥 𥾄
120 糸 缵 䊵 䍁 𥾅 𦈡
121 缶 罐 䍂 䍎 𦈢 𦉩
12
[/indent]

[indent]基于表二部首查询的sql 实现
select index from radical where (x>=A1 and x<=A2) or (x>=B1 and x<=B2) or (x>=C1 and x<=C2)
只用一条语句就够了[/indent]

第二，97年规范部件表中的部件有好多本身是就是汉字。UNICODE收录CJK汉字的排序准则就是《康熙字典》的部首笔画序。扩充A、B都严格地遵守了这个准则。事实上这也是唯一被CJKV四国和泛汉字区共同认可的准则，我不知道如果违背了这一准则UNICODE的CJKV还有没有实现的可能。所以说，给部件建区,可以，把部件从unified ideographs中剥离出来,不行（尤其是成字的部件）！

[centrish]

发表于 2005-12-28 21:41:55 |只看该作者 驚弓之鳥

[table=98%]
[tr][td][indent]原帖由 凯文君 于 2005-12-28 02:59 发表
呵呵，GB13000.1 汉字部件规范早在97年就公布了，但相应的部件名称规范直到2003年才确定－－这滞后也忒大了些。
根据这两份规范文档，U+2E9C的那个字符形制扁而宽，正是97部件规范中的10号部件，例字有“冒”、“ …[/indent]

不对，前以前做歬，从止从舟，后加刀为前，隶书将舟讹写作月。
“兪”也是如此。[/td][/tr]
[/table]

[centrish]

发表于 2005-12-28 22:15:42 |只看该作者 凯文君

致谢有女同车！[table=98%]
[tr][td]首先感谢车君的资料，我想应该会对我的工作有所帮助的。另外我澄清一下，我并没有想把成字部件从统一汉字中剖离出来的意思。事实上我只是想表达这样一种愿望，既然国家制定并公布了某一种规范或标准，就应该马上着力于相关的推广应用工作。否则到最后只能是规而不范，到头来只能落下笑柄和骂名。
比如我们既然有了部件规范，就应该尽快争取将其纳入GB和Unicode编码体系中。而不是制定完了就算了，我觉得香港在这方面就做得比我们好。他们几乎没隔两三年就会将其在实际应用中新增收的增补字符纳入ISO10646/Unicode的编码体系。基本上实现了规范标准的制定和推广应用的同步及互动，这是很令人“羡慕”的~[/td][/tr]
[/table]

[centrish]

发表于 2005-12-29 23:01:15 |只看该作者 谢振斌

[table=98%]
[tr][td][indent]原帖由 有女同车 于 2005-12-28 11:48 发表

Unicode 的CJK统一表意字符集部分（CJK unified ideographs)大体上就是像你设想的那么排的。CJK基本区、扩展A、扩展B都是按《康熙字典》部首笔画序排列的，部首和笔画都相同的，传统汉字在前简化字在后。

基 …[/indent]

1）我知道现在是按照康熙部首排的。但还是存在有些部首不是很对或很合适。
2）我也不是说要按照字频排列。只是说按照字频分几个字集。
3）字频虽然在不同时期、不同门类差别很大。但是我们至少应该优先考虑现代阶段的实用性。至少在几百年内有它的合理性和实用性。
4）康熙字典虽然是目前唯一被大家认同的一个基础。但是里面错误也是不少，为何就不能整理的更好些呢。
5）汉字除了部首外，还有众多的部件。最好也给出编码。目前缺少太多了。我在拆分整理时明显感到很不方便。而且很多部件跑到EXT-B区去了，我现在统一使用UTF8编码，这导致3字节和4字节混杂，给一些处理或输出对齐带来不便。难道就不能在BMP保留一块部件区，不断地往里面增补。
6）我同意一个字集增补是另辟字区，但是最好是紧连，不得已才分开。但是高频字一定要占据BMP平面。不可以跑到扩展平面去。BMP一定要预留足够的扩充空间，包括活字（有用字）和部件。
7）一个字集不一定永不变动，像GB2312-80、BIG5等那样，留下很多空位，从来就没有后续版本修订，造成浪费，这是没必要的。增补字区和基本字区最好是256个字符为一节对齐。每个区尽量不留空位，万一不刚好留了，那只好永远空着，不用为宜，这样有时会带来一些便利。
8）再说说收字原则。大的方面分为部件区、活字区、死字区。
部件区包括康熙部首和增补部首。
活字区为现今还在流通或比较有可能流通的正体字、简体字、异体字。
死字区包括已经淘汰的古字（整理古文献才用的到）、以及小篆、金文、甲骨文等等。

活字部分至少可以分为3个区。也就是常用字区、罕用字区、异体字区。区内按照部首和笔画顺序排列。
死字部分主要是一些淘汰的古字。但我认为古代异体字（不是所有异体字）没有必要给予编码。我对古字了解不多，但是我整理部件时感觉很多都是字形很小的变动。
一种是部件产生变种，比如过去的草字头写法不一样（Unicode基本上也不给这种情况编码、但是又不统一）。
一种是字形发生小变异或者变异。
还有一种是缺点少画的，按现代的语言说，实际上就是错别字。
那么不给编码，又想用它怎么办？可以按照字体的办法切换字体解决，当然如果一个字有很多异体字，一两个字体切换都不够用，那么按照上面活字区的办法，收入异体字区（一般来说这样的字是活字）。

9）再来说一下部件。很显然部件不止是那些部首，单靠214个康熙部首是不够的。目前Unicode明显还有很多部件没有收入。有些也到了EXT-B才收入。国家的部件规范表问题很多，但应该设法整理好。
10）再说说笔画。笔画按理说国家颁布了规范，应该是最没有争议的汉字构形信息了。对于颁布的那些字即便存在争议或不合理，至少也是有了依据。可是字集再扩大，很明显很多二义性问题就产生了。一个是新旧字形的差异，比如现在很多新字形把撇改为横或者竖。造成新旧字的笔画不一致。一是笔画变体或称谓不同，比如“心字底”该是竖撇点点还是竖点点点呢，还有一些点在旧字形中都是右折形，如穴宝盖的的右那一个点捺。还有一种则是大陆和港台规范的不一致性。种种问题在笔画应用时就会无所适从，如笔画输入法。

11)最后说一下Unicode一直追求的目标，就是给每个字符唯一的编码。我刚刚调一下数据库，列一点出来供大家参考。这些字出现完全一样或几乎一样的字形，但编码不同。(如果是字库搞错那我就不清楚，希望大家指出）。

这里还没有包括PUA里的多数字、以及扩展部首区的那些部件或成字。那些重复更多。
有些虽然含义有区别但是外形已经无法区分的，我认为也应该给予一个码位，比如“二”和古代的“上”字，字形就无法区分。有些字形也相差非常少，个别也列出来。
PUA区的字(E8开头的)，就算可以不算，但是我搞不懂的是为什么各个转码程序还都把GBK里的字往PUA那里转。

====
附：多重编码的字例（有些字论坛无法显示，可以复制出去应该可以看到，必要是我改为贴图）
2E8B ⺋ 353E 㔾
96A3 隣 F9F1 隣
29FCE𩿎 29FD7𩿗
23040𣁀 27959𧥙
E816 ? 20087𠂇
E831 ? 215D7𡗗
8192 膒 267FE𦟾
26842𦡂 26866𦡦
3B3B 㬻 4420 䐠
813C 脼 23377𣍷
3B3A 㬺 5E50 幐
3B35 㬵 80F6 胶
E83B ? 2298F𢦏
363D 㘽 39B3 㦳
4E8C 二 2011E𠄞
FA23 﨣 27EAF𧺯
E854 ? 2099D𠦝
5829 堩 21377𡍷
55C0 嗀 FA0D 嗀
3588 㖈 439B 䎛
58AB 墫 58FF 壿
7468 瑨 24A01𤨁
2001F𠀟 233BA𣎺
5140 兀 FA0C 兀
249BC𤦼 249E9𤧩
23F41𣽁 23F9E𣾞
6C77 汷 23C8B𣲋
23FCD𣿍 25096𥂖
2ECA ⻊ 27FB7𧾷
21018𡀘 2103C𡀼
21F37𡼷 2439A𤎚
51E0 几 20627𠘧
9094 邔 2866C𨙬
2EAA ⺪ 24D14𤴔
E818 ? 200CC𠃌
E855 ? 241FE𤇾
3DB7 㶷 2420E𤈎
720B 爋 24455𤑕
9F0F 鼏 2A503𪔃
5910 夐 657B 敻
3ADA 㫚 66F6 曶
9459 鑙 28BBA𨮺
6287 抇 22A8F𢪏
2E81 ⺁ 20086𠂆
6267 执 22A7E𢩾
672C 本 2097D𠥽
2EA7 ⺧ 20092𠂒
3D1D 㴝 2A3ED𪏭
79CA 秊 F995 秊
E817 ? 20089𠂉
2EAE ⺮ 25AD7𥫗
2EB7 ⺷ 2634C𦍌
8F9B 辛 2840B𨐋
51C9 凉 F979 凉
22472𢑲 26133𦄳
5F13 弓 22397𢎗
470C 䜌 E864 ?
88CF 裏 F9E7 裏
90DE 郞 F92C 郎
===[/td][/tr]
[/table]

[centrish]

发表于 2005-12-30 00:50:19 |只看该作者 extc

[indent]原帖由 凯文君 于 2005-12-27 23:22 发表
嗯～好像差不多是这样了，谢谢采采卷耳兄！
那么能不能再请你详细解释一下2E80-2EF3里面哪些是异体写法，哪些又是简化字写法呢？另外，这些异体/简化字写法又分别和2F00-2FD6里面哪些字符对应呢？ [/indent]

只要从unicode.org 下载以下两个code chart 就成了!

CJK Radicals
http://www.unicode.org/charts/PDF/U2E80.pdf

KangXi Radicals
http://www.unicode.org/charts/PDF/U2F00.pdf

关于部件的拆分, 其实Unicode还沒有定案, IRG(Unicode 的汉字研究小组) 内部是把所有
已编码的字符都用IDS (Ideographic Description Sequence) 来记录的, 就好象6=1+2+3
这般用部件串成一条独特的"方程式". 但是怎样拆分, 以及怎样处理不在已编码的字符表上的部件
还在讨论中.

[centrish]

发表于 2005-12-30 01:17:07 |只看该作者 有女同车

[table=98%]
[tr][td][indent]原帖由 谢振斌 于 2005-12-29 23:01 发表

6）我同意一个字集增补是另辟字区，但是最好是紧连，不得已才分开。但是高频字一定要占据BMP平面。不可以跑到扩展平面去。BMP一定要预留足够的扩充空间，包括活字（有用字）和部件。 …[/indent]

这不大可能吧。BMP基本上已经满了,除了Private区和兼容UTF16的保留区外好像没有大块的空间可用了,Basic Mulitlingual Plane总不能被CJK独占了吧。65534个码位光CJK和Hangul就占了4万来个，已经够意思了。我们要占地盘别人就得挪窝儿，改是改不得的。谢君所说的高频字，除了ZH部件外不知还应包含哪些内容。如果数量级不甚大的话，应该可以考虑单独建区。已编入UNIFIED部分的是不能动的。如确有特殊的用途可以以CJK compatible components的名目区别于unified的variations。[/td][/tr]
[/table]
[indent]原帖由 谢振斌 于 2005-12-29 23:01 发表
我现在统一使用UTF8编码，这导致3字节和4字节混杂，给一些处理或输出对齐带来不便。 …[/indent]

刚刚又温习了一下UTF8的编码格式。
0xxxxxxx
110yyyyy 10xxxxxx
1110zzzz 10yyyyyy 10xxxxxx（A
11110uuu 10zzzzzz 10yyyyyy 10xxxxxx（B
to uuuzzzzzzyyyyyyxxxxxx

实现 A/B的兼容好像并不怎么困难吧。鉴于目前只有plane1一个补充平面的事实，只要把 A的高字节高四位替换成1001再往前边加一个11110000就OK了。

现实的问题恐怕是现有的大多数软件开发平台，跟字符串相关的对象模型（类库）对plane1支持的都很糟糕。恐怕只有用utf32（for ucs4）才能绕开这些麻烦。无奈的是，即便开发的时候可以绕开，应用的时候还是一坨屎。

不管怎么说，纵使BMP完全按谢君的期望来部署的话，总还是有直接跟extB ( or extC?)打交道的危险存在，明摆着，65534个码位装不下业已存在的cjk ideographs，我们不能把希望全寄托在U+0000–>U+FFFD上，就如同当初GBK把希望寄托在 Fxxxxxxx + yyyyyyyy上一样。躱得过初一，躲不了十五，抱残守缺的心态是不对的。假如当初GBK把事情做得更绝一点，打破ASCII的拜物教，干脆把高字节的最高位也给kill了，为祖国多争取3万来个码位……我想说，要么向unicode投诚，要么学阎老西将铁路全都改成窄轨，鬼子进不来，俺也出不去，喝XX腎寶，他好我也好。

[centrish]

发表于 2005-12-31 00:26:24 |只看该作者 谢振斌

[indent]原帖由 有女同车 于 2005-12-30 01:17 发表

这不大可能吧。BMP基本上已经满了,除了Private区和兼容UTF16的保留区外好像没有大块的空间可用了,Basic Mulitlingual Plane总不能被CJK独占了吧。65534个码位光CJK和Hangul就占了4万来个，已经够意思了。我们要 …[/indent]

===
是的，BMP基本上已经满了。
我知道目前Unicode的编排已成定局，要么不用它，要么还只能将就着用吧。
我这不过是抛开现状，畅想一下自己的想法而已。当然就算我能设计出一个很合理的类Unicode来，也没有那个号召力让全世界都来用呢，现在的码已经够多了。
不过畅想一下却也无妨。

我的意思是，规划时每个区域就预留好足够的增补空间，分批补充。
比如汉字的活字部分规划一个通用字集8000字＋罕用字集8000字。通用字先编入7500字，留它512字作为增补（这个不需要留很多因为依据字频统计很难出现遗漏情景）。罕用字先编入6000字，留2000字增补（罕用字遗漏机会就大些)。另外非成字部件区1024字，编入500字，留下500字未来增补。
这样的话，就不会造成有些部件跑到EXT-B区, 有些还可能跑到EXT-C去。
据说一些新华字典的字都还没有收全，或者跑到EXT-B甚至C. 比如新华字典里那个象“不”字(U+233B4,dun3)就跑到Ext-B区去了。虽然这些字没什么用，但毕竟字典收进去了，我很小时，喜欢翻字典就把它给记住了。我想如果连普及型字典的字都不优先考虑，那字典何必收了这些字呢。

你说到BMP给了我们2万多字已经够意思了，这倒也是。
不过我要说的是最好把它再切为两半，一半是有用的活字，一半是罕用字或死字。
而不是全部挤在一起。这样更加科学合理。
再设法让活字部分使用双字节编码，死字部分使用三字节编码（指在UTF8模式做到)。

既然我说的是畅想，那就不妨再来彻底畅想一下。
Unicode希望统一世界字符的构想，是很好也很必要的。
但是如果不论具体情况，一切照单全收， 那么对于2字节的UCS2自然是不够应付。
如果使用UCS4，那么信息储存、处理的浪费就太大了。
目前Unicode采取UCS2为主，兼容UCS4的折中方案。所以应用上多数还是使用UTF16形式表示Unicode, 很多支持Unicode宽字符的软件平台也是如此。
从信息处理的角度来说，信息储存量最好是依据它的信息量来定，这样才能尽可能地减少浪费。
就ASCII字集来说，其实 用来表达单纯的英文文本已经浪费不少了。因为英文26字母平均每个字母的信息量不到5个bit, 但却使用了7bit的ASCII编码（实际上用了8bit）. 虽然现在看来这一点浪费还是值得，毕竟除了字母，还有数字、符号、控制符等需要处理的场合。
但现在让ASCII字符也使用16bit甚至32bit来表示，那么浪费就很明显了。我看老美也未必热衷使用UTF16作为储存资料的编码，最多是考虑用UTF16加工和处理，而保存为海量数据库时还是用UTF8经济一些。
从实用角度来说，UTF8倒是在一定程度上很好地解决了这些问题。
一是它是Unicode的一种表达形式，所以保持Unicode的好处，统一了全部文字。
一是它能够和旧的8bit系统兼容（如C语言的string兼容问题）。
一是信息密度提高了。（不过这仅仅是对ASCII而言，而对汉字就相反了，由2字节变为3字节了。）
一是它不怕乱码，由于后续字节都是10xxxxxx的形式，有别于首字节，所以抗干扰能力比较强，当然这也是牺牲一定的编码空间作为代价的。

我前面为何提到按照频度分集，主要的目的也是想提高信息储存和处理的效率。
根据计算，现代汉字的平均熵值（信息量）为9.6左右。按理使用16bit编码都已经有很大的冗余了，还要忍受3字节甚至4字节的编码浪费。虽然目前这点浪费还能忍受，但全世界的浪费加在一起，就很可观了。难不成都要依赖压缩储存和压缩传输来弥补。

如果规划的更加彻底一些。那么全世界的现有文字，先来一个总字频分布统计。再适当考虑各个文字的人群状况、社会地位、语言地位、经济地位等等，给予一定的权值。
然后得出合理的字符熵值。再给予编码。
这样编制出来的编码就会有比较高的效率，虽然共同编码必定要牺牲各自的一些效率，但好处还是很明显的。

就拿汉字来说。如果和英文加权计算，熵值一定超过目前的9.6,
那么综合考虑一下，给ASCII字符7bit空间, 给CJK汉字13bit空间还是合理的。

那么汉字的编码空间只有16384个字。看起来好像不够，但实际上对活字部分完全足够。就好像7bitASCII没有把各种数学符号都收进基本ASCII空间一样，我们也不该都挤到BMP里面。

再说说UTF8的改进。UTF8的最主要好处是和现有的8bit体系相容。
但UTF8对于Unicode编码7FF以后的BMP字符一律需要3个字节，而拥有2个字节的只有80H-7FFH这有限的一点点编码。这样的设计考虑未免有点低效，也有点不公平。
撇开ASCII区域的地位不说，就说这不到2000个字的双字节编码空间，给谁好呢？我看给谁都不是。根据汉字的熵值也很有理由搬进去，可是2000字的空间都给也不够呢。
由此可见，UTF8一方面是编码空间利用还不充分，一方面是没有根据字频合理布局。

放开思路来调整一下，看看能不能让这块宝贵的双字节空间变大呢？
我们把双字节格式由110xxxxx 10xxxxxx变为1xxx xxxx 0xxxxxxx, 其中首字节取值为80-FF, 次字节取值为20-7F（牺牲一点,再照顾一下控制码的兼容）。
这样最大限度地利用双字节空间，码位有128*96=12288个。这就比原本的1920个字好多了。
当然这里还没有考虑到扩充码位，所以实际上还要扣减一些。

所以，一个设计方案也许可以是:
2字节: 10xxxxxx byte2, 有6496=6144个字（少是少了点，挤一挤只能给够格的入住）
3字节: 110xxxxx byte2 byte3， 有329696=29万个字（多了点，目前的字符我看都够了）
4字节: 111xxxxx byte2 byte3 byte4, 有32969696＝2831万字, 这是个天文数字，但其实3字节那里都用不完呢。4字节预留只是搞搞形式好了。

上述方案，双字节空间还是太紧，再加大一些。于是，另一个方案也许是：
2字节：byte1 byte2, 其中byte1=80-EF, 有11296=10752字。
3字节：byte1 byte2 byte3, 其中byte1=F0-FD, 有14×96×96＝13万字。
4字节：byte1 byte2 byte3 byte4, 其中byte1=FE-FF, 有2969696＝177万。
这个方案的双字节，我看勉强足够目前在流通的活字。

如果按照这样的空间规划，那么显然对于我们的日常用字，不怎么需要用到2字节以上的形式，又能保持一定的8bit兼容性。其他语言文字也是如此。

当然,这里的设计低字节扩充到ASCII空间去，所以赢得了巨大的空间，不想UTF8那样全部避开ASCII空间，造成很大的浪费。）
当然这里使用20-2F这段ASCII是有些代价的，可能会造成某些8bit软件的兼容问题。

把上述分段编码线性变换成一个空间，也是和Unicode一样，是唯一编码形式。除了这个8bit兼容表达外，也可以表达为16位或者32位。
对于16位形式，和UTF16一样，我们汉字占便宜，ASCII吃亏。
但是至少这里的8位兼容模式，比UTF8好多了。对谁都公平。因为谁的熵值大谁的空间就多给些，分到的bit就多些，这是天经地义的。

以上规划和Unicode一样，为了避免传输乱码，考虑了两个字节的互斥，所以都造成一定的浪费。否则双字节空间可以扩大到120*(128+96)=26880字。

为此，我再设想了一个折中的办法，既可以扩大2字节编码的空间，又可以具备很强的容错能力。
那就是主要考虑实用字（高频字、通用字、活字）的容错，而忽视罕用字（或淘汰字、死字）的容错。按此思想来进行编码设计，也很难出现乱码，具备实用价值。
具体思想是：
如果汉字出现了字节丢失，引起字节装配错位。那么错位的实用字全部变为ASCII字符于是重新获得同步。对于扩展字，将会变为非法字，也会得到同步。

只要你的文章主要使用实用字（基本字集1万2字）， 那么就不会出现乱码。
除非你的文本是由罕用字淘汰字构成，才可能出现乱码。

具体设计：
实用字：首字节80-FF, 次字节(20-7F), 共有12896=12288字
罕用字：首字节80-F7, 次字节(80-F7), 共有120128=15360字
合在一起2字节字符共有27648字。
3字节扩展：首字节=F8-FE, 次、三字节(20-F7), 共有7224224=30万
4字节扩展：首字节=FF, 其余(20-FF), 共有224224224=1124万字
当然其中20-2F这一段也可以让给罕用字，或者干脆割掉它，以增加兼容性。

抗干扰性分析：
这样的汉字编码，出现乱码时，每逢以下字节时，便可以重新获得同步。
1）只要遇到实用字（高频字）的次字节。因为次字节高位为0，只能被识别为ASCII, 不会再拉上下一个字节。
2）遇到扩展编码的首字节，他们是F8-FF, 这段码不可能出现在汉字的剩余字节里，所以要是出现在其他字节里，自然就同步了。F8-FF便是地地道道的同步字节。所以处理古字也不怕乱码：）如果不需要这个容错，那么F8-FF也可以用到次字节里。
唯一不如意的是，如果整篇文章没有一个常用字，全部是罕用字，那么就没有抵抗乱码的能力了。
这种情况几乎不会出现，因为那些罕用字一般是组不成有意义的文章，除非你的文本就是一个字集表。
即便有此小小不如意，也已经很不错了，毕竟这块空间是牺牲了一点容错能力挣来的，我看拿来放异体字倒是蛮合适。

[centrish]

发表于 2005-12-31 00:29:25 |只看该作者 谢振斌

[indent]原帖由 有女同车 于 2005-12-30 01:57 发表

刚刚又温习了一下UTF8的编码格式。
0xxxxxxx
110yyyyy 10xxxxxx
1110zzzz 10yyyyyy 10xxxxxx（A
11110uuu 10zzzzzz 10yyyyyy 10xxxxxx（B
to uuuzzzzzzyyyyyyxxxxxx

实现 A/B的兼容好像并不怎么困难吧。 …[/indent]

===
倒不是说技术上这个转换有什么困难。我在另外一个帖子也提到关于Unicode编码的处理。
http://pkucn.com/viewthread.php?tid=161855&extra=page%3D1

我主要的意思是，在一些处理和输出造成了一些不统一和不便。比如原本计算字符串长度很简单，现在就不是了。还有输出时，原本2字节汉字的宽度正好是ASCII字符的两倍，很容易对齐，现在不是了。要都是三字节汉字在一起还好，也还整齐，掺杂一些4字节进来，又不整齐了。
我还常常使用DOS时代的Foxbase处理汉字的信息呢，这些都得迁就它了。为了简单，我在拆分时，干脆不使用EXT-B里的部件字符，改用其他表达方式表示所缺的部首或部件。

另外，你说的没错，我们不能期望BMP解决所有问题，毕竟空间只有6万多。难免有需要和plane1打交道的时候，但从我前面的分析可以看出，合理的编码，可以延缓这种矛盾。

至少求得一定的统一性。比如研究汉字或古文的人才去光顾那些扩展区域。普通人就感觉不到这些，而不至于以后我们要列一张部件表，还得用到EXT-B甚至EXT-C吧。且不说UTF8或UTF16会产生码长不一致情况外，还要求每个人电脑都装上EXT-B/EXT-C吧。而汉字部件可以是汉字文化的基本内容，也是我们教育应该重视的内容，这样的代价未免高了点。台式机还好说，便携机、掌上机呢。当然也只能自带一个小扩展字库或者造字来解决了。

一个是尽可能让BMP放在所有活字部分，对于大众一般都不需要考虑扩展区域。
一个是改进UTF8的结构，就算是现有的Unicode也可以在发明一个类似我上面设计的新UTF8来。
这样我看我们放弃GBK或GB18030改用Unicode也会更加实惠一些。
可惜即便如此，也无法让所有的实用汉字都进入双字节部分，因为它没有把实用字剥离出来，2万多汉字混成一片了。

你提到，GBK规划时干脆把高位也给kill掉，这就难多了，会造成大量的软件兼容性问题，还是让出半壁江山好了：）
可恨的是我们的低字节，也不能使用全部的ASCII7bit空间，必须给控制符（00－20）让空间。这也是一个损失。而控制码我看主要也就00（NUL）、0A（LF）真正有点利用率，最多加上09(TAB)和有点多余的0D(CR）。以及一般不会用在文本中的08(BS）、07(BELL)、0C(FF)等。
折腾下来，如果考虑互斥，避免乱码，那么最大可用空间是128*96=12288字。
或者是高低字节平分bit, 这样空间增大到112×112=12544字。

如果不考虑高低字节互斥，那么最大可用空间是128*224=28672字.
如果合理点，不浪费的话，还是足够目前世界在用活字的使用的。

对于12288字的“类UTF8”空间来说，我看CJK分到8000-9000左右就很好了。足够我们把国标通用字以及部件放进去再说，即便是CJK实用字也差不多。