Java正则表达式中w和的Unicode等价物? [英] Unicode equivalents for w and in Java regular expressions?
问题描述
许多现代正则表达式实现将 w 字符类速记解释为任何字母、数字或连接标点符号"(通常:下划线).这样，像 w+ 这样的正则表达式匹配 hello、élève、GOÄ_432 或 gefräßig.
不幸的是，Java 没有.在 Java 中，w 仅限于 [A-Za-z0-9_].这使得匹配上面提到的词变得困难，还有其他问题.
单词分隔符似乎也在不该匹配的地方匹配.
Java 中类似 .NET、支持 Unicode 的 w 或 的正确等效项是什么?哪些其他快捷方式需要重写"以使其能够识别 Unicode?
源代码
我在下面讨论的重写函数的源代码可在此处获得.
Java 7 中的更新
Sun 为 JDK7 更新的 Pattern 类有一个了不起的新标志，UNICODE_CHARACTER_CLASS，它使一切重新正常工作.它可以作为模式内部的可嵌入 (?U) 使用，因此您也可以将它与 String 类的包装器一起使用.它还修正了各种其他属性的定义.它现在在 RL1.2 和 RL1.2a 来自UTS#18:Unicode 正则表达式.这是一项令人兴奋且引人注目的改进，开发团队的这一重要努力值得表扬.
Java 的正则表达式 Unicode 问题
Java 正则表达式的问题在于 Perl 1.0 字符类转义——意味着 w, , s, d 和它们的补码——在 Java 中没有扩展以使用 Unicode.其中， 享有某些扩展语义，但这些都没有映射到 w，也不是 Unicode 标识符，也不是Unicode 换行符属性.
另外，Java 中的 POSIX 属性是这样访问的:
POSIX 语法 Java 语法[[:下:]] p{下}[[:上:]] p{上}[[:ASCII:]] p{ASCII}[[:Alpha:]] p{Alpha}[[:数字:]] p{数字}[[:Alnum:]] p{Alnum}[[:Punct:]] p{Punct}[[:Graph:]] p{Graph}[[:打印:]] p{打印}[[:Blank:]] p{Blank}[[:Cntrl:]] p{Cntrl}[[:XDigit:]] p{XDigit}[[:Space:]] p{Space}这真是一团糟，因为这意味着 Alpha、Lower 和 Space 之类的东西不会 在 Java 中映射到 Unicode Alphabetic、Lowercase 或 Whitespace 属性.这是非常烦人的.Java 的 Unicode 属性支持严格意义上是千禧年，我的意思是它不支持过去十年中出现的任何 Unicode 属性.
不能正确地谈论空白是非常烦人的.考虑下表.对于每个代码点，都有一个 J-results 列用于 Java 和用于 Perl 或任何其他基于 PCRE 的正则表达式引擎的 P-results 列:
正则表达式 001A 0085 00A0 2029J P J P J P J Ps 1 1 0 1 0 1 0 1pZ 0 0 0 0 1 1 1 1p{Zs} 0 0 0 0 1 1 0 0p{空格} 1 1 0 1 0 1 0 1p{空白} 0 0 0 0 0 1 0 0p{空格} - 1 - 1 - 1 - 1p{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个字符类转义:
w W s S v V h H d D B X R用可预测和一致的方式实际匹配 Unicode 的东西替换它们.它只是来自单个黑客会话的 alpha 原型，但它是完整的功能.
简而言之，我的代码将这 14 个重写如下:
s =>[u0009-u000Du0020u0085u00A0u1680u180Eu2000-u200Au2028u2029u202Fu205Fu3000]S =>[^u0009-u000Du0020u0085u00A0u1680u180Eu2000-u200Au2028u2029u202Fu205Fu3000]v =>[u000A-u000Du0085u2028u2029]V =>[^u000A-u000Du0085u2028u2029]h =>[u0009u0020u00A0u1680u180Eu2000-u200Au202Fu205Fu3000]H =>[^u0009u0020u00A0u1680u180Eu2000u2001-u200Au202Fu205Fu3000]w =>[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]]W =>[^pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]] =>(?:(?<=[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])(?![pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])|(?<![pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])(?=[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]]))B =>(?:(?<=[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])(?=[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])|(?<![pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])(?![pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]]))d =>p{Nd}D =>P{Nd}R =>(?:(?>u000Du000A)|[u000Au000Bu000Cu000Du0085u2028u2029])X =>(?>PMpM*)需要考虑的一些事情...
它的
X定义使用了 Unicode 现在所指的内容作为一个遗留字形簇，而不是一个扩展字形簇，因为后者更复杂.Perl 本身现在使用更高级的版本，但旧版本在最常见的情况下仍然完全可用.见底部附录.如何处理
d取决于您的意图，但默认值是 Uniode 定义.我可以看到人们并不总是想要p{Nd}，但有时需要[0-9]或pN.两个边界定义，
和B，是专门为使用w定义而编写的.p>那个
w定义过于宽泛，因为它抓住了括号内的字母，而不仅仅是圈出的字母.UnicodeOther_Alphabetic属性在 JDK7 之前不可用，所以这是你能做的最好的事情.
探索边界
自从 Larry Wall 于 1987 年首次创造 和 B 语法来讨论 Perl 1.0 的边界以来，边界一直是一个问题.理解的关键 和 B 的工作原理是消除关于它们的两个普遍存在的神话:
- 他们只寻找
w个单词字符，从不寻找非单词字符. - 他们不会专门寻找字符串的边缘.
A 边界意味着:
IF 确实跟随单词THEN 不放在单词之前ELSIF 不听话THEN 确实先于单词这些都非常直接地定义为:
- follows word 是
(?<=w). - 词前是
(?=w). - 不跟词是
(?<!w). - 不在词前是
(?!w).
因此，由于 IF-THEN 在正则表达式中被编码为 and ed-together AB，一个 or> 是 X|Y，并且因为 and 的优先级高于 or，所以就是 AB|CD>.所以每个表示边界的 都可以安全地替换为:
(?:(?<=w)(?!w)|(?使用以适当方式定义的 w .
(您可能认为 A 和 C 组件是对立的很奇怪.在一个完美的世界中，您应该能够编写 AB|D，但有一段时间我一直在寻找 Unicode 属性中的互斥矛盾——我认为我已经解决了这个问题，但为了以防万一，我在边界中留下了双重条件.此外，如果您以后有其他想法，这会使其更具可扩展性.)
对于B 非边界，逻辑是:
IF 确实跟随单词THEN 确实先于单词ELSIF 不听话THEN 不放在单词之前允许将 B 的所有实例替换为:
(?:(?<=w)(?=w)|(?这确实是 和 B 的行为方式.它们的等效模式是
使用((IF)THEN|ELSE)构造是(?(?<=w)(?!w)|(?=w))B使用((IF)THEN|ELSE)构造是(?(?=w)(?<=w)|(?
但是只有 AB|CD 的版本很好，特别是如果您的正则表达式语言中缺少条件模式——比如 Java.☹
我已经使用所有三个等效定义和测试套件验证了边界的行为，该测试套件每次运行检查 110,385,408 个匹配项，并且我已经根据以下内容在十几种不同的数据配置上运行:
0 .. 7F ASCII 范围80 .. FF 非 ASCII Latin1 范围100 .. FFFF 非Latin1 BMP(基本多语言平面)范围10000 .. 10FFFF Unicode 的非 BMP 部分(星光"平面)然而，人们通常想要一种不同的边界.他们想要一些能够识别空格和字符串边缘的东西:
- 左边缘为
(?:(?<=^)|(?<=s)) - 右边缘为
(?=$|s)
用 Java 修复 Java
我在我的其他答案中发布的代码 提供了这一点以及许多其他便利.这包括自然语言单词、破折号、连字符和撇号的定义，以及更多.
它还允许您在逻辑代码点中指定 Unicode 字符，而不是在愚蠢的 UTF-16 代理中.这一点的重要性再怎么强调也不为过！这只是为了字符串扩展.
对于使 Java 正则表达式中的字符类最终在 Unicode 上运行的正则表达式字符类替换，并且正常工作，抓住 来自此处的完整源代码.当然，您可以随意使用它.如果您对其进行修复，我很乐意听到它，但您不必这样做.它很短.主要正则表达式重写函数的内容很简单:
开关(code_point){case 'b': newstr.append(boundary);休息;/* 转变 */案例'B':newstr.append(not_boundary);休息;/* 转变 */case 'd': newstr.append(digits_charclass);休息;/* 转变 */案例'D':newstr.append(not_digits_charclass);休息;/* 转变 */case 'h': newstr.append(horizontal_whitespace_charclass);休息;/* 转变 */案例'H':newstr.append(not_horizontal_whitespace_charclass)；休息;/* 转变 */case 'v': newstr.append(vertical_whitespace_charclass);休息;/* 转变 */case 'V': newstr.append(not_vertical_whitespace_charclass);休息;/* 转变 */case 'R': newstr.append(linebreak);休息;/* 转变 */case 's': newstr.append(whitespace_charclass);休息;/* 转变 */case 'S': newstr.append(not_whitespace_charclass);休息;/* 转变 */case 'w': newstr.append(identifier_charclass);休息;/* 转变 */case 'W': newstr.append(not_identifier_charclass);休息;/* 转变 */案例'X':newstr.append(legacy_grapheme_cluster)；休息;/* 转变 */默认值:newstr.append('\');newstr.append(Character.toChars(code_point));休息;/* 转变 */}锯反斜线 = 假；无论如何，该代码只是一个 alpha 版本，是我在周末修改的内容.它不会一直这样.
对于测试版，我打算:
将重复的代码折叠起来
针对非转义字符串转义与扩充正则表达式转义提供更清晰的界面
在
d扩展中提供一些灵活性，也许提供方便的方法来处理转向和调用 Pattern.compile 或 String.matches 或诸如此类的东西
对于生产版本，它应该有 javadoc 和一个 JUnit 测试套件.我可能会包含我的 gigatester，但它不是作为 JUnit 测试编写的.
<小时>附录
我有好消息和坏消息.
好消息是我现在有一个非常近似于一个扩展的字素簇，用于改进的X.
坏消息☺是这种模式是:
(?:(?:u000Du000A)|(?:[u0E40u0E41u0E42u0E43u0E44u0EC0u0EC1u0EC2u0EC3u0EC4uAAB5uAABB6uAuuAABC]*(?:[u1100-u115FuA960-uA97C]+|([u1100-u115FuA960-uA97C]*((?:[[u1160-u11A2uD7B0-uD7C6][uAC00uAC1CuAC38]][u1160-u11A2uD7B0-uD7C6]*|[uAC01uAC02uAC03uAC04])[u11A8-u11F9uD7CB])|[u11A8-u11F9uD7CB-uD7FB]+|[^[p{Zl}p{Zp}p{Cc}p{Cf}&&[^u000Du000Au200Cu200D]]u000Du000A])[[p{Mn}p{我}u200Cu200Du0488u0489u20DDu20DEu20DFu20E0u20E2u267E3uAuA672uFF9EuFF9F][p{Mc}u0E30u0E32u0E33u0E45u0EB0u0EB2u0EB3]]])|(?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:.))";¡Tschüß！
Many modern regex implementations interpret the w character class shorthand as "any letter, digit, or connecting punctuation" (usually: underscore). That way, a regex like w+ matches words like hello, élève, GOÄ_432 or gefräßig.
Unfortunately, Java doesn't. In Java, w is limited to [A-Za-z0-9_]. This makes matching words like those mentioned above difficult, among other problems.
It also appears that the word separator matches in places where it shouldn't.
What would be the correct equivalent of a .NET-like, Unicode-aware w or in Java? Which other shortcuts need "rewriting" to make them Unicode-aware?
Source code
The source code for the rewriting functions I discuss below is available here.
Update in Java 7
Sun’s updated Pattern class for JDK7 has a marvelous new flag, UNICODE_CHARACTER_CLASS, which makes everything work right again. It’s available as an embeddable (?U) for inside the pattern, so you can use it with the String class’s wrappers, too. It also sports corrected definitions for various other properties, too. It now tracks The Unicode Standard, in both RL1.2 and RL1.2a from UTS#18: Unicode Regular Expressions. This is an exciting and dramatic improvement, and the development team is to be commended for this important effort.
Java’s Regex Unicode Problems
The problem with Java regexes is that the Perl 1.0 charclass escapes — meaning w, , s, d and their complements — are not in Java extended to work with Unicode. Alone amongst these, enjoys certain extended semantics, but these map neither to w, nor to Unicode identifiers, nor to Unicode line-break properties.
Additionally, the POSIX properties in Java are accessed this way:
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}
This is a real mess, because it means that things like Alpha, Lower, and Space do not in Java map to the Unicode Alphabetic, Lowercase, or Whitespace properties. This is exceeedingly annoying. Java’s Unicode property support is strictly antemillennial, by which I mean it supports no Unicode property that has come out in the last decade.
Not being able to talk about whitespace properly is super-annoying. Consider the following table. For each of those code points, there is both a J-results column for Java and a P-results column for Perl or any other PCRE-based regex engine:
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 -
See that?
Virtually every one of those Java white space results is ̲w̲r̲o̲n̲g̲ according to Unicode. It’s a really big problem. Java is just messed up, giving answers that are "wrong" according to existing practice and also according to Unicode. Plus Java doesn’t even give you access to the real Unicode properties! In fact, Java does not support any property that corresponds to Unicode whitespace.
The Solution to All Those Problems, and More
To deal with this and many other related problems, yesterday I wrote a Java function to rewrite a pattern string that rewrites these 14 charclass escapes:
w W s S v V h H d D B X R
by replacing them with things that actually work to match Unicode in a predictable and consistent fashion. It’s only an alpha prototype from a single hack session, but it is completely functional.
The short story is that my code rewrites those 14 as follows:
s => [u0009-u000Du0020u0085u00A0u1680u180Eu2000-u200Au2028u2029u202Fu205Fu3000]
S => [^u0009-u000Du0020u0085u00A0u1680u180Eu2000-u200Au2028u2029u202Fu205Fu3000]
v => [u000A-u000Du0085u2028u2029]
V => [^u000A-u000Du0085u2028u2029]
h => [u0009u0020u00A0u1680u180Eu2000-u200Au202Fu205Fu3000]
H => [^u0009u0020u00A0u1680u180Eu2000u2001-u200Au202Fu205Fu3000]
w => [pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]]
W => [^pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]]
=> (?:(?<=[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])(?![pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])|(?<![pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])(?=[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]]))
B => (?:(?<=[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])(?=[pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])|(?<![pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]])(?![pLpMp{Nd}p{Nl}p{Pc}[p{InEnclosedAlphanumerics}&&p{So}]]))
d => p{Nd}
D => P{Nd}
R => (?:(?>u000Du000A)|[u000Au000Bu000Cu000Du0085u2028u2029])
X => (?>PMpM*)
Some things to consider...
That uses for its
Xdefinition what Unicode now refers to as a legacy grapheme cluster, not an extended grapheme cluster, as the latter is rather more complicated. Perl itself now uses the fancier version, but the old version is still perfectly workable for the most common situations. EDIT: See addendum at bottom.What to do about
ddepends on your intent, but the default is the Uniode definition. I can see people not always wantingp{Nd}, but sometimes either[0-9]orpN.The two boundary definitions,
andB, are specifically written to use thewdefinition.That
wdefinition is overly broad, because it grabs the parenned letters not just the circled ones. The UnicodeOther_Alphabeticproperty isn’t available until JDK7, so that’s the best you can do.
Exploring Boundaries
Boundaries have been a problem ever since Larry Wall first coined the and B syntax for talking about them for Perl 1.0 back in 1987. The key to understanding how and B both work is to dispel two pervasive myths about them:
- They are only ever looking for
wword characters, never for non-word characters. - They do not specifically look for the edge of the string.
A boundary means:
IF does follow word
THEN doesn't precede word
ELSIF doesn't follow word
THEN does precede word
And those are all defined perfectly straightforwardly as:
- follows word is
(?<=w). - precedes word is
(?=w). - doesn’t follow word is
(?<!w). - doesn’t precede word is
(?!w).
Therefore, since IF-THEN is encoded as an and ed-together AB in regexes, an or is X|Y, and because the and is higher in precedence than or, that is simply AB|CD. So every that means a boundary can be safely replaced with:
(?:(?<=w)(?!w)|(?<!w)(?=w))
with the w defined in the appropriate way.
(You might think it strange that the A and C components are opposites. In a perfect world, you should be able to write that AB|D, but for a while I was chasing down mutual exclusion contradictions in Unicode properties — which I think I’ve taken care of, but I left the double condition in the boundary just in case. Plus this makes it more extensible if you get extra ideas later.)
For the B non-boundaries, the logic is:
IF does follow word
THEN does precede word
ELSIF doesn't follow word
THEN doesn't precede word
Allowing all instances of B to be replaced with:
(?:(?<=w)(?=w)|(?<!w)(?!w))
This really is how and B behave. Equivalent patterns for them are
using the((IF)THEN|ELSE)construct is(?(?<=w)(?!w)|(?=w))Busing the((IF)THEN|ELSE)construct is(?(?=w)(?<=w)|(?<!w))
But the versions with just AB|CD are fine, especially if you lack conditional patterns in your regex language — like Java. ☹
I’ve already verified the behaviour of the boundaries using all three equivalent definitions with a test suite that checks 110,385,408 matches per run, and which I've run on a dozen different data configurations according to:
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)
However, people often want a different sort of boundary. They want something that is whitespace and edge-of-string aware:
- left edge as
(?:(?<=^)|(?<=s)) - right edge as
(?=$|s)
Fixing Java with Java
The code I posted in my other answer provides this and quite a few other conveniences. This includes definitions for natural-language words, dashes, hyphens, and apostrophes, plus a bit more.
It also allows you to specify Unicode characters in logical code points, not in idiotic UTF-16 surrogates. It’s hard to overstress how important that is! And that’s just for the string expansion.
For regex charclass substitution that makes the charclass in your Java regexes finally work on Unicode, and work correctly, grab the full source from here. You may do with it as you please, of course. If you make fixes to it, I’d love to hear of it, but you don’t have to. It’s pretty short. The guts of the main regex rewriting function is simple:
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;
Anyway, that code is just an alpha release, stuff I hacked up over the weekend. It won’t stay that way.
For the beta I intend to:
fold together the code duplication
provide a clearer interface regarding unescaping string escapes versus augmenting regex escapes
provide some flexibility in the
dexpansion, and maybe theprovide convenience methods that handle turning around and calling Pattern.compile or String.matches or whatnot for you
For production release, it should have javadoc and a JUnit test suite. I may include my gigatester, but it’s not written as JUnit tests.
Addendum
I have good news and bad news.
The good news is that I’ve now got a very close approximation to an extended grapheme cluster to use for an improved X.
The bad news ☺ is that that pattern is:
(?:(?:u000Du000A)|(?:[u0E40u0E41u0E42u0E43u0E44u0EC0u0EC1u0EC2u0EC3u0EC4uAAB5uAAB6uAAB9uAABBuAABC]*(?:[u1100-u115FuA960-uA97C]+|([u1100-u115FuA960-uA97C]*((?:[[u1160-u11A2uD7B0-uD7C6][uAC00uAC1CuAC38]][u1160-u11A2uD7B0-uD7C6]*|[uAC01uAC02uAC03uAC04])[u11A8-u11F9uD7CB-uD7FB]*))|[u11A8-u11F9uD7CB-uD7FB]+|[^[p{Zl}p{Zp}p{Cc}p{Cf}&&[^u000Du000Au200Cu200D]]u000Du000A])[[p{Mn}p{Me}u200Cu200Du0488u0489u20DDu20DEu20DFu20E0u20E2u20E3u20E4uA670uA671uA672uFF9EuFF9F][p{Mc}u0E30u0E32u0E33u0E45u0EB0u0EB2u0EB3]]*)|(?s:.))
which in Java you’d write as:
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:.))";
¡Tschüß!
这篇关于Java正则表达式中w和的Unicode等价物?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
