许多现代正则表达式实现将\w字符类速记解释为“任何字母、数字或连接标点符号”（通常：下划线）。这样，正则表达式之类的\w+匹配词，如hello,或.élèveGOÄ_432gefräßig
不幸的是，Java 没有。在 Java 中，\w仅限于[A-Za-z0-9_]. 这使得匹配上面提到的单词变得困难，以及其他问题。
似乎\b单词分隔符在不应该匹配的地方匹配。
什么是类似 .NET、Unicode 感知\w或\bJava 的正确等价物？哪些其他快捷方式需要“重写”以使它们能够识别 Unicode？
我在下面讨论的重写函数的源代码可在此处获得。
SunPattern为 JDK7 更新的类有一个了不起的新标志UNICODE_CHARACTER_CLASS，它使一切重新正常工作。它可以作为模式内部的嵌入(?U)对象使用，因此您也可以将它与String类的包装器一起使用。它还对各种其他属性进行了更正的定义。它现在在UTS#18: Unicode Regular Expressions的RL1.2和RL1.2a中跟踪 Unicode 标准。这是一个令人兴奋和戏剧性的改进，开发团队的这一重要努力值得称赞。
Java 正则表达式的问题在于 Perl 1.0 的字符类转义——意思是\w, \b, \s,\d以及它们的补语——在 Java 中没有扩展为使用 Unicode。其中只有一个，\b享有某些扩展语义，但这些既不映射\w到Unicode 标识符，也不映射到Unicode 换行符属性。
此外，Java 中的 POSIX 属性可以通过以下方式访问：
POSIX syntax Java syntax
[[:Lower:]] \p{Lower}
[[:Upper:]] \p{Upper}
[[:ASCII:]] \p{ASCII}
[[:Alpha:]] \p{Alpha}
[[:Digit:]] \p{Digit}
[[:Alnum:]] \p{Alnum}
[[:Punct:]] \p{Punct}
[[:Graph:]] \p{Graph}
[[:Print:]] \p{Print}
[[:Blank:]] \p{Blank}
[[:Cntrl:]] \p{Cntrl}
[[:XDigit:]] \p{XDigit}
[[:Space:]] \p{Space}
这真是一团糟，因为这意味着 Java 中的 , 和 do not 之类的东西Alpha映射Lower到SpaceUnicode , ,Alphabetic或Lowercase属性Whitespace。这非常烦人。Java 的 Unicode 属性支持严格来说是 antemillennial，我的意思是它不支持过去十年出现的任何 Unicode 属性。
不能正确地谈论空白是非常烦人的。考虑下表。对于这些代码点中的每一个，都有一个用于 Java 的 J-results 列和一个用于 Perl 或任何其他基于 PCRE 的正则表达式引擎的 P-results 列：
Regex 001A 0085 00A0 2029
J P J P J P J P
\s 1 1 0 1 0 1 0 1
\pZ 0 0 0 0 1 1 1 1
\p{Zs} 0 0 0 0 1 1 0 0
\p{Space} 1 1 0 1 0 1 0 1
\p{Blank} 0 0 0 0 0 1 0 0
\p{Whitespace} - 1 - 1 - 1 - 1
\p{javaWhitespace} 1 - 0 - 0 - 1 -
\p{javaSpaceChar} 0 - 0 - 1 - 1 -
看到了吗？
根据 Unicode，几乎每一个 Java 空白结果都是 ̲w̲r̲o̲n̲g̲。这真是个大问题。 Java 只是一团糟，根据现有实践和 Unicode，给出的答案都是“错误的”。此外，Java 甚至不让您访问真正的 Unicode 属性！事实上，Java 不支持任何对应于 Unicode 空白的属性。
为了解决这个问题和许多其他相关问题，昨天我编写了一个 Java 函数来重写一个模式字符串，该字符串重写了这 14 个 charclass 转义：
\w \W \s \S \v \V \h \H \d \D \b \B \X \R
通过将它们替换为实际可以以可预测且一致的方式匹配 Unicode 的东西。它只是来自单个 hack 会话的 alpha 原型，但它是完全可用的。
简而言之，我的代码将这 14 个代码重写如下：
\s => [\u0009-\u000D\u0020\u0085\u00A0\u1680\u180E\u2000-\u200A\u2028\u2029\u202F\u205F\u3000]
\S => [^\u0009-\u000D\u0020\u0085\u00A0\u1680\u180E\u2000-\u200A\u2028\u2029\u202F\u205F\u3000]
\v => [\u000A-\u000D\u0085\u2028\u2029]
\V => [^\u000A-\u000D\u0085\u2028\u2029]
\h => [\u0009\u0020\u00A0\u1680\u180E\u2000-\u200A\u202F\u205F\u3000]
\H => [^\u0009\u0020\u00A0\u1680\u180E\u2000\u2001-\u200A\u202F\u205F\u3000]
\w => [\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]]
\W => [^\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]]
\b => (?:(?<=[\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]])(?![\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]])|(?<![\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]])(?=[\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]]))
\B => (?:(?<=[\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]])(?=[\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]])|(?<![\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]])(?![\pL\pM\p{Nd}\p{Nl}\p{Pc}[\p{InEnclosedAlphanumerics}&&\p{So}]]))
\d => \p{Nd}
\D => \P{Nd}
\R => (?:(?>\u000D\u000A)|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029])
\X => (?>\PM\pM*)
有些事情要考虑...
它使用Unicode 现在称为legacy grapheme cluster\X的定义，而不是扩展的 grapheme cluster，因为后者相当复杂。Perl 本身现在使用更高级的版本，但旧版本在最常见的情况下仍然可以完美运行。编辑：见底部的附录。
做什么\d取决于你的意图，但默认是 Uniode 定义。我可以看到人们并不总是想要\p{Nd}，但有时要么[0-9]或\pN。
两个边界定义\b和\B是专门为使用该\w定义而编写的。
该\w定义过于宽泛，因为它不仅包含带圆圈的字母，还包含括号中的字母。UnicodeOther_Alphabetic属性直到 JDK7 才可用，所以这是您能做的最好的事情。
自从 Larry Wall于 1987 年首次为 Perl 1.0 创造了用于讨论边界的\band语法以来，边界就一直是一个问题。理解两者如何工作以及两者如何工作的关键是消除关于它们的两个普遍的神话：\B\b\B
\w字符，从不寻找非单词字符。\b边界意味着：
IF does follow word
THEN doesn't precede word
ELSIF doesn't follow word
THEN does precede word
这些都被完美地直接定义为：
(?<=\w)。(?=\w)。(?<!\w)。(?!\w)。因此，因为is在正则表达式中IF-THEN被编码为and ed-together ，所以 an是，并且因为 the的优先级高于，所以就是。因此，这意味着边界可以安全地替换为：ABorX|YandorAB|CD\b
(?:(?<=\w)(?!\w)|(?<!\w)(?=\w))
以\w适当的方式定义。
（你可能觉得A和C组件是相反的很奇怪。在一个完美的世界里，你应该可以写那个AB|D，但是有一段时间我一直在追查 Unicode 属性中的互斥矛盾——我想我已经处理好了, 但我把双重条件留在了边界以防万一。另外，如果你以后有额外的想法，这使它更具可扩展性。）
对于\B无边界，逻辑是：
IF does follow word
THEN does precede word
ELSIF doesn't follow word
THEN doesn't precede word
允许将 的所有实例\B替换为：
(?:(?<=\w)(?=\w)|(?<!\w)(?!\w))
这确实是如何\b和\B行为。它们的等效模式是
\b使用((IF)THEN|ELSE)构造是(?(?<=\w)(?!\w)|(?=\w))\B使用((IF)THEN|ELSE)构造是(?(?=\w)(?<=\w)|(?<!\w))但是带有 just 的版本AB|CD很好，特别是如果您的正则表达式语言（如 Java）中缺少条件模式。☹</p>
我已经使用所有三个等效定义和一个测试套件验证了边界的行为，该测试套件每次运行检查 110,385,408 个匹配项，并且我已经根据以下十几种不同的数据配置运行了该测试套件：
0 .. 7F the ASCII range
80 .. FF the non-ASCII Latin1 range
100 .. FFFF the non-Latin1 BMP (Basic Multilingual Plane) range
10000 .. 10FFFF the non-BMP portion of Unicode (the "astral" planes)
然而，人们通常想要不同类型的边界。他们想要一些可以识别空格和字符串边缘的东西：
(?:(?<=^)|(?<=\s)) (?=$|\s)我在其他答案中发布的代码提供了这一点以及许多其他便利。这包括自然语言单词、破折号、连字符和撇号的定义，还有更多。
它还允许您在逻辑代码点中指定 Unicode 字符，而不是在愚蠢的 UTF-16 代理项中。很难过分强调这是多么重要！这只是为了字符串扩展。
对于使 Java 正则表达式中的 charclass最终在 Unicode 上工作并正常工作的正则表达式 charclass 替换，请从此处 获取完整源代码。 当然，您可以随心所欲地使用它。如果您对其进行修复，我很乐意听到它，但您不必这样做。它很短。主要的正则表达式重写函数的内容很简单：
switch (code_point) {
case 'b': newstr.append(boundary);
break; /* switch */
case 'B': newstr.append(not_boundary);
break; /* switch */
case 'd': newstr.append(digits_charclass);
break; /* switch */
case 'D': newstr.append(not_digits_charclass);
break; /* switch */
case 'h': newstr.append(horizontal_whitespace_charclass);
break; /* switch */
case 'H': newstr.append(not_horizontal_whitespace_charclass);
break; /* switch */
case 'v': newstr.append(vertical_whitespace_charclass);
break; /* switch */
case 'V': newstr.append(not_vertical_whitespace_charclass);
break; /* switch */
case 'R': newstr.append(linebreak);
break; /* switch */
case 's': newstr.append(whitespace_charclass);
break; /* switch */
case 'S': newstr.append(not_whitespace_charclass);
break; /* switch */
case 'w': newstr.append(identifier_charclass);
break; /* switch */
case 'W': newstr.append(not_identifier_charclass);
break; /* switch */
case 'X': newstr.append(legacy_grapheme_cluster);
break; /* switch */
default: newstr.append('\\');
newstr.append(Character.toChars(code_point));
break; /* switch */
}
saw_backslash = false;
无论如何，该代码只是一个 alpha 版本，是我在周末破解的东西。它不会一直这样。
对于测试版，我打算：
将代码重复折叠在一起
提供关于非转义字符串转义与增加正则表达式转义的更清晰的界面
在扩展中提供一些灵活性\d，也许\b
为您提供方便的方法来处理转身和调用 Pattern.compile 或 String.matches 或诸如此类的东西
对于生产版本，它应该有 javadoc 和一个 JUnit 测试套件。我可能包括我的 gigatester，但它不是作为 JUnit 测试编写的。
我有好消息和坏消息。
好消息是，我现在已经非常接近扩展字素簇，可用于改进的\X.
坏消息☺是这种模式是：
(?:(?:\u000D\u000A)|(?:[\u0E40\u0E41\u0E42\u0E43\u0E44\u0EC0\u0EC1\u0EC2\u0EC3\u0EC4\uAAB5\uAAB6\uAAB9\uAABB\uAABC]*(?:[\u1100-\u115F\uA960-\uA97C]+|([\u1100-\u115F\uA960-\uA97C]*((?:[[\u1160-\u11A2\uD7B0-\uD7C6][\uAC00\uAC1C\uAC38]][\u1160-\u11A2\uD7B0-\uD7C6]*|[\uAC01\uAC02\uAC03\uAC04])[\u11A8-\u11F9\uD7CB-\uD7FB]*))|[\u11A8-\u11F9\uD7CB-\uD7FB]+|[^[\p{Zl}\p{Zp}\p{Cc}\p{Cf}&&[^\u000D\u000A\u200C\u200D]]\u000D\u000A])[[\p{Mn}\p{Me}\u200C\u200D\u0488\u0489\u20DD\u20DE\u20DF\u20E0\u20E2\u20E3\u20E4\uA670\uA671\uA672\uFF9E\uFF9F][\p{Mc}\u0E30\u0E32\u0E33\u0E45\u0EB0\u0EB2\u0EB3]]*)|(?s:.))
在Java中你会写成：
String extended_grapheme_cluster = "(?:(?:\\u000D\\u000A)|(?:[\\u0E40\\u0E41\\u0E42\\u0E43\\u0E44\\u0EC0\\u0EC1\\u0EC2\\u0EC3\\u0EC4\\uAAB5\\uAAB6\\uAAB9\\uAABB\\uAABC]*(?:[\\u1100-\\u115F\\uA960-\\uA97C]+|([\\u1100-\\u115F\\uA960-\\uA97C]*((?:[[\\u1160-\\u11A2\\uD7B0-\\uD7C6][\\uAC00\\uAC1C\\uAC38]][\\u1160-\\u11A2\\uD7B0-\\uD7C6]*|[\\uAC01\\uAC02\\uAC03\\uAC04])[\\u11A8-\\u11F9\\uD7CB-\\uD7FB]*))|[\\u11A8-\\u11F9\\uD7CB-\\uD7FB]+|[^[\\p{Zl}\\p{Zp}\\p{Cc}\\p{Cf}&&[^\\u000D\\u000A\\u200C\\u200D]]\\u000D\\u000A])[[\\p{Mn}\\p{Me}\\u200C\\u200D\\u0488\\u0489\\u20DD\\u20DE\\u20DF\\u20E0\\u20E2\\u20E3\\u20E4\\uA670\\uA671\\uA672\\uFF9E\\uFF9F][\\p{Mc}\\u0E30\\u0E32\\u0E33\\u0E45\\u0EB0\\u0EB2\\u0EB3]]*)|(?s:.))";
¡
真的很不幸，\w不起作用。建议的解决方案\p{Alpha}对我也不起作用。
它似乎[\p{L}]捕获了所有 Unicode 字母。所以 Unicode 等价物\w应该是[\p{L}\p{Digit}_].
在 Java 中，\w并且\d不支持 Unicode；它们只匹配 ASCII 字符，[A-Za-z0-9_]并且[0-9]. 和朋友也是如此\p{Alpha}（他们所基于的 POSIX“字符类”应该是对语言环境敏感的，但在 Java 中他们只匹配过 ASCII 字符）。如果您想匹配 Unicode “单词字符”，您必须将其拼写出来，例如[\pL\p{Mn}\p{Nd}\p{Pc}]，对于字母、非间距修饰符（重音）、十进制数字和连接标点符号。
然而，Java\b 是Unicode 的。它也使用Character.isLetterOrDigit(ch)并检查重音字母，但它识别的唯一“连接标点符号”字符是下划线。 编辑：当我尝试您的示例代码时，它会按原样打印""（élève"在ideone.com 上查看）。