man uuencode () - encode a binary file

NAME

uuencode - encode a binary file

SYNOPSIS

uuencode [-m][file] decode_pathname

DESCRIPTION

The uuencode utility shall write an encoded version of the named input file, or standard input if no file is specified, to standard output. The output shall be encoded using one of the algorithms described in the STDOUT section and shall include the file access permission bits (in chmod octal or symbolic notation) of the input file and the decode_pathname, for re-creation of the file on another system that conforms to this volume of IEEE Std 1003.1-2001.

OPTIONS

The uuencode utility shall conform to the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.

The following option shall be supported by the implementation:

-m
Encode the output using the MIME Base64 algorithm described in STDOUT. If -m is not specified, the historical algorithm described in STDOUT shall be used.

OPERANDS

The following operands shall be supported:

decode_pathname
The pathname of the file into which the uudecode utility shall place the decoded file. Specifying a decode_pathname operand of /dev/stdout shall indicate that uudecode is to use standard output. If there are characters in decode_pathname that are not in the portable filename character set the results are unspecified.
file
A pathname of the file to be encoded.

STDIN

See the INPUT FILES section.

INPUT FILES

Input files can be files of any type.

ENVIRONMENT VARIABLES

The following environment variables shall affect the execution of uuencode:

LANG
Provide a default value for the internationalization variables that are unset or null. (See the Base Definitions volume of IEEE Std 1003.1-2001, Section 8.2, Internationalization Variables for the precedence of internationalization variables used to determine the values of locale categories.)
LC_ALL
If set to a non-empty string value, override the values of all the other internationalization variables.
LC_CTYPE
Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments and input files).
LC_MESSAGES
Determine the locale that should be used to affect the format and contents of diagnostic messages written to standard error.
NLSPATH
Determine the location of message catalogs for the processing of LC_MESSAGES .

ASYNCHRONOUS EVENTS

Default.

STDOUT

uuencode Base64 Algorithm

The standard output shall be a text file (encoded in the character set of the current locale) that begins with the line: 

"begin-base64 %s %s\n", <mode>, <decode_pathname>




and ends with the line:


"====\n"




In both cases, the lines shall have no preceding or trailing <blank>s.


The encoding process represents 24-bit groups of input bits as output
strings of four encoded characters. Proceeding from left
to right, a 24-bit input group shall be formed by concatenating three
8-bit input groups. Each 24-bit input group then shall be
treated as four concatenated 6-bit groups, each of which shall be
translated into a single digit in the Base64 alphabet. When
encoding a bit stream via the Base64 encoding, the bit stream shall
be presumed to be ordered with the most-significant bit first.
That is, the first bit in the stream shall be the high-order bit in
the first byte, and the eighth bit shall be the low-order bit
in the first byte, and so on. Each 6-bit group is used as an index
into an array of 64 printable characters, as shown in uuencode Base64
Values .

Table: uuencode Base64 Values
center; l1 l1 l1 l1 l1 l1 l1 l1 l1 l1 l.
Value	Encoding	Value	Encoding	Value	Encoding	Value	Encoding	 	 	 
0	A	17	R	34	i	51	z	 	 	 
1	B	18	S	35	j	52	0	 	 	 
2	C	19	T	36	k	53	1	 	 	 
3	D	20	U	37	l	54	2	 	 	 
4	E	21	V	38	m	55	3	 	 	 
5	F	22	W	39	n	56	4	 	 	 
6	G	23	X	40	o	57	5	 	 	 
7	H	24	Y	41	p	58	6	 	 	 
8	I	25	Z	42	q	59	7	 	 	 
9	J	26	a	43	r	60	8	 	 	 
10	K	27	b	44	s	61	9	 	 	 
11	L	28	c	45	t	62	+	 	 	 
12	M	29	d	46	u	63	/	 	 	 
13	N	30	e	47	v	 	 	 	 	 
14	O	31	f	48	w	(pad)	=	 	 	 
15	P	32	g	49	x	 	 	 	 	 
16	Q	33	h	50	y	 	 	 	 	 


The character referenced by the index shall be placed in the output
string.


The output stream (encoded bytes) shall be represented in lines of
no more than 76 characters each. All line breaks or other
characters not found in the table shall be ignored by decoding software
(see uudecode ).


Special processing shall be performed if fewer than 24 bits are available
at the end of a message or encapsulated part of a
message. A full encoding quantum shall always be completed at the
end of a message. When fewer than 24 input bits are available in
an input group, zero bits shall be added (on the right) to form an
integral number of 6-bit groups. Output character positions that
are not required to represent actual input data shall be set to the
character '=' . Since all Base64 input is an integral
number of octets, only the following cases can arise:

 1.

The final quantum of encoding input is an integral multiple of 24
bits; here, the final unit of encoded output shall be an
integral multiple of 4 characters with no '=' padding.



 2.

