CN104424163A - 文字处理方法和系统 - Google Patents

Abstract

本发明提供了一种文字处理方法及系统，属于嵌入式软件技术领域以及文字信息处理技术领域。该方法包括：服务器通过移动通信网络接收到来自移动终端的编码序列；服务器从编码序列中解析得到字符编码类型、字符编码和字体类型信息；服务器从字符编码类型对应的字库的公有数据部分中，获取所述字符编码的索引，并根据所述索引从所述字符编码类型对应的字库的字型专属数据部分中获取所述字体类型信息所对应的字型专属数据；所述服务器将所述字型专属数据通过所述移动通信网络发送给所述移动终端。本发明既能简便的解决移动终端中缺字的问题，还能够减轻网络负载，提高响应速度，大幅降低数据的冗余量，并降低了缺字字符的使用难度。

Description

文字处理方法和系统

技术领域

本发明涉及字库技术领域，特别是涉及一种文字处理方法和系统，以便于可以方便快捷的解决移动终端缺字问题。

背景技术

字库是移动终端（例如智能手机）操作系统的重要组成部分，移动终端通过字库完成文字的呈现，如汉字的录入、显示或者阅读等。我国现有的主流移动终端的字库基本是按照国家编码标准GBK或GB18030-2000进行组织的。

GBK的编码标准兼容GB2312的编码标准，共收录汉字21003个，提供1894个造字码位，并将简体字和繁体字融于一库。

GB18030-2000是GBK的取代版本，它的主要特点是在GBK基础上增加了六千多个CJK统一汉字扩充A的汉字，达27533个汉字，基本上可以满足日常生活中的大部分需求。

然而，由于目前仍有相当数量的冷僻字在国家GB18030-2000编码标准以外（如人名地名冷僻字等），因此，就出现了大字符集GB13000-2005/GB13000-2010（完全等同于国际字符编码标准UNICODE5.0），其字数达70000多字。这些大字符集最主要的变化就是增加了四万多字的CJK统一汉字扩充B，且未来还会继续增加CJK统一汉字扩充C以及CJK统一汉字扩充D……等等。

虽然这些大字符集能够更多的显示冷僻字字符，但是随着字符集的不断扩充，尤其是为了支持东亚语种，字符数会不断增加，这会导致字库文件的数据量不断增加。

现有的大字符集网络实时分发的方法通常为移动终端直接下载大字库全库的方式，

如果移动终端的操作系统直接将这种大字库设置为默认字库，则不但会占用较大的空间，并会降低系统启动速度，还会出现字符冗余现象，即大部分冷僻字字符的使用频率极低，如某个用户可能只需要其中几个冷僻字，而其余几万数量的冷僻字针对该用户而言是不需要的；这最终会造成移动终端运行效率较低等问题。

另外，大字库通常需要两个字库来显示，如由于Truetype和Opentype字库标准设计最多容纳65536个字，因此，7万多字的超大宋体字库通常需要两个字库来显示。这样，两个字库文件再加上字符显示动态渲染指令部分会超过20M以上。而且，两个字库容纳7万多字的不同编码区域的字符，这会造成字库在网络环境和移动环境下分发的不便和使用上的不便，例如，需要用户自己来区分哪个字符在两个字库中的哪个字库中。还有，用户在费时下载了两个大字库后，在移动终端中安装这两个字库的整库也很费力，如不但安装过程繁琐，而且还需要修改系统进行两个字库的关联；普通用户基本上不会自己安装移动终端中下载的新的大字库。

发明内容

针对现有技术中存在的缺陷，本发明的目的是提供一种文字处理方法和系统，该方法和系统通过分离服务器端缺字字型专属glyph数据，既能方便的解决移动终端中缺字的问题，同时还能够减轻网络负载，提高移动终端的响应速度，大幅度降低数据冗余量，并降低缺字字符的使用难度。

为了实现上述目的，本发明提供的一种文字处理方法，包括：服务器通过移动通信网络接收到来自移动终端的编码序列；所述服务器从所述编码序列中解析得到字符编码类型、字符编码和字体类型信息；所述服务器从所述字符编码类型对应的字库的公有数据部分中，获取所述字符编码的索引，并根据所述索引从所述字符编码类型对应的字库的字型专属数据部分中获取所述字体类型信息所对应的字型专属数据；所述服务器将所述字型专属数据通过所述移动通信网络发送给所述移动终端。

本发明提供的一种文字处理系统，所述系统包括服务器，且所述服务器包括：请求处理分配模块，用于通过移动通信网络接收到来自移动终端的编码序列，并从编码序列中解析得到字符编码类型、字符编码和字体类型信息；数据提取模块，用于从所述字符编码类型对应的字库的公有数据部分中，获取所述字符编码的索引，并根据所述索引从所述字符编码类型对应的字库的字型专属数据部分中获取所述字体类型信息所对应的字型专属数据；数据下发模块，用于将所述字型专属数据通过所述移动通信网络发送给所述移动终端。

本发明的效果在于：采用本发明所述的方法及系统，通过将现有字库中的数据分割为字库公有数据和字型专属部分，在网络分发时，可以仅分发所需的缺字字符对应的字型专属部分数据；这样，减轻了移动通讯网络负载，提高了移动终端的响应速度，大大降低了字库数据的冗余量，节省了移动终端的存储空间，降低了缺字处理的使用难度，完全达到了缺字时按需实时分发的目的。

附图说明

