“?”“?”“?”这三个字为何老是无法在输入法候选栏上显示呢？！

Secask

我使用的紫光是目前最新版的6.7.0.24
我发现“?”“?”“?”这三个字很特别，它们不是一些特别偏僻的字，起码不会是扩展B区的字，这三个字就连比较普通的“宋体GB18030”字体也能支持显示了。而我的电脑安装了超大字符集，还按照这张帖子中http://bbs.unispim.com/viewthread.php?tid=7112&extra=&page=1 sanwsw兄的介绍，做好了注册表字体链接。我就连微软官方的“GB18030支持包”也安装好了。但结果却仍是令我啼笑皆非，我的输入法候选栏上，基本上连扩展BC区的字都能正常显示了，但偏偏就是这三个不太算偏僻的“偏僻字”，老是在我的输入法候选栏上留下“空档”（它不是常见的开天窗成了个方框，而是直接空了出来，如图）


在记事本上也是（记事本字体使用了“宋体”）



但这三个字在偏旁部首检字上却能正常显示：
                         


这是什么回事呢？ 这三个“缺口”好烦人啊！！

[ 本帖最后由 Secask 于 2010-7-20 02:53 编辑 ]

kingdick

原帖由 Secask 于 2010-8-15 21:28 发表
kingdick用的是office2010吗？能够直接输入吗？

无论哪个版本Office，都应可以直接输入这个字吧，问题是能不能直接显示。我这里Office2010换成Sun-ExtB字体才能显示，输入栏也一样。

kingdick

····················

Secask

kingdick用的是office2010吗？能够直接输入吗？

Secask

再一次谢谢sanwsw，用sanwsw的第二个方法，成功输入字了

[ 本帖最后由 Secask 于 2010-8-15 21:25 编辑 ]

kingdick

～～～～～～～～～～～～～～～～～～～～～～～～～～

sanwsw

方法2：打开空白Word文档，不输入任何字符，先选择字体为Sun-ExtB，然后输入想要输入的Ext-B或者Ext-C汉字。

找不到网上关于Word字体显示bug的介绍。记得在我的一篇帖子中，有个高人回复提到这是bug，并从理论上进行了剖析。很遗憾找不到帖子所在论坛了。

sanwsw

　　我用Word 2003，装有国际标准超大字符集字体支持包ＵｎｉＦｏｎｔｓ５．４，勾选“全集”、“超大字符集”。
　　不光是这个字，word的空白文档内显示Ext-C汉字需要转个弯：

方法1：



[ 本帖最后由 sanwsw 于 2010-8-15 21:12 编辑 ]

Secask

原帖由 sanwsw 于 2010-8-14 20:01 发表
word2003有bug。你再鼓捣几次，应可用Sun-ExtB显示。或者先输入该字的Unicode内码，然后按下Alt+X试试。

已试过“Alt+X”的方法，但仍然无法显示。不知道sanwsw你用word能否正常显示该字？

sanwsw

word2003有bug。你再鼓捣几次，应可用Sun-ExtB显示。或者先输入该字的Unicode内码，然后按下Alt+X试试。

Secask

今天我发现了一个新问题，是有关CJK扩展C区汉字的。

我安装了海峰的那个超大字符集支持包，而我看到里面有关的介绍是：

★　本字库包含近十万标准字符，其中中日韩越通用汉字有七万五千多：

　　CJK基本　　　[4E00-9FFF]   20992码位　实际20924字
　　CJK扩展A　　 [3400-4DBF]   6592码位 　实际6582字
　　CJK扩展B　　 [20000-2A6DF] 42720码位　实际42711字
　　CJK扩展C　　 [2A700-2B73F] 4159码位 　实际4149字
　　CJK兼容扩展  [2F800-2FA1F] 544码位　　实际542字
　　CJK部首扩展  [2E80-2EFF]   128码位　　实际115字
　　CJK康熙部首  [2F00-2FDF]   224码位　　实际214字
　　CJK笔画　　  [31C0-31EF]   48码位 　　实际36字
　　CJK兼容      [F900-FAFF]   512个码位  实际474字

