问题标签 [case-folding]

在 C# 中，在大多数情况下似乎Grüsse和Grüße被认为是平等的，正如这个漂亮的网页所解释的那样。我试图在 Java 中找到类似的行为 - 显然不是在java.lang.String.

我以为我很幸运java.regex.Pattern与Pattern.UNICODE_CASE. Javadoc 说：

UNICODE_CASE 启用 Unicode 感知大小写折叠。如果指定了此标志，那么在由 CASE_INSENSITIVE 标志启用时，不区分大小写的匹配将以符合 Unicode 标准的方式进行。

然而下面的代码：

产量false。为什么？是否有另一种重现 C# 案例折叠行为的方法？

- - 编辑 - -

正如@VGR 指出的那样，String.toUpperCase将转换ß为ss，这可能是也可能不是大小写折叠（也许我在这里混淆了概念）。但是，德语语言环境中的其他字符不会“折叠”，例如ü不会变成UE. 因此，为了使我的初始示例更加完整，有没有办法在 Java中使Grüße和比较相等？Gruesse

我在想这个java.text.Normalizer类可以用来做到这一点，但它转换ü为u?而不是ue. 它也没有提供 a 的选项Locale，这让我更加困惑。

我试图让大小写折叠在三种语言（C++、Python 和 Golang）之间保持一致，因为无论使用哪种语言，我都需要能够检查字符串是否与保存的字符串匹配。

一个有问题的单词示例是德语单词“grüßen”，它的大写字母是“GRÜSSEN”（注意“ß”变成了两个字符“SS”）。

• C++ 使用 boost::locale文本转换文档效果很好
• Python 3 也可以通过 str.casefold() casefold 文档工作
• 但是，Golang 似乎没有办法进行正确的大小写折叠。golang 操场示例

有没有我遗漏的方法可以做到这一点，或者unicode 文档末尾的这个错误是否适用于 golang 中文本转换的所有用法？如果是这样，除了在 cgo 中编写之外，我还有哪些案例折叠选项？

我的 python 代码运行良好，但代码看起来有点乏味和混乱。我想知道是否有更简单的方法来编写它。我有一个文本文件，我需要查找是否可以在该行内找到字母“aardvark”。

这返回真。哪个是对的。不幸的是，当我将其中一个存储在 postgres 中时，它认为在进行不区分大小写的匹配时它们是不一样的（例如， with ~*）。我也用 citext 测试过。

因此，一种解决方案是预先折叠案例，从而将strasse这些值中的任何一个存储在另一列中。然后我可以索引并搜索匹配项。

我一直在寻找如何在 C# 中折叠大小写，但一直无法在 C# 中找到解决方案。显然，知识是存在的，因为它可以正确比较这些字符串，我只是找不到从哪里得到它。

一种解决方案是生成一个 perl 进程perl -E "binmode STDOUT, ':utf8'; binmode STDIN, ':utf8'; while (<>) { print fc }"，将这些管道的 C# 端也设置为 utf8，然后通过 perl 发送文本以折叠案例。但必须有比这更好的方法。

是否有 String.toLowerCase() 和 String.toUpperCase() 的 JavaScript polyfill 实现，或者 JavaScript 中可以处理 Unicode 字符并在浏览器之间保持一致的其他方法？

背景资料

执行以下操作将在浏览器中产生不同的结果，甚至在浏览器版本之间（例如 FireFox 54 与 55）：

在 Firefox 55 中它为您提供ss，在 Firefox 54 中它为您提供ß。

通常这很好，诸如 Locales 之类的机制可以处理很多您想要的情况；但是，当您需要跨平台的一致行为（例如与google-cloud-firestore等 BaaS 系统通信）时，它可以大大简化您在客户端处理内部数据的交互。

Unicode 强调软件应尽可能向前兼容，默认将未分配的字符视为私人使用的代码点。这在大多数情况下效果很好，因为大多数新字符在规范化、大小写折叠等时不会改变。

但是，我想分析 Unicode 中的规范化“破坏性”变化：具有在应用 NFx、NFKx、casefold 或 NFKC_Casefold 规范化时会导致更改的属性的字符。我对自己对 NFC 或 NFKC 算法的理解并不是 100% 有信心，而且我相信存在一些限制特殊情况数量的稳定性变化。如果这意味着不必处理特殊情况，我可以将我的分析限制在 Unicode 4、5 甚至 6。

我最初尝试解析 XML Unicode 字符数据库并根据规范组合类) ( ccc != 0)、NFxy 快速检查( NFC_QC != 'Y',NFD_QC != 'Y'等) 和casefolding/NFKC_Casefold ( CWKCF = 'Y' or CWCF = 'Y') 属性选择代码点。

这是最好的方法，还是我应该只看分解映射和类型？

要不区分大小写地比较两个字符串，一种正确的方法是先将它们大小写折叠。这比上壳或下壳好多少？

我发现小写字母不能在网上正常工作的例子。例如，“σ”和“ς”（“Σ”的两种形式）在转换为小写时不会变得相同。但我没能找到为什么大小写折叠比映射到大写更好。是否存在应该不区分大小写的两个字符串对相同字符串不大写的情况？

另一种情况是当我想存储不区分大小写的索引时。推荐的方法似乎是案例折叠然后规范化。与存储映射为大写和规范化的字符串相比，它有什么优势？规范说映射到大写不能保证跨 Unicode 版本是稳定的，而大小写折叠是。但是在早期版本的 Unicode 中，是否存在映射到大写的不同字符串的情况？

我不明白这个错误......在将其转换为列表数据框之前，我已经将 df 转换为小写：

代码：

但我在这一行有一个错误：

但是，如果我之前已经通过了小写数据帧，为什么程序会返回小写错误？

在 Python 3.7 或更高版本中，我想测试两个pathlib.Path对象p1和p2大小写相等性。写出来我想要的结果

是否有内置函数或运算符？或者更简单/更短的测试方法？

ps：我在 macOS 上需要这个，但首选forPosixPath和 for的通用解决方案。WindowsPath

假设这些字符串定义：

使用这种模式：

...这个断言通过：

...而这个失败了：

...而两者都 lowerStream使用这些正则表达式upperStream传递rubular.com ：

/.*(ss).*/i

/.*(SS).*/i

/.*(ß).*/i

String.equalsIgnoreCase()使用、String.toLowerCase().equals()或中的任何一个也无法成功进行比较String.toUpperCase().equals()。

java的unicode正则表达式是否只支持简单的大小写折叠？如果是这样，为什么没有明确记录？