问题标签 [unicode-normalization]

我需要对一组字符串执行大小写折叠，并且必须事先确保它们在完成后不会超过给定的长度（硬编码所需的缓冲区大小）。问题是在应用大小写折叠后字符串长度（以代码点为单位）可能会发生变化。参见，例如，在 Python3 中：

现在，一个字符串在执行大小写折叠后可能包含的最大代码点数可以很容易地计算出来：

但它在所有情况下都有效吗？我的意思是，由于Unicode的一些神秘属性，代码点的序列（它们出现的顺序）是否可能会影响字符串的最终长度？或者我可以假设最终的字符串总是最多比原始字符串长 3 倍吗？

我正在尝试在 IPA 字符字符串中插入空格，例如ɔ̃wɔ̃tɨ 变成ɔ̃ w ɔ̃ t ɨ. 使用 split/join 是我的第一个想法：

正如我通过检查结果发现的那样，带有变音符号的字母实际上被编码为两个字符。经过一番研究，我找到了 UnicodeUtils 模块，并使用了 each_grapheme 方法：

这工作得很好，除了倒置的短标记。代码更改̑a为̑ a. 我尝试了标准化（UnicodeUtils.nfc, UnicodeUtils.nfd），但无济于事。我不知道为什么该each_grapheme方法对这个特殊的变音符号有问题，但我注意到在 gedit 中，短号也被视为一个单独的字符，而不是波浪号、重音符号等。所以我的问题如下：是有一种直接的归一化方法，即将Latin Small Letter A和的组合Combining Inverted Breve变成Latin Small Letter A With Inverted Breve?

我正在开发一个需要生成“不区分大小写”的规范化形式的 Unicode 文本的 C 项目。我选择将规范化形式定义为首先转换为规范化形式 NFD，然后应用 Unicode 大小写折叠算法，最后将结果转换为 Unicode 规范化形式 NFC。

我依靠 ICU 的 C API 来实现其 Unicode 表示和实用功能，使用 ICUunorm_normalize()和u_strFoldCase()功能实现我的方案相当简单。但是我的一项测试失败了，我不明白为什么。ICU 似乎正在生成与我预期不同的 NFC 形式。

输入序列由以下 BMP 代码点组成：

通过调试器，我确定 ICU 和我同意案例折叠后的中间结果：

请特别注意，早期转换为 NFD 的形式将字符 U+031C 移动到 U+1EC4 分解的中间，这取决于所涉及字符的相对 CCC 编号。这是我正在尝试测试的一部分。

现在好的部分：根据 ICU，折叠字符序列的 NFC 规范化是

而我认为应该是

因为后面的三个组合字符已经是规范顺序了，不存在 U+0065 和 U+031C 的规范组合。

所以，两个问题：

1. 哪个是正确的 NFC 形式？
2. 如果ICU是正确的，那为什么？

我想规范化任何扩展的 ascii 字符，但不包括变音符号。

如果我想包括变音符号，我会选择：

但是我怎样才能排除德语变音符号呢？

结果我想得到：

来源：üöäâÇæôøñÁ

期望的结果：üöäaCaeoonA或类似的

我知道 ES6 将有一个新功能，它将对字符串进行 utf-8 规范化（例如使用“NFC”形式）。

阅读http://www.unicode.org/faq/normalization.html，我看到了这个常见问题解答：

问：W3C 规范化和 Unicode 规范化有什么区别？

