te
Copyright 1989 AT&T Copyright (c) 1980 Regents of the University of California. All rights reserved. The Berkeley software License Agreement specifies the terms and conditions for redistribution. Copyright (c) 2003, Sun Microsystems, Inc. All Rights Reserved Portions Copyright (c) 2002, X/Open Company Limited All Rights Reserved
Sun Microsystems, Inc. gratefully acknowledges The Open Group for permission to reproduce portions of its copyrighted documentation. Original documentation from The Open Group can be obtained online at
http://www.opengroup.org/bookstore/.
The Institute of Electrical and Electronics Engineers and The Open Group, have given us permission to reprint portions of their documentation. In the following statement, the phrase "this text" refers to portions of the system documentation. Portions of this text are reprinted and reproduced in electronic form in the Sun OS Reference Manual, from IEEE Std 1003.1, 2004 Edition, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 6, Copyright (C) 2001-2004 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between these versions 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.
This notice shall appear on any product containing this material.
uuencode, uudecode - encode a binary file, or decode its encoded representation

uuencode [source-file] decode_pathname

uuencode [-m] [source-file] decode_pathname

uudecode [-p] [encoded-file]

uudecode [-o outfile] [encoded-file]

These commands encode and decode files as follows:

The uuencode utility converts a binary file into an encoded representation that can be sent using mail(1). It encodes the contents of source-file, or the standard input if no source-file argument is given. The decode_pathname argument is required. The decode_pathname is included in the encoded file's header as the name of the file into which uudecode is to place the binary (decoded) data. uuencode also includes the permission modes of source-file (except setuid, setgid, and sticky-bits), so that decode_pathname is recreated with those same permission modes.

The uudecode utility reads an encoded-file, strips off any leading and trailing lines added by mailer programs, and recreates the original binary data with the filename and the mode specified in the header.

The encoded file is an ordinary portable character set text file; it can be edited by any text editor. It is best only to change the mode or decode_pathname in the header to avoid corrupting the decoded binary.

The following options are supported:

-m -o outfile -p

The following operands are supported by uuencode and uudecode:

decode_pathname source-file encoded-file

See largefile(5) for the description of the behavior of uuencode and uudecode when encountering files greater than or equal to 2 Gbyte ( 2^31 bytes).

See environ(5) for descriptions of the following environment variables that affect the execution of uuencode and uudecode: LANG, LC_ALL, LC_CTYPE, LC_MESSAGES, and NLSPATH.

stdout

The standard output is a text file, encoded in the character set of the current locale, that begins with the line:

begin-base64 %s %s\en, mode, decode_pathname

and ends with the line:

====

In both cases, the lines have no preceding or trailing blank characters.

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 is formed by concatenating three 8-bit input groups. Each 24-bit input group is then treated as four concatenated 6-bit groups, each of which is translated into a single digit in the Base64 alphabet. When encoding a bit stream by means of the Base64 encoding, the bit stream is presumed to be ordered with the most-significant bit first. That is, the first bit in the stream is the high-order bit in the first byte, and the eighth bit is 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 the following table.

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 is placed in the output string.

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

Special processing is performed if fewer than 24 bits are available at the end of a message or encapsulated part of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are 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 are set to the equals (=) character. Since all Base64 input is an integral number of octets, only the following cases can arise:

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

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

begin %s %s\en, mode, decode_pathname

and ends with the line:

end\en

In both cases, the lines have no preceding or trailing blank characters.

The algorithm that is used for lines 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 are converted to characters by adding a value of 0x20 to each octet, so that each octet is in the range 0x20-0x5f, and each octet is assumed to represent a printable character. Each octect is then 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 the codeset were EBCDIC.

Where the bits of two octets are combined, the least significant bits of the first octet are shifted left and combined with the most significant bits of the second octet shifted right. Thus, the three octets A, B, C are 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 are then 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 is 45.

The following exit values are returned: 0

>0

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE ATTRIBUTE VALUE

Interface Stability Standard

mail(1), mailx(1), uucp(1C), uux(1C), attributes(5), environ(5), largefile(5), standards(5)

The size of the encoded file is expanded by 35% (3 bytes become 4, plus control information), causing it to take longer to transmit than the equivalent binary.

The user on the remote system who is invoking uudecode (typically uucp) must have write permission on the file specified in the decode_pathname.

If you invoke uuencode and then execute uudecode on a file in the same directory, you will overwrite the original file.