图1为本发明所述的系统结构图；

图2为本发明所述的方法流程图；

图3为本发明具体实施方式中数据类别划分示意图；

图4A-4C为本发明具体实施方式中缺字字型范例图；

图5为本发明具体实施方式中缺字字型轮廓数据二进制范例图；

图6为本发明具体实施方式中缺字字型数据打包流程图；

图7为本发明具体实施方式中缺字字型数据解包流程图；

图8为本发明具体实施方式中本地字库追加缺字字型数据流程图。

具体实施方式

下面结合实施例和附图对本发明所述的方法及系统进行详细说明。

本发明实施例提供的文字处理方法主要包括如下步骤：

步骤（1）、申请端（即移动终端）判断出移动终端系统内的当前字符序列不在本地字库内（即申请端确定出本地缺字），移动终端向服务器（即发送端）发送包括字符编码类型、字符编码以及字体类型信息在内的编码序列，即移动终端向服务器发送缺字请求。

上述本地字库是指移动终端操作系统内的预装字库，且本地字库的主流编码范围通常支持国家GBK/GB18030-2000编码标准。另外，移动终端的操作系统包括但不限于如下智能移动终端操作系统：Symbian、ios、Android或者WindowsPhone等。

上述缺字可以是缺一个字或者缺多个字，且缺字字符通常为本地字库不含有的中文字符（汉字）和英文字符，即利用本地字库无法正常显示的字符。

字符编码类型可以是GB18030-2005、GB13000-2010、ISO/IEC10646-2003或者UNICODE5.0，且可以随着标准的扩展而同步扩展。

上述字符编码是指对应字符编码类型的缺字的字符编码，缺字的字符编码通常以四字节形式出现。

上述字体类型是指字体的类型，如宋体、黑体或者楷体等。本地缺字字体类型需要与服务器选择的字体类型一致，如缺字字体类型为黑体，则服务器端也应选择黑体。

上述缺字请求既可以是针对单一一个字的缺字请求，也可以是针对若干个字的缺字请求；另外，缺字请求既可以是针对单一字体类型的缺字请求，也可以是针对混合字体类型的缺字请求；为避免混淆，缺字请求不可以是缺字的混合编码类型的缺字请求。

步骤（2）、发送端（即服务器），在接收到缺字请求后，对该缺字请求进行解析，以确定缺字的编码类型，字符编码以及字体类型信息，从本地选择合适的字体类型，并执行提取这些缺字字符对应的相应的数据的操作；服务器的字库中的数据被划分为公有数据部分和字型专属数据部分，其中，字库中具备全局数据性质并能够多次使用的数据被划分为公有数据部分，字库中与字型相关的数据划分为字型专属数据部分，且通过公有数据的索引部分可以快速定位到缺字所需的字型专属数据部分。

上述公有数据无需下发至移动终端，且公有数据中的索引部分是作为快速定位字型专属数据的依据。

上述服务器的字库的字符编码应涵盖国家最高、覆盖范围最广的编码标准，如GB18030-2005、GB13000-2010、ISO/IEC10646-2003以及UNICODE5.0，且该字库能够随着标准的扩展而继续向后兼容，上述字符编码标准GB18030-2005、GB13000-2010、ISO/IEC10646-2003以及UNICODE5.0是互相兼容发展的，有完全对照关系的。服务器的字库的字数至少要支持国家编码标准GB13000-2010中7万多字，且随着标准的扩展，字数也能同步增加。另外，服务器的字库应支持不同的字体类型，如支持宋体、黑体以及楷体等。

步骤（3）、发送端根据解析后获得的信息通过公有数据中的索引部分定位到字型专属数据部分，然后，动态提取字型专属数据部分中与所需字符相关的字型专属数据，并对被提取的缺字字型数据进行汇总打包处理，生成数据包。

上述数据包包括：字型数据头、字型专属数据索引表以及字型二进制数据。

上述字型数据头包括：传入数据总个数、当前数据类型的序号、传入数据的字型编码作为整体的类型、当前数据头的版本以及预留位组成。

上述字型专属数据索引表包括若干个索引；每个字型专属数据索引包括：当前传入数据的类型、标识编码、与此标识编码有关的字型二进制数据的存储位置及字型二进制数据的长度。

在服务器的字库为TrueType字库或者OpenType字库的情况下，公有数据部分包括TrueType字库或者OpenType字库的文件头、描述表目录以及除字型专属轮廓数据表之外的其他描述表。

上述字型专属数据部分包括轮廓数据表。

上述提取缺字的字型专属数据即提取缺字的字型专属轮廓数据，该过程的一个具体的例子可以包括以下步骤：

A）、读取文件头，获取三个表距离字库文件头的偏移量，这三个表即Cmap（编码序号映射关系表）、Loca（记录字型轮廓数据距离字型轮廓数据表头偏移量以及该字型轮廓数据长度的表）以及glyf（记录字型轮廓数据表）。

B）、在Cmap中，顺序找到该字型编码与对应的Glyf中的序号；在TTF和OTF字库标准中，Glyf字型序号范围被设计为1至65536，即一个TTF或OTF字库最多只能容纳65536个字符。

C）、根据上述步骤B中的序号，到Loca中顺序查找该序号对应的偏移值，该偏移值是距离Glyf中字型轮廓数据表头的偏移量。

