RegexBuddy—Better than a regular expression tutorial!

Unicode 正则表达式

Unicode 是一种字符集，旨在定义所有语言（包括现存和已消亡语言）中的所有字符和字形。随着越来越多的软件需要支持多种语言，甚至只是任何语言，Unicode 近年来获得了极大的普及。对不同语言使用不同的字符集对于程序员和用户来说过于繁琐。

遗憾的是，在正则表达式中，Unicode 带来了自己的要求和陷阱。在本教程中讨论的正则表达式类型中，Java、XML 和 .NET 使用基于 Unicode 的正则表达式引擎。Perl 从 5.6 版开始支持 Unicode。PCRE 可以选择编译时启用 Unicode 支持。请注意，尽管 PCRE 的名称为“Perl 兼容”，但在允许 \p 令牌方面，它的灵活性远不如 Perl。基于 PCRE 的 PHP preg 函数在正则表达式后追加 /u 选项时支持 Unicode。Ruby 从 1.9 版开始在正则表达式中支持 Unicode 转义和属性。XRegExp 为 JavaScript 带来了对 Unicode 属性的支持。

RegexBuddy 的正则引擎从 2.0.0 版本开始完全基于 Unicode。RegexBuddy 1.x.x 根本不支持 Unicode。 PowerGREP 从 3.0.0 版本开始使用相同的 Unicode 正则引擎。早期版本会在使用 8 位（即非 Unicode）正则引擎进行 grep 之前将 Unicode 文件转换为 ANSI。 EditPad Pro 从 6.0.0 版本开始支持 Unicode。

字符、代码点和音节或 Unicode 如何让事情变得一团糟

大多数人会认为 à 是一个字符。不幸的是，这取决于“字符”一词的含义，所以不一定正确。

本教程中讨论的所有 Unicode 正则引擎将任何单个 Unicode 代码点视为单个字符。当本教程告诉你点匹配任何单个字符时，这在 Unicode 术语中转化为“点匹配任何单个 Unicode 代码点”。在 Unicode 中，à 可以编码为两个代码点：U+0061 (a) 后跟 U+0300（重音符）。在这种情况下，应用于 à 的 . 将匹配没有重音符的 a。 ^.$ 将无法匹配，因为字符串由两个代码点组成。 ^..$ 匹配 à。

Unicode 代码点 U+0300（重音符）是一个组合标记。任何不是组合标记的代码点都可以后跟任意数量的组合标记。此序列（如上文的 U+0061 U+0300）在屏幕上显示为单个音节。

不幸的是，à 还可以使用单个 Unicode 代码点 U+00E0（带重音符的 a）进行编码。这种二元性的原因在于，许多历史字符集将“带重音符的 a”编码为单个字符。Unicode 的设计者认为，除了 Unicode 分离标记和基础字母的方式（这使得传统字符集不支持的任意组合成为可能）之外，与流行的传统字符集进行一对一映射会很有用。

如何匹配单个 Unicode 音节

在 Perl、PCRE、PHP、Boost、Ruby 2.0、Java 9 和 Just Great Software 应用程序中，匹配单个音节（无论它是编码为单个代码点还是使用组合标记编码为多个代码点）都很容易：只需使用 \X。你可以将 \X 视为点的 Unicode 版本。不过，有一个区别：\X 始终匹配换行符，而点不会匹配换行符，除非你启用点匹配换行匹配模式。

在 .NET、Java 8 及更早版本和 Ruby 1.9 中，你可以使用 \P{M}\p{M}*+ 或 (?>\P{M}\p{M}*) 作为相对接近的替代品。要匹配任意数量的音节，请使用 (?>\P{M}\p{M}*)+ 作为 \X+ 的替代品。

匹配特定代码点

要匹配特定 Unicode 代码点，请使用 \uFFFF，其中 FFFF 是你想要匹配的代码点的十六进制数字。你必须始终指定 4 个十六进制数字，例如 \u00E0 匹配 à，但仅当编码为单个代码点 U+00E0 时。

Perl、PCRE、Boost 和 std::regex 不支持 \uFFFF 语法。它们改用 \x{FFFF}。你可以省略大括号中的十六进制数字中的前导零。由于 \x 本身不是有效的正则表达式标记，因此 \x{1234} 永远不会被误认为匹配 \x 1234 次。它始终匹配 Unicode 代码点 U+1234。 \x{1234}{5678} 将尝试匹配代码点 U+1234 恰好 5678 次。

