我正在尝试查看是否可以从 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。
那么差异背后的机制是什么呢？谢谢。
最佳答案
两个结果是等效的。
人类很复杂，语言也很复杂，因此 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 的简单部分(但它是少数具有大写和小写的脚本之一)。
关于unicode - 使用带有\dot 输入参数的 codepoint() 会产生不同的结果，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/76626974/