[发明专利]用于处理字符流的方法与设备

说明书

本专利申请涉及根据35USC§119(e)要求其优先权的2005年6月21日提交的美国临时申请No.60/692,683，该临时申请的全部内容都被包括于此。

技术领域

本发明的一个或多个实现涉及用于处理字符流的方法与设备

背景技术

文本处理应用用于处理按照特定的字符编码方案的规约被编码成字符串或字符流的文本数据。长期以来，很多已开发的文本处理应用都是基于固定长度，单字节的字符编码方案，例如，ASCII和EBCDIC。此外，涉及各种欧洲语言或非罗马字母的文本数据的文本处理应用可使用ISO 8859的8位扩展的ASCII的方案之一。另外，一些可供选择的变长编码方案被用于中文，日文和韩文的应用。

Unicode正逐渐地被用作可能需要调整和/或组合不同来源的文本的文本处理应用的基础。Unicode字符集被设计为包括世界各地语言的字符，同时也包括来自用于数学，音乐和其他应用领域的正规符号系统的一些附加的字符。众所周知，UTF-8，UTF-16和UTF-32分别是基于8位，16位，32位代码单元的三种基础的Unicode编码方案。特别地，UTF-8是每个字符需要一至四个8位代码单元的一种变长编码方案；UTF-16是每个字符通常需要单个16位代码单元的编码方案(有些不常用的字符需要两个代码单元)；以及UTF-32是每个字符需要单个32位代码单元的定长编码方案。UTF-16和UTF-32具有一些被称为UTF-16LE，UTF-16BE，UTF-32LE和UTF-32BE，这取决于代码单元内的字节排序规约。

尽管Unicode允许应用和来自许多不同资源的字符流间的相互操作，与已往基于8位字符编码方案的应用相比在处理效率上要付出一定成本。该成本在以为了实现期望的吞吐量所需的额外硬件、执行对特定字符流的应用的额外能耗，和/或一应用完成处理的所用的额外执行时间的形式表现出来时会变得很明显。

应用还可能要求将数据流的内容根据基于文本的符号系统的词法和/或者句法的规约结构化。存在很多这样的规约，范围从用于各种操作系统的简单的面向行的结构规约，到用于将计算机程序表示为源语言文本的正规程序语言文法。特别重要的是，XML作为用于编码文档和各种数据的一种标准的基于文本的标记语言的使用不断增加。在每种情况下，强加结构化信息可能会相当程度上增加对相关文本处理应用的资源需求。

一般而言，现有技术的高速文本处理用了顺序的一次一个字符(或一次一个字节)的处理，通常用C程序语言来编写。例如，XML和Unicode串处理的许多现有技术教授了顺序字符处理方法的使用。标准计算科学教科书也是这样处理解析、词法分析和文本处理应用的。

在现有技术中，有三种用于实现文本处理应用的基本技术。第一种基本技术是使用了迭代循环(例如，while循环)和分支指令(例如，if语句)来执行基于特定的字符或字符类的条件动作的手编实现。第二种基本技术是第一种变形，其中对不同字符或字符类的不同逻辑的分解是通过转移表来处理的(例如，case语句)。第三种基本技术是将有限状态机形式的表的使用系统化。有限状态机实现来源于串处理的标准理论技术；也就是用正则表达式文法来表示字符和词法语法，以及用有限自动机来识别与这些文法匹配字符串。当状态的数量和每个状态潜在字符转换的数量适度小时有限状态机技术可以给出有效实现；例如涉及7位位的ASCII处理应用每个状态需要至多128个条目。然而，基于UTF-16的16位表示的有限状态机的一次简单实现都需要每个状态64,000个条目以上。因此，对于任何复杂的状态空间，这很快被禁止。

工业标准处理器已演化为8位，16位和32位的体系结构。另外，字符编码方案已从扩展的ASCII的8位表示演化为16和32位的UTF16和UTF32表示。经过了处理器体系结构和字符编码方案的这种演化，处理器的性能和一次一字符处理的要求之间有了大致匹配。