D）、上述距离Glyf中字型轮廓数据表头的偏移量加上Loca中记录的该字型轮廓数据的相对偏移量，即为该字型轮廓数据的实际存储头开始位置，结合Loca中记录的该字型的轮廓数据的长度，即可提取出单个字符专属轮廓数据的二进制段。

重复上述步骤B）、步骤C）和步骤D），直到遍历完所有的缺字字符，完成所有缺字字符的提取操作。

上述打包处理过程的一个具体例子可以包括以下步骤：

步骤a）、建立字型轮廓索引数组和字型轮廓数组，记录提取后的每个字符的标准编码、该字字型轮廓数组中的偏移量、该字字型轮廓数据的长度值；

步骤b）、根据上述传入的字型轮廓索引数组，将对应的字型轮廓数据追加到数据数组（即字型轮廓数组）中。

步骤c）、将需要打包的数据依次追加到字型轮廓索引数组和字型轮廓数组中，并更新字型轮廓索引数组里的偏移量和字型轮廓数据的长度。

步骤d）、继续传入需要打包的数据，直到没有需要打包的数据。

步骤e）、为字型轮廓索引数组和字型轮廓数组增加数据头，形成数据包。

步骤（4）、发送端向接收端（即申请端）发送该数据包，接收端对接收到的数据包进行解包处理，以获取数据包中的数据。

上述解包处理过程的一个具体的例子可以包括：根据字型轮廓索引数组总索引数量遍历所有的索引，根据索引中数据的偏移量和每个字型轮廓数据段的长度，从字型轮廓数组的实体二进制数据中提取出对应的字型轮廓数据。

步骤（5）、接收端将从数据包中的缺字字符的字型专属数据追加到本地字库的字型专属数据中，同时在本地字库的公有数据中增加新的索引数据，并进行修正，从而可以通过新的索引数据映射到新追加的缺字字型专属数据，从而完成了将从服务器下载的缺字字型融合到本地字库中，以正常显示所需的缺字字符，而不再需要从服务器下载整个新的大字库。

上述步骤（5）的一个具体例子可以包括下述步骤：

步骤①、移动终端读取本地字库文件头，获取三个表距离该字库文件头的偏移量，即：Cmap编码序号映射关系表、Loca记录字型轮廓数据距离字型轮廓数据表头偏移量以及该字型轮廓数据长度的表、glyf记录字型轮廓数据表。

步骤②、在Cmap中，根据缺字的字符编码，按照顺序插入映射关系，映射关系的一端是缺字的字符编码，另一端是glyf中的字型轮廓序号，glyf中的字型轮廓序号可以参照Loca里最后一个序号加1，这样就完成了Cmap的映射。

步骤③、在Loca中，按照顺序新增该序号，即最后一个序号，该序号对应Glyf中存储的最后一个字型轮廓偏移量，并且两个相邻序号的字型轮廓偏移量相减即为上一个字型轮廓数据段的长度。如果是最后一个，则需要额外填写加上该字型轮廓信息长度的数据值。

步骤④、通过上述Loca中确定的新增字符对应的偏移量加上Glyf中数据头偏移量，即为该字型轮廓数据的实际存储头开始位置，结合Loca中记录的该字型的轮廓数据的长度，将解包处理过的数据数组中提取的单个字符轮廓数据复制，复制长度等于解包处理过的索引数组中每个字型轮廓数据段的长度。

重复上述步骤②、步骤③以及步骤④，直到插入完所有解包处理过的缺字字符数据，这样就完成了从服务器端获取缺字字符序列，并追加到本地字库中的全过程。

本发明提供的文字处理系统主要包括：发送端（服务器）以及接收端（即申请端，也即移动终端）。

上述发送端中设置有缺字请求的受理和任务分配模块、数据划分和定位模块、数据提取模块、打包模块以及数据下发模块。

缺字请求的受理和任务分配模块主要用于接收并识别申请端发送来的缺字请求，以确定缺字的字符编码类型、字符编码以及字体类型等信息；然后，该模块根据识别的结果进行相应的任务分配。

数据划分和定位模块主要用于将字库中的数据划分为公有数据部分和字型专属数据部分，然后，利用公有数据中的索引部分定位字型专属数据部分；其中，该公有数据是指字库中具备全局数据性质并能够多次使用的数据，该字型专属数据是指字库中与字型相关的数据。

数据提取模块主要用于利用缺字在公有数据中的索引部分来定位字型专属数据部分，并提取缺字需要的特定字型专属数据。

上述数据提取模块包括：数据分析定位子模块和字型数据提取子模块；数据分析定位子模块主要用于提取缺字字型的索引数据；字型数据提取子模块主要用于提取缺字字型专属数据。

打包模块主要用于将数据提取模块提取的数据进行打包处理，生成数据包。

数据下发模块主要用于将打包模块生成的数据包下发给移动终端。

上述接收端（申请端）中设置有本地字库缺字验证和请求模块、解包模块以及本地字库追加模块。

本地字库缺字验证和请求模块主要用于判断当前字符是否在本地预装字库内，如果不再本地预装字库内，则向服务器发生缺字请求；该缺字请求主要包括缺字的字符编码类型、字符编码以及字体类型。

解包模块主要用于对数据下发模块传输来的数据包进行解包处理。

本地字库追加模块主要用于将解包处理后获得的字型专属数据追加到本地字库中，以使缺字可以被正常显示。

上述本地字库追加模块包括：缺字索引数据追加子模块和缺字字型专属数据追加子模块；缺字索引数据追加子模块主要用于在本地字库中追加缺字的索引数据；缺字字型专属数据追加子模块主要用于在本地字库中追加缺字的字型专属数据。

