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

Question

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

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

julia> [codepoint(i) for i in string(:ẋ)]
1-element Vector{UInt32}:
 0x00001e8b

julia> [codepoint(i) for i in "ẋ"]
2-element Vector{UInt32}:
 0x00000078
 0x00000307

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

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

Answer 1

两个结果是等效的。

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

就您而言，您有两种代表:

• U+1E8B(上面带点的拉丁文小写字母 X)
• U+0087(拉丁文小写字母 X)+ U+0307(组合上面的点)

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

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

参见https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization

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

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

就您而言，我认为您应该规范化字符串，请参阅例如https://docs.julialang.org/en/v1/stdlib/Unicode/ 中的 Unicode.normalize

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