我想问，CJK扩展C的那些汉字，支持包是用哪套字体收录了呢？是不是”Sun-ExtB“？我网上找到一些资料是这样说的

的确，我用浏览器（不论IE或是火狐）来浏览一些带有”扩展C区“汉字的网页时，都能正常显示扩展C区的汉字。
例如这个网页：http://longwiki.net/%F0%AA%A8%8A   里面有扩展C区汉字
而我找遍电脑中做过字体链接的字体，唯一有可能收录扩展C区汉字的字体，也就只有”Sun-ExtB“了。
但令我感到困惑的是，我把那个字复制到word 2003 后，居然变成了“空格”，无论我调用任何一款字体（包括Sun-ExtB、MingLiU-ExtB等等所有收录扩展B区汉字的字体），均无法显示出该字，就像我的电脑中没有一款字体有收录这个汉字。但这显然是不可能的，否则我用浏览器看网页时不可能显示到这个字。而且，就算把复制到记事本中，也能正常显示，怎么换到word上就不行了？

这真的奇了怪了

Secask

谢谢楼上两位的解答。

字型不一致的问题，是这样看的：
首先是扩展区的汉字本身少用到，不会出现大量不一致情况影响阅读；
其次，即使宋体-方正超大字符集也与宋体的字型不一致，而偏偏扩展区的汉字很多时候会夹杂在基本集汉字之中，那么阅读起来的话，当宋体搭上宋体-方正超大字符集的时候，也是会出现字型不一致的情况的。

我继续使用宋体-18030与Sun-ExtB来配合宋体以显示CJK基本集、CJK扩展A、扩展B的中文字，如果没发现什么问题的话，就不作改动了。

[ 本帖最后由 Secask 于 2010-8-14 12:05 编辑 ]

sanwsw

Ext-B、Ext-C中的汉字，只是偶尔用到，字体不一致，问题不大。使用孙海峰的Sun-ExtB的好处是已经包括了Ext-C的4149个汉字

racingstar

确实是用IE输入的。
你说的80个字符，方正楷体超大字符集是有收录的，不过不是在pua区中。比如“?”，可以用紫光的汉字管理小工具，直接输入unicode编码9FB6找到。
宋体超大字符集包含65530个字符，完全覆盖宋体-18030的收字范围。据san版说是因为一个字符文件不能收入超过65536个字符造成的，不过san版贴出来了一个2.0的版本，是完全收录70244个汉字的，不过分成了两个文件。两个字体文件连接的话，往往实际显示时会出现两种字体不一样的情况，海峰的Sun-ExtA和Sun-ExtB连接就是这样的，明显可以发现字体不一样。宋体超大字符集是单个文件，包含了扩展A全部字符和扩展B的大多数字符，优势就是字体统一，不会出现连接时的字符大小不一致的情况，可以用宋体超大字符集连接Sun-ExtB或者Simsunb字体，这样可以保证字体最大化的一致。
Win7和Vista的simsun+simsunb直接支持扩展a和扩展b的70244个汉字。

[ 本帖最后由 racingstar 于 2010-8-14 09:18 编辑 ]

Secask

我发现“”这个字符真的很特别，无论Sun-ExtA，还是方正楷体超大字符集，都没有收录，唯独宋体-18030和新宋体收录了，而宋体-18030还收录了扩展A区。这是我觉得宋体-18030的收字比较全的原因（不算上扩展B区了）

Secask

racingstar发的那80个字符，我在火狐下查看，全部成了乱码，跟一楼的那三个字一样，必须把编码改为GB2312才成功显示。racingstar你应该是在IE下用GB2312发的吧？