下面结合图1-8对本发明实施例提供的可以有效解决移动终端（如手机）中缺字的文字处理方法和系统进行进一步的举例说明。

图1中，从逻辑上而言，该系统包括：申请端1（即移动终端，也可以称为用户设备）、发送端2（即服务器）以及接收端3（即申请端，也即移动终端或者用户设备）。

上述申请端1中主要设置有本地字库缺字判断和请求模块10（即图1中的缺字判断和请求模块）。

本地字库缺字判断和请求模块10主要用于判断当前字符是否在本地预装字库内，如果当前字符不在本地预装字库内，则向服务器发送缺字请求。

模块10发出的缺字请求主要包括：缺字的字符编码类型、字符编码以及字体类型；其中，字符编码类型是指GB18030、GB13000、UNICODE或者ISO/IEC10646等；字符编码是指对应上述字符编码类型的缺字的字符编码，且缺字通常以四字节形式出现；字体类型是指字体的类型，如宋体、黑体或者楷体等。

上述发送端2（即服务器2）中主要设置有缺字请求的受理和任务分配模块20（即图1中的请求处理分配模块）、数据提取模块21、数据打包模块22以及数据下发模块23。

缺字请求的受理和任务分配模块20主要用于接收申请端1发送来的缺字请求信息，并识别缺字请求信息，并进行任务分配。该模块20应可有效识别缺字请求中的缺字的字符编码类型、字符编码以及字体类型等。

模块20在接收到缺字请求信息后，将相应的任务分配给服务器端的数据提取模块21，以提取对应的超大字库中的信息。上述超大字库如超大宋体字库、超大黑体字库或者超大楷体字库等；在通常情况下，这些超大字库同时兼容GB18030、GB13000、UNICODE以及ISO/IEC10646的最新版本，并可以随标准的扩展而同步扩展。

数据提取模块21在接收到模块20分配来的任务后，确定缺字的字体类型，然后进行字库整体数据分析、字型数据定位以及字型数据提取操作；即数据提取模块21主要用于定位和提取缺字对应的字型专属数据。

在本实施例中，数据提取模块21中设有缺字分析定位子模块211（即图1中的数据分析定位子模块）和字型专属数据提取子模块212（即图1中的字型数据提取子模块）。缺字分析定位子模块211主要用于分析定位缺字字型专属数据；而字型专属数据提取子模块212主要用于提取缺字字型专属数据。

具体的，缺字分析定位子模块211主要用于将字库中的数据划分为公有数据部分和字型专属数据部分，并利用公有数据部分中的索引定位缺字对应的字型专属数据部分；上述公有数据是指字库中具备全局数据性质并能够多次使用的数据，其包含有定位字型专属数据部分的索引数据，上述字型专属数据是指字库中与字型相关的数据。

数据打包模块22主要用于将数据提取模块21提取的多个缺字的字型专属数据进行汇总以及打包处理，以生成相应的数据包，且该数据包可以进行压缩处理。

数据下发模块23主要用于向接收端3下发打包模块22所生成的数据包。

上述接收端3中主要设置有本地解包模块30（也可以称为解包模块30）以及本地字库追加模块31。

本地解包模块30主要用于解析数据下发模块23下发的数据包。

本地字库追加模块31主要用于将解包模块30解包后获得的字型专属数据追加到本地字库中，以正常显示缺字。

在本实施例中，本地字库追加模块31中设置有缺字索引数据追加子模块311（即图1中的索引数据追加子模块）和缺字字型专属数据追加子模块312（即图1中的字型数据追加子模块）；其中的缺字索引数据追加子模块311主要用于在本地字库中追加缺字的索引数据；而缺字字型专属数据追加子模块312主要用于在本地字库中追加缺字字型专属数据。

本发明实施例提供的一种解决移动终端（如手机）中缺字的文字处理方法如图2所示，该方法包括以下步骤：

步骤1、针对本地文档里的字符，申请端1通过本地字库缺字判断和请求模块10进行判断，以确定本地文档里的字符是否在本地预装的字库里，即是否可以正常显示；如果某个或者某些字符不在本地预装字库内，则申请端1通过本地字库缺字判断和请求模块10向服务器发送包含缺字的字符编码类型、字符编码以及字体类型在内的缺字请求信息（也可以称为缺字请求序列）。

例如：以申请端1手机内的文字无法显示为例，该字符的字型大图见图4A-4C，申请端1经过判断比较后，发现该字符的编码在本地字库中不存在，则向服务器发出缺字请求。

上述字符的UCS-4编码为0X20000，为UNICODE第二平面冷僻字，对应的GB13000/UTF16编码为0XD840DC00，为四字节编码，对应的GB18030-2005编码为0X91428236，即需要使用四个字节才能表示一个字。

申请端1向服务器发出的缺字请求包括字符的编码类型、字体编码本身以及字体类型等信息；其中的字体编码可以是GB13000、UTF16或者GB18030-2005的字体编码，字体类型可以是宋体、黑体或者楷体等；需要说明的是，请求的字体类型必须与本地默认字库的字体类型相匹配，如本地字库为黑体，请求的字体类型也应该为黑体，从而服务器也应该选择黑体。

步骤2、服务器中的缺字请求的受理和任务分配模块20在接收到申请端发送的包括缺字的字符编码类型、字符编码以及字体类型的缺字请求信息后，对该缺字请求中的信息进行识别，并进行任务分配。