在 Java 中，正则表达式标记 \uFFFF 仅匹配指定的代码点，即使你打开了规范等价性。但是，相同的语法 \uFFFF 也用于在 Java 源代码中将 Unicode 字符插入到字符串文字中。 Pattern.compile("\u00E0") 将匹配 à 的单代码点和双代码点编码，而 Pattern.compile("\\u00E0") 仅匹配单代码点版本。请记住，在将正则表达式写为 Java 字符串文字时，必须转义反斜杠。前一个 Java 代码编译正则表达式 à，而后一个编译 \u00E0。根据你正在做什么，差异可能是显着的。

JavaScript，通过其 RegExp 类不提供任何 Unicode 支持，但支持 \uFFFF，以匹配单个 Unicode 代码点作为其字符串语法的一部分。

XML Schema 和 XPath 没有用于匹配 Unicode 代码点的正则表达式标记。但是，您可以轻松地使用 XML 实体（如 ）将文字代码点插入正则表达式。

Unicode 类别

除了复杂性之外，Unicode 还带来了新的可能性。其中之一是每个 Unicode 字符都属于某个类别。您可以使用 \p{L} 匹配属于“字母”类别的单个字符。您可以使用 \P{L} 匹配不属于该类别的单个字符。

同样，“字符”实际上是指“Unicode 代码点”。\p{L} 匹配“字母”类别中的单个代码点。如果您的输入字符串是编码为 U+0061 U+0300 的 à，它将匹配没有重音符号的 a。如果输入是编码为 U+00E0 的 à，它将匹配带有重音符号的 à。原因是代码点 U+0061 (a) 和 U+00E0 (à) 都属于“字母”类别，而 U+0300 属于“标记”类别。

您现在应该明白为什么 \P{M}\p{M}*+ 等于 \X。 \P{M} 匹配不是组合标记的代码点，而 \p{M}*+ 匹配零个或多个是组合标记的代码点。要匹配包括任何变音符号的字母，请使用 \p{L}\p{M}*+。无论如何编码，这个最后一个正则表达式都将始终匹配 à。所有格量词确保回溯不会导致 \P{M}\p{M}*+ 匹配没有后面跟随的组合标记的非标记，而 \X 永远不会这样做。

PCRE、PHP 和 .NET 在检查 \p 标记的大括号之间的部分时区分大小写。\p{Zs} 将匹配任何类型的空格字符，而 \p{zs} 将抛出错误。本教程中描述的所有其他正则表达式引擎将在两种情况下都匹配空格，忽略大括号之间类别的案例。不过，我建议您养成使用与我在下面的属性列表中所做相同的字母大小写组合的习惯。这将使您的正则表达式适用于所有 Unicode 正则表达式引擎。

除了标准符号 \p{L} 外，Java、Perl、PCRE、JGsoft 引擎和 XRegExp 3 允许您使用简写 \pL。简写仅适用于单字母 Unicode 属性。 \pLl 不是等同于 \p{Ll}。它等同于 \p{L}l，它匹配 Al 或 àl 或任何 Unicode 字母后跟一个字面 l。

Perl、XRegExp 和 JGsoft 引擎还支持长写 \p{Letter}。您可以在下面找到所有 Unicode 属性的完整列表。您可以省略下划线或改用连字符或空格。