宋体-方正超大字符集，我知道它收字很多，但是，也不够GBK+A区+B区的所有汉字啊，GBK+A区+B区应该有七万多个吧。我觉得宋体-方正超大字符集肯定是在哪里收录不完全的。有鉴于此，既然我电脑已经有一些支持A区和B区的字体，那我如果做好链接：宋体、宋体-1830、Sun-ExtB，互相弥补，这反而能够显示全七万多个汉字。所以我就干脆不用宋体-方正超大字符集，而利用字体链接，搭配好字体了，有点“三个臭皮匠，胜过一个诸葛亮”的感觉

但我见racingstar还是劝我我使用宋体-方正超大字符集，是不是宋体-18030有一些问题了？

[ 本帖最后由 Secask 于 2010-8-13 22:58 编辑 ]

racingstar

GBK增补的80个字符本来是放在PUA区的。后来又被Unicode收录。所以既可以用PUA区的编码表示，也可以用非PUA编码表示。
方正楷体超大字符集这些字是有的，在FZKaiS(SIP)中，做好字体连接就能显示。
我说的超大字符集是 宋体-方正超大字符集，office 2003自带的，有六万多个字符。

汉字        GBK编码        PUA编码        非PUA编码
?        FE50        E815        2E81
?        FE51        E816        20087
?        FE52        E817        20089
?        FE53        E818        200CC
?        FE54        E819        2E84
?        FE55        E81A        3473
?        FE56        E81B        3447
?        FE57        E81C        2E88
?        FE58        E81D        2E8B
?        FE59        E81E        9FB4
?        FE5A        E81F        359E
?        FE5B        E820        361A
?        FE5C        E821        360E
?        FE5D        E822        2E8C
?        FE5E        E823        2E97
?        FE5F        E824        396E
?        FE60        E825        3918
?        FE61        E826        9FB5
?        FE62        E827        39CF
?        FE63        E828        39DF
?        FE64        E829        3A73
?        FE65        E82A        39D0
?        FE66        E82B        9FB6
?        FE67        E82C        9FB7
?        FE68        E82D        3B4E
?        FE69        E82E        3C6E
?        FE6A        E82F        3CE0
?        FE6B        E830        2EA7
?        FE6C        E831        215D7
?        FE6D        E832        9FB8
?        FE6E        E833        2EAA
?        FE6F        E834        4056
?        FE70        E835        415F
?        FE71        E836        2EAE
?        FE72        E837        4337
?        FE73        E838        2EB3
?        FE74        E839        2EB6
?        FE75        E83A        2EB7
?        FE76        E83B        2298F
?        FE77        E83C        43B1
?        FE78        E83D        43AC
?        FE79        E83E        2EBB
?        FE7A        E83F        43DD
?        FE7B        E840        44D6
?        FE7C        E841        4661
?        FE7D        E842        464C
?        FE7E        E843        9FB9
?        FE80        E844        4723
?        FE81        E845        4729
?        FE82        E846        477C
?        FE83        E847        478D
?        FE84        E848        2ECA
?        FE85        E849        4947
?        FE86        E84A        497A
?        FE87        E84B        497D
?        FE88        E84C        4982
?        FE89        E84D        4983
?        FE8A        E84E        4985
?        FE8B        E84F        4986
?        FE8C        E850        499F
?        FE8D        E851        499B
?        FE8E        E852        49B7
?        FE8F        E853        49B6
?        FE90        E854        9FBA
?        FE91        E855        241FE
?        FE92        E856        4CA3
?        FE93        E857        4C9F
?        FE94        E858        4CA0
?        FE95        E859        4CA1
?        FE96        E85A        4C77
?        FE97        E85B        4CA2
?        FE98        E85C        4D13
?        FE99        E85D        4D14
?        FE9A        E85E        4D15
?        FE9B        E85F        4D16
?        FE9C        E860        4D17
?        FE9D        E861        4D18
?        FE9E        E862        4D19
?        FE9F        E863        4DAE
?        FEA0        E864        9FBB