其中，上述字符编码类型是指GB18030、GB13000、UNICODE以及ISO/IEC10646等，上述字符编码是指对应字符编码类型的缺字的字符编码，且缺字的字符编码通常以四字节形式出现，上述字体类型是指字体的类型，如宋体、黑体或者楷体等。

服务器中的缺字请求的受理和任务分配模块20会在接收并识别缺字请求后，将相应的任务分配给服务器中的数据提取模块21，以从对应的超大字库中提取相应的信息。上述超大字库如超大宋体字库、超大黑体字库以及超大楷体字库等。通常情况下，这些超大字库会同时兼容GB18030、GB13000、UNICODE以及ISO/IEC10646的最新版本，并可以随标准的扩展而同步扩展。

步骤3、服务器中的数据提取模块21在接收到上述模块20分配来的任务后，如接收到缺字请求信息后，确定缺字的字体类型，并进行字库整体数据分析、字型数据定位以及字型数据提取操作，以定位和提取缺字对应的字型专属数据。

在本发明实施例中，服务器通过数据提取模块21可先分析定位缺字字型专属数据，之后提取缺字字型专属数据。

本发明实施例的字库中的数据被划分为公有数据部分和字型专属数据部分，可以利用公有数据中的索引来定位缺字对应的字型专属数据部分中的内容。上述公有数据是指字库中具备全局数据性质并能够多次使用的数据，且公有数据通常包含定位字型专属数据部分的索引数据；上述字型专属数据是指字库中与字型相关的数据。

也就是说，本发明实施例是将字库中具备全局数据性质并能够多次使用的数据划分为公有数据部分，并将字库中的与单个字型相关的数据划分为字型专属数据部分。字库的一个具体的例子如图3所示。

图3示出了TrueType字库格式（以下简称TTF），具体的，一个标准的TTF文件由2个部分组成，即文件头和一系列的描述表；其中的文件头包括偏移表和表目录等信息；偏移表的后面为表目录的描述，表目录包括表名称、表偏移地址以及表字节长度等；最后是各个文件描述表本身。

常用的TTF文件描述表一般有19个，核心表主要包括字符编码映射表（即Cmap）、字型数据定位表（即Loca）以及轮廓数据表（即Glyf）等。其中，Glyf是TTF文件的主体部分，用于存放所有字符的轮廓描述信息，且包括描述字型轮廓的数据信息和字型轮廓指令信息两部分，描述字型轮廓的数据信息主要用于描述字型轮廓结构组成的贝塞尔曲线数据，字型轮廓指令信息主要用于根据屏幕分辨率动态修正调整字型轮廓结构，两者在Glyf中的存储空间的占比是根据指令信息量的不同而变化的，例如WINDOWS7的系统字体微软雅黑的两者占比通常为50%：50%。Glyf占据整个TTF文件的大约80%的容量，其中，针对每个字的glyf字型轮廓描述信息而言，根据字型复杂度和轮廓指令信息量，每个字大约需要200-400个字节左右的存储空间。

当读取TTF文件中的字型数据时，首先根据文件头得到描述表的个数，然后，遍历描述表目录，并提取描述表偏移量和描述表数据长度大小，最后根据偏移量和数据大小找到相应的数据，并读取该表中的数据。

本发明实施例将TTF文件的文件头以及轮廓数据Glyf之外的其他描述表划分为字体公有数据部分；轮廓数据Glyf是与每个字型相关的数据，将其划分为字体字型专属数据部分。

对于公有数据部分，在字库应用与手机时，由于手机中已经安装有默认字库，因此，公有数据无需分发，针对增加的字符，仅需在本地字库中根据编码动态增加公有数据中对应的索引数据即可。

服务器的公有数据部分中的索引值可以作为根据字符请求编码快速定位字型轮廓Glyf的专属数据的引导。

提取缺字的字型专属数据的过程（即字型专属数据提取子模块212执行的操作）如图6所示。该过程包括以下步骤：

1）读取文件头，获取三个表距离字库文件头的偏移量，这三个表即：Cmap（也即字符编码映射表）、Loca（也即记录字型轮廓数据距离字型轮廓数据表头偏移量以及该字型轮廓数据长度的表）、Glyf（也即记录字型轮廓数据表）；以“宋体--超大字符集”的SURSONG.TTF为例，该字库文件近7万字，TTF文件大小约40.5M，以缺字无法显示为例，该字符的字型大图请参见图4A-图4C，以该字UNICODE的UCS-4编码0X20000为例，在该字库TTF文件中，三个表距离字库文件头的偏移量分别为：

字符编码映射表'cmap'偏移量off=0x00001B94,数据长度len=30452字节，约3K；

字型数据定位表'loca'偏移量off=0x0275FDD8,数据长度len=262128字节，约255K；

字型轮廓数据表'glyf'偏移量off=0x00009288,数据长度len=40987400字节，约39M，即该字库中存放所有6万多字符字型轮廓数据的'glyf'表约占整个字库文件大小的96.3%。

2）偏移到“宋体-超大字符集”TTF文件中的Cmap中，按照升序顺序找到该字型编码0X20000与对应的Loca里记录GLYF中字型轮廓偏移量对应关系的序号，此处的字符编码映射关系为：

'cmap'Table-Character To Index Map

Seg142:startCharCode=00020000,endCharCode=00020005,startGlyphCode=28669

