home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1997 March / Simtel-MSDOS-Mar1997-CD2.iso / 00_start / transgid.txt < prev    next >
Text File  |  1990-04-21  |  27KB  |  600 lines

  1. [File; TRANSGID.TXT                        Revision date; April 23, 1990]
  2.  
  3.               A SHORT GUIDE TO NETWORKING AND FILE TRANSMISSION
  4.                            Erich Neuwirth
  5.                  Institute of Statistics and Computer Science
  6.                          University of Vienna
  7.                                Austria
  8.                       (A4422DAB@AWIUNI11.BITNET)
  9.  
  10.  
  11. GENERAL PRINCIPLES OF SENDING FILES IN ELECTRONIC NETWORKS
  12.  
  13. Networking is mainly used in 2 ways:
  14.  
  15.       Electronic mail
  16.       Sending (binary) files
  17.  
  18. This paper tries to explain what some of the differences are and how
  19. one of the two transmission methods sometimes can be (mis)used for
  20. tasks which seem to belong to the other method.
  21.  
  22. Electronic Mail
  23.  
  24. Electronic mail means you are sending text from one computer site to
  25. another site.  Letters of text are coded as numbers internally within
  26. computers.  Problems arise from the fact that the same letter may be
  27. represented by different numbers on different computer systems and vice
  28. versa the same number may yield a different letter on different computer
  29. systems.  Mostly we are concerned with two such representation systems
  30. for letters by numbers.
  31.  
  32.      ASCII (which is used on IBM-compatible PCs and on most non-IBM
  33.             mainframe computers)
  34.      EBCDIC (which is used on IBM (and compatible) mainframe computers)
  35.  
  36. When you are sending text from one computer to another computer the
  37. computers "think" they only are sending numbers.  People reading or
  38. writing text, on the other hand, expect characters, so some
  39. interpretation of the numbers producing the text must take place.  Simply
  40. transferring the text file as a sequence of numbers (which is what it
  41. looks like to the computers involved) would result in an unreadable file
  42. on the receiving computer system.  Therefore when using computers with
  43. different character representation systems the transmission usually
  44. involves a "translation process" which has the net effect of yielding a
  45. different "sequence of numbers" (= file)  on the receiving machine, but
  46. this file usually gives the same letters when read as a text file.
  47. Usually these translation processes work quite well for letters
  48. (lowercase and uppercase) and digits.  Quite often you will encounter
  49. problems with special characters like parentheses, brackets, tildes,
  50. carets and so on.  If you are interested in merely transferring texts
  51. this is not much of a problem, because even if some special characters
  52. get scrambled it is usually not too hard to reconstruct the original
  53. text by normal editing.  If you are setting up a new communications link
  54. it is a good idea to send a file containing all printable characters
  55. with descriptions and to test if they arrive at the other end as they
  56. should.  At the end of this paper you will find an example of how such a
  57. test file could look.  Of course such a file should be sent from both
  58. ends of the line because the scrambling process in many cases is
  59. asymmetrical, so different transpositions happen in the two different
  60. communication directions.  Closely inspecting the file you receive will
  61. show you which characters are changed during the transmission process.
  62.  
  63. Now three different events can happen:
  64.  
  65. 1) You receive all the characters as they should be:
  66.  
  67.    Action: Don't worry, be happy
  68.  
  69. 2) Some characters are not what they should be, but different characters
  70.    still are different (even when not identical with their original)
  71.  
  72.    Action: Do worry, but not too much.  In this case you can use the FIND
  73.    and REPLACE function of your text editing program to restore the
  74.    original meaning of the file.  You even could program a macro in your
  75.    text editor (if you don't know what that means just ignore this
  76.    sentence) which automatically performs the "retranslation" process.
  77.  
  78. 3) Some characters are scrambled and different characters in the source
  79.    text file come out as identical characters at the receiving end.
  80.  
  81.    Action: Do worry, because this is the worst possible situation.  It is
  82.    not possible to construct an automatic "retranslation" process.  As
  83.    long as you are only concerned with text you will not have too many
  84.    problems, because letters, digits, commas and periods usually are not
  85.    scrambled when sent between different computer systems.  If these
  86.    characters also are scrambled the transmission process does not
  87.    deserve the name "communication process" any more and you should talk
  88.    to the technical people in charge of the transmission channel to take
  89.    care of these problems.
  90.  
  91. Things become more difficult when you want to send data files or program
  92. source files.  Files of this kind usually contain special characters
  93. like parentheses and to reconstruct the original text of the file you
  94. usually have to edit the file you received by hand and to infer from the
  95. context the original meaning of a recognizably incorrect character.
  96.  
  97. The automatic file transfer usually takes place between mainframe
  98. computers.  So the most simple situation with text file transfer is that
  99. you use the editor on your mainframe computer to create your text and
  100. then you use the mailing program on the mainframe to send the text file
  101. (sometimes called e-mail or note) to its destination.  At the
  102. destination site the receiver then can receive the file and read it with
  103. the help of the text editor program on the receiving mainframe computer.
  104.  
  105. Sometimes the situation is more difficult.  The file you want to send
  106. may exist on your PC, but not yet on the mainframe which is your
  107. entrance to the international computer networks.
  108.  
  109. There is an important detail you have to take care of here.
  110. Usually you can write texts on a PC using two different kinds of
  111. programs to write with:
  112.        Text editor programs or
  113.        word processing programs
  114.  
  115. Text files produced by text editing programs usually give no problems
  116. when you try to send them over a network.  With most word processor files
  117. you will experience difficulties.  But most word processing programs have
  118. a special way of saving your text as a "plain ASCII file".  Remember to
  119. save your texts with this option if you intend to send them over
  120. networks.  And if you are still considering which word processing program
  121. you should select for your personal use, only select a program which
  122. offers this option.  If you do not know yourself how to verify the
  123. existence of such an option ask somebody more experienced than you to
  124. help you to find out.
  125.  
  126. Now you have to find a way to transfer the file from your PC to your
  127. mainframe computer.  For this purpose you need a file transfer program on
  128. the PC and on the mainframe.  Different varieties of programs of this
  129. kind exist, but the prevalent program in an academic environment at the
  130. moment is KERMIT.  To use KERMIT to transfer files you need the version of
  131. KERMIT for your PC and an installed version of KERMIT on the mainframe.
  132. The mainframe KERMIT is not your responsibility, you just have to
  133. find out from the staff of your computing center if they already have
  134. installed this program.  If they have not done so yet you should tell them
  135. to do so because KERMIT is one of the very few hardware independent
  136. standards and it should be supported.  Additionally, all KERMIT versions
  137. are in the Public Domain, so they do NOT COST MONEY.  Your local
  138. computing center also should help you to find the version of KERMIT you
  139. need for your PC.
  140.  
  141. KERMIT is a program used for 2 purposes; namely for using your PC as a
  142. terminal to your mainframe computer and for transferring files between
  143. these two systems.
  144.  
  145. Now things start to be complicated (even more complicated? I hear you
  146. complain!).
  147.  
  148. In this paper we will not deal with using KERMIT as a terminal emulator.
  149. There are many ways to do this and it mainly depends on which kind of
  150. mainframe you are using.  You should try to get some help from the people
  151. from you local computing center who can show you exactly how to use
  152. KERMIT for this purpose.
  153.  
  154. An additional remark: If you only want to use KERMIT as a "terminal
  155. emulator", which means using your PC as a terminal, you do not need
  156. KERMIT on the mainframe computer you are connecting to.  The mainframe
  157. version is only needed for file transfer between the mainframe and your
  158. PC.
  159.  
  160. Now things become really complicated!  The PC KERMIT has only one way of
  161. transferring files.  But the mainframe version usually has two ways
  162. (called "modes" by computer scientists).  One way is text mode, the other
  163. way is binary mode.  Text mode is used to transfer text files.  E-mail
  164. consists of text files so it is this mode you need for downloading e-
  165. mail from your mainframe to your PC.  Usually you need not care too
  166. much because practically all mainframe versions of KERMIT use text mode
  167. for file transfer if not told otherwise explicitly.
  168.  
  169. So simply transferring a text file from your PC to the PC of somebody
  170. else you want to send it to can be done using the following steps:
  171.  
  172. 1) Upload the text file from your PC to your mainframe with KERMIT in
  173.    text mode
  174.  
  175. 2) Use the mail facilities of your mainframe to send the text file as
  176.    mail to the intended receiver
  177.  
  178. 3) The receiver finally has to download this mail file (it still is
  179.    text) with KERMIT in text mode to his/her PC
  180.  
  181. In most cases the received file is identical with the original file.
  182. Letters and digits arrive as they should.
  183.  
  184. The idea behind text mode of KERMIT is that the meaning of characters is
  185. preserved, so when transferring in text mode KERMIT automatically
  186. adjusts for different systems of character representations on the
  187. mainframe and on the PC.
  188.  
  189. You might find that some of the special characters do not arrive as they
  190. should, but this usually is no problem when the text is only intended
  191. for reading and not as input to some computer program.
  192.  
  193. Later we will see what you can do if you have to send a text file
  194. containing special characters and want to make sure that these
  195. characters arrive unchanged.
  196.  
  197.  
  198.  
  199. TRANSFERRING NON-TEXT FILES
  200.  
  201. It is becoming even more difficult in this section, but if you want to
  202. send programs and data files usable on other machines it is important
  203. that you understand this section.
  204.  
  205. Networks can also be used to send PC programs over the network.  If you
  206. want to send a program to somebody with the same kind of PC you have, the
  207. basic procedure is very much like the procedure for transferring text
  208. files from your PC via the network to somebody else's PC.
  209.  
  210. The steps involved are:
  211.     Uploading to a mainframe
  212.     Using the sending facilities of the network
  213.     Downloading from the target mainframe to the target PC
  214.  
  215. The difficulties arising with program files are that programs contain
  216. more different symbols than text files.  They especially contain lots of
  217. so called "nonprintable" characters.  You can see this if you try to
  218. look at your program file with a text editor program or a word
  219. processing program.
  220.  
  221. The simplest solution to transferring program files and like things
  222. (called binary files in computer terminology) is to use the binary
  223. transfer mode of your mainframe KERMIT to upload the program to your
  224. mainframe.  Binary mode means that no translation whatsoever takes place
  225. while sending the file (remember, sending text files often involves a
  226. translation process).  Now you can use the facilities of your mainframe
  227. for sending files over the network.  Sending a file is not the same as
  228. sending a text as mail.  Mailing implies that your text is put into the
  229. electronic equivalent of an envelope.  Sending a files does not add the
  230. envelope, so the file being sent is (almost) identical with what you
  231. have on your PC.  The receiver then can download the file to his/her PC
  232. also using the binary transfer mode of his/her mainframe KERMIT and the
  233. PC version of KERMIT.
  234.  
  235. This file transfer quite often does not work.  Some reasons may be: the
  236. two mainframes involved come from different manufacturers, some
  237. intermediate mainframe makes problems or the file is passing through
  238. different networks.  One situation where it makes sense to try this way
  239. of sending binaries is when both mainframes are members of the EARN,
  240. BITNET or NETNORTH networks.  It usually does not work when the
  241. mainframes belong to different networks like EARN and JANET.
  242.  
  243. Now what can we do when we want to send a program or a data file from
  244. an EARN site to a JANET site?
  245.  
  246. The main idea is translating your binary file (the one you cannot read
  247. because it contains nonprintable characters) into a file consisting only
  248. of printable characters.  The most popular scheme for doing such a
  249. translation is the UUENCODE/UUDECODE process.  It implies 2 programs,
  250. one usually called UUENCODE and the other one UUDECODE.  UUENCODE takes
  251. a binary file and converts it into a file consisting only of printable
  252. characters.  UUDECODE reverses this process and restores the original
  253. binary files from the encoded file.  So what do you need these programs
  254. for?
  255.  
  256. You UUENCODE the binary file and upload it to your mainframe (using the
  257. text mode of your mainframe KERMIT).  Since it consists of printable
  258. characters only, you can incorporate it into a mail file you send.  This
  259. mail file hopefully arrives at its destination and the receiver can
  260. download the mail from his/her mainframe to the local PC.  Then it is
  261. mandatory to remove the "electronic envelope" from the mail file.  An
  262. appendix will describe how an UUENCODEd file looks and how to recognize
  263. the parts forming the "envelope".  Then the UUDECODE program can be used
  264. to translate the UUENCODEd version of the file back into its binary
  265. version.
  266.  
  267. If you want to use this process you have to get hold of a copy of the
  268. UUENCODE and UUDECODE program.  It is not possible (at least not in an
  269. easy way) to send this programs over networks if you have no experience
  270. with encoding and decoding binary files.  These programs are binary files
  271. themselves and we cannot send unencoded binary files.  So we would need
  272. the binary files already to translate the encoded versions into the
  273. binary version.  It is a "who is first, the hen or the egg" kind of
  274. situation.  There are ways of solving these problems, but the solutions
  275. involve a nontrivial amount of technical knowledge and also depend very
  276. much on the circumstances of the PCs and mainframes involved.
  277.  
  278. (For the more technically inclined: we could send the source files of
  279. the translation programs as text files, but then we have to be sure that
  280. the recipient has a compiler for the programming language we are using.)
  281.  
  282. So quite often the easiest way of setting up an environment where file
  283. transfer is possible involves sending a disk with the UUNCODE/UUDECODE
  284. programs to the sites involved.  Once the programs are available file
  285. transfer can start.
  286.  
  287. Now let us look what an UUENCODED file looks like:
  288.  
  289. ------- the file starts directly below this line ------------
  290. begin 644 erich.com
  291. MZV>0("`@("`@("`@("`@("`@4V\@>6]U(&UA;F%G960@=&\@555$14-/1$4@
  292. M=&AE('1E<W0@9FEL92X-"B`@("`@("`@("`@("`@("`@("`@("`@0V]N9W)A
  293. ;='5L871I;VYS(2$-"B0:N@,!M`G-(;@`3,TA
  294. `
  295. end
  296. ------ the UUENCODED file ended just above this line -------
  297.  
  298. The first line always contains the word 'begin' starting in the first
  299. column.  The next item is a number which you can safely ignore and the
  300. last item is the name of the UUENCODEd file.  The last line of the
  301. encoded file consists of the word "end" starting in the first column and
  302. nothing else.  Some encoding programs add a line containing size
  303. information about the encoded file, but this is not really necessary.
  304. If you use the UUENCODing program on your PC the encoded version of the
  305. file usually has the same first part of the file name as the file being
  306. encoded and the file extension .UUE So encoding a program ERICH.COM
  307. would produce a file ERICH.UUE .  This file ERICH.UUE is the one that
  308. should be uploaded and sent using the mail facilities of the network.
  309. At the receiving site the mail file sent can be downloaded to the PC.
  310.  
  311. The downloaded file usually looks similar to the following example:
  312.  
  313. ---------------- this line is not part of the file -----------
  314. Date: Sat 14 Jan 89 06:51:59-EST
  315. From: John R.  Somebody <SOMEBODY@SOMESITE>
  316. Subject: File transfer demonstration
  317. To: The catcher in the rye <CATCHRYE@MYSITE>
  318.  
  319. begin 644 erich.com
  320. MZV>0("`@("`@("`@("`@("`@4V\@>6]U(&UA;F%G960@=&\@555$14-/1$4@
  321. M=&AE('1E<W0@9FEL92X-"B`@("`@("`@("`@("`@("`@("`@("`@0V]N9W)A
  322. ;='5L871I;VYS(2$-"B0:N@,!M`G-(;@`3,TA
  323. `
  324. end
  325.  
  326.   John R.  Somebody   1/14/89
  327.   SOMEBODY@SOMESITE   CATCHRYE@MYSITE    1/14/89 file transfer demonstration
  328.  
  329. --------- this line does not belong to the file any more ---
  330.  
  331. From this example it should be easy to see what the next step is:  Every
  332. line above the "begin" line and every line below the "end" line has to be
  333. removed.  The remaining file the can be decoded using UUDECODE.  If no
  334. additional problems occurred the decoded program is identical with the
  335. binary program the sender wanted to send.  Now for possible
  336. difficulties:  UUENCODEd files contain special characters like brackets.
  337. Now when you are reading a text file you usually can recognize the
  338. intended special character even if it has been changed in a file
  339. transfer process.  But it is not possible to recognize changed
  340. characters in an UUENCODEd file.  So you have to find out if all the
  341. characters arrived unchanged.  For this you can use the method described
  342. at the beginning of this paper, namely sending a file with all
  343. characters together with a verbal description of the characters.  All
  344. remarks from the earlier part of the paper apply.  Inspecting such a file
  345. closely might help you to find out which characters were changed and
  346. into what and with luck you can reverse this exchange process.  The main
  347. problem with the UU scheme is that the set of characters being used
  348. contains special characters.  So a variant of this method has been
  349. devised.  It is call the XXENCODE/XXDECODE process.  Essentially it
  350. functions like UUENCODE/UUDECODE, but the encoded file only contains
  351. letters, digits, and the plus and the minus sign.  The advantage is that
  352. these characters usually are not changed when passed through different
  353. computers, so chances are higher that such a file will arrive unchanged.
  354. As with UUENCODE/UUDECODE you need the programs before you can start
  355. transmission of binary files.  The XX scheme is relatively new, so
  356. usually it is easier to find programs for the UU scheme than for the XX
  357. scheme.
  358.  
  359. It is important to be aware of the fact that UUENCODEd and XXENCODEd
  360. files are more than 30 percent larger than the original file.  This is
  361. the price we have to pay for better transportability.
  362.  
  363. There is one more important concept you should be aware of when
  364. transferring more than one file at a time and/or transferring big files.
  365. It is the concept of an archive.  An archive essentially in one file
  366. created by pasting together and compressing one or more files.  Usually
  367. when transferring a few files you use an archiving program which creates
  368. just one file out of a few files.  This archived file also is smaller
  369. than all the "source" files together.  In the archiving process you need
  370. two programs: the archiving program creating the archive and the
  371. dearchiving program reconstructing the original files.  The advantages of
  372. using archives are:
  373.  
  374. 1) It is impossible to forget a file belonging to a set of files when
  375.    transferring copies of an archive
  376.  
  377. 2) The amount of data to be transferred is smaller and therefore uses
  378.    less disk space and less connect time for transferring them
  379.    electronically.
  380.  
  381. So if you want to send a few files belonging together it is quite common
  382. to create an archive, then to send the archive and then have the
  383. recipient reconstruct the original files by archiving.  When you receive
  384. a file with file name extension ARC it is highly probable that it is an
  385. archive file.  In this case the extension ARC denotes a special
  386. archiving (= pasting together and compressing) scheme.  There is a new
  387. scheme around now which usually can be recognized by the file name
  388. extension ZIP.  The 2 programs needed to be able to work with the ZIP
  389. scheme are PKZIP and PKUNZIP.
  390.  
  391. Let us look at an example of how to use this set of programs.
  392. Let us assume we want to send 3 file named FILEA.TXT, FILEB.DTA and
  393. FILEC.COM.
  394.  
  395. If we execute the command line
  396.  
  397. PKZIP ARCHIVE FILEA.TXT FILEB.DTA FILEC.COM
  398.  
  399. PKZIP will create a file ARCHIVE.ZIP.  This file is our archive and
  400. contains all 3 "source" files in a condensed form.
  401.  
  402. To reconstruct the original files we execute the command line
  403.  
  404. PKUNZIP ARCHIVE
  405.  
  406. which will create the 3 original file FILEA.TXT, FILEB.DTA and
  407. FILEC.COM.
  408.  
  409. There are different programs around for the ARC variant of the process.
  410. ARC and ARCX are a pair performing essentially the same function as
  411. PKZIP and PKUNZIP, PKARC and PKXARC are another pair.  There also is a
  412. program called LHARC which performs archiving and dearchiving functions
  413. with just one program. The difference is that PKZIP and PKUNZIP use the
  414. ZIP scheme whereas ARC, ARCX, PKARC and PKXARC use the ARC scheme and
  415. LHARC uses the LZH scheme.  All these different schemes are
  416. incompatible.
  417.  
  418. If you want to create an LZH-archive similar to the ZIP archive of
  419. the previous example you can do so with the following command:
  420.  
  421. LHARC A ARCHIVE FILEA.TXT FILEB.DTA FILEC.COM
  422.  
  423. This will create a file ARCHIVE.LZH.
  424.  
  425. Extracting the files from the archive is done with the following
  426. command:
  427.  
  428. LHARC E ARCHIVE
  429.  
  430.  
  431. There is a special variant of archive files, so-called self extracting
  432. archives.  In this special case the archive and the dearchiving program
  433. are pasted together.  The result is an executable file (usually with
  434. extension EXE) which, when executed, reconstructs the original files
  435. contained in the archive.  It is not possible to recognize
  436. self-extracting archives from the file name extension, so you have to be
  437. told that a certain file is a self-extracting archive.
  438.  
  439. So we have met two important concepts:
  440.        Encoding for creating "mailable" files
  441.        Archiving for creating smaller files
  442.  
  443. It is quite common to combine these 2 processes.  So if we want to send
  444. a set of files, first we create an archive containing all the files and
  445. then encode this archive.  This hybrid product is sent via E-mail.  The
  446. recipient first decodes the mail file into the archive file and then
  447. dearchives the archive into the original files.  In this way we combine
  448. the advantages of compressing for reducing costs and of encoding to
  449. allow better transportability.
  450.  
  451.  
  452.  
  453.  
  454. APPENDIX A: CHARACTER TABLE
  455.  
  456. Next is a list of all printable characters together with
  457. descriptions:
  458.  
  459.   Characters of the ASCII table
  460.  
  461.        blank
  462.   !    exclamation mark
  463.   "    double quote
  464.   #    number sign
  465.   $    dollar sign
  466.   %    percent sign
  467.   &    ampersand
  468.   '    (closing) single quote
  469.   (    left parenthesis
  470.   )    right parenthesis
  471.   *    star
  472.   +    plus
  473.   ,    comma
  474.   -    minus
  475.   .    period
  476.   /    slash
  477.  
  478.   digits
  479.  
  480.   0123456789
  481.  
  482.   :    colon
  483.   ;    semicolon
  484.   <    less
  485.   =    equal
  486.   >    greater
  487.   ?    question mark
  488.   @    at-sign
  489.  
  490.   uppercase letters
  491.  
  492.   ABCDEFGHIJKLMNOPQRSTUVWXYZ
  493.  
  494.   [   left bracket
  495.   \   backslash
  496.   ]   right bracket
  497.   ^   caret
  498.   _   underscore
  499.   `   left single quote
  500.  
  501.   lowercase letters
  502.  
  503.   abcdefghijklmnopqrstuvwxyz
  504.  
  505.   {    left curly brace
  506.   :    vertical bar
  507.   }    right curly bracket
  508.   ~    tilde
  509.  
  510.   ASCII 127 is nonprintable
  511.  
  512.  
  513.  
  514. APPENDIX B: TECHNICAL DETAILS OF ENCODING AND DECODING
  515.  
  516. The rest of the paper is very technical, so you should read it only if
  517. you have some knowledge of the mathematics underlying the functioning of
  518. computers.
  519.  
  520. How do UUECODE and UUDECODE work?
  521.  
  522. For UUENCODing, the bytes forming the file are grouped in groups of
  523. three.  Every byte is an 8-bit binary number, so every group of three
  524. bytes is a 24-bit binary number.  This number then is split into four
  525. groups of 6 bits each, i.e.  into 4 6-bit binary numbers. The 6-bit binary
  526. numbers give all decimal numbers from 0 to 63.  To every such 6-bit
  527. number 32 (decimal) is added, giving numbers in the range from 32 to 95.
  528. Every number then is replaced by the ASCII character associated with
  529. this value.  (32 becomes  (a blank), 33 becomes !,...  95 becomes _ (an
  530. underscore)).  So the translation process converts each group of 3 bytes
  531. into 4 printable characters.
  532.  
  533. Additionally every group of 45 bytes (giving 60 characters) is grouped
  534. into a line in the file to be sent.  Then a leading character is added to
  535. this line.  The leading character is calculated by using the encoding
  536. scheme we just discussed onto the number of bytes represented by the
  537. line.  (45+32=77, so for a line representing 45 bytes the leading
  538. character is M (M is ASCII character 77)).  Usually the last line is
  539. shorter and therefore the leading character of the last line also is
  540. different from M.  Finally a first line containing "begin", a 3 digit
  541. number (giving access privileges on UNIX systems and meaningless on
  542. other systems) and the name of the original file and a last line
  543. containing the word "end" is added.
  544.  
  545. The decoding program then mainly has to convert each group of 4
  546. characters back into a group of three bytes (using the byte count given
  547. by the first character of each line for consistency checks).
  548.  
  549. There are some problems with this scheme.  We already discussed the
  550. possibility of special characters being scrambled.  Additionally some
  551. "smart" mailing programs assume that trailing blanks always are
  552. unnecessary.  Therefore they strip trailing blanks from every mail file.
  553. If it is only text you want to read you will not notice the difference.
  554. But an UUDECODing program will find out that the lines are too short
  555. (the first character of the line gives information about the line
  556. length!).
  557.  
  558. There are different solutions for this problem.
  559.  
  560. 1) Replace blanks by ` (the single opening quote having ASCII value
  561.    32+64=96)
  562.  
  563. 2) Add an additional nonblank character at the end of each line
  564.  
  565. 3) Make the decoding program smart enough to produce the missing
  566.    blanks by itself.
  567.  
  568. All the solutions are nonstandardized, so if you have some troubles when
  569. decoding you have to analyze them carefully.  Solution number 2 usually
  570. works better than the two other solutions.  So you should try to get an
  571. encoding program adding that additional character.  Using an editor also
  572. makes it possible to transform the different "extended" formats of
  573. UUENCODEd files into one another.
  574.  
  575.  
  576.  
  577. How do XXENCODE and XXDECODE work?
  578.  
  579. XXENCODE uses the same splitting technique as the UU scheme (3 bytes
  580. into 4 6-digit binary numbers).  Then every such number is converted
  581. into a character according to the following sequence:
  582.  
  583. +-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
  584.  
  585. So (decimal) 0 becomes +, 1 becomes -, (number) 2 becomes (character) 0,
  586. ....  63 becomes z.
  587.  
  588. The mechanism for adding byte counts to lines is identical to the UU
  589. scheme with the difference the the numbers again are coded according to
  590. the above sequence of letter, digits, + and -.  So it even is possible
  591. to convert UUENCODEd files into XXENCODEd files using the replace
  592. feature of a text editor.
  593.  
  594.  
  595.  
  596. ACKNOWLEDGEMENTS
  597.  
  598. The author wishes to thank Ted Werntz whose comments and suggestions
  599. helped enourmously to improve the paper.
  600.