[ 本帖最后由 racingstar 于 2010-8-13 22:23 编辑 ]

Secask

原帖由 racingstar 于 2010-8-13 20:58 发表
可以使用方正超大字符集吧，那个收字更多。
一般来说，你用到cjk扩展a区的汉字，你很有可能也会用到扩展b区的汉字。
很多时候就是这样，那些生僻字一般都用不到。但是一些有特殊需求的人，比如从事文字工作，一旦要 ...

我现在浏览器的字体链接是宋体-18030后面再跟一个Sun-ExtB，就是为了弥补B区的汉字。
宋体-18030真的有问题吗？不是说字体跟编码集无关的吗？难道GB18030有问题也对宋体-18030有影响了？

我只是觉得宋体-18030不但有GBK、扩展A区的全收录，而且连GBK中的PUA区域那些“特别字”都收录了，很齐全。这是很多字体，例如新宋体（漏ExtA）、Sun-ExtA（漏PUA）、超大字符集方正楷体（漏PUA）都做不到的。
但我不知道宋体-18030会不会因为GB18030的缘故，而有一些缺陷。

racingstar

可以使用方正超大字符集吧，那个收字更多。
一般来说，你用到cjk扩展a区的汉字，你很有可能也会用到扩展b区的汉字。
很多时候就是这样，那些生僻字一般都用不到。但是一些有特殊需求的人，比如从事文字工作，一旦要用到，恐怕扩展a的汉字还不够用。

Secask

原帖由 racingstar 于 2010-8-13 09:16 发表
GB18030非常特殊，它要向下兼容ANSI编码的GBK，但是有六千多个汉字又是需要四个字节编码的（就是超过了16进制的FFFF，不能用两个字节编码）。我们脑残的国家相关部门制定了这个不伦不类的标准（其实就是把unicode字符集中的cjk ext-a中的字符加入GBK，但是制定标准的人不考虑具体的实现，不知道ANSI字符集表示不了这么多字符）

那么最后GB18030来理顺那些矛盾的呢？

正如之前所讲，racingstar你也提到字体不存在编码的问题，宋体-18030只是代表了它收录了GB18030字符集的所有字符。那么，虽然GB18030是一套不伦不类的标准，但宋体-18030这套字体应该没多少问题吧。
它收录了GBK和扩展A区的所有汉字，我是挺喜欢这款字体的，因为收字挺全的。

Secask

让我梳理一下

编码（字符集）：Unicode、GB18030、GBK、GB2312.....
编码方式：UTF-8、UTF-16、UTF-32、ANSI

我这样理解，对不对？

此外，使用不同编码方式的字符集，是否不同呢？例如，同一个字符，在UTF-8编码的Unicode和UTF-16编码的Unicode下，它所获得编码号是不是不一样？

racingstar

原帖由 Secask 于 2010-8-12 23:59 发表

那么，不同的判定方式、控制方式，就衍生出了不同的编码：GB18030、Unicode等等？