找到第142段Seg，该段记录了从0X20000至0X20005其中的startGlyphCode表示本段中字型轮廓的起始序号；

然后偏移到142段：

142.Char00020000->Index28669即为Loca里记录的该字在GLYF中的字型轮廓偏移量：

Char00020001->Index28670

Char00020002->Index28671

Char00020003->Index28672

Char00020004->Index28673

Char00020005->Index28674

3）然后根据这个序号，到Loca中顺序找到该序号对应的偏移值，该偏移值是距离Glyf中字型轮廓数据表头的偏移量。

'loca'Table-Index To Location Table

根据上述2）的'cmap'中第142段记录的映射关系：Char00020000->Index28669，在'loca'按照升序顺序找到Index28669对应的偏移量：

Idx28669->glyfOff0x00FD9B3E

即四字节缺字字符UNICODE的UCS-4编码0X20000，在Glyf中相对于Glyf头偏移0x00FD9B3E即可定位到。

4）通过到Glyf头的偏移量，加上Loca中记录的该字型轮廓数据的相对偏移量，即为该字型轮廓数据的实际存储头开始位置，结合每个字型轮廓起始位置头记录的该字型的轮廓数据的长度，即可提取出单个字符专属轮廓数据二进制段。

'glyf'Table-Glyph Data

Glyph20000:相对于'glyf'表头的偏移量off=0x00A96FBE字节,数据长度len=142字节；

即四字节缺字字符该字符的字型大图请参见图4A-图4C，UNICODE的UCS-4编码0X20000，在Glyf中相对于Glyf头偏移0x00FD9B3E即可定位到（Glyf距离整个字库的偏移量为0x00009288），那么该字距离整个字库文件头的偏移量为：Glyf偏移量0x00009288+本字的相对偏移量0x00FD9B3E=0XFE2DC6字节，这样，即可快速准确的定位到该字符，由于该缺字的字型轮廓长度为142字节，仅需下载142字节，即可完成针对该缺字的字型轮廓提取和下载，而无需将全部40M大字库进行下载；

数据长度142字节（包括字型轮廓贝塞尔曲线信息和轮廓调整指令信息）均以二进制形式出现，在提取的时候，按照原有的数据顺序存储即可。

重复上述步骤2）、步骤3）以及步骤4），直到遍历完所有的缺字字符的缺字请求为止。

为了便于多个缺字数据信息的下发，本发明实施例（可以利用打包模块22）在提取数据的过程中对被提取的数据进行打包处理，生成数据包，然后，再进行网络下发。数据打包的目的是为了将提取出来的数据(可能包含有不定个数的缺字字型专属数据的集合)组合成一个数据包，一方便数据的统一下发。为此，可以参考如下的数据结构：

首先是一个数据头（名称HEAD）：由传入字符总个数sNumOfCod以及预留位usOther组成，其结构如下：

然后是索引表，其中的每个元素为一个FONTGLYFDATAINDEX结构，该结构由当前传入缺字字符的编码类型uCodType、缺字字符编码dwCode、与此字型编码有关的实体二进制数据的存储位置dwOffset（该位置的起始位置为实体二进制数据的存储起始位置）以及字型二进制数据的长度sLenOfBin组成，其结构如下：

最后是所有实体二进制数据。上述数据头和索引表是为辅助实体二进制数据的数据结构。

打包完的数据可以使用开源的压缩算法进行压缩，以减小数据量。

多个提取后的缺字字型数据的打包过程继续如图6所示，主要包括以下步骤：

1）传入打包数据和相应的参数。本步骤传入的主要是本次提取的缺字用字型二进制数据和总字数。

2）根据传入的参数构造出索引参数。该索引参数的结构可以为：

{字符编码类型，提取后的缺字字符编码数据索引，dwOffset，传入数据长度}；

其中，dwOffset为当前偏移量。

一个具体的例子，传入字型索引为0X20000的字型专属数据，其长度为142个字节，则根据传入的参数构造出的索引参数如下：

{1，0X20000，dwOffset，142}；

其中，1表示为UNICODE编码，当新构造一个提取后缺字字型数据包时，当前偏移量累加，每次传入新的数据，当前偏移量在构造索引参数结束后，累加传入数据的长度。

在上述例子中，如果是首次构造数据包，则上述dwOffset的取值为0，在构造完当前索引参数后，更新为0+142，即142；即下一次构造索引单元时，dwOffset的取值为142。如果是第一次操作，还需要重置索引数组和数据数组。在构造完当前的索引参数后，将当前的索引参数追加到索引数组中，并且将对应的142个字节的数据，追加到二进制数据数组中，然后，更新偏移量为142；其中，数据数组为一个二进制数组，索引数组为索引结构的数组。

接下来，如果仍需要传入数据，则重复上述流程。

3）当所有数据传入完毕后，对数据进行整合。现有的数据分散在两个数据组中，需要将索引数组和二进制数据数组进行合并，并且加一个数据头，以组合成一个数据包。在上述例子中，可以构造出如下数据头：

{1,0}；

其中，1代表传入提取后的缺字字型数据的总个数，也就是说，共有1个需要索引的数据，保留项为0。

数据打包完成后，服务器（如数据分发模块23）便可以将数据包下发给接收端（也是申请端）。

步骤4、服务器（如数据下发模块23）向接收端下发上述数据包（如打包模块22生成的数据包），接收端（如解包模块30）对接收到的数据包进行解包处理后，提取数据包中的数据。

