1UUENCODE(1P)               POSIX Programmer's Manual              UUENCODE(1P)
2
3
4

PROLOG

6       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
7       implementation of this interface may differ (consult the  corresponding
8       Linux  manual page for details of Linux behavior), or the interface may
9       not be implemented on Linux.
10
11

NAME

13       uuencode — encode a binary file
14

SYNOPSIS

16       uuencode [−m] [file] decode_pathname
17

DESCRIPTION

19       The uuencode utility shall write an encoded version of the named  input
20       file,  or  standard  input if no file is specified, to standard output.
21       The output shall be encoded using one of the  algorithms  described  in
22       the  STDOUT  section  and shall include the file access permission bits
23       (in chmod octal or  symbolic  notation)  of  the  input  file  and  the
24       decode_pathname,  for  re-creation  of  the file on another system that
25       conforms to this volume of POSIX.1‐2008.
26

OPTIONS

28       The uuencode utility shall conform to the Base  Definitions  volume  of
29       POSIX.1‐2008, Section 12.2, Utility Syntax Guidelines.
30
31       The following option shall be supported by the implementation:
32
33       −m        Encode  the  output using the MIME Base64 algorithm described
34                 in STDOUT.  If −m is not specified, the historical  algorithm
35                 described in STDOUT shall be used.
36

OPERANDS

38       The following operands shall be supported:
39
40       decode_pathname
41                 The  pathname  of  the  file  into which the uudecode utility
42                 shall place the decoded file.  Specifying  a  decode_pathname
43                 operand of /dev/stdout shall indicate that uudecode is to use
44                 standard output. If there are characters  in  decode_pathname
45                 that  are  not  in  the  portable  filename character set the
46                 results are unspecified.
47
48       file      A pathname of the file to be encoded.
49

STDIN

51       See the INPUT FILES section.
52

INPUT FILES

54       Input files can be files of any type.
55

ENVIRONMENT VARIABLES

57       The following environment variables shall affect the execution of uuen‐
58       code:
59
60       LANG      Provide  a  default  value for the internationalization vari‐
61                 ables that are unset or null. (See the Base Definitions  vol‐
62                 ume  of POSIX.1‐2008, Section 8.2, Internationalization Vari‐
63                 ables for the precedence  of  internationalization  variables
64                 used to determine the values of locale categories.)
65
66       LC_ALL    If  set  to  a non-empty string value, override the values of
67                 all the other internationalization variables.
68
69       LC_CTYPE  Determine the locale for the interpretation of  sequences  of
70                 bytes of text data as characters (for example, single-byte as
71                 opposed to  multi-byte  characters  in  arguments  and  input
72                 files).
73
74       LC_MESSAGES
75                 Determine the locale that should be used to affect the format
76                 and contents  of  diagnostic  messages  written  to  standard
77                 error.
78
79       NLSPATH   Determine the location of message catalogs for the processing
80                 of LC_MESSAGES.
81

ASYNCHRONOUS EVENTS

83       Default.
84

STDOUT

