home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 35 Internet
/
35-Internet.zip
/
rxdecode.zip
/
RxDecode.txt
< prev
next >
Wrap
Text File
|
1993-11-12
|
6KB
|
131 lines
RXDECODE
========
RxDecode was written in REXX and is a program which automatically assembles
UU-encoded- and XX-encoded-pieces into whole files. While doing that it will
strip any mail-headers, mail-footers, Unix-shar- and other Unix-scripts. Pieces
which belong together may be saved into one file, rather than as separated
files.
As it was developed in the course of almost two years, additional logic went
into the program in order to take into account numerous ways people individually
mark the beginning and the end of UU- and XX-encoded files.
As it stands now, RxDecode is capable of automatically assembling 99.5 % of all
presently existing UU- and XX-encoded files.
In the case that a very exotic manual mark-up of the beginning and ending of
encoded files were used, RxDecode will issue an error-message and keep the
original-files and the temporary file which should contain the clean, original
UU- resp. XX-encoded content. Look-up this file, in order to determine what
went wrong. In the case of such a rare error, you merely need to clean the
original pieces manually, as you would do in any case now.
UUENCODE and XXENCODE
=====================
UUENCODE has roots in Unix and is a way to encode binary files such, that they
become mailable. This means for instance, that no encoded file will have
line-lengths larger than 80 characters. In fact a UU- or XX-encoded file has a
maximum line-length of 61 resp. 62 characters.
Each encoded file SHOULD have a translation table, which would allow any
UUDECODER or XXDECODER to restore the original binary file. Almost all files
just omit that table. RxDecode tries to determine which encoding type a file has
and inserts the translation table, in case it is missing. Therefore a
UUDECODE-program is capable of decoding an XX-encoded file !
The converse is not necessarily true (i.e. a XXDECODing program cannot always
successfully decode a UUencoded file). The reason for this is the translation
table, the original UU-schem used: one of the characters is the blank character.
As UUencoded files can be generated that have blanks at the end of a line, some
mailers just tore those blanks off, in order to save bandwidth in the old days
... that really messed things up. Two solutions were found: one was using an
additional character for the used blank, the other to end each line with a
non-blank-character (normally a capital M). Now the problem for XXdecoders on
UU-encoded files which don't have a translation table lies in the simple fact,
that it is not clear whether a blank or an ` (decimal 96) is used.
For this reason RxDecode analyzes UUencoded files for the usage of `-characters.
If found they will be replaced by blanks, an the original UU-translation table
will be inserted. Hence XXdecoders can work successfully on UU-encoded files
too.
In principal both, UUENCODE/XXENCODE and UUDECODE/XXDECODE have the same logic
in encoding and decoding. They simply differ in the used translation table (the
original UU-translation-table caused troubles in non-ASCII-character sets, e.g.
EBCDIC, therefore the XX-translation-table was created).
The principle is simple: use 64 characters from the base ASCII-set as the
translation character (you need 6 bits to encode them). Map 3 regular
8-Bit-characters into 4 Bytes such, that only the translation characters are
used and that one only needs 7-Bit-ASCII-characters to express them (something
like 11112222B 33334444B 55556666B => 00111122B 00223333B 00444455B 00556666B).
Indicate with the first character in a line, how many encoded characters will
follow in that line. Optionally add a capital M to each line.
Because mailing can be costly, some mailers do not allwo to transport messages
that have more than let's say 1,000 lines. As encoded binary files can consist
of much more than 1,000 lines they are split up into several pieces in order to
circumvent such a limitation (i.e. each chunk has less than 1,000 lines).
Therefore one needs to assemble those pieces and run a decode-program
thereafter. You need to either save each part as a separate file and indicate
it in the extension, e.g. .UU1, .UU2, .XX1, .XX2 (UU stands for UUencoded, XX
stands for XXencoded) etc. or save all the pieces into one file (in the correct
order !!!). RxDecode will harvest all saved pieces and join them in its
processing (removing whatever surrounds the encoded part and doing translations
where necesseray) in a temporary file, which always starts with the letters
"tmp" plus the first letter of file-stem of the encoded pieces. After RxDecode
regenerated the original encoded file it will start UUDECODE or XXDECODE to
decode the file into its original state.
With this package both decoders are enclosed, which work under DOS too as they
were compiled for FAPI (under OS/2 they are windowable, which means that no
full-screen-switching occurs while decoding).
Hint
====
You can use RxDecode for decoding binaries which were encoded e.g. in
<comp.os2.binaries> or <alt.binaries.pictures.fine-art> etc.
RxDecode - usage
================
purpose: concatenates XX- or UU-encoded file chunks and decodes them
usage: RXDECODE [X|U] [/B]
option [X|U]: X ... use XXDECODE to decode UU- and XX-encoded files
U ... use UUDECODE to decode UU- and XX-encoded files
option [/B]: /B ... show output in black/white (no ANSI-colors)
This program decodes XX- or UU-encoded files (even if split), e.g.:
chunks-order in file extension:
foo.uu1 foo.uu2 foo.uu3 foo.uu4 foo.uu5 foo.uu6
foo.uu7 foo.uu8 foo.uu9 foo.u10 foo.u11 foo.u12
chunks-order in file-body:
foo1.uue foo2.uue foo3.uue foo4.uue foo5.uue foo6.uue
foo7.uue foo8.uue foo9.uue foo10.uue foo11.uue foo12.uue
normal encoded file:
foo.xxe
It handles XX- and UU-encoded files, removes mail-headers and mail-trailers,
as well as information supplied by the sender. In addition it takes care of
newer UU-encoded files which changed the translation-table. Chunks are ordered
in the ascending order implied by the chunks-number (serial-number).
Hint: A 'chunk' may contain several parts of an encoded file.
1993-11-12
Rony G. Flatscher
Wirtschaftsuniversitaet Wien
Vienna/Austria/Europe