错误 - 在右-to-左文本环境中的箭头方向

功能
1

这与 Discourse 中的 bidi 设置无关。

当我输入 -\u003e 时，它会被转换为箭头字符 →，因此 A -\u003e B 会渲染为“A -\u003e B”。很酷。

但是，在 RTL 文本中，箭头方向是错误的：א -\u003e ב 渲染为：“א -\u003e ב”，箭头方向错误。（如果您在未来此 bug 已修复后阅读此内容，则此内容将渲染为“א → ב”）

请注意，这里的输入字符序列是：

字符 名称
א 希伯来字母 Alef
空格
- 连字符减号
\u003e 大于号
空格
ב 希伯来字母 Bet

您可以通过将字符串 א -\u003e ב 复制到此工具来验证：https://unicodedecode.com/

这是因为箭头字符在 Unicode 中不会进行 bidi 镜像。相关文档：https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf

特别是，箭头和类似箭头的字符通常都有一个镜像字符。有人可能会认为它们应该具有 Bidi_Mirrored=Yes 属性值，但它们没有，现在也无法获得。

不幸的是，没有 bidi 翻转的箭头字符，这意味着如果您想正确地进行此替换，您必须确定周围文本的 bidi 方向，以便正确地在 \u003c- 和 -\u003e 箭头之间进行选择。这并非易事。

1 个赞
2

@falco 我认为这是一个 bug，而不是功能请求。输出与用户的意图和期望完全相反。

3

鉴于

这意味着我们必须构建一项新功能，因为我们目前遵循的是 Unicode 规范，这就是为什么我将其重新归类为 Feature request。

接下来，让我们来解决你的问题，我认为可以使用我们现有的 api.decorateCooked API 在 Theme component 中轻松完成。

2 个赞
4

谢谢。我不急于在任何特定论坛上修复它，我只是认为这应该在 Discourse 中修复。

我不想陷入毫无意义的语义争论，所以就此打住。我已经说完了我想说的，我认为这应该被视为一个错误，但接下来怎么做由你决定。

感谢您的关注和快速回复 :slight_smile:

1 个赞
5

嗯……一个人只能抵抗这么久。我会再说最后一件事（我保证）。据我所知，Unicode 规范并不鼓励将 -\u003e 转换为 →（并且此问题是其中一个原因），因此此现有的 Discourse 功能并未遵循任何 Unicode 规范。它对文本做出了错误的假设，并在此过程中引入了这个错误。这就是我的看法。（尽管这个功能仍然很棒）

现在我说完我该说的了！

3 个赞
6

如果我输入的是从右到左的语言，我希望输入“破折号”后跟“小于号”，并期望它能转换为向左的箭头，如下所示：←。对我来说，这似乎是一个合理的期望。但是，当我输入小于号时，组合器会插入一个大于号。这完全出乎意料。这是bug吗？？

我注意到一个从右到左的文本框（例如 aljazeera.net 上的搜索框）会在从右到左的文本中以从左到右的顺序插入数字和数学符号。这似乎很自然。（它对拉丁字母也做同样的事情）

下面我将在从右到左的上下文（我不知道在从右到左的区域设置中是否会这样工作）中输入“小于号是 < 且大于号是 >”：

‮小于号是 < 且大于号是 >

3 个赞
7

你平时不使用从右到左的脚本，对吧？你描述的并没有 bug。你说的有些含糊，为了避免混淆，我将先回答你评论的后半部分。

这正是它应该工作的方式。这样想：

字符 > 字面意思就是“大于”。字符串“A > B”的意思是“A 大于 B”。

同样，要说“א 大于 ב”，我将用同一个大于号字符，其 Unicode 代码为 U+003E，来替换“大于”。然而，因为整个字符串是从右到左的，所以“א”出现在“ב”的右边。如果“大于号”字符像 LTR 一样渲染，它会显示：א<ב，这读作“א 小于 ב”或“ב 大于 א”——这与正在描述的关系恰恰相反。

这就是为什么在渲染大于号字符时，它在 RTL 上下文中会被视觉翻转。但底层字符，以及支持它的 Unicode 数据，仍然是“大于”符号。字符串仍然意味着“א 大于 ב”。

现在回到你的第一个问题：