经过网络下发之后，数据需要进行解压缩，并进行规制解包才能够使用。解包的过程如图7所示。具体的，首先根据数据头中的传入字型数据总个数确定可以使用的索引数量；其中，数据的字符编码标识可以用于快速确定当前数据包中是否还有所需要的数据；接下来，遍历所有的索引，根据索引中数据的偏移量和数据的大小，从实体二进制数据中提取出对应的数据，其中，实体数据的起始位置为数据头的大小和所有索引的大小的总和；然后，结合索引中提供的类型变量和标识编码，共同确定提取出的数据，供后续使用。

步骤5、接收端（如本地字库追加模块31）将解包（如解包模块30解包）后的字型专属数据追加到本地字库，并使缺字得到正常显示。

在本实施例中，接收端（如本地字库追加模块31）中设置有缺字索引数据追加子模块311和缺字字型专属数据追加子模块312，这两个子模块分别用于在本地字库中追加缺字的索引数据以及在本地字库中追加缺字的字型专属数据。

如图8所示，经过解压缩和解包（如经过模块30解压缩和解包）处理后，应先依次读取解包后数据中的数据总个数以及可以使用的索引数量，然后，遍历所有的索引，根据索引中数据的偏移量和数据的大小以及索引对应的缺字字符编码，从实体二进制数据中提取出对应的数据。

一个具体的例子，缺字字符只有一个，即字符该字符的字型大图见图4A-图4C所示，其编码为UNICODE0X20000，模块30读取的数据如下：

{1,0}，

{1，0X20000，0，142}

{该字对应的二进制字型轮廓数据和指令数据}，见图5；

然后，参考服务器端字型专属数据提取子模块212，对本地已有TTF字库进行如下操作：

1）读取本地字库文件头，获取三个表距离该字库文件头的偏移量，即：字符编码映射表'cmap'表，字型数据定位表'loca'表，字型轮廓数据表'glyf'表；

2）先在Cmap中，根据上述读取的缺字字符的编码0X20000，按照顺序插入到Cmap映射表中，映射的一端是缺字字符的编码，另一端是Glyf字型轮廓序号，Glyf字型轮廓序号参照Loca里最后一个序号加1，这样就完成了Cmap的映射；

以本地字库目前主要是采用GB18030-2000约3万字的字库为例，按照顺序将在下述位置插入：

Seg141:startCharCode=0000FFE0,endCharCode=0000FFE5,

Seg142:startCharCode=00020000,endCharCode=00020005,

即第141段后，按照升序插入0X20000的字符映射：

141.Char0000FFE0->Index28663

Char0000FFE1->Index28664

Char0000FFE2->Index28665

Char0000FFE3->Index28666

Char0000FFE4->Index28667

Char0000FFE5->Index28668

142.Char00020000->Index28669//插入本条映射关系

3）然后到Loca中按照顺序新增该序号，即最后一个序号，该序号对应Glyf中存储的最后一个字型轮廓偏移量，即为新增字符对应的偏移量，并且两个相邻序号的字型轮廓偏移量相减即为上一个字型轮廓数据段的长度；如果是最后一个，则需要额外填写加上该字型轮廓信息长度的数据值；

在本例中，0X20000为当前最后一个缺字，因此，需要在最后增加模块30里读取的该字符的字型轮廓数据长度142字节；

Idx28668->glyfOff0x00FD9AAE

Idx28669->glyfOff0x00FD9B3E//此为最后一个字

Ends at0x00FD9B3E+142（0X8E）=0XFD9BCC；表示在0XFD9BCC结束最后一个GLYF字型轮廓数据；

4）通过上述步骤3)，Loca中确定的新增字符对应的偏移量加上Glyf头的偏移量，即为该字型轮廓数据的实际存储开始位置，结合Loca中记录的该字型的轮廓数据的长度，在这里将模块30解包处理后的数据数组中提取的单个字符轮廓数据复制即可，复制长度为上述解包处理后获得的索引数组中每个字型轮廓数据段的长度。

重复上述步骤2）、步骤3）以及步骤4），直到插入完所有解包处理过的缺字字符数据，这样，就完成了从服务器端获取缺字字符序列，并追加到本地字库中的全过程。

按照上述步骤，当遇到缺字字符如字符（该字符的字型大图见图4A-图4C），其编码为UNICODE0X20000，仅需从服务器端下载约150个字节，就可完成下载的缺字字型数据与本地字库的融合，且通过多次缺字申请，可以累加在本地字库内，而不需下载替换40M的整个大字库文件；这就大大节约了流量，减轻了移动终端（如手机）网络负载，提高了移动终端（如手机）的响应速度，大大降低了移动终端中字库数据的冗余量，节省了移动终端的存储空间，降低了避免缺字实现方式的使用难度，完全达到了缺字时按需实时分发的目的。

显然，本领域的技术人员应该明白，上述本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种文字处理方法，其特征在于，包括：

服务器通过移动通信网络接收到来自移动终端的编码序列；

所述服务器从所述编码序列中解析得到字符编码类型、字符编码和字体类型信息；

所述服务器从所述字符编码类型对应的字库的公有数据部分中，获取所述字符编码的索引，并根据所述索引从所述字符编码类型对应的字库的字型专属数据部分中获取所述字体类型信息所对应的字型专属数据；

所述服务器将所述字型专属数据通过所述移动通信网络发送给所述移动终端。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述移动终端从应用中获取字符的字符编码类型、字符编码以及字体类型信息；

