使用带有 \dot 输入参数的 codepoint() 会产生不同的结果

Question

我想看看是否可以从 Julia 中的符号中检测到 \\dot 运算符，这是我尝试过的：

\n

以下两个块返回不同的结果

\n

julia> [codepoint(i) for i in string(:x\xcc\x87)]\n1-element Vector{UInt32}:\n 0x00001e8b\n

julia> [codepoint(i) for i in "x\xcc\x87"]\n2-element Vector{UInt32}:\n 0x00000078\n 0x00000307\n

理想情况下，我会在开头有一个符号，而不是字符串，所以我需要使用第一种方法，但这不会返回 0x307，这是 \\dot 的 unicode，使得很难检测 \\dot。

\n

那么差异背后的机制是什么呢？谢谢。

\n

Answer 1

两个结果是等效的。

人类是复杂的，语言也是如此，因此 Unicode 需要有复杂的规则。

在你的情况下，你有两种代表：

两者在 Unicode 上被认为是等效的。注意：比较字符串时，最好对字符串进行规范化。不幸的是，有两个主要的标准化：

NFD：规范化形式规范分解，所以是第二种情况。如果可能的话，总是将字符分解为基本字符+修饰符）。这种规范化是 Apple 所偏爱的，也是 Unicode 的最初想法。
NFC：标准化形式规范组合。如果有办法组合字符，那就完成了。如果有各种修饰符（因此优先级），则有关于如何制作它的规则。大多数其他操作系统都首选此方法。
和K版本（兼容性而不是规范），但它更棘手：有各种兼容性原因。所以它们通常不用于显示而是用于搜索文本）。

显示引擎（布局引擎、文本形状、字形显示、字体元数据）可能会生成相同的符号（每种字体对于它们期望的数据的标准化有自己的偏好，但随后它们将尝试找到组合的字形）。

我认为就您的情况而言，文本文件中可能有两种不同的变体。一种使用两个字符，一种使用单个字符。复制字符时经常会发生这种情况（与另一种相比，某些编辑器更喜欢一种标准化）。

在你的情况下，我认为你应该规范化字符串，请Unicode.normalize参见https://docs.julialang.org/en/v1/stdlib/Unicode/

我们使用的是拉丁字符，因此属于 Unicode 的简单部分（但它是少数具有大写和小写的脚本之一）。