在上一节里面,我们讨论了什么是双向文字以及两个重要的概念:逻辑顺序(Logical order)和视觉顺序(Visual order)。本章我们详细了解下,Bidi算法。
Bidi的算法
在“Unicode Standard Annex #9”中具体描述了UniBidi的具体实现。UniBidi的核心的逻辑包含3个方面:
- 按照语言信息,识别字符类型(分为强类型、弱类型和中性类型)
- 字符重新排序
- 分析镜像
在具体的实现过程中,UniBidi首先把文字按照段落划分,然后再根据条件划分为行,最后对每行进行双向文字的识别和处理。除UniBidi 外,还有四种其他的算法,分别是ICU
、PGBA算法、FriDidi算法和HaBi算法。
ICU 是Unicode 国际化组件,它是由IBM维护开源项目,是一个跨平台的多文件处理函数库。ICU布局引擎是ICU中独立的模块结构,用于处理复杂的文本语言。ICU 和UniBidi很相似,它实际上采用了UniBidi的字符重排算法。
PGBA 算法主要对隐式的文本进行双向文字的处理,它不采用Unicode的显示标注,不能对这些标注进行处理,它的特点是功能比较多,但是使用不方便,不具备通用性。
FriDidi是另外一个和UniBidi很相似的算法,本质就是一个具有图形界面的UniBidi算法。HaBi也是一样,实际上就是用Haskell98来描述UniBidi而已。综上所述,Unicode 的Bidi算法是目前最主要是双向文字处理算法。接下来我们详细分析Bidi算法,了解其优缺点。
基本概念
UniBidi扩展了目前已采用的一些现有实现中的隐式模型,并为特殊情况添加了显式的格式码。在大多数情况下,没有必要再包含额外的文本信息来获取正确的显示顺序。然而,在双向文本的情况下,对于有些情况,一个隐式的双向排序不足以产生可以理解的文本。为了处理这些情况,则定义一个方向格式码的最小的集合,来控制渲染时字符的顺序。这样则可以对显示顺序进行精确的控制以完成清晰的互换,并可以确保用于像文件名或者标签这样的简单项目的纯文本总是可以被正确的排序来显示。
方向格式码仅仅被用来改变文本的显示顺序。在其他所有方面它们应该被忽略掉——它们不影响文本的比较或者断字,解析,或数值分析。每个字符都有一个隐式双向类型。双向类型left-to-right和 right-to-left被称为强类型,具有这些类型的字符被称为强方向字符。与数字相关的双向类型被称为弱类型,具有这些类型的字符被称为弱方向字符。除了方向格式码,剩下的双向类型和字符被称为中性。此算法在文本中依据字符的隐式双向类型以达到对文本的合理的排序显示。
当使用双向文本的时候,字符仍然解释为逻辑顺序,只有显示时会被影响。双向文本的显示顺序依赖于文本中字符的方向属性。注意,有一些重要的安全问题与双向文本相关联:请参考[UTR36]来获取更多信息。
方向格式码仅仅被用来改变文本的显示顺序。在其他所有方面它们应该被忽略掉——它们不影响文本的比较或者断字,解析,或数值分析。每个字符都有一个隐式双向类型。双向类型left-to-right和 right-to-left被称为强类型,具有这些类型的字符被称为强方向字符。与数字相关的双向类型被称为弱类型,具有这些类型的字符被称为弱方向字符。除了方向格式码,剩下的双向类型和字符被称为中性。此算法在文本中依据字符的隐式双向类型以达到对文本的合理的排序显示。
当使用双向文本的时候,字符仍然解释为逻辑顺序,只有显示时会被影响。双向文本的显示顺序依赖于文本中字符的方向属性。注意,有一些重要的安全问题与双向文本相关联:请参考[UTR36]来获取更多信息。