所述移动终端根据所述字符编码类型、字符编码以及字体类型信息确定缺字字符；

所述移动终端根据所述字符编码类型、所述字符编码以及所述字体类型信息构建所述编码序列，并将该编码序列通过移动通信网络发送给服务器；

其中，所述确定缺字字符包括：

所述移动终端在本地找不到所述字符编码类型的字库；或者

所述移动终端在本地找到所述字符编码类型的字库，但在该字库的公有数据部分中找不到所述字符编码的索引；或者

所述移动终端在本地找到所述字符编码类型的字库，且在该字库的公有数据部分中找到所述字符编码的索引找到所述索引，但根据所述索引从所述字库的字型专属数据部分找不到所述字体类型信息所对应的字型专属数据。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

所述移动终端将所述服务器发送来的字型专属数据作为所述汉字返回到所述应用中。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

所述移动终端将所述服务器发送来的字型专属数据加入到本地的所述字库的字型专属数据部分，并将其与本地的所述字库的公有数据部分中的字符编码的索引相关联。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

在移动终端本地的所述字库的公有数据部分中没有所述字符编码的索引的情况下，将所述字符编码加入本地字库的公有数据部分中，并为该字符编码建立索引。

6.根据权利要求4所述的方法，其特征在于，所述方法还包括：

在移动终端本地没有所述字符编码类型的字库的情况下，创建该字符编码类型的字库，并将所述字符编码加入创建的字库的公有数据部分中，并为该字符编码建立索引，再将该创建的字库加入到移动终端的本地字库中。

7.根据权利要求2所述的方法，其特征在于，所述服务器将所述字型专属数据通过所述移动通信网络发送给所述移动终端包括：

所述服务器以数据包的形式将所述字型专属数据通过所述移动通信网络发送给所述移动终端，且所述数据包包括：数据头、字型专属数据索引表以及字型二进制数据；

其中，

所述字型数据头包括：新增字符个数、字符编码类型以及所述新增字符序号；

所述字型专属数据索引表包括一个或多个用于定位一个字符的字型二进制数据的索引，所述索引包括：字符编码、偏移量以及每个字型轮廓数据段的长度；

所述字型二进制数据包括：贝塞尔曲线和轮廓点。

8.根据权利要求7所述的方法，其特征在于，所述服务器以数据包的形式将所述字型专属数据通过所述移动通信网络发送给所述移动终端包括：

建立字型轮廓索引数组和字型轮廓数组；

根据各字符的字符编码、字型轮廓数据在字型轮廓数组中的偏移量以及字型轮廓数据的长度值形成各字符的索引值，并存储在字型轮廓索引数组中；

根据所述字型轮廓索引数组中的索引值，将对应的字型轮廓数据追加到字型轮廓数组中，并更新字型轮廓索引数据组中的偏移量和长度值；

为所述索引数组和数据数组设置数据头，形成所述数据包。

9.一种文字处理系统，其特征在于，所述系统包括服务器，且所述服务器包括：

请求处理分配模块，用于通过移动通信网络接收到来自移动终端的编码序列，并从所述编码序列中解析得到字符编码类型、字符编码和字体类型信息；

数据提取模块，用于从所述字符编码类型对应的字库的公有数据部分中，获取所述字符编码的索引，并根据所述索引从所述字符编码类型对应的字库的字型专属数据部分中获取所述字体类型信息所对应的字型专属数据；

数据下发模块，用于将所述字型专属数据通过所述移动通信网络发送给所述移动终端。

10.根据权利要求1所述的系统，其特征在于，所述系统还包括：移动终端，且所述移动终端包括：

缺字判断和请求模块，用于从应用中获取字符的字符编码类型、字符编码以及字体类型信息，根据所述字符编码类型、字符编码以及字体类型信息确定缺字字符，根据所述字符编码类型、所述字符编码以及所述字体类型信息构建所述编码序列，并将该编码序列通过移动通信网络发送给服务器；

其中，所述确定缺字字符包括：

所述缺字判断和请求模块在本地找不到所述字符编码类型的字库；或者

所述缺字判断和请求模块在本地找到所述字符编码类型的字库，但在该字库的公有数据部分中找不到所述字符编码的索引；或者

所述缺字判断和请求模块在本地找到所述字符编码类型的字库，且在该字库的公有数据部分中找到所述字符编码的索引找到所述索引，但根据所述索引从所述字库的字型专属数据部分找不到所述字体类型信息所对应的字型专属数据。

11.根据权利要求10所述的系统，其特征在于，所述移动终端还包括：

本地字库追加模块，用于将所述服务器发送来的字型专属数据加入到本地的所述字库的字型专属数据部分，并将其与本地的所述字库的公有数据部分中的字符编码的索引相关联。

12.根据权利要求10所述的系统，其特征在于，所述服务器还包括：

数据打包模块，用于以数据包的形式将所述字型专属数据通过所述移动通信网络发送给所述移动终端，且所述数据包包括：数据头、字型专属数据索引表以及字型二进制数据；

其中，

所述字型数据头包括：新增字符个数、字符编码类型以及所述新增字符序号；

所述字型专属数据索引表包括一个或多个用于定位一个字符的字型二进制数据的索引，所述索引包括：字符编码、偏移量以及每个字型轮廓数据段的长度；

所述字型二进制数据包括：贝塞尔曲线和轮廓点。