SQLite FTS5乌克兰语前缀搜索因西里尔/拉丁i编码差异匹配失效

问题现象 #

在SQLite 3中创建FTS5虚拟表存储书籍标题数据，初始建表语句：

CREATE VIRTUAL TABLE books_fts USING fts5(title, content='');

执行全文检索SQL：

SELECT rowid FROM books_fts WHERE title MATCH ?;

测试发现：

• 传入前缀参数усмi*、ночiв*时无任何匹配结果
• 传入усм*、ноч*时可以正常匹配到词条Усмiшки、Ночiвля对应的rowid
  最初怀疑是SQLite FTS5存在bug或操作失误。

排查过程 #

第一步：命令行复现测试 #

在SQLite 3.31.1命令行环境下执行复现脚本：

sqlite3 fts.db
SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> DROP TABLE IF EXISTS books_fts;
sqlite> CREATE VIRTUAL TABLE books_fts USING fts5(title, content='');
sqlite> INSERT INTO books_fts (rowid, title) VALUES (1, 'Усмiшки');
sqlite> INSERT INTO books_fts (rowid, title) VALUES (2, 'Ночiвля');
sqlite> SELECT rowid FROM books_fts WHERE title MATCH 'усм*';
1
sqlite> SELECT rowid FROM books_fts WHERE title MATCH 'усмi*';
1
sqlite> SELECT rowid FROM books_fts WHERE title MATCH 'ноч*';
2
sqlite> SELECT rowid FROM books_fts WHERE title MATCH 'ночiв*';
2
sqlite> .q

命令行下所有前缀检索均正常，初步判断为业务代码侧编码问题。

第二步：根因确认 #

进一步排查定位到核心原因：

• 数据库中存储的视觉上类似i的字符，是2字节的西里尔小写字母і（UTF-8编码0xd196）
• 业务代码传入搜索参数中的i，是1字节的拉丁小写字母i（UTF-8编码0x69）
  两个字符视觉几乎无差别，但编码完全不同，导致前缀匹配失效。
  尝试调整分词器配置：

CREATE VIRTUAL TABLE books_fts USING fts5(title, content='', tokenize = 'unicode61 remove_diacritics 2');

测试后发现该配置仅对拉丁字母变音符号生效，无法处理西里尔字符和同形拉丁字符的匹配问题。

可行解决方案 #

方案1：业务层做字符归一化（推荐，成本最低） #

不需要修改数据库结构、不需要加载额外扩展，只需要在搜索参数传入MATCH语句之前，加一层同形字符映射逻辑：

• 针对当前场景，直接把搜索参数里的拉丁i（编码0x69）替换为西里尔і（编码0xd196），即可正常匹配存量数据
• 如果后续需要覆盖更多易混场景，可以扩展同形字符映射表，把西里尔а/拉丁a、西里尔е/拉丁e等视觉高度相似、容易输入混淆的字符对都加入映射规则，统一把入库文本和搜索参数转换为同一套字符标准即可。
  这个方案上线最快，没有兼容风险，适合绝大多数业务场景。

方案2：自定义FTS5分词器 #

如果不想在业务层散放字符处理逻辑，可以开发自定义FTS5分词器：

• 在分词逻辑里内置同形字符归一化规则，建索引和检索分词时，都把同形的不同编码字符统一映射为同一个标准字符
• 匹配逻辑完全在数据库侧完成，业务层不需要额外处理，性能更好，但需要开发SQLite扩展，开发和部署成本略高。

方案3：使用ICU分词器配置字符折叠 #

如果你的SQLite环境支持加载ICU扩展，可以切换到FTS5的icu分词器，通过配置ICU的字符归一化规则，实现同形字符的自动折叠匹配。注意默认的ICU规则不会自动做西里尔和拉丁同形字符的映射，需要自定义规则集，配置复杂度较高，适合有多语种复杂归一化需求的场景。

注意：unicode61分词器的remove_diacritics参数仅处理拉丁字母的变音符号移除，没有跨语系同形字符映射的能力，不需要在这个参数上继续调试。

内容的提问来源于stack exchange，提问作者Serguei Vine