\p{L} 或 \p{Letter}：任何语言中的任何类型的字母。
- \p{Ll} 或 \p{Lowercase_Letter}：具有大写变体的字母。
- \p{Lu} 或 \p{Uppercase_Letter}：具有小写变体的大写字母。
- \p{Lt} 或 \p{Titlecase_Letter}：当单词的首字母大写时出现在单词开头的一个字母。
- \p{L&} 或 \p{Cased_Letter}：存在于小写和大写变体中的字母（Ll、Lu 和 Lt 的组合）。
- \p{Lm} 或 \p{Modifier_Letter}：一个像字母一样使用的特殊字符。
- \p{Lo} 或 \p{Other_Letter}：没有小写和大写变体的字母或表意文字。
\p{M} 或 \p{Mark}：旨在与另一个字符组合的字符（例如重音符号、变音符号、包围框等）。
- \p{Mn} 或 \p{Non_Spacing_Mark}：旨在与另一个字符组合而不占用额外空间的字符（例如重音符号、变音符号等）。
- \p{Mc} 或 \p{Spacing_Combining_Mark}：旨在与另一个字符组合的字符，占用额外空间（许多东方语言中的元音符号）。
- \p{Me} 或 \p{Enclosing_Mark}：包围与其组合的字符的字符（圆圈、方块、键帽等）。
\p{Z} 或 \p{Separator}：任何类型的空白或不可见分隔符。
- \p{Zs} 或 \p{Space_Separator}：不可见但确实占用空间的空白字符。
- \p{Zl} 或 \p{Line_Separator}：行分隔符字符 U+2028。
- \p{Zp} 或 \p{Paragraph_Separator}: 段落分隔符字符 U+2029。
\p{S} 或 \p{Symbol}: 数学符号、货币符号、装饰符号、框图字符等。
- \p{Sm} 或 \p{Math_Symbol}: 任何数学符号。
- \p{Sc} 或 \p{Currency_Symbol}: 任何货币符号。
- \p{Sk} 或 \p{Modifier_Symbol}: 作为独立全字符的组合字符（标记）。
- \p{So} 或 \p{Other_Symbol}: 不是数学符号、货币符号或组合字符的各种符号。
\p{N} 或 \p{Number}: 任何脚本中的任何类型的数字字符。
- \p{Nd} 或 \p{Decimal_Digit_Number}: 除表意文字脚本之外的任何脚本中的数字零到九。
- \p{Nl} 或 \p{Letter_Number}: 看起来像字母的数字，如罗马数字。
- \p{No} 或 \p{Other_Number}: 上标或下标数字，或不是数字 0-9 的数字（不包括表意文字脚本中的数字）。
\p{P} 或 \p{Punctuation}: 任何类型的标点符号字符。
- \p{Pd} 或 \p{Dash_Punctuation}: 任何类型的连字符或破折号。
- \p{Ps} 或 \p{Open_Punctuation}: 任何类型的左括号。
- \p{Pe} 或 \p{Close_Punctuation}: 任何类型的右括号。
- \p{Pi} 或 \p{Initial_Punctuation}: 任何类型的左引号。
- \p{Pf} 或 \p{Final_Punctuation}: 任何类型的右引号。
- \p{Pc} 或 \p{Connector_Punctuation}: 连接单词的标点符号字符，如下划线。
- \p{Po} 或 \p{Other_Punctuation}：任何不是破折号、括号、引号或连接符的标点符号字符。
\p{C} 或 \p{Other}：不可见的控制字符和未使用的代码点。
- \p{Cc} 或 \p{Control}：ASCII 或 Latin-1 控制字符：0x00–0x1F 和 0x7F–0x9F。
- \p{Cf} 或 \p{Format}：不可见的格式指示符。
- \p{Co} 或 \p{Private_Use}：为私用保留的任何代码点。
- \p{Cs} 或 \p{Surrogate}：UTF-16 编码中代理对的一半。
- \p{Cn} 或 \p{Unassigned}：尚未分配字符的任何代码点。

Unicode 脚本

Unicode 标准将每个已分配的代码点（字符）放入一个脚本中。脚本是由特定人类书写系统使用的代码点组。一些脚本（如 Thai）与单一人类语言相对应。其他脚本（如 Latin）跨越多种语言。

一些语言由多个脚本组成。没有日语 Unicode 脚本。相反，Unicode 提供了 Hiragana、Katakana、Han 和 Latin 脚本，这些脚本通常用于组成日语文档。

一个特殊的脚本是 Common 脚本。此脚本包含各种字符，这些字符在各种脚本中都很常见。它包括各种标点符号、空白和杂项符号。

所有已分配的 Unicode 代码点（与 \P{Cn} 匹配的代码点）恰好属于一个 Unicode 脚本。所有未分配的 Unicode 代码点（与 \p{Cn} 匹配的代码点）根本不属于任何 Unicode 脚本。

JGsoft 引擎、Perl、PCRE、PHP、Ruby 1.9、Delphi 和 XRegExp 可以匹配 Unicode 脚本。以下是列表

