1UUENCODE(1P) POSIX Programmer's Manual UUENCODE(1P)
2
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
13 uuencode — encode a binary file
14
16 uuencode [−m] [file] decode_pathname
17
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
28 The uuencode utility shall conform to the Base Definitions volume of
29 POSIX.1‐2008, Section 12.2, Utility Syntax Guidelines.
30 The following option shall be supported by the implementation:
32 −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
38 The following operands shall be supported:
39 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 file A pathname of the file to be encoded.
49
51 See the INPUT FILES section.
52
54 Input files can be files of any type.
55
57 The following environment variables shall affect the execution of uuen‐
58 code:
59 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 LC_ALL If set to a non-empty string value, override the values of
67 all the other internationalization variables.
68 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 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 NLSPATH Determine the location of message catalogs for the processing
80 of LC_MESSAGES.
81
83 Default.
84
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 "begin-base64 %s %s\n", <mode>, <decode_pathname>
91 and ends with the line:
93 "====\n"
95 In both cases, the lines shall have no preceding or trailing <blank>
97 characters.
98 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 Table 4-22: uuencode Base64 Values
113 ┌──────┬──────────┬┬──────┬──────────┬┬──────┬──────────┬┬──────┬──────────┐
115 │Value │ 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 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 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 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 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 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 A terminating "====" evaluates to nothing and denotes the end of the
166 encoded data.
167 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 "begin %s %s\n" <mode>, <decode_pathname>
173 and ends with the line:
175 "end\n"
177 In both cases, the lines shall have no preceding or trailing <blank>
179 characters.
180 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 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 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 These octets then shall be translated into the local character set.
204 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
211 The standard error shall be used only for diagnostic messages.
212
214 None.
215
217 None.
218
220 The following exit values shall be returned:
221 0 Successful completion.
223 >0 An error occurred.
225
227 Default.
228 The following sections are informative.
230
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 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
255 None.
256
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 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 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 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 See the RATIONALE section in uudecode for the derivation of the
283 /dev/stdout symbol.
284
286 None.
287
289 chmod, mailx, uudecode
290 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 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 .
310IEEE/The Open Group 2013 UUENCODE(1P)