从SQLite数据库查询日语字符失败问题排查与解决

我来帮你分析这个问题——你遇到的情况在处理Unicode字符的SQLite查询里很常见，核心问题大概率和字符匹配规则或者Unicode规范化有关，下面具体拆解：

可能的原因 #

1. SQLite默认的LIKE是字节层面的BINARY匹配 #

SQLite的LIKE运算符默认使用BINARY排序规则，也就是说它会直接对比字符串的字节序列，而不是字符的语义。日语里有些字符存在两种Unicode编码形式：

• 预组合字符（比如「べ」是单个U+3079）
• 组合字符（比如「へ」+ 浊音符号「゙」，也就是U+3078 + U+3099）

这两种形式显示出来完全一样，但字节序列不同，用BINARY匹配就会直接判定为不相等，导致查不到结果。

2. 字符串字面量的编码传递问题 #

如果你的SQL语句是直接拼接的（比如"SELECT * FROM entry WHERE wordJP LIKE '" + word + "'"），Java在把这个字符串发送给SQLite的过程中，可能出现编码转换的偏差——虽然全表查询能显示正确，但拼接的字面量可能在字节层面和数据库存储的不一致。

解决方法 #

优先尝试：使用参数化查询 + 统一Unicode规范化 #

这是最稳妥的方案，能同时解决编码传递和规范化问题：

1. 用PreparedStatement绑定参数：避免直接拼接SQL，让Java正确处理字符串的编码传递：

   String sql = "SELECT * FROM entry WHERE wordJP LIKE ?";
   try (PreparedStatement pstmt = yourConnection.prepareStatement(sql)) {
       // 查询前先统一规范化字符串
       String normalizedQuery = Normalizer.normalize("食べる", Normalizer.Form.NFC);
       pstmt.setString(1, normalizedQuery);
       ResultSet rs = pstmt.executeQuery();
       // 处理查询结果
       while (rs.next()) {
           // 读取数据
       }
   } catch (SQLException e) {
       e.printStackTrace();
   }
   

2. 存入数据库时也做同样的规范化：确保存储的字符串和查询的字符串用相同的Unicode形式（比如NFC）：

   String normalizedWord = Normalizer.normalize(originalJapaneseWord, Normalizer.Form.NFC);
   // 把normalizedWord存入数据库
   

备选方案：指定Unicode排序规则 #

如果你的SQLite版本支持ICU扩展（很多发行版默认包含），可以在查询时显式指定Unicode排序规则，让LIKE按字符语义匹配，而不是字节：

SELECT * FROM entry WHERE wordJP LIKE '食べる' COLLATE UTF8_GENERAL_CI;

这个规则会忽略Unicode规范化的差异，直接按字符的语义进行匹配。如果你的SQLite没有ICU支持，可能需要重新编译SQLite并启用SQLITE_ENABLE_ICU选项。

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