\p{Common}
\p{Arabic}
\p{亚美尼亚语}
\p{孟加拉语}
\p{注音符号}
\p{盲文}
\p{布希德语}
\p{加拿大土著语言}
\p{切罗基语}
\p{西里尔语}
\p{天城文}
\p{埃塞俄比亚语}
\p{格鲁吉亚语}
\p{希腊语}
\p{古吉拉特语}
\p{古木基语}
\p{汉语}
\p{韩语}
\p{哈努诺语}
\p{希伯来语}
\p{平假名}
\p{继承}
\p{卡纳达语}
\p{片假名}
\p{高棉语}
\p{老挝语}
\p{拉丁语}
\p{林布语}
\p{马拉雅拉姆语}
\p{蒙古语}
\p{缅甸语}
\p{欧甘字母}
\p{奥里亚语}
\p{卢恩字母}
\p{僧伽罗语}
\p{叙利亚语}
\p{塔加禄语}
\p{塔格巴努瓦语}
\p{泰老语}
\p{泰米尔语}
\p{泰卢固语}
\p{塔纳语}
\p{泰语}
\p{藏语}
\p{彝语}

Perl 和 JGsoft 风格允许你使用 \p{IsLatin} 代替 \p{Latin}。如下一节所述，“Is”语法对于区分脚本和块很有用。PCRE、PHP 和 XRegExp 不支持“Is”前缀。

Java 7 为 Unicode 脚本添加了支持。与其他风格不同，Java 7 需要“Is”前缀。

Unicode 块

Unicode 标准将 Unicode 字符映射划分为不同的块或代码点范围。每个块用于定义特定脚本的字符（如“藏语”）或属于特定组的字符（如“盲文模式”）。大多数块包括未分配的代码点，为 Unicode 标准的未来扩展保留。

请注意，Unicode 块与脚本不完全对应。块和脚本之间的一个本质区别是，块是代码点的单个连续范围，如下所示。脚本由从整个 Unicode 字符映射中获取的字符组成。块可能包括未分配的代码点（即与 \p{Cn} 匹配的代码点）。脚本绝不包括未分配的代码点。通常，如果你不确定是使用 Unicode 脚本还是 Unicode 块，请使用脚本。

例如，货币块不包括美元和日元符号。这些符号分别位于 Basic_Latin 和 Latin-1_Supplement 块中，即使它们都是货币符号，并且日元符号不是拉丁字符。这是由于历史原因，因为 ASCII 标准包括美元符号，而 ISO-8859 标准包括日元符号。您不应该盲目地根据名称使用下面列出的任何块。相反，请查看它们实际匹配的字符范围。像 RegexBuddy 这样的工具在此方面非常有用。在尝试查找所有货币符号时，Unicode 属性 \p{Sc} 或 \p{Currency_Symbol} 将比 Unicode 块 \p{InCurrency_Symbols} 更好的选择。