答：Unicode 标准化有 4 种风格：C、D、KC、KD。与 W3C 规范化相关的是 C。W3C 规范化还将字符引用 (&#nnnn;) 视为等同于字符。例如，文本字符串“a&#xnnnn;” (其中 nnnn = "0301") 是 Unicode 规范化的，因为它仅包含 ASCII 字符，但它不是 W3C 规范化的，因为它包含与“a”组合的锐音重音的表示，并且在规范化形式 C 中，应该已经归一化为 U+00E1。

这是否意味着我们需要替换所有出现的 &#xnnnn; 在调用 normalize('nfc') 之前通过他们的 utf8 等价物？

或者是否会有某种 normalize('w3c') 有助于考虑通过 ascii "&#xnnnn;" 结合重音的字母 等价于它的规范化形式？

我正在尝试用 ZWNJ 替换用阿拉伯字母书写的两个标记之间的空格，但函数返回的内容在屏幕上未正确解码：

\u200 应该被渲染为一个半空间，将放置在 'رشته' 和 'ها' 之间，但它会像那样搞砸。我正在使用 Python 3.3.3

是否有任何 Java API 可以将 Unicode 数字标准化为 ASCII 数字？

JDK和ICU4J中有一个规范化 API，它似乎无法处理这种规范化（因为它可能不被Unicode 标准称为规范化）

我需要将所有形式的 Unicode 数字（在这篇文章中列出）转换为 [0-9]。一个可能的混乱解决方案是 10 替换所有从 0 到 9 的任何数字。

这个问题是指在索引中存储本地名称的国际字符的规范化。我想一般性地讨论这个问题，也想听听 Java 中可能存在的解决方案（类/库）。

在全局应用程序中，用户输入自己的姓名，应用程序将每个姓名写入搜索索引，以便其他用户可以搜索姓名并找到用户。在英语中微不足道，但在许多其他语言和/或全球范围内并不那么微不足道，因为特定字母需要音译和/或可以以多种形式书写。例如，德国名字 Häußler 可以写成

• 豪斯勒（德国）
• Haeussler（德国，国际音译）
• 豪斯勒（瑞士）
• 豪斯勒（英文音译）

Java有

类，但这似乎在很多情况下都不起作用和/或我不知道如何正确使用它。很好的阅读也在这里http://en.wikipedia.org/wiki/Unicode_equivalence但我找不到足够的关于这个主题的捆绑信息。

有人知道现有的开源项目已经有人解决了这个问题吗？有什么可以使用的库吗？网站？

您是如何将日本人、中国人、阿拉伯人等人的语言音译成英语的？像 Facebook 这样的大型社交网络如何音译他们的用户名，以确保他们可以在国际上找到？

编辑：好的，听起来 .normalize() 并没有我最初想象的那么广泛支持。因此，对我的以下问题进行修改：您认为在尚不支持此功能的 Safari 等浏览器上标准化 unicode 的最佳解决方法是什么？

好的，我写的一些代码在大约一周前在所有浏览器上都可以正常工作，现在只在 Safari 上被破坏（所有其他浏览器仍然可以正常工作）。我已经对有问题的代码进行了磨练，但我仍然不确定为什么这对 Safari 来说是个问题。这段代码应该比较两个 URL 子字符串（例如：“Williams%2C+John%2C+1932-”）以确保它们相同。有时字符串包含变音符号、空格和其他有问题的字符，因此 decodeURI（对于第一个字符串）和规范化（对于两个字符串）。

我所知道的是，如果我删除两个 .normalize('NFD') 命令，代码再次正常工作......但我需要在那里的 normalize 命令，因为有时一个字符串会使用预先组合的变音符号而另一个会使用分解（出于我的目的，我想将它们视为匹配项）。我很好奇是否有人知道为什么 .normalize() 可能会在 Safari 中导致问题，但在其他浏览器中却没有。

这是 Safari 的错误代码：

当我的应用程序在我的笔记本电脑 CouchDB 上本地运行时，它可以完美运行，但是当我从 Cloudant 上的复制运行它时，它会中断。我不得不使用https://github.com/walling/unorm js 库来使其工作，但这会根据我的喜好添加太多 kb 的 js 代码（我非常痴迷于速度）。

我非常希望将我的本地 CouchDB 编码为 Cloudant 使用的相同 utf-8 编码，这可能吗？最好的方法是什么？

我的应用程序是一个客户端（全部在浏览器中）迷你搜索引擎，它从页面 html 中包含的 csv 文件中获取数据。csv 是从运行 ubuntu 14.10 的笔记本电脑上的 couchDB 生成的。该应用程序是双语的，英语和法语：bottinbio.com

我编写了一个建议功能（在原型上，而不是主网站上），以便在用户键入时向她建议单词。其数据来自通过复制笔记本电脑 CouchDB 数据库创建的 Cloudant 数据库。

问题是从 Cloudant 数据库中检索到的“bière”等重读词的编码方式与我的本地 CouchDB 不同。通常单击单词“bière”会触发在 csv 中搜索该单词，但搜索失败，即使在 csv 中写入了“bière”。当建议来自我的 localhost 开发服务器上的 CouchDB 数据库时，不会发生这种情况。