\a Alarm or bell.
\A Beginning of string. Not in [].
\b{}, \b Boundary. (\b is a backspace in []).
- \B{}, \B Not a boundary.
+ \B{}, \B Not a boundary. Not in [].
\cX Control-X.
- \C Single octet, even under UTF-8. Not in [].
- (Deprecated)
\d Character class for digits.
\D Character class for non-digits.
\e Escape character.
=head3 Hexadecimal escapes
Like octal escapes, there are two forms of hexadecimal escapes, but both start
-with the same thing, C<\x>. This is followed by either exactly two hexadecimal
+with the sequence C<\x>. This is followed by either exactly two hexadecimal
digits forming a number, or a hexadecimal number of arbitrary length surrounded
by curly braces. The hexadecimal number is the code point of the character you
want to express.
C<\b{...}>, available starting in v5.22, matches a boundary (between two
characters, or before the first character of the string, or after the
final character of the string) based on the Unicode rules for the
-boundary type specified inside the braces. The currently known boundary
+boundary type specified inside the braces. The boundary
types are given a few paragraphs below. C<\B{...}> matches at any place
between characters where C<\b{...}> of the same type doesn't match.
All plain C<\b> and C<\B> boundary determinations look for word
characters alone, not for
non-word characters nor for string ends. It may help to understand how
-<\b> and <\B> work by equating them as follows:
+C<\b> and C<\B> work by equating them as follows:
\b really means (?:(?<=\w)(?!\w)|(?<!\w)(?=\w))
\B really means (?:(?<=\w)(?=\w)|(?<!\w)(?!\w))
-In contrast, C<\b{...}> may or may not match at the beginning and end of
-the line depending on the boundary type (and C<\B{...}> never does).
-The boundary types currently available are:
+In contrast, C<\b{...}> and C<\B{...}> may or may not match at the
+beginning and end of the line, depending on the boundary type. These
+implement the Unicode default boundaries, specified in
+L<http://www.unicode.org/reports/tr14/> and
+L<http://www.unicode.org/reports/tr29/>.
+The boundary types are:
=over
the same functionality. It is equivalent to C</.+?\b{gcb}/>. Use
whichever is most convenient for your situation.
+=item C<\b{lb}>
+
+This matches according to the default Unicode Line Breaking Algorithm
+(L<http://www.unicode.org/reports/tr14/>), as customized in that
+document
+(L<Example 7 of revision 35|http://www.unicode.org/reports/tr14/tr14-35.html#Example7>)
+for better handling of numeric expressions.
+
+This is suitable for many purposes, but the L<Unicode::LineBreak> module
+is available on CPAN that provides many more features, including
+customization.
+
=item C<\b{sb}>
This matches a Unicode "Sentence Boundary". This is an aid to parsing
natural language sentences. It gives good, but imperfect results. For
example, it thinks that "Mr. Smith" is two sentences. More details are
-at L<http://www.unicode.org/reports/tr29/>.
+at L<http://www.unicode.org/reports/tr29/>. Note also that it thinks
+that anything matching L</\R> (except form feed and vertical tab) is a
+sentence boundary. C<\b{sb}> works with text designed for
+word-processors which wrap lines
+automatically for display, but hard-coded line boundaries are considered
+to be essentially the ends of text blocks (paragraphs really), and hence
+the ends of sententces. C<\b{sb}> doesn't do well with text containing
+embedded newlines, like the source text of the document you are reading.
+Such text needs to be preprocessed to get rid of the line separators
+before looking for sentence boundaries. Some people view this as a bug
+in the Unicode standard, and this behavior is quite subject to change in
+future Perl versions.
=item C<\b{wb}>
-This matches a Unicode "Word Boundary". This gives better (though not
+This matches a Unicode "Word Boundary", but tailored to Perl
+expectations. This gives better (though not
perfect) results for natural language processing than plain C<\b>
(without braces) does. For example, it understands that apostrophes can
-be in the middle of words. More details are at
-L<http://www.unicode.org/reports/tr29/>.
+be in the middle of words and that parentheses aren't (see the examples
+below). More details are at L<http://www.unicode.org/reports/tr29/>.
+
+The current Unicode definition of a Word Boundary matches between every
+white space character. Perl tailors this, starting in version 5.24, to
+generally not break up spans of white space, just as plain C<\b> has
+always functioned. This allows C<\b{wb}> to be a drop-in replacement for
+C<\b>, but with generally better results for natural language
+processing. (The exception to this tailoring is when a span of white
+space is immediately followed by something like U+0303, COMBINING TILDE.
+If the final space character in the span is a horizontal white space, it
+is broken out so that it attaches instead to the combining character.
+To be precise, if a span of white space that ends in a horizontal space
+has the character immediately following it have either of the Word
+Boundary property values "Extend" or "Format", the boundary between the
+final horizontal space character and the rest of the span matches
+C<\b{wb}>. In all other cases the boundary between two white space
+characters matches C<\B{wb}>.)
=back
+It is important to realize when you use these Unicode boundaries,
+that you are taking a risk that a future version of Perl which contains
+a later version of the Unicode Standard will not work precisely the same
+way as it did when your code was written. These rules are not
+considered stable and have been somewhat more subject to change than the
+rest of the Standard. Unicode reserves the right to change them at
+will, and Perl reserves the right to update its implementation to
+Unicode's new rules. In the past, some changes have been because new
+characters have been added to the Standard which have different
+characteristics than all previous characters, so new rules are
+formulated for handling them. These should not cause any backward
+compatibility issues. But some changes have changed the treatment of
+existing characters because the Unicode Technical Committee has decided
+that the change is warranted for whatever reason. This could be to fix
+a bug, or because they think better results are obtained with the new
+rule.
+
+It is also important to realize that these are default boundary
+definitions, and that implementations may wish to tailor the results for
+particular purposes and locales. For example, some languages, such as
+Japanese and Thai, require dictionary lookup to determine word
+boundaries.
+
Mnemonic: I<b>oundary.
=back
print $1; # Prints 'cat'
}
- print join "\n", "I don't care" =~ m/ ( .+? \b{wb} ) /xg;
+ my $s = "He said, \"Is pi 3.14? (I'm not sure).\"";
+ print join("|", $s =~ m/ ( .+? \b ) /xg), "\n";
+ print join("|", $s =~ m/ ( .+? \b{wb} ) /xg), "\n";
prints
- I, ,don't, ,care
+ He| |said|, "|Is| |pi| |3|.|14|? (|I|'|m| |not| |sure
+ He| |said|,| |"|Is| |pi| |3.14|?| |(|I'm| |not| |sure|)|.|"
=head2 Misc
=over 4
-=item \C
-
-(Deprecated.) C<\C> always matches a single octet, even if the source
-string is encoded
-in UTF-8 format, and the character to be matched is a multi-octet character.
-This is very dangerous, because it violates
-the logical character abstraction and can cause UTF-8 sequences to become malformed.
-
-Use C<utf8::encode()> instead.
-
-Mnemonic: oI<C>tet.
-
=item \K
This appeared in perl 5.10.0. Anything matched left of C<\K> is
https://perl5.git.perl.org / perl5.git / blobdiff