文本搜索解析器负责把未处理的文档文本划分成记号并标识每一个记号的类型,而可能的类型集合由解析器本身定义。一个解析器完全不会修改文本 — 它简单地标识看似有理的词边界。因为这种有限的视野,对于应用相关的自定义解析器的需求就没有自定义字典那么强烈。目前本数据库中只提供了一种内建解析器,它已经被证实对很多种应用都适用。
内建解析器被称为pg_catalog.default
。它识别 23 种记号类型,如表1所示。
表1 默认解析器的记号类型
别名 | 描述 | 例子 |
| 单词,所有 ASCII 字母 |
|
| 单词,所有字母 |
|
| 单词,字母和数字 |
|
| 带连字符的单词,所有 ASCII |
|
| 带连字符的单词,所有字母 |
|
| 带连字符的单词,字母和数字 |
|
| 带连字符的单词部分,所有 ASCII |
|
| 带连字符的单词部分,所有字母 |
|
| 带连字符的单词部分,字母和数字 |
|
| Email 地址 |
|
| 协议头部 |
|
| URL |
|
| 主机 |
|
| URL 路径 |
|
| 文件或路径名 |
|
| 科学记数法 |
|
| 十进制记数法 |
|
| 有符号整数 |
|
| 无符号整数 |
|
| 版本号 |
|
| XML 标签 |
|
| XML 实体 |
|
| 空格符号 | (其他不识别的任意空白或标点符号) |
解析器的“字母”的概念由数据库的区域设置决定,具体是lc_ctype
。只包含基本 ASCII 字母的词被报告为一个单独的记号类型,因为有时可以用来区别它们。在大部分欧洲语言中,记号类型word
和asciiword
应该被同样对待。email
不支持 RFC 5322 定义的所有合法 email 字符。具体来说,对 email 用户名被支持的非字母数字字符只有句点、破折号和下划线。
解析器有可能从同一份文本得出相互覆盖的记号。例如,一个带连字符的词可能会被报告为一整个词或者多个部分:
SELECT alias, description, token FROM ts_debug('foo-bar-beta1');
alias | description | token
-----------------+------------------------------------------+---------------
numhword | Hyphenated word, letters and digits | foo-bar-beta1
hword_asciipart | Hyphenated word part, all ASCII | foo
blank | Space symbols | -
hword_asciipart | Hyphenated word part, all ASCII | bar
blank | Space symbols | -
hword_numpart | Hyphenated word part, letters and digits | beta1
这种行为是值得要的,因为它允许对整个复合词和每个部分进行搜索。这里是另一个例子:
SELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');
alias | description | token
----------+---------------+------------------------------
protocol | Protocol head | http://
url | URL | example.com/stuff/index.html
host | Host | example.com
url_path | URL path | /stuff/index.html