SQL Server LIKE语句单Unicode字符匹配正常 多字符匹配无返回结果

这个问题本质是SQL Server处理希伯来语这类从右到左（RTL）书写的Unicode字符时的排序规则匹配逻辑问题：

• 执行单字符模糊匹配时，逻辑仅校验字段中是否存在对应单个Unicode码位的字符，不涉及连续字符的顺序判定，因此N'%ב%'可以正常返回命中结果。
• 执行多字符模糊匹配时，如果字段使用的是Hebrew_CI_AS这类带语义解析的非二进制希伯来语排序规则，会出现两类典型异常：
  1. 错误判定RTL字符的连续顺序，将实际存储顺序符合要求的字符序列判定为顺序不匹配；
  2. 这类排序规则的单字符匹配会自动忽略希伯来语附带的隐形元音标记、重音组合符，但多字符连续匹配时，夹在两个可见字符中间的隐形组合符会直接打断连续匹配逻辑，导致无法命中记录。
• 低概率诱因是查询编辑器的RTL自动排版功能，导致你视觉上看到的匹配串字符顺序，和SQL常量实际存储的字符顺序相反，最终匹配失败。

• 优先使用二进制排序规则做匹配，直接按字符实际存储的字节序列校验，跳过排序规则的语义解析，从根源避免顺序误判问题，写法如下：

SELECT ...
FROM ...
WHERE FIELD LIKE N'%בו%' COLLATE Hebrew_BIN2;

注意：二进制排序规则默认严格区分大小写、区分重音与附加符号，若需要实现不区分大小写的匹配，可先将字段值和匹配串统一转换为大写/小写后再执行匹配。

• 若不希望更换匹配时的排序规则，可先通过UNICODE()函数逐位解析目标字段中对应记录的字符编码，确认两个可见希伯来字符之间是否夹带隐形组合控制字符：如果存在，可在匹配串中补入对应隐形字符，或提前清洗字段值、移除所有希伯来语特殊控制字符后再做匹配。
• 编写RTL语言的匹配常量后，可逐位打印常量的字符编码，确认实际存储的字符顺序和字段内的存储顺序一致，避免编辑器自动排版导致常量顺序错误。

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