The final quantum of encoding input is exactly 16 bits; here, the
final unit of encoded output shall be three characters
followed by one '=' padding character.



 3.

The final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output shall be two characters followed
by two '=' padding characters.




A terminating "====" evaluates to nothing and denotes the end
of the encoded data.

uuencode Historical Algorithm

The standard output shall be a text file (encoded in the character
set of the current locale) that begins with the line:


"begin %s %s\n" <mode>, <decode_pathname>




and ends with the line:


"end\n"




In both cases, the lines shall have no preceding or trailing <blank>s.


The algorithm that shall be used for lines in between begin
and end takes three octets as input and writes four
characters of output by splitting the input at six-bit intervals into
four octets, containing data in the lower six bits only.
These octets shall be converted to characters by adding a value of
0x20 to each octet, so that each octet is in the range
[0x20,0x5f], and then it shall be assumed to represent a printable
character in the ISO/IEC 646:1991 standard encoded
character set. It then shall be translated into the corresponding
character codes for the codeset in use in the current locale.
(For example, the octet 0x41, representing 'A' , would be translated
to 'A' in the current codeset, such as 0xc1
if it were EBCDIC.)


Where the bits of two octets are combined, the least significant bits
of the first octet shall be shifted left and combined with
the most significant bits of the second octet shifted right. Thus
the three octets A, B, C shall be converted
into the four octets:


0x20 + (( A >> 2                    ) & 0x3F)
0x20 + (((A << 4) | ((B >> 4) & 0xF)) & 0x3F)
0x20 + (((B << 2) | ((C >> 6) & 0x3)) & 0x3F)
0x20 + (( C                         ) & 0x3F)




These octets then shall be translated into the local character set.


Each encoded line contains a length character, equal to the number
of characters to be decoded plus 0x20 translated to the local
character set as described above, followed by the encoded characters.
The maximum number of octets to be encoded on each line shall
be 45.

STDERR

The standard error shall be used only for diagnostic messages.

OUTPUT FILES

None.

EXTENDED DESCRIPTION

None.

EXIT STATUS

The following exit values shall be returned:

 0

Successful completion.

>0

An error occurred.


CONSEQUENCES OF ERRORS

Default.


The following sections are informative.

APPLICATION USAGE

The file is expanded by 35 percent (each three octets become four,
plus control information) causing it to take longer to
transmit.


Since this utility is intended to create files to be used for data
interchange between systems with possibly different codesets,
and to represent binary data as a text file, the ISO/IEC 646:1991
standard was chosen for a midpoint in the algorithm as a
known reference point. The output from uuencode is a text file
on the local system. If the output were in the
ISO/IEC 646:1991 standard codeset, it might not be a text file (at
least because the <newline>s might not match), and
the goal of creating a text file would be defeated. If this text file
was then carried to another machine with the same codeset, it
would be perfectly compatible with that system's uudecode. If
it was transmitted
over a mail system or sent to a machine with a different codeset,
it is assumed that, as for every other text file, some
translation mechanism would convert it (by the time it reached a user
on the other system) into an appropriate codeset. This
translation only makes sense from the local codeset, not if the file
has been put into a ISO/IEC 646:1991 standard
representation first. Similarly, files processed by uuencode
can be placed in pax
archives, intermixed with other text files in the same codeset.

EXAMPLES

None.

RATIONALE

A new algorithm was added at the request of the international community
to parallel work in RFC 2045 (MIME). As with the
historical uuencode format, the Base64 Content-Transfer-Encoding
is designed to represent arbitrary sequences of octets in a
form that is not humanly readable. A 65-character subset of the ISO/IEC 646:1991
standard is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, '='
, is used to signify a special processing
function.)


This subset has the important property that it is represented identically
in all versions of the ISO/IEC 646:1991 standard,
including US ASCII, and all characters in the subset are also represented
identically in all versions of EBCDIC. The historical
uuencode algorithm does not share this property, which is the
reason that a second algorithm was added to the
ISO POSIX-2 standard.


The string "====" was used for the termination instead of the
end used in the original format because the latter is a
string that could be valid encoded input.


In an early draft, the -m option was named -b (for Base64),
but it was renamed to reflect its relationship to the
RFC 2045. A -u was also present to invoke the default algorithm,
but since this was not historical practice, it was
omitted as being unnecessary.


See the RATIONALE section in uudecode for the derivation of
the /dev/stdout
symbol.

FUTURE DIRECTIONS

None.

SEE ALSO

chmod() , mailx , uudecode

COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
Electrical and Electronics Engineers, Inc and The Open Group. In the
event of any discrepancy between this version and the original IEEE and
The Open Group Standard, the original IEEE and The Open Group Standard
is the referee document. The original Standard can be obtained online at
http://www.opengroup.org/unix/online.html .