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 or 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. saving e-mail containing UU- or XX-encoded data =============================================== Just save the e-mail which contains encoded data with *any* name like "aha.uu1" or "aha.xx1". If the encoded file was split over several e-mails than save the additional chunks with "aha.uu2", "aha.uu3", "aha.uu?" until all chunks are saved (use .xx2, .xx3. xx?). After that start RxDecode. If you are working on a FAT-system and have more than nine pieces proceed with using extensions like ".u10, .u11, ..." or ".x10, .x11, ...". If you have multipart encoded files as described above, you could also append subsequent pieces to the existing "aha.uu1" resp. "aha.xx1". After that start RxDecode. It will extract the encoded parts from the files (judging the filename and the extension), combine them into a temporary file and decode it. The decoded file-name will be the name given in the encoded file itself, hence it does not matter how you name the chunks. 1993-11-14 Rony G. Flatscher Wirtschaftsuniversitaet Wien Vienna/Austria/Europe