主要就是ANSI和Unicode两种编码方式。
ANSI编码方式的特点是向下兼容ascaii，现有的ANSI编码都是在ascaii上扩展一个字节得到的。不同国家都制定了不同的ANSI编码的字符集。比如说我国制定了GB3212和GBK，日本制定了日文的ANSI字符集，韩国制定了韩文的ANSI字符集，台湾制定了Big5字符集。
这样每种语言就有一个字符集编码方式，是不是有一种编码方式可以搞定所有的字符集？就出现了unicode编码。Unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符，或者说有1114112个码位，这样的话，就绝对够用了。但是有一个问题，这样一来，每个字符就需要多个字节编码，英语又是使用最广泛的语言，这样浪费了很多空间。然后人们就想出了各种编码方式，比如utf-8就使用一到六个变长字符表示一个字符，原来ascaii的字符集在utf-8编码方式下还是使用一个字节。utf-16使用两个或者四个字节编码，但是为了计算机识别，还需要加上控制字节，那么一个字符就可能需要三个或者五个字节。utf-32使用四个字节编码，是最直观的一种编码方式，直接把16进制数翻译成2进制表示，实际使用时还需要加上一个控制字节，也就是说一个字符需要五个字节编码。
GB18030非常特殊，它要向下兼容ANSI编码的GBK，但是有六千多个汉字又是需要四个字节编码的（就是超过了16进制的FFFF，不能用两个字节编码）。我们脑残的国家相关部门制定了这个不伦不类的标准（其实就是把unicode字符集中的cjk ext-a中的字符加入GBK，但是制定标准的人不考虑具体的实现，不知道ANSI字符集表示不了这么多字符），微软为了卖产品给中国，就加入了GB18030的支持（方法一般是加控制字节来区分），表示我的产品可以支持GB18030，实际使用中都没什么人用的，兼容性太差，遇到ANSI字符集之外的字符，大家都会使用unicode编码。
GB18030编码的所有字符，可以找那个文件查到。

[ 本帖最后由 racingstar 于 2010-8-13 09:22 编辑 ]

Secask

在此要再次谢谢racingstar，教了我很多，扫了我很多“计算机编码知识”的盲区，让我获益良多

Secask

原帖由 racingstar 于 2010-8-12 20:10 发表
所以我们在应用层要关心的是，怎么判定到底是几个字节表示一个字符。比如说ANSI编码的字符，一定是一个或两个字节的。读到的字节位小于127，就直接解码，读到的字节位大于127，就和后面一个字节一起解码。
unicode编码，有很多方式，各个编码方式的控制字节都不一样，这个可以google上搜一下具体的定义。

那么，不同的判定方式、控制方式，就衍生出了不同的编码：GB18030、Unicode等等？

racingstar

原帖由 Secask 于 2010-8-12 19:23 发表
那么解码是怎样的机制？
例如，宋体-18030是按照GB18030编码排序，那么宋体-18030里应该有GB18030的编码信息。那么对于一些Uniocde编码的页面，浏览器是不是先把它转换成字体的编码（GB18030）而去调用字体？

无论什么编码，程序都会解码，然后按照解码后的顺序去读取字体文件。字体文件里面字符的编排顺序是固定的，字体没有编码的说法。
http://download.csdn.net/source/2044299
gb18030所有汉字的编码，你可以下载这个文件查看。
你可以注意到同一个字符的GBK编码和unicode编码不一样，但是字体文件字符的编排顺序是固定的，那么是怎么读取的呢？因为程序会先读取字体的分页信息，如果你是GBK编码，程序会读取GBK的分页信息，找到对应解码后字体的地址位。

[ 本帖最后由 racingstar 于 2010-8-12 20:53 编辑 ]

racingstar

计算机的信息是一组比特流。我们定义了一个字节有8个比特。
那计算机是怎么知道我输入的字节是从哪个比特位开始的呢？这个是靠硬件实现的，集成电路的开关电路一定是按照最基本的8个逻辑开关为一组设计的。
比如说总线带宽256位512位，一定是8的倍数，cpu的逻辑处理单元也一定是按照8个比特位一组的方式设计的，一下子能够处理8个比特位。
所以我们在应用层要关心的是，怎么判定到底是几个字节表示一个字符。比如说ANSI编码的字符，一定是一个或两个字节的。读到的字节位小于127，就直接解码，读到的字节位大于127，就和后面一个字节一起解码。
unicode编码，有很多方式，各个编码方式的控制字节都不一样，这个可以google上搜一下具体的定义。

Secask