如果你将键盘布局切换到 RTL 语言（如希伯来语或阿拉伯语），那么 Shift+,（带有 < 字符的键）实际上会输入“大于”字符 >。在 RTL 上下文中，它会渲染为 ‭>‭。

[编辑：下一段是在我稍微误解了你所说的测试内容时写的。我以为你在用 LTR 键盘在 RTL 输入框中输入，而你实际上做了相反的事情。希望我仍然解答了你的疑惑。]

但你仍然在使用拉丁键盘布局，所以当你按下这个键组合时，它会插入一个“小于”字符 <。但它被渲染为 ‭<‭，因为在 RTL 中，它意味着右边的内容小于左边的内容。

底线：字符是相同的，但它的渲染被镜像了。

如果你理解了我到目前为止所说的内容，那么你就会明白，那会变成 -<，或者在 RTL 中是 ‭-\u003c‭，这可能不是你想要的。

我成功解释清楚了吗，还是让你更困惑了？

1 个赞
8

如果您认为官方的 Unicode 文档对您更有帮助，可以试试这个：UAX #9: Unicode Bidirectional Algorithm 按 Ctrl+F 搜索“mirror”，您会找到一些很好的描述和示例。

1 个赞
9

你说得对，我是在没有经验的情况下开始的，而且还用的是拉丁键盘！

所以，我应该保持沉默……但我确实看到，如果我在半岛电视台的搜索框中输入（在我的拉丁键盘上）3<6，我会看到这个：

image
image200×126 1.98 KB

这可能表明你是对的，我是错的，这没什么好奇怪的！

2 个赞
10

完全不是！如果只允许 RTL 用户讨论和修复 RTL 错误，那我们会糟糕得多！我只是借此机会向您介绍这个主题。您需要花些时间来理解它。我很乐意回答您关于这个问题的任何其他疑问或好奇之处。

1 个赞
11

我已加入 Unicode 邮件列表，提议向 Unicode 添加一个解决方案，以应对此类情况。我收到的一条回复是：

（我：）问题在于，据我所知，这种替换是在任何渲染上下文之外完成的，此时文本仅仅是一系列字符代码。无法合理地知道文本的方向。有时这完全不可能，因为文本方向取决于当时不可用的上下文。

严格来说，上述说法不准确。如今，任何严肃的文本渲染都需要一个整形引擎，例如 HarfBuzz，而将“->”连字为“→”将由这样的整形器与支持连字的字体协同完成。整形引擎 确实 了解双向上下文以及它所整形文本的脚本，因此原则上可以镜像箭头。

他们正在谈论类似这样的东西：GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures

考虑切换到连字方法，而不是盲目替换字符。另一个可争论的优点是，当复制粘贴时，文本仍然是“- >”，而不是箭头。

我还没有研究过实现此目的的技术细节，如果您选择使用此解决方案，我将把这些留给您。

编辑：不出所料，Fira Text 尤其不是为 RTL 设计的，因此渲染效果不佳——但至少方向是正确的！https://fonts.google.com/specimen/Fira+Code?preview.text=A%20->%20B,%20א%20->%20ב
火狐浏览器：

image
image473×164 5.61 KB

我不确定今天是否存在一个能够正确执行此操作并明确支持 RTL/双向的字体。

1 个赞
12

有趣的是，我在 Chromium 中得到了不同的结果：
编辑：我现在无法重现它了，所以我想我在截图时输入错误了。
编辑：现在我又可以重现它了。情况很糟糕。

image
image524×165 5.86 KB

浏览器渲染引擎/塑形器可能无法胜任这项任务。我需要进一步调查，而这 不是 我现在应该关注的重点……

编辑：论坛限制迫使我从之前的回复中删除了这个：
供参考，这是负责此替换的代码：

1 个赞
14

正如我所提到的，我正在为这个问题提出一个 Unicode 解决方案。我在其中详细解释了这个问题，希望比我在这里解释得更清楚。它仍在进行中，但请看一下：Making sure you're not a bot! （永久链接）

特别是，请查看Discourse 部分。

当然，即使 Unicode 最终接受了这个提案（当我最终提交它时），它也需要数年时间才能被广泛实施以确保可靠性，所以等待它不是一个好计划。