4

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

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

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

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

在此处输入图像描述

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

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

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

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

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

2 回答 2

4

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

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

让我们使用一个希伯来语单词，对于非希伯来语使用者来说，其方向比文本中指定的字符串更清楚：

上一页

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

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

于 2012-04-24T15:38:21.383 回答
1
  1. 我相信 C# 中的所有字符串都会在内部存储为 LTR；RTL 字符串将有一个不可打印的字符（或其他东西），表示它们确实是 RTL。
  2. 很有可能。例如，RTL GUI 和渲染文本需要设置某些属性（特别是 RightToLeft 和 RightToLeftLayout）才能正确显示。
  3. NUnit 不应该。它也不应该在意。恕我直言，一个反转的字符串！=原始字符串。
  4. 我无法发表评论。我假设它们应该是测试所期望的，假设它一开始就通过了。
  5. 不要用 RTL 做一半的措施，它真的不喜欢它。要么有完整的 RTL 支持，要么没有。这可能很糟糕，祝你好运！
于 2012-04-24T14:50:35.243 回答