1 |
<html>
|
2 |
<head>
|
3 |
<title>pcreprecompile specification</title>
|
4 |
</head>
|
5 |
<body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
|
6 |
<h1>pcreprecompile man page</h1>
|
7 |
<p>
|
8 |
Return to the <a href="index.html">PCRE index page</a>.
|
9 |
</p>
|
10 |
<p>
|
11 |
This page is part of the PCRE HTML documentation. It was generated automatically
|
12 |
from the original man page. If there is any nonsense in it, please consult the
|
13 |
man page, in case the conversion went wrong.
|
14 |
<br>
|
15 |
<ul>
|
16 |
<li><a name="TOC1" href="#SEC1">SAVING AND RE-USING PRECOMPILED PCRE PATTERNS</a>
|
17 |
<li><a name="TOC2" href="#SEC2">SAVING A COMPILED PATTERN</a>
|
18 |
<li><a name="TOC3" href="#SEC3">RE-USING A PRECOMPILED PATTERN</a>
|
19 |
<li><a name="TOC4" href="#SEC4">COMPATIBILITY WITH DIFFERENT PCRE RELEASES</a>
|
20 |
<li><a name="TOC5" href="#SEC5">AUTHOR</a>
|
21 |
<li><a name="TOC6" href="#SEC6">REVISION</a>
|
22 |
</ul>
|
23 |
<br><a name="SEC1" href="#TOC1">SAVING AND RE-USING PRECOMPILED PCRE PATTERNS</a><br>
|
24 |
<P>
|
25 |
If you are running an application that uses a large number of regular
|
26 |
expression patterns, it may be useful to store them in a precompiled form
|
27 |
instead of having to compile them every time the application is run.
|
28 |
If you are not using any private character tables (see the
|
29 |
<a href="pcre_maketables.html"><b>pcre_maketables()</b></a>
|
30 |
documentation), this is relatively straightforward. If you are using private
|
31 |
tables, it is a little bit more complicated.
|
32 |
</P>
|
33 |
<P>
|
34 |
If you save compiled patterns to a file, you can copy them to a different host
|
35 |
and run them there. This works even if the new host has the opposite endianness
|
36 |
to the one on which the patterns were compiled. There may be a small
|
37 |
performance penalty, but it should be insignificant.
|
38 |
</P>
|
39 |
<br><a name="SEC2" href="#TOC1">SAVING A COMPILED PATTERN</a><br>
|
40 |
<P>
|
41 |
The value returned by <b>pcre_compile()</b> points to a single block of memory
|
42 |
that holds the compiled pattern and associated data. You can find the length of
|
43 |
this block in bytes by calling <b>pcre_fullinfo()</b> with an argument of
|
44 |
PCRE_INFO_SIZE. You can then save the data in any appropriate manner. Here is
|
45 |
sample code that compiles a pattern and writes it to a file. It assumes that
|
46 |
the variable <i>fd</i> refers to a file that is open for output:
|
47 |
<pre>
|
48 |
int erroroffset, rc, size;
|
49 |
char *error;
|
50 |
pcre *re;
|
51 |
|
52 |
re = pcre_compile("my pattern", 0, &error, &erroroffset, NULL);
|
53 |
if (re == NULL) { ... handle errors ... }
|
54 |
rc = pcre_fullinfo(re, NULL, PCRE_INFO_SIZE, &size);
|
55 |
if (rc < 0) { ... handle errors ... }
|
56 |
rc = fwrite(re, 1, size, fd);
|
57 |
if (rc != size) { ... handle errors ... }
|
58 |
</pre>
|
59 |
In this example, the bytes that comprise the compiled pattern are copied
|
60 |
exactly. Note that this is binary data that may contain any of the 256 possible
|
61 |
byte values. On systems that make a distinction between binary and non-binary
|
62 |
data, be sure that the file is opened for binary output.
|
63 |
</P>
|
64 |
<P>
|
65 |
If you want to write more than one pattern to a file, you will have to devise a
|
66 |
way of separating them. For binary data, preceding each pattern with its length
|
67 |
is probably the most straightforward approach. Another possibility is to write
|
68 |
out the data in hexadecimal instead of binary, one pattern to a line.
|
69 |
</P>
|
70 |
<P>
|
71 |
Saving compiled patterns in a file is only one possible way of storing them for
|
72 |
later use. They could equally well be saved in a database, or in the memory of
|
73 |
some daemon process that passes them via sockets to the processes that want
|
74 |
them.
|
75 |
</P>
|
76 |
<P>
|
77 |
If the pattern has been studied, it is also possible to save the study data in
|
78 |
a similar way to the compiled pattern itself. When studying generates
|
79 |
additional information, <b>pcre_study()</b> returns a pointer to a
|
80 |
<b>pcre_extra</b> data block. Its format is defined in the
|
81 |
<a href="pcreapi.html#extradata">section on matching a pattern</a>
|
82 |
in the
|
83 |
<a href="pcreapi.html"><b>pcreapi</b></a>
|
84 |
documentation. The <i>study_data</i> field points to the binary study data, and
|
85 |
this is what you must save (not the <b>pcre_extra</b> block itself). The length
|
86 |
of the study data can be obtained by calling <b>pcre_fullinfo()</b> with an
|
87 |
argument of PCRE_INFO_STUDYSIZE. Remember to check that <b>pcre_study()</b> did
|
88 |
return a non-NULL value before trying to save the study data.
|
89 |
</P>
|
90 |
<br><a name="SEC3" href="#TOC1">RE-USING A PRECOMPILED PATTERN</a><br>
|
91 |
<P>
|
92 |
Re-using a precompiled pattern is straightforward. Having reloaded it into main
|
93 |
memory, you pass its pointer to <b>pcre_exec()</b> or <b>pcre_dfa_exec()</b> in
|
94 |
the usual way. This should work even on another host, and even if that host has
|
95 |
the opposite endianness to the one where the pattern was compiled.
|
96 |
</P>
|
97 |
<P>
|
98 |
However, if you passed a pointer to custom character tables when the pattern
|
99 |
was compiled (the <i>tableptr</i> argument of <b>pcre_compile()</b>), you must
|
100 |
now pass a similar pointer to <b>pcre_exec()</b> or <b>pcre_dfa_exec()</b>,
|
101 |
because the value saved with the compiled pattern will obviously be nonsense. A
|
102 |
field in a <b>pcre_extra()</b> block is used to pass this data, as described in
|
103 |
the
|
104 |
<a href="pcreapi.html#extradata">section on matching a pattern</a>
|
105 |
in the
|
106 |
<a href="pcreapi.html"><b>pcreapi</b></a>
|
107 |
documentation.
|
108 |
</P>
|
109 |
<P>
|
110 |
If you did not provide custom character tables when the pattern was compiled,
|
111 |
the pointer in the compiled pattern is NULL, which causes <b>pcre_exec()</b> to
|
112 |
use PCRE's internal tables. Thus, you do not need to take any special action at
|
113 |
run time in this case.
|
114 |
</P>
|
115 |
<P>
|
116 |
If you saved study data with the compiled pattern, you need to create your own
|
117 |
<b>pcre_extra</b> data block and set the <i>study_data</i> field to point to the
|
118 |
reloaded study data. You must also set the PCRE_EXTRA_STUDY_DATA bit in the
|
119 |
<i>flags</i> field to indicate that study data is present. Then pass the
|
120 |
<b>pcre_extra</b> block to <b>pcre_exec()</b> or <b>pcre_dfa_exec()</b> in the
|
121 |
usual way.
|
122 |
</P>
|
123 |
<br><a name="SEC4" href="#TOC1">COMPATIBILITY WITH DIFFERENT PCRE RELEASES</a><br>
|
124 |
<P>
|
125 |
The layout of the control block that is at the start of the data that makes up
|
126 |
a compiled pattern was changed for release 5.0. If you have any saved patterns
|
127 |
that were compiled with previous releases (not a facility that was previously
|
128 |
advertised), you will have to recompile them for release 5.0 and above.
|
129 |
</P>
|
130 |
<P>
|
131 |
If you have any saved patterns in UTF-8 mode that use \p or \P that were
|
132 |
compiled with any release up to and including 6.4, you will have to recompile
|
133 |
them for release 6.5 and above.
|
134 |
</P>
|
135 |
<P>
|
136 |
All saved patterns from earlier releases must be recompiled for release 7.0 or
|
137 |
higher, because there was an internal reorganization at that release.
|
138 |
</P>
|
139 |
<br><a name="SEC5" href="#TOC1">AUTHOR</a><br>
|
140 |
<P>
|
141 |
Philip Hazel
|
142 |
<br>
|
143 |
University Computing Service
|
144 |
<br>
|
145 |
Cambridge CB2 3QH, England.
|
146 |
<br>
|
147 |
</P>
|
148 |
<br><a name="SEC6" href="#TOC1">REVISION</a><br>
|
149 |
<P>
|
150 |
Last updated: 06 March 2007
|
151 |
<br>
|
152 |
Copyright © 1997-2007 University of Cambridge.
|
153 |
<br>
|
154 |
<p>
|
155 |
Return to the <a href="index.html">PCRE index page</a>.
|
156 |
</p>
|