查询SQL表中从右向左的标记

我有一个大型本地化系统，包含26种语言的翻译，其中两种是从右向左（阿拉伯语和希伯来语）。测试在软件交付物中发现了一些有缺陷的字符串，这些字符串可以追溯到翻译人员（不包括字符串中适当位置的RTL标记）。当时我正好在我的IDE中，并使用EF编写了一个快速控制台应用程序，以生成一个最近翻译的所有字符串的列表，这些字符串缺少生成器（\u200f），以加快调查，因为并非所有字符串都需要它们

为了将其添加到我们的QA过程中，我想创建一个存储过程来执行查询。就我的一生而言，我无法让它工作，也无法找到任何关于查询角色的文档

我发现RTL标记是Unicode代码点中的NCHAR（8207）或十六进制中的NCHAR（0x200F）。我的数据库排序规则是SQL\u Latin1\u General\u CP1\u CS\u AS

但是，类似以下情况的查询：

declare @RTLM nchar
set @RTLM = NCHAR(8207)


  SELECT [Translation]
  FROM [dbo].[Translations]
  where Translation like '%' + @RTLM +'%'

GO

返回表中的每个字符串，无论它是否包含RTL标记。如果我在查询中查找可打印的字符，则相同的查询可以正常工作。十六进制版本NCHAR（0x200F）也存在相同的行为

---

有人对可能发生的事情有什么想法吗？

疯狂地猜测，这可能是SQLServer操作员的限制，就像那些特殊字符一样

---

作为替代方法，我建议您使用CHARINDEX函数而不是LIKE运算符重写查询

标记是否出现在PARISTED字符串的任何位置？或者它应该只出现在乞讨（或结尾）。。。你试过只用一个%来看看会发生什么吗？另一件要测试的事情是在你的每个字符串上都有那个（不可见的）字符（例如，你的前端可能正在做的事情）。。。您是否尝试用select上的另一个可见字符替换此字符，只是为了检查返回的行是否确实不包含此字符？我可以确认，用可见的、可打印的字符替换不会产生字符串替换，并且在代码中处理它（例如，使用EF作为ORM的c#console应用程序不会在任何没有EF的字符串中检测到\u200f（包括英语字符串和23种其他非RTL语言的字符串）。我应该更清楚地说，上面的查询返回表中的每个条目，甚至是非RTL字符串（212000个字符串）。如果重新编写它而不使用LIKE，而是使用CHARINDEX呢？疯狂猜测原因可能是LIKE运算符具有这些特殊字符的限制。结果很有趣，但仍然没有成功。将where子句重写为where CHARINDEX（@RTLM，[翻译]）>0会导致从表中仅返回76个字符串。如果为True，则所有76个字符串都具有RTL标记（在C#app中确认），但查询中不会返回其他2500多个具有RTL标记的字符串。Marcelo上面的注释相同。使用CHARINDEX>0会返回总共76个字符串（有2500多个具有RTL标记）.>=返回数据库中的所有字符串。CHARINDEX的MSDN文档状态：如果在字符表达式中找不到搜索字符表达式，则此函数返回0。它基于1，而不是基于零。我想答案在于找到将返回的76行与包含R它上面的TL char…可能是RTL在字符串上的位置？或者特殊字符出现的次数？在检测到的和未检测到的结果中都只是一个实例。位置不同，结果集中存在交集（在一个字符串中检测到字符7处带有RTL标记的字符串，但在另一个字符串中未检测到）在这一点上，我只是要接受性能的打击，并在代码中这样做，因为它是100%准确的，SSMS在尝试在SQL中这样做时留下了很多需要改进的地方。我应该提到的是，我用十六进制编辑器做我的所有分析。十六进制中的RTL标记是E280 8f。所有结果都在记事本++十六进制编辑插件中确认。好的，正如你所看到的在谈到生产环境时，我鼓励您通过代码解决问题（如果这是一个可行且经确认的解决方案）。如果我遇到任何有助于进一步澄清此问题的内容，我将在此处发布，以供将来和其他人参考。。。