Spherical UUDecode 1.11
Copyright © 1999-2000 Dominik Deobald <dominik@spherical-bytes.com>
Spherical Bytes: http://www.spherical-bytes.com
[001] Description
Spherical UUDecode is a program to decode files in UUE or Base64 and
Quoted Printable-format, usually used to create text-files from binaries
to transfer them via mail (Usenet or eMail) over the Internet (or any
other net).
I wrote this program, because I needed one that just decodes but
that supports long filenames. I tried several other tools, which should
do that job, but none of them worked good for me. Some created huge
output-files which contained all small files which should have been
created from several input files linked together to one big file. Others
did not work because the input-files contained mail-headers, too, so the
decoder was not able to find the coded parts. Just in case you want to
know, why I invented the wheel for the 1378193rd time.
[002] Disclaimer, Licence & Copyright
Spherical UUDecode is distributed "AS IS" with no further service or
guarantees implied. You want it, you use it. That's it. I won't help
you and cannot be held responsible, if you somehow manage to crash
your hard-disk with this program!
However don't hesitate to ask for further features you want to see
in future releases of this software or to report bugs you have found.
You may use, copy and distribute this program for free as long as you
do not remove my name, do not discompile or change the program-
executable or this text-file.
The software and this documentation are Copyright (c) 1999-2000 by
Dominik Deobald <dominik@spherical-bytes.com>
This software was developed using Free Pascal, a freeware pascal
compiler, which is available at http://www.freepascal.org
[003] Usage
Nothing fancy here. Just start UUDecode with the files you want to
decode as parameter.
UUDECODE [parameter] filespec [parameter]
Where filespec is something like FILE.UUE, *.UUE or *.* (Yes, you MAY
use wildcarts!).
Supported parameters are the following:
-ltrim
If you have text-files containing encoded parts which have spaces in
front of them in each line (maybe by converting HTML to simple text
or however), you can force Spherical UUDecode to ignore leading
spaces.
-neveroverwrite
If the file which should be decoded or another file with the same
filename already exists, it will not be overwritten and the file
will be skipped.
-alwaysoverwrite
In the same case as above the file will be overwritten.
-autorename
In the same case as above, Spherical UUDecode tries to find a new
filename by adding "(1)", "(2)" and so on to the filename until it
finds an unused filename.
-neverask
Suppresses all required user-interaction (questions) and defaults
to the following values (if not changed by other parameters)
- - Never overwrite existing files
- - Files without given filename are called "Unnamed.dat"
[004] Known Problems
I'm not sure if it is a problem for anyone, but Spherical UUDecode does
not support splitted UUEs or Mime-Files! I just thought, I should
mention it.
[005] Updates
Updates of this software can be found on Spherical Bytes' Webpage:
http://www.spherical-bytes.com
[006] Appendix
[00a] What's new?
* Bugfix
+ Added or removed function
- General changes
1.00 -> 1.02: * 1999-01-04 Files decoded from UUE-Source always were 64
bytes too long. Fixed!
1.02 -> 1.04: + 1999-09-19 Added parameter "-ltrim"
+ 1999-09-19 If encoded File contains a full path with the
files filename, it will be truncated, if the
file could not be generated otherwise (eg.
o:\comm\nscape30\filename.xxx will be cut
down to filename.xxx)
1.04 -> 1.07: + 1999-11-19 Added parameter "-autorename"
+ 1999-11-19 Added parameter "-alwaysoverwrite"
+ 1999-11-19 Added parameter "-neveroverwrite"
+ 1999-11-19 Added parameter "-neverask"
1.07 -> 1.09: * 2000-02-25 Cosmetic fix if there is no filename given for
UUE but the software should not ask the user.
+ 2000-02-27 Added Support for "Quoted Printable" files; had
to make bigger internal changes to add
rudimentary MIME-Support and to work around a
bug (?) in Free Pascal.
+ 2000-02-27 Now supports just $0D (and still $0D$0A) as
End Of Line.
* 2000-02-27 UUDecode did not accept filespec after
parameters.
* 2000-03-02 Path of filenames with path will now be cut off
in any case because of problems
1.09 -> 1.10: * 2000-03-03 Could not specify path for files outside the
current working directory as input files. Fixed!
1.10 -> 1.11: * 2000-06-06 Fixed problem with illegal output-filenames
(e.g. containing "?" or "*")
* 2000-06-06 Fixed bug in routine to find unused filename by
adding (1), (2), ... if the filename does only
consist of an extension (e.g. ".inf")
[00b] UUE
You can easily recognize UUE-blocks. They start with a line like this:
begin 666 filename.dat
"begin" is always contained in there.
Then there comes a number. This number is used in UNIX-Systems and holds
the information needed for the system to decide, who is allowed to use
the created file and who is not.
This number has absolutely no effect on Windows/DOS-Computers as these
to not have support for locking out users from files. On UNIX (e.g.
Linux) this has the same format as the one given with CHMOD-command
(Rights for owner/group/others).
After that there should come an filename - it might be left out.
After that line there follow lots of lines with the same width, most of
them beginning with "M" (That "M" gives information about the length of
the following line, which means: 45 Bytes encoded in 60 Characters).
After that first Char there are the encoded data. Four Chars result in
three Bytes output file.
The UUE-Block ends with an line that contains an "end" right at the
beginning with nothing else in that line.
[00c] Base64
The look of Base64-encoded blocks is almost the same as UUE. There is
just another header (Which is defined be the Mime-Specs defined in RFC
1521) and there is no length information at the beginning of each line
(which results in smaller output files).
The header is something like this:
Content-Type: Application/Octet-stream; name="filename.dat"
Content-Transfer-Encoding: Base64
Spherical UUDecode just needs lines beginning with "Content-", with one
of them containing name="xxxxx" (That's where it gets the filename from)
and a line starting with "Content-Transfer-Encoding: Base64".
[00d] Quoted Printables
Quoted Printables are defined in RFC 1522 and are also part of Mime. The
difference between Base64 and QP is, that QP are better if used on texts
with just some special characters. The text still remains readable, only
special characters are encoded.
The header is almost the same as with Base64:
Content-Type: application/octet-stream;
name="B0000000637.MSG"
Content-Transfer-Encoding: quoted-printable
As mentioned before, the text remains readable. Just some characters
look different. For example "=" becomes "=3D" or upper characters
like "©" become something like "=A9" (Equal-Sign plus Hex-Code of
character).
Copyright © 1999-2000 by Dominik Deobald
|