纠正C＃中的希伯来字符序列和可搜索的PDF

Question

我正在测试从可搜索的PDF中提取文本的SDK。最近更新了SDK的一个依赖项，它导致对希伯来语文本的现有测试失败。我不知道希伯来语，也不知道所涉及的技术如何代表从右到左的语言。

NUnit测试声明提取的文本与C＃字符串“מנבוצץז”匹配。

 string hebrewText = reader.ReadToEnd();
 Assert.AreEqual("מנבוצץז ", hebrewText);

光栅化PDF具有我认为相同的字符，但顺序相反。

单元测试失败并显示以下消息：

  

预计：“מנבוצץז”

     

但是：“זץצובנמ”

虽然实际结果与我在光栅化PDF中看到的更接近，但我并不完全确定原始测试是错误的。

1. C＃字符串中的希伯来字符是否应该像打印的希伯来文一样从右向左读取？
2. .NET堆栈的任何部分是否会篡改希伯来字符串的方向？
3. NUnit怎么样？
4. 嵌入在可搜索PDF中的希伯来字符通常应该与光栅化文本的方向相同吗？
5. 在决定是否“修复”此单元测试之前，我应该知道的其他任何事情？

Answer 1

有多种方法可以编码RTL语言。最常见的方式（和Window的默认方式）是使用逻辑排序，这意味着第一个字母被编码为字符串（或文件）中的第一个字符。因此，无论是在视觉上第一个字母出现在屏幕的左侧还是右侧，都不会影响它们的存储顺序。

现在，对于Visual Studio中出现的文本，它取决于版本。据我所知，在Visual Studio 2010之前，代码编辑器向后显示了希伯来语，很明显，当你试图选择希伯来语文本时，它以奇怪的方式反转（这在视觉上令人困惑）。 Visual Studio 2010似乎不再存在这个问题（至少我刚刚测试过SP1）。

让我们看一个希伯来语，非希伯来语使用者的方向比你文本中指定的字符串更明确：

  

יון

这个词恰好是希伯来语中的一个词，在你的屏幕上，它应该显示为三个字母，其中最高的字母在左边，最短的字母在右边。在.NET字符串中，表达式"יון".Substring(0, 1)将生成短字母，因为它是字符串中的第一个字母。该字符串也可以写为"\u05D9\u05D5\u05DF"，其中最左边的Unicode字符\u05D9表示右侧显示的短字母，这清楚地表明了字母的存储顺序。

由于您的测试用例中的字符串是荒谬的，我无法告诉您这是否是一个错误的测试，或者它是否应该通过正确的测试。如果您上传的图片已正确呈现，则表明您的测试的实际结果是正确的并且预期值不正确，因此您应该修复该测试。

Answer 2

1. 我相信C＃中的所有字符串都将作为LTR存储在内部; RTL字符串将具有不可打印的字符（或其他内容），表示它们确实是RTL。
2. 很可能。例如，RTL GUI和渲染文本需要设置某些属性（特别是RightToLeft和RightToLeftLayout）才能正确显示。
3. NUnit不应该。它也不应该关心。恕我直言！反向字符串！=原始字符串。
4. 我无法发表评论。我认为它们应该是测试期望的任何东西，假设它首先通过。
5. 不要用RTL做一半的措施，它真的不喜欢它。要么有完整的RTL支持，要么没有。它可能非常讨厌，祝你好运！