\p{InBasic_Latin}: U+0000–U+007F
\p{InLatin-1_Supplement}: U+0080–U+00FF
\p{InLatin_Extended-A}: U+0100–U+017F
\p{InLatin_Extended-B}: U+0180–U+024F
\p{InIPA_Extensions}: U+0250–U+02AF
\p{InSpacing_Modifier_Letters}: U+02B0–U+02FF
\p{InCombining_Diacritical_Marks}: U+0300–U+036F
\p{InGreek_and_Coptic}: U+0370–U+03FF
\p{InCyrillic}: U+0400–U+04FF
\p{InCyrillic_Supplementary}: U+0500–U+052F
\p{InArmenian}: U+0530–U+058F
\p{InHebrew}: U+0590–U+05FF
\p{InArabic}: U+0600–U+06FF
\p{InSyriac}: U+0700–U+074F
\p{InThaana}: U+0780–U+07BF
\p{InDevanagari}: U+0900–U+097F
\p{InBengali}: U+0980–U+09FF
\p{InGurmukhi}: U+0A00–U+0A7F
\p{InGujarati}: U+0A80–U+0AFF
\p{InOriya}: U+0B00–U+0B7F
\p{InTamil}: U+0B80–U+0BFF
\p{InTelugu}: U+0C00–U+0C7F
\p{InKannada}: U+0C80–U+0CFF
\p{InMalayalam}: U+0D00–U+0D7F
\p{InSinhala}: U+0D80–U+0DFF
\p{InThai}: U+0E00–U+0E7F
\p{InLao}: U+0E80–U+0EFF
\p{InTibetan}: U+0F00–U+0FFF
\p{InMyanmar}: U+1000–U+109F
\p{InGeorgian}: U+10A0–U+10FF
\p{InHangul_Jamo}: U+1100–U+11FF
\p{InEthiopic}: U+1200–U+137F
\p{InCherokee}: U+13A0–U+13FF
\p{InUnified_Canadian_Aboriginal_Syllabics}: U+1400–U+167F
\p{InOgham}: U+1680–U+169F
\p{InRunic}: U+16A0–U+16FF
\p{InTagalog}: U+1700–U+171F
\p{InHanunoo}: U+1720–U+173F
\p{InBuhid}: U+1740–U+175F
\p{InTagbanwa}: U+1760–U+177F
\p{InKhmer}: U+1780–U+17FF
\p{InMongolian}: U+1800–U+18AF
\p{InLimbu}: U+1900–U+194F
\p{InTai_Le}: U+1950–U+197F
\p{InKhmer_Symbols}: U+19E0–U+19FF
\p{InPhonetic_Extensions}: U+1D00–U+1D7F
\p{InLatin_Extended_Additional}: U+1E00–U+1EFF
\p{InGreek_Extended}: U+1F00–U+1FFF
\p{InGeneral_Punctuation}: U+2000–U+206F
\p{InSuperscripts_and_Subscripts}: U+2070–U+209F
\p{InCurrency_Symbols}: U+20A0–U+20CF
\p{InCombining_Diacritical_Marks_for_Symbols}: U+20D0–U+20FF
\p{InLetterlike_Symbols}: U+2100–U+214F
\p{InNumber_Forms}: U+2150–U+218F
\p{InArrows}: U+2190–U+21FF
\p{InMathematical_Operators}: U+2200–U+22FF
\p{InMiscellaneous_Technical}: U+2300–U+23FF
\p{InControl_Pictures}: U+2400–U+243F
\p{InOptical_Character_Recognition}: U+2440–U+245F
\p{InEnclosed_Alphanumerics}: U+2460–U+24FF
\p{InBox_Drawing}: U+2500–U+257F
\p{InBlock_Elements}: U+2580–U+259F
\p{InGeometric_Shapes}: U+25A0–U+25FF
\p{InMiscellaneous_Symbols}: U+2600–U+26FF
\p{InDingbats}: U+2700–U+27BF
\p{InMiscellaneous_Mathematical_Symbols-A}: U+27C0–U+27EF
\p{InSupplemental_Arrows-A}: U+27F0–U+27FF
\p{InBraille_Patterns}: U+2800–U+28FF
\p{InSupplemental_Arrows-B}: U+2900–U+297F
\p{InMiscellaneous_Mathematical_Symbols-B}: U+2980–U+29FF
\p{InSupplemental_Mathematical_Operators}: U+2A00–U+2AFF
\p{InMiscellaneous_Symbols_and_Arrows}: U+2B00–U+2BFF
\p{InCJK_Radicals_Supplement}: U+2E80–U+2EFF
\p{InKangxi_Radicals}: U+2F00–U+2FDF
\p{InIdeographic_Description_Characters}: U+2FF0–U+2FFF
\p{InCJK_Symbols_and_Punctuation}: U+3000–U+303F
\p{InHiragana}: U+3040–U+309F
\p{InKatakana}: U+30A0–U+30FF
\p{InBopomofo}: U+3100–U+312F
\p{InHangul_Compatibility_Jamo}: U+3130–U+318F
\p{InKanbun}: U+3190–U+319F
\p{InBopomofo_Extended}: U+31A0–U+31BF
\p{InKatakana_Phonetic_Extensions}: U+31F0–U+31FF
\p{InEnclosed_CJK_Letters_and_Months}: U+3200–U+32FF
\p{InCJK_Compatibility}: U+3300–U+33FF
\p{InCJK_Unified_Ideographs_Extension_A}: U+3400–U+4DBF
\p{InYijing_Hexagram_Symbols}: U+4DC0–U+4DFF
\p{InCJK_Unified_Ideographs}: U+4E00–U+9FFF
\p{InYi_Syllables}: U+A000–U+A48F
\p{InYi_Radicals}: U+A490–U+A4CF
\p{InHangul_Syllables}: U+AC00–U+D7AF
\p{InHigh_Surrogates}: U+D800–U+DB7F
\p{InHigh_Private_Use_Surrogates}: U+DB80–U+DBFF
\p{InLow_Surrogates}: U+DC00–U+DFFF
\p{InPrivate_Use_Area}: U+E000–U+F8FF
\p{InCJK_Compatibility_Ideographs}: U+F900–U+FAFF
\p{InAlphabetic_Presentation_Forms}: U+FB00–U+FB4F
\p{InArabic_Presentation_Forms-A}: U+FB50–U+FDFF
\p{InVariation_Selectors}: U+FE00–U+FE0F
\p{InCombining_Half_Marks}: U+FE20–U+FE2F
\p{InCJK_Compatibility_Forms}: U+FE30–U+FE4F
\p{InSmall_Form_Variants}: U+FE50–U+FE6F
\p{InArabic_Presentation_Forms-B}: U+FE70–U+FEFF
\p{InHalfwidth_and_Fullwidth_Forms}: U+FF00–U+FFEF
\p{InSpecials}: U+FFF0–U+FFFF