原帖由 racingstar 于 2010-8-12 19:18 发表
计算机只认识0和1的比特流，一个字节有8个比特位。
那一个字节能表示00000000-11111111之间的一个数字，变成10进制就是0-255，变成16进制就是00-FF，总共能表示256个字符。
我们要对字符编码，就必须要有一个字符集，在这个字符集中定义了每一个字符对应的字节。
比如大写字母A，我们定义用16进制的41表示，那么转换成2进制，就是01000001。那计算机碰到一个字节是01000001的话，它就会解码成对应的字符。
但是这样的话，最多也只能表示256个字符，后来就扩展可以使用2个字节编码，这样能表示更多的字符。这一类ascaii字符集扩展，我们都称为ANSI编码。
unicode编码能表示更多的字符，从00000-10FFFF，但是我们不能就这样直接表示一个字符，因为计算机不知道这个字符哪里开始哪里结束，所以必须加上控制位，然后就出现了utf-8，utf-16，utf-32等各种unicode编码

那什么叫做控制位呢？可不可以这样理解，计算机的信息，就是一大堆有字节组成的信息流，而字体也是用信息流表示的。但不是所有的字节都是字符信息，还有一些是颜色、排版信息等等。而控制位，就是告诉计算机，哪个到哪个字节是代表字符的，并是怎样编码的，由此衍生出unicode、GBK等各种编码？

Secask

那么解码是怎样的机制？
例如，宋体-18030是按照GB18030编码排序，那么宋体-18030里应该有GB18030的编码信息。那么对于一些Uniocde编码的页面，浏览器是不是先把它转换成字体的编码（GB18030）而去调用字体？

racingstar

计算机只认识0和1的比特流，一个字节有8个比特位。
那一个字节能表示00000000-11111111之间的一个数字，变成10进制就是0-255，变成16进制就是00-FF，总共能表示256个字符。
我们要对字符编码，就必须要有一个字符集，在这个字符集中定义了每一个字符对应的字节。
比如大写字母A，我们定义用16进制的41表示，那么转换成2进制，就是01000001。那计算机碰到一个字节是01000001的话，它就会解码成对应的字符。
美国就制定了这样一个字符集，用一个字节表示字符，叫做ascaii字符集。但是这样的话，最多也只能表示256个字符，后来就扩展可以使用2个字节编码，这样能表示更多的字符。
当然扩展成2个字节编码还是要兼容原来的ascaii字符集的，比如我们的GBK字符集就定义如果遇到一个字节大于127，那么这个字节和后面一个字节共同表示一个字符；如果第一个自己小于127，那么这个字节就单独表示一个字符，就是ascaii中定义的相关字符。这一类从ascaii字符集扩展出来的字符集，我们统称其编码方式为ANSI编码。采用ANSI编码，需要一个或两个字节表示一个字符。
Unicode编码能表示更多的字符，范围从00000-10FFFF，但是我们不能就这样直接表示一个字符，因为计算机不知道这个字符是从哪个字节开始哪个字节结束的，所以必须加上控制位，然后就出现了utf-8，utf-16，utf-32等各种unicode编码。
GB18030的问题在于有6000多个字符是四个字节表示的，并且这个字符集还要兼容GBK和GB3212，GBK和GB3212是ANSI编码，而ANSI编码是一个或两个字节表示一个字符的。但是GB18030是中国制定的字符集标准，销售到中国的产品必须要支持，微软就采用了一种特别的方式来识别GB18030字符集。但是这种不伦不类的字符集，实在是鸡肋，有四个字节的字符，不能用unicode编码，因为要兼容ANSI编码的字符集，微软只能费点时间来实现，表示我的产品是支持这个字符集的，就可以在中国卖了，实际没什么人使用，兼容性太差。

[ 本帖最后由 racingstar 于 2010-8-12 19:53 编辑 ]

racingstar

原帖由 Secask 于 2010-8-12 11:09 发表

那我是否可以这样理解：
编码的解码是程序（例如浏览器）的问题，只要告知浏览器网页的编码（选择正确的字符编码），浏览器即可正确解码出字符，然后就可以调用字体来显示了。字体文件本身并不需要识别各种编码， ...

可以这么说，有专用的api去解码，当然字体文件一定是要按照编码表排序的。