匹配器

让我们再来回顾一下组包的核心流程:

1. 选中报文文档的根节点

• 从上到下遍历组包样式定义,检查其匹配器是否与当前报文节点匹配。

匹配器描述了一条规则,kyou以此来分出"满足规则的报文节点"和"不满足规则的报文节点"。

匹配器的语法灵感来源于jquery的选择器,总体上看起来与jquery选择器非常类似。但本质上是完全不同的。

• field
  所有报文域节点均满足匹配要求

• struct>field
  所有父节点是报文结构的报文域均满足匹配要求

• #Name
  所有名称为Name的报文节点均满足匹配要求

• field[type='int']
  所有type属性为int的报文节点均满足要求

• array:empty
  所有报文数组节点,并且其内容为空

• struct#HEAD struct>field[type='string']
  一个比较复杂的匹配器,表示的是"一个位于结构中的报文域,其type属性为string,并且一定要有一个名为HEAD的报文结构作为祖先节点"。

jquery是"选择器"(selector),而kyou是"匹配器"(matcher)。当几个条件并列时,jquery会先在整棵dom树中_选择_出满足前面规则的节点,再从这些节点中_选择_出满足后面规则的节点。而kyou做的是检查给定的一个节点是否满足要求。

这造成的最典型的区别是,jquery中几个并列的规则,前后是包含关系;而kyou中并列的规则之间是单纯的"与"的关系。或者说,jquery选择器中,并列写在一起的各个规则是有顺序的,而kyou中并列写在一起的规则之间是无顺序的。

举一个例子如下:

struct#name:first

jquery的规则是先从整棵报文树中选择出struct类型的节点,再从中选择出名称为name的节点,再从这个列表中取出第一个。

而kyou不同,在组包时kyou首先会拿到一个待组包的报文节点,然后再去检查这个节点是不是struct、是不是名称为name,是不是结构中的第一个节点,只要这三个条件中有一个失败则返回匹配失败。

绝对路径匹配器匹配路径与

绝对路径匹配器不支持与任何其它匹配器结合使用。

匹配节点类型。

支持如下四种节点类型:

• document
  匹配报文文档根节点。

• field
  匹配报文域节点。

• struct
  匹配报文结构节点

• array
  匹配报文数组节点

属性匹配器检查当前正被组包的节点,判断其指定的属性是否满足属性匹配器的要求。

语法为[<属性名><运算符>'<属性值>']

其中,如果属性名满足的规则,则可直接写。否则必须写成一个字符串。

属性值必须写成字符串形式。

单独的匹配器不可能完全描述清楚实际的需求,实际运用中一定会把多个匹配器结合起来,并且需要有"与"和"或"之类的关系。

kyou支持把多个匹配器按照不同的业务逻辑结合在一起。把两个匹配器结合在一起的匹配器,kyou称之为"管道匹配器",对应的符号称之为"管道符"。

目前kyou支持的管道符列表参见全部管道匹配器列表。

管道匹配器之间是有优先级的。优先级如下:

• 并列写在一起的,表示"且"的关系,优先级最高
• 其余管道符的优先级一样高,从左向右计算
• 表示"或"关系的逗号,优先级最低

全部匹配器列表

Add a custom footer