并非所有 Unicode 正则表达式引擎都使用相同的语法来匹配 Unicode 块。 Java、Ruby 2.0 和 XRegExp 使用如上所列的 \p{InBlock} 语法。 .NET 和 XML 则使用 \p{IsBlock}。 Perl 和 JGsoft 风格支持这两种表示法。如果您使用的正则表达式引擎支持“In”表示法，我建议您使用它。“In”只能用于 Unicode 块，而“Is”还可以用于 Unicode 属性和脚本，具体取决于您使用的正则表达式风格。通过使用“In”，很明显您匹配的是一个块，而不是一个类似命名的属性或脚本。

在 .NET 和 XML 中，您必须省略下划线，但保留块名称中的连字符。例如，使用 \p{IsLatinExtended-A} 而不是 \p{InLatin_Extended-A}。在 Java 中，您必须省略连字符。.NET 和 XML 还区分名称的大小写，而 Perl、Ruby 和 JGsoft 风格则不区分大小写。Java 4 区分大小写。Java 5 及更高版本对“Is”前缀区分大小写，但对块名称本身不区分大小写。

所有正则表达式引擎中块的实际名称都是相同的。块名称在 Unicode 标准中定义。PCRE 和 PHP 不支持 Unicode 块，即使它们支持 Unicode 脚本。

您需要担心不同的编码吗？

虽然您应该始终牢记由重音字符的不同编码方式带来的陷阱，但您并不总是需要担心它们。如果您知道您的输入字符串和正则表达式使用相同的样式，那么您根本不必担心。此过程称为 Unicode 规范化。所有具有原生 Unicode 支持的编程语言，如 Java、C# 和 VB.NET，都具有用于规范化字符串的库例程。如果您在尝试匹配之前规范化主题和正则表达式，就不会有任何不一致。

如果您使用 Java，则可以将 CANON_EQ 标志作为第二个参数传递给 Pattern.compile()。这会指示 Java regex 引擎将规范相等的字符视为相同字符。编码为 U+00E0 的 regex à 匹配编码为 U+0061 U+0300 的 à，反之亦然。当前没有其他 regex 引擎在匹配时支持规范相等性。

如果您在键盘上键入 à 键，据我所知，所有文字处理器都会将代码点 U+00E0 插入到文件中。因此，如果您使用自己键入的文本，您自己键入的任何 regex 都将以相同的方式匹配。

最后，如果您使用 PowerGREP 搜索使用传统 Windows（通常称为“ANSI”）或 ISO-8859 代码页编码的文本文件，PowerGREP 始终使用一对一替换。由于所有 Windows 或 ISO-8859 代码页都将重音字符编码为单个代码点，因此在将文件转换为 Unicode 时，几乎所有软件都为每个字符使用单个 Unicode 代码点。

| 快速入门 | 教程 | 工具和语言 | 示例 | 参考 | 书籍评论 |