- UUOPT_VERSION
- (string, read-only)
Retrieves the full version number of the library, composed as
MAJOR.MINORplPATCH
(the major and minor version
numbers and the patchlevel are integers).
- UUOPT_FAST
- (integer, default=0)
If set to 1, the library will assume that each input file consists of
exactly one email message or newsgroup posting. After finding encoded
data within a file, the scanner will not continue to look for more
data below. This strategy can save a lot of time, but has the drawback
that files also cannot be checked for completeness - since the
scanner does not look for ``end'' lines, we don't notice them missing.
This flag does not have any effect on MIME multipart messages, which
are always scanned to the end (alas, the Epilogue will be skipped).
Actually, with this flag set, the scanner becomes more MIME-compliant.
- UUOPT_DUMBNESS
- (integer, default=0)
As already mentioned, the library evaluates
information found in the part's ``Subject'' header line if
available. The heuristics here are versatile, but cannot be guaranteed
to be completely failure-proof. If false information is derived, the
parts will be ordered and grouped wrong, resulting in wrong decoding.
If the ``dumbness'' is set to 1, the code to derive a part number is
disabled; it will then be assumed that all parts within a group appear
in correct order: the first one is assigned number 1 etc. However,
part numbers found in MIME-headers are still used (I haven't yet found
a file where these were wrong).
A dumbness of 2 also switches off the code to select a unique
identifier from the subject line. This does still work with
single-part files6 and might work with multi-part files, as long as
they're in correct order and not mixed. The filename is found on
the first part and then passed on to the following parts.
This option only takes effect for files scanned afterwards.
- UUOPT_BRACKPOL
- (integer, default=0)
Series of multi-part postings on the Usenet usually have subject lines
like ``You must see this! [1/3] (2/4)''. How to parse this
information? Is this the second part of four in a series of three
postings, or is it the first of three parts and the second in a series
of four postings? The library cannot know, and simply gives numbers in
() parentheses precedence over number in [] brackets. If this
assumption fails, the parts will be grouped and ordered completely
wrong.
Setting the ``bracket policy'' to 1 changes this precedence.
If now both parentheses and brackets are present, the
numbers within brackets will be evaluated first.
This option only takes effect for files scanned afterwards.
- UUOPT_VERBOSE
- (integer, default=1)
If set to 0, the Message Callback will not be bothered with messages
of level
UUMSG-_MESSAGE or
UUMSG-_NOTE.
The default is to generate these messages.
- UUOPT_DESPERATE
- (integer, default=0)
By default, the library refuses to decode incomplete files and
generates errors. But if switched into ``desperate mode'' these kinds
of errors are ignored, and all available data is decoded.
The usefulness of the resulting corrupt file depends on the type of
the file.
- UUOPT_IGNREPLY
- (integer, default=0)
If set to 1, the library will ignore email messages and news postings
which were sent as ``Reply'', since they are less likely to feature
useful data. There's no real reason to turn on this option any more
(earlier versions got easily confused by replies).
- UUOPT_OVERWRITE
- (integer, default=1)
When the decoder finds that the target file already exists, it is
simply overwritten silently by default. If this option is set to 0,
the decoder fails instead, generating a
UURET-_EXIST error.
- UUOPT_SAVEPATH
- (string, default=(empty))
Without setting this option, files are decoded to the current
directory. This ``save path'' is handled as prefix to each
filename. Because the library does not know about directory layouts,
the resulting filename is simply the concatenation of the save path
and the target file, meaning that the path must include a final
directory separator (slash, backslash, or whatever).
- UUOPT_IGNMODE
- (integer, default=0)
Usually, the decoder tries to restore the file mode found on the
``begin'' line of uuencoded and xxencoded files. This is
turned off if this option is set to 1.
- UUOPT_DEBUG
- (integer, default=0)
If set to 1, all messages will be prefixed with the exact sourcecode
location (filename and line number) where they were created. Might be
useful if this is not clear from context.
- UUOPT_ERRNO
- (integer, read-only)
This ``option'' can be queried after an operation failed with
UURET-_IOERR and returns the
errno value that originally caused the problem. The ``real''
value of this variable might already be obscured by secondary
problems.
- UUOPT_PROGRESS
- (uuprogress, read-only)
Returns the progress structure. This would only make sense in
multi-threaded environments where the decoder runs in one thread and
is controlled from another. Although some care is taken while updating
the structure's values, there might still be synchronization problems.
- UUOPT_USETEXT
- (integer, default=0)
If this flag is true, plain text files will be presented for
``decoding''. This includes non-decodeable messages as well as
plain-text parts from MIME multipart messages. Since they usually
don't have associated filenames, a unique name will be created from a
sequential four-digit number.
- UUOPT_PREAMB
- (integer, default=0)
Whether to use the plain-text preamble and epilogue from MIME
multipart messages. The standard defines they're supposed to
be ignored, so there's no real reason to set this option.
- UUOPT_TINYB64
- (integer, default=0)
Support for tiny Base64 data.
If set to off, the scanner does not recognize stand-alone Base64
encoded data with less than 3 lines. The problem is that in some
cases plain text might be misinterpreted as Base64 data, since,
for example, any four-character alphanumerical string like ``Argh''
appearing on a line of its own is valid Base64 data. Since encoded
files are usually longer, and there is considerable confusion about
erroneous Base64 detection, this option is off by default. There's
probably no need to present this option separately to the user. It's
reasonable to associate it with the ``desperate mode'' described
above.
Note that this option only affects stand-alone data. Input
from Mime messages with the encoding type correctly specified in
the ``Content-Transfer-Encoding'' header is always evaluated.
There is also no problem with encoding types different than Base64,
since they have an explicit notion of the beginning and end of a
file, and no danger of misinterpretation exists.
- UUOPT_ENCEXT
- (string, default=(empty))
When encoding into a file on the local disk, the target files
usually receive an extension composed of the three-digit part
number. This may be considered inappropriate for single-part files.
If this option is set, its value is attached to the base file name as
extension for the target file. A dot `.' is inserted automatically.
When using uuencoding, a sensible value might be ``uue''.
This option does not alter the behaviour on multi-part files, where
the individual parts always receive the three-digit part number as
extension.
- UUOPT_REMOVE
- (integer, default=0)
If true, input files are deleted if data was successfully decoded from
them. Be careful with this option, as the library does not care if the
file contains any other useful information besides the decoded
data. And it also does not and can not check the integrity of the
decoded file. Therefore, if in doubt of the incoming data, you should
do a confidence check first and then delete the relevant input files
afterwards. But then, this option was requested by many users.
- UUOPT_MOREMIME
- (integer, default=0)
Makes the library behave more MIME-compliant. Normally, some liberties
are taken with seemingly MIME files in order to find encoded data
within it, therefore also finding files within broken MIME
messages. If this option is set to 1, the library is more strict in
its handling of MIME files, and will for example not allow Base 64
data outside of properly tagged subparts, and will not accept
``random'' encoded data.
You can also set the value of this option to 2 to enforce strict MIME
adherance. If the option is 1, the library will still look into plain
text attachments and try to find encoded data within it. This causes
for example uuencoded files that were then sent in a MIME envelope to
be recognized. With an option value of 2, the library won't even do
that, trusting all MIME header information.