summaryrefslogtreecommitdiff
path: root/usr.bin/uuencode
diff options
context:
space:
mode:
authorjeremy <jeremy@NetBSD.org>1997-08-03 08:51:33 +0000
committerjeremy <jeremy@NetBSD.org>1997-08-03 08:51:33 +0000
commitebf4cbfe8e30bea672faf640db95f4f4f952fd74 (patch)
treece886f67ddbf059580f34e80bd99136317b45a18 /usr.bin/uuencode
parent7826bcb58c69d1a2482a64a070e18a4446e7ba35 (diff)
Major re-write.
Resolves some outstanding ambiguities and documents the tolerances of uuencode and uudecode. [PR/3268]
Diffstat (limited to 'usr.bin/uuencode')
-rw-r--r--usr.bin/uuencode/uuencode.5111
1 files changed, 79 insertions, 32 deletions
diff --git a/usr.bin/uuencode/uuencode.5 b/usr.bin/uuencode/uuencode.5
index 637b6367433..59257937131 100644
--- a/usr.bin/uuencode/uuencode.5
+++ b/usr.bin/uuencode/uuencode.5
@@ -1,4 +1,4 @@
-.\" $NetBSD: uuencode.5,v 1.2 1997/04/10 20:22:50 jeremy Exp $
+.\" $NetBSD: uuencode.5,v 1.3 1997/08/03 08:51:33 jeremy Exp $
.\"
.\" Copyright (c) 1989, 1991, 1993
.\" The Regents of the University of California. All rights reserved.
@@ -33,7 +33,7 @@
.\"
.\" @(#)uuencode.format.5 8.2 (Berkeley) 1/12/94
.\"
-.Dd January 12, 1994
+.Dd April 9, 1997
.Dt UUENCODE 5
.Os BSD 4
.Sh NAME
@@ -53,48 +53,95 @@ following the trailer.
Lines preceding a header must not, of course,
look like a header.
.Pp
-The header line is distinguished by having the first
-6 characters
-.Dq begin\ \&
-(note the trailing space).
-The word
-.Em begin
-is followed by a mode (in octal),
-and a string which names the remote file.
-A space separates the three items in the header line.
+The header line starts with the word
+.Dq begin ,
+a space,
+a file mode (in octal),
+a space,
+and finally a string which names the file being encoded.
.Pp
-The body consists of a number of lines, each at most 62 characters
-long (including the trailing newline).
-These consist of a character count,
-followed by encoded characters,
+The central engine of
+.Xr uuencode 1
+is a six-bit encoding function which outputs an
+.Tn ASCII
+character.
+The six bits to be encoded are treated as a small integer and added
+with the
+.Tn ASCII
+value for the space character (octal 40).
+The result is a printable
+.Tn ASCII
+character.
+In the case where all six bits to be encoded are zero,
+the
+.Tn ASCII
+character \` (octal 140) is emitted instead of what would normally be
+a space.
+.Pp
+The body of an encoded file consists of one or more lines,
+each of which may be a maximum of 86 characters long (including the trailing
+newline).
+Each line represents an encoded chunk of data from the input file and begins
+with a byte count,
+followed by encoded bytes,
followed by a newline.
-The character count is a single printing character,
-and represents an integer, the number of bytes
-the rest of the line represents.
-Such integers are always in the range from 0 to 63 and can
-be determined by subtracting the character space (octal 40)
-from the character.
.Pp
-Groups of 3 bytes are stored in 4 characters, 6 bits per character.
-All are offset by a space to make the characters printing.
-The last line may be shorter than the normal 45 bytes.
-If the size is not a multiple of 3, this fact can be determined
-by the value of the count on the last line.
-Extra garbage will be included to make the character count a multiple
-of 4.
-The body is terminated by a line with a count of zero.
-This line consists of one
+The byte count is a six-bit integer encoded with the above function,
+representing the number of bytes encoded in the rest of the line.
+The method used to encode the data expands its size by
+133% (described below).
+Therefore it is important to note that the byte count describes the size of
+the chunk of data before it is encoded, not afterwards.
+The six bit size of this number effectively limits the number of bytes
+that can be encoded in each line to a maximum of 63.
+While
+.Xr uuencode 1
+will not encode more than 45 bytes per line,
+.Xr uudecode 1
+will tolerate the maximum line size.
+.Pp
+The remaining characters in the line represent the data of the input
+file encoded as follows.
+Input data are broken into groups of three eight-bit bytes,
+which are then interpreted together as a 24-bit block.
+The first bit of the block is the lowest order bit of the first character,
+and the last is the highest order bit of the third character.
+This block is then broken into four six-bit integers which are encoded one by
+one starting from the first bit of the block.
+The result is a four character
+.Tn ASCII
+string for every three bytes of input data.
+.Pp
+Encoded lines of data continue in this manner until the input file is
+exhausted.
+The end of the body is signaled by an encoded line with a byte count
+of zero (the
.Tn ASCII
-\` (opening single quote) character.
+character \`).
+.Pp
+Obviously, not every input file will be a multiple of three bytes in size.
+In these cases,
+.Xr uuencode 1
+will pad the remaining one or two bytes of data with garbage bytes until
+a three byte group is created. The byte count in a line containing
+garbage padding will reflect the actual number of bytes encoded, making
+it possible to convey how many bytes are garbage.
.Pp
The trailer line consists of
.Dq end
on a line by itself.
+.Sh BUGS
+The interpretation of the
+.Nm
+format relies on properties of the
+.Tn ASCII
+character set and may not work correctly on non-ASCII systems.
.Sh SEE ALSO
.Xr uuencode 1 ,
.Xr uudecode 1 ,
.Xr uucp 1 ,
-.Xr mail 1
+.Xr mail 1 ,
+.Xr ascii 7
.Sh HISTORY
The
.Nm uuencode