Starting with release 8.30, it is possible to compile two separate PCRE libraries: the original, which supports 8-bit character strings (including UTF-8 strings), and a second library that supports 16-bit character strings (including UTF-16 strings). The build process allows either one or both to be built. The majority of the work to make this possible was done by Zoltan Herczeg.
Starting with release 8.32 it is possible to compile a third separate PCRE library that supports 32-bit character strings (including UTF-32 strings). The build process allows any combination of the 8-, 16- and 32-bit libraries. The work to make this possible was done by Christian Persch.
The three libraries contain identical sets of functions, except that the names
in the 16-bit library start with pcre16_ instead of pcre_, and the
names in the 32-bit library start with pcre32_ instead of pcre_. To
avoid over-complication and reduce the documentation maintenance load, most of
the documentation describes the 8-bit library, with the differences for the
16-bit and 32-bit libraries described separately in the
HREF
pcre16
and
HREF
pcre32
pages. References to functions or structures of the form pcre[16|32]_xxx
should be read as meaning "pcre_xxx when using the 8-bit library,
pcre16_xxx when using the 16-bit library, or pcre32_xxx when using
the 32-bit library".
The current implementation of PCRE corresponds approximately with Perl 5.12, including support for UTF-8/16/32 encoded strings and Unicode general category properties. However, UTF-8/16/32 and Unicode support has to be explicitly enabled; it is not the default. The Unicode tables correspond to Unicode release 6.3.0.
In addition to the Perl-compatible matching function, PCRE contains an
alternative function that matches the same compiled patterns in a different
way. In certain circumstances, the alternative function has some advantages.
For a discussion of the two matching algorithms, see the
HREF
pcrematching
page.
PCRE is written in C and released as a C library. A number of people have
written wrappers and interfaces of various kinds. In particular, Google Inc.
have provided a comprehensive C++ wrapper for the 8-bit library. This is now
included as part of the PCRE distribution. The
HREF
pcrecpp
page has details of this interface. Other people's contributions can be found
in the Contrib directory at the primary FTP site, which is:
HTML <a href="ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre">
</a>
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre
Details of exactly which Perl regular expression features are and are not
supported by PCRE are given in separate documents. See the
HREF
pcrepattern
and
HREF
pcrecompat
pages. There is a syntax summary in the
HREF
pcresyntax
page.
Some features of PCRE can be included, excluded, or changed when the library is
built. The
HREF
pcre_config()
function makes it possible for a client to discover which features are
available. The features themselves are described in the
HREF
pcrebuild
page. Documentation about building PCRE for various operating systems can be
found in the
HTML <a href="README.txt">
</a>
README
and
HTML <a href="NON-AUTOTOOLS-BUILD.txt">
</a>
NON-AUTOTOOLS_BUILD
files in the source distribution.
The libraries contains a number of undocumented internal functions and data tables that are used by more than one of the exported external functions, but which are not intended for use by external callers. Their names all begin with "_pcre_" or "_pcre16_" or "_pcre32_", which hopefully will not provoke any name clashes. In some environments, it is possible to control which external symbols are exported when a shared library is built, and in these cases the undocumented symbols are not exported. . .
One way of guarding against this possibility is to use the pcre_fullinfo() function to check the compiled pattern's options for UTF. Alternatively, from release 8.33, you can set the PCRE_NEVER_UTF option at compile time. This causes an compile time error if a pattern contains a UTF-setting sequence.
If your application is one that supports UTF, be aware that validity checking can take time. If the same data string is to be matched many times, you can use the PCRE_NO_UTF[8|16|32]_CHECK option for the second and subsequent matches to save redundant checks.
Another way that performance can be hit is by running a pattern that has a very
large search tree against a string that will never match. Nested unlimited
repeats in a pattern are a common example. PCRE provides some protection
against this: see the PCRE_EXTRA_MATCH_LIMIT feature in the
HREF
pcreapi
page.
.
.
Philip Hazel University Computing Service Cambridge CB2 3QH, England.
Putting an actual email address here seems to have been a spam magnet, so I've taken it away. If you want to email me, use my two initials, followed by the two digits 10, at the domain cam.ac.uk. . .
Last updated: 08 January 2014 Copyright (c) 1997-2014 University of Cambridge.