【问题标题】:Normalize unicode does not work as expected规范化 unicode 无法按预期工作
【发布时间】:2015-08-25 23:27:07
【问题描述】:

我目前在特殊字符的不同 unicode 表示方面遇到了一些问题,尤其是那些带有重音或分音符号等的问题。我编写了一个 python 脚本,它解析多个数据库转储并比较它们之间的值。问题是,在不同的文件中,这些特殊字符的存储方式不同。在某些文件中,这些字符是组合的,而在其他文件中是分解的。由于我希望始终以组合表示形式从转储中提取字符串,因此我尝试添加以下行:

value = unicodedata.normalize("NFC", value)

但是,这仅在某些情况下解决了我的问题。例如,对于变音符号,它按预期工作。然而,像 ë 这样的字符将保留在分解的架构中 (e͏̈)。

我发现,在 e 和分音符号之间有 COMBINING GRAPHEME JOINER-character(U+034F)。这是正常的,还是这可能是我的问题的原因?

有人知道,如何处理这个问题吗?

【问题讨论】:

  • 我想说,如果你有 COMBINING GRAPHEME JOINER 那么它的存在是有原因的,但它取决于文本语言(是的,即使是分音符号)。我倾向于认为这不是一个错误,那么您不应该将其删除(除非您想进行 轻松 比较),但您应该询问该语言的母语人士:它也可能存在,因为原始文本处理软件,不是因为语言。

标签: python unicode special-characters normalize


【解决方案1】:

U+034F COMBINING GRAPHEME JOINER 的目的是确保某些序列在搜索/排序/规范化下保持不同。这是正确处理字符和组合标记所必需的,因为它们在某些具有 Unicode 算法的语言中使用。来自 Unicode 标准的section 23.2(第 805 页):

U+034F 组合字形连接符(CGJ)用于影响排序规则 用于语言敏感排序的相邻字符 和搜索。它还用于区分序列 否则是规范等价的。

...

反过来,这意味着在两个组合标记之间插入一个组合字形连接符将阻止规范化切换这两个组合标记的位置,无论它们自己的组合类如何。

一般来说,您应该在不了解为什么首先插入 CGJ 的情况下移除 CGJ。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-05-05
    • 2017-12-24
    • 2013-12-23
    • 2014-12-09
    • 2016-01-13
    • 2020-09-21
    • 2011-08-17
    相关资源
    最近更新 更多