86   uuencode Base64 Algorithm
87       The standard output shall be a text file (encoded in the character  set
88       of the current locale) that begins with the line:
89
90           "begin-base64 %s %s\n", <mode>, <decode_pathname>
91
92       and ends with the line:
93
94           "====\n"
95
96       In  both  cases,  the lines shall have no preceding or trailing <blank>
97       characters.
98
99       The encoding process represents 24-bit groups of input bits  as  output
100       strings  of  four  encoded characters. Proceeding from left to right, a
101       24-bit input group shall be formed by concatenating three  8-bit  input
102       groups.  Each 24-bit input group then shall be treated as four concate‐
103       nated 6-bit groups, each of which shall be  translated  into  a  single
104       digit in the Base64 alphabet. When encoding a bit stream via the Base64
105       encoding, the bit stream shall be presumed to be ordered with the most-
106       significant  bit  first.  That is, the first bit in the stream shall be
107       the high-order bit in the first byte, and the eighth bit shall  be  the
108       low-order bit in the first byte, and so on. Each 6-bit group is used as
109       an index into an array of 64 printable characters, as  shown  in  Table
110       4-22, uuencode Base64 Values.
111
112                         Table 4-22: uuencode Base64 Values
113
114     ┌──────┬──────────┬┬──────┬──────────┬┬──────┬──────────┬┬──────┬──────────┐
115Value Encoding ││Value Encoding ││Value Encoding ││Value Encoding 
116     ├──────┼──────────┼┼──────┼──────────┼┼──────┼──────────┼┼──────┼──────────┤
117     │  0   │    A     ││ 17   │    R     ││ 34   │    i     ││ 51   │    z     │
118     │  1   │    B     ││ 18   │    S     ││ 35   │    j     ││ 52   │    0     │
119     │  2   │    C     ││ 19   │    T     ││ 36   │    k     ││ 53   │    1     │
120     │  3   │    D     ││ 20   │    U     ││ 37   │    l     ││ 54   │    2     │
121     │  4   │    E     ││ 21   │    V     ││ 38   │    m     ││ 55   │    3     │
122     │  5   │    F     ││ 22   │    W     ││ 39   │    n     ││ 56   │    4     │
123     │  6   │    G     ││ 23   │    X     ││ 40   │    o     ││ 57   │    5     │
124     │  7   │    H     ││ 24   │    Y     ││ 41   │    p     ││ 58   │    6     │
125     │  8   │    I     ││ 25   │    Z     ││ 42   │    q     ││ 59   │    7     │
126     │  9   │    J     ││ 26   │    a     ││ 43   │    r     ││ 60   │    8     │
127     │ 10   │    K     ││ 27   │    b     ││ 44   │    s     ││ 61   │    9     │
128     │ 11   │    L     ││ 28   │    c     ││ 45   │    t     ││ 62   │    +     │
129     │ 12   │    M     ││ 29   │    d     ││ 46   │    u     ││ 63   │    /     │
130     │ 13   │    N     ││ 30   │    e     ││ 47   │    v     ││      │          │
131     │ 14   │    O     ││ 31   │    f     ││ 48   │    w     ││(pad) │    =     │
132     │ 15   │    P     ││ 32   │    g     ││ 49   │    x     ││      │          │
133     │ 16   │    Q     ││ 33   │    h     ││ 50   │    y     ││      │          │
134     └──────┴──────────┴┴──────┴──────────┴┴──────┴──────────┴┴──────┴──────────┘
135       The  character  referenced  by  the index shall be placed in the output
136       string.
137
138       The output stream (encoded bytes) shall be represented in lines  of  no
139       more  than  76 characters each. All line breaks or other characters not
140       found in the table shall be ignored by  decoding  software  (see  uude‐
141       code).
142
143       Special  processing shall be performed if fewer than 24 bits are avail‐
144       able at the end of a message or encapsulated part of a message. A  full
145       encoding  quantum  shall  always  be completed at the end of a message.
146       When fewer than 24 input bits are available in  an  input  group,  zero
147       bits  shall be added (on the right) to form an integral number of 6-bit
148       groups. Output character positions that are not required  to  represent
149       actual  input data shall be set to the character '='.  Since all Base64
150       input is an integral number of octets, only  the  following  cases  can
151       arise:
152
153        1. The  final  quantum of encoding input is an integral multiple of 24
154           bits; here, the final unit of encoded output shall be  an  integral
155           multiple of 4 characters with no '=' padding.
156
157        2. The  final  quantum of encoding input is exactly 16 bits; here, the
158           final unit of encoded output shall be three characters followed  by
159           one '=' padding character.
160
161        3. The  final  quantum  of encoding input is exactly 8 bits; here, the
162           final unit of encoded output shall be two  characters  followed  by
163           two '=' padding characters.
164
165       A  terminating  "===="  evaluates to nothing and denotes the end of the
166       encoded data.
167
168   uuencode Historical Algorithm
169       The standard output shall be a text file (encoded in the character  set
170       of the current locale) that begins with the line:
171
172           "begin %s %s\n" <mode>, <decode_pathname>
173
174       and ends with the line:
175
176           "end\n"
177
178       In  both  cases,  the lines shall have no preceding or trailing <blank>
179       characters.
180
181       The algorithm that shall be used for lines in  between  begin  and  end
182       takes  three  octets  as  input and writes four characters of output by
183       splitting the input at six-bit intervals into four  octets,  containing
184       data  in  the  lower  six bits only. These octets shall be converted to
185       characters by adding a value of 0x20 to each octet, so that each  octet
186       is  in the range [0x20,0x5f], and then it shall be assumed to represent
187       a printable character in the ISO/IEC 646:1991 standard encoded  charac‐
188       ter  set.  It then shall be translated into the corresponding character
189       codes for the codeset in use in the current locale. (For  example,  the
190       octet 0x41, representing 'A', would be translated to 'A' in the current
191       codeset, such as 0xc1 if it were EBCDIC.)
192
193       Where the bits of two octets are combined, the least  significant  bits
194       of  the  first  octet  shall be shifted left and combined with the most
195       significant bits of the second octet  shifted  right.  Thus  the  three
196       octets A, B, C shall be converted into the four octets:
197
198           0x20 + (( A >> 2                    ) & 0x3F)
199           0x20 + (((A << 4) | ((B >> 4) & 0xF)) & 0x3F)
200           0x20 + (((B << 2) | ((C >> 6) & 0x3)) & 0x3F)
201           0x20 + (( C                         ) & 0x3F)
202
203       These octets then shall be translated into the local character set.
204
205       Each  encoded  line contains a length character, equal to the number of
206       characters to be decoded plus 0x20 translated to  the  local  character
207       set as described above, followed by the encoded characters. The maximum
208       number of octets to be encoded on each line shall be 45.
209

STDERR

211       The standard error shall be used only for diagnostic messages.
212

OUTPUT FILES

214       None.
215

EXTENDED DESCRIPTION

217       None.
218

EXIT STATUS

220       The following exit values shall be returned:
221
222        0    Successful completion.
223
224       >0    An error occurred.
225

CONSEQUENCES OF ERRORS

227       Default.
228
229       The following sections are informative.
230

APPLICATION USAGE

232       The file is expanded by 35 percent (each three octets become four, plus
233       control information) causing it to take longer to transmit.
234
235       Since  this  utility  is  intended  to create files to be used for data
236       interchange between systems with possibly different  codesets,  and  to
237       represent binary data as a text file, the ISO/IEC 646:1991 standard was
238       chosen for a midpoint in the algorithm as a known reference point.  The
239       output  from uuencode is a text file on the local system. If the output
240       were in the ISO/IEC 646:1991 standard codeset, it might not be  a  text
241       file  (at  least because the <newline> characters might not match), and
242       the goal of creating a text file would be defeated. If this  text  file
243       was  then carried to another machine with the same codeset, it would be
244       perfectly compatible with that system's uudecode.  If it was  transmit‐
245       ted  over  a mail system or sent to a machine with a different codeset,
246       it is assumed that, as for every  other  text  file,  some  translation
247       mechanism  would convert it (by the time it reached a user on the other
248       system) into an appropriate codeset. This translation only makes  sense
249       from  the  local  codeset,  not  if  the  file  has  been  put  into  a
250       ISO/IEC 646:1991 standard representation first. Similarly,  files  pro‐
251       cessed by uuencode can be placed in pax archives, intermixed with other
252       text files in the same codeset.
253

EXAMPLES

255       None.
256

RATIONALE

258       A new algorithm was added at the request of the international community
259       to  parallel  work  in RFC 2045 (MIME). As with the historical uuencode
260       format, the Base64 Content-Transfer-Encoding is designed  to  represent
261       arbitrary sequences of octets in a form that is not humanly readable. A
262       65-character subset of the ISO/IEC 646:1991 standard is used,  enabling
263       6 bits to be represented per printable character. (The extra 65th char‐
264       acter, '=', is used to signify a special processing function.)
265
266       This subset has the important property that it is  represented  identi‐
267       cally  in  all  versions of the ISO/IEC 646:1991 standard, including US
268       ASCII, and all characters in the subset are  also  represented  identi‐
269       cally in all versions of EBCDIC. The historical uuencode algorithm does
270       not share this property, which is the reason that  a  second  algorithm
271       was added to the ISO POSIX‐2 standard.
272
273       The  string "====" was used for the termination instead of the end used
274       in the original format because the latter is a  string  that  could  be
275       valid encoded input.
276
277       In  an early draft, the −m option was named −b (for Base64), but it was
278       renamed to reflect its relationship to the  RFC 2045.  A  −u  was  also
279       present to invoke the default algorithm, but since this was not histor‐
280       ical practice, it was omitted as being unnecessary.
281
282       See the RATIONALE  section  in  uudecode  for  the  derivation  of  the
283       /dev/stdout symbol.
284

FUTURE DIRECTIONS

286       None.
287

SEE ALSO

289       chmod, mailx, uudecode
290
291       The  Base  Definitions  volume  of POSIX.1‐2008, Chapter 8, Environment
292       Variables, Section 12.2, Utility Syntax Guidelines
293
295       Portions of this text are reprinted and reproduced in  electronic  form
296       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
297       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
298       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
299       cal and Electronics Engineers,  Inc  and  The  Open  Group.   (This  is
300       POSIX.1-2008  with  the  2013  Technical Corrigendum 1 applied.) In the
301       event of any discrepancy between this version and the original IEEE and
302       The  Open Group Standard, the original IEEE and The Open Group Standard
303       is the referee document. The original Standard can be  obtained  online
304       at http://www.unix.org/online.html .
305
306       Any  typographical  or  formatting  errors that appear in this page are
307       most likely to have been introduced during the conversion of the source
308       files  to  man page format. To report such errors, see https://www.ker
309       nel.org/doc/man-pages/reporting_bugs.html .
310
311
312
313IEEE/The Open Group                  2013                         UUENCODE(1P)
Impressum