ZZZO@DHVRRZN1.BITNET.UUCP (04/13/87)
I am a novice in networking and receiving (decoding) UUENCODED files from BITNET-Servers (FINHUTC and UHUPVM1). I tried to receive those files with my IBM-Host. There must be some kind of character-conversion from ASCII to EBCDIC to ASCII: character | (hex 21) changes to ! (hex 5D). What can I do?? Wolfgang Zocher ZZZO at DHVRRZN1.BITNET
jhs@MITRE-BEDFORD.ARPA (04/20/87)
>I am a novice in networking and receiving (decoding) UUENCODED > files from BITNET-Servers (FINHUTC and UHUPVM1). I tried to > receive those files with my IBM-Host. There must be some kind > of character-conversion from ASCII to EBCDIC to ASCII: > character | (hex 21) changes to ! (hex 5D). What can I do?? > > - Wolfgang Zocher ZZZO at DHVRRZN1.BITNET Here are some suggestions from people who have dealt with this problem previously. I hope this will help you solve your problem. -John Sangster / jhs@mitre-bedford.arpa -------------------- From: Mike Vederman <ACS19%UHUPVM1.BITNET@WISCVM.WISC.EDU> Subject: finally, i've figured uudecode ... To: ST Users <INFO-ATARI16@SU-SCORE.ARPA> After many, many problems with BITNET, IBM machines and uudecode, I have found the true answer to having all of my files uudecode. Every single file which has bombed in the past, now decodes perfectly. The normal sequence that I do is to send the file over from the IBM machine (actually we have an AS/9000N) to the AT&T 3B20 and uudecode on the 3B20. Previously, the only two files which worked were UNITERM and uEmacs. Now, however, I have found the solution, but I am uncertain as to the exact cause. Here is what I do. First, while in Xedit, I set the logical record length to 61, then I set the record format to fixed. The following commands do this: set lrecl 61 set recfm f now, when I send the file to the 3B20, I enter the command: sf file uue to acs19 at uhnix1 to receive on the 3B20, I enter the command: receive $job/pnch6 >file.uue (since the 3B20 is hooked up as a punch machine (yuck). What you do may be different, but I know setting the logical record length and the record format have made all of my files work.) When I get to the 3B20, I do have to fix the file a little bit. I go to the last line and delete the blanks to end of line, after 'end'. Then I go up one line and make sure that there is only 1 (one) blank on the second to the last line. Then I save the file and uudecode it. All the files I have tried thus far have worked, and most of these have always bombed. Mike ------------------------------------------------------------------------------ From: <MHD@slacvm.bitnet> Reply-To: MHD%SLACVM.BITNET@forsythe.stanford.edu Like others, I had little success at first in decoding the uuencoded files on this net. After looking closely at the files I noticed that the tilde character (~) was present when it should not have been. Upon further inspection I found that the carat character (^) was missing in all files. I tried a global change of tilde to carat and had no further trouble Perhaps many others have been screwed up in the same way by IBM machines in the net. Perhaps at other sites just one other character is screwed up. Give it a try, preferably do it first on a .ARC file where deARCing will show errors on the CRC checks. The only characters that should be in the uuencoded files are: space( ) through underline(_), ascii 20 through 5F. All of these should be present in a file of reasonable length. Note: The tilde and carat may get screwed up in this file. They are ascii 7E and 5E respectivly. ------------------------------------------------------------------------------ From: XBR1Y049%DDATHD21.BITNET@WISCVM.WISC.EDU (Stephan Leicht c/o HRZ TH Darmstadt, Germany ) Subject: UUDECODE difficulties / Translation tables I found my troubles in being not able to run some uuencoded programs comming over the net. The translation of the not-Char/circumflex(^)-Char is not unique. Translating it to EBCDIC 5Fhex and sending it over some gateways, it not always returns as EBCDIC 5Fhex, sometimes it returns as EBCDIC 71hex. (I saw it sending it to ucbvax and return) Now I have told our translation table to recognize 71hex as 5Fhex too. Strange ! Maybe that this is a hint for those having no success in uudecoding. Stephan Name : Stephan Leicht Organisation : Computer Center of Technical University Darmstadt, Germany Bitnet : XBR1Y049@DDATHD21 insert all usual & unusual disclaimers here --> ------------------------------------------------------------------------------ From: mcvax!ukc!dcl-cs!bath63!pes@seismo.css.gov (Paul Smee) Organization: Bath University, England Subject: Re: Lattice C and UUDECODE I've found several problems with uudecode, which are caused by the uuencoded file being munged by 'terminal handlers' enroute to me. The symptoms sound like some I've seen complained about, specifically that the file appears to decode, but bombs. On looking at the files, I found 2 different sorts of problem. First, spurious 'control chars' get inserted in some cases. In fact, these appear to always be NULs (0x0) put in as 'delay padding' by someones term handling software. Second, trailing spaces get stripped. It is fairly trivial to modify uudecode to ignore all control chars (less that ASCII space) -- and harmless, as they should not be in a uuencoded file. Then, pad the line out to an arbitrarily large length using spaces (I simply tack 64 spaces on the end, in my buffer, before decoding a line). Appending 64 spaces is crude and inelegant, I know, but it insures that there will be enough in all circumstances, and is a much simpler mod than actually looking to see how many are needed -- especially since the line may contain as yet unprocessed control chars to be thrown away. Since making these trivial changes I've had no problems with uudecoded files. Hope this helps someone... ------------------------------------------------------------------------------ From: <RDROYA01%ULKYVX.BITNET@WISCVM.WISC.EDU> (Robert Royar) Organization: University of Louisville Subject: Another version of uue/decode offered (repost) I have a version of uue/decode that I have been testing and that seems to avoid some of the problems with the present setup. I added some code to the original programs to do some error checking. The format of the files the encoder uses is similar to the current version. If you have the current version, you can delete the extra information with your word processor. My version adds the following things: 1. It breaks up long files so that each uuencoded file is no more than 300 lines long. 2. It places and include directive at the end of each file at the break so the companion program can reassemble the files into a program. >********Note especially*********Besonders bemerken!!!************************ > 3. It adds a key table at the beginning of each file so that > the decoder can index into this table to find the value for > letters in the file. I discovered that the errors I had with > uudecode were often because a mailer had changed each instance > of a character to something else. This solves that problem. > > 4. It checks the key table for integrity before it decodes the > file. This way if both 'H' and 'Z' have been changed to ' ', > it will exit and tell you. >***************************************************************************** 5. If it finds a letter in the file that was not in the key table, it issues a warning telling what the character was, the filename, and the current file position. 6. It appends a 'part' letter (a-z) at the end of each output line to avoid truncation problems. This program makes uue/decoding somewhat simpler than it has been because it breaks the files up into parts automatically and reassembles them. It actually is smaller and runs faster than the net version of the program because I used freopen() to cut down on file pointers and I used register variables where possible. If you are interested in this program, drop me a line and I will post it to you. Robert Royar rdroya01@ulkyvx.bitnet ----------------------- Summary (jhs): The main problems seem to be translation of characters by various hosts and gateways, and truncation of lines with trailing blanks. The key table idea will solve the first problem, to the extent that it can be solved. Putting a nonblank, e.g. x, as character 62 of the line at the encoder will solve the second problem, provided the decoder is designed properly. The suggestion made above of padding the received line with blanks may not always work, as blanks produced by uuencoding zeros may have been trimmed and replaced with garbage. If you are sure that they have merely been trimmed, then filling out the line with blanks ought to work. When all else fails, the "BINHEX/HEXBIN" approach devised by Dan Fleysher in the 8-bit Atari world will probably work -- it basically encodes 18 bytes into 36 bytes using the Hex representation of the data, 0-9 and A-F. NOBODY seems to monkey with these characters in networks. The size was chosen for printability on 38-character 800/XL/XE screens. For compatibility, you might as well keep the line length the same. File format and checksum details available on request. -jhs