1UUENCODE(P) POSIX Programmer's Manual UUENCODE(P)
2
6 uuencode - encode a binary file
7
9 uuencode [-m][file] decode_pathname
10
12 The uuencode utility shall write an encoded version of the named input
13 file, or standard input if no file is specified, to standard output.
14 The output shall be encoded using one of the algorithms described in
15 the STDOUT section and shall include the file access permission bits
16 (in chmod octal or symbolic notation) of the input file and the
17 decode_pathname, for re-creation of the file on another system that
18 conforms to this volume of IEEE Std 1003.1-2001.
19
21 The uuencode utility shall conform to the Base Definitions volume of
22 IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
23 The following option shall be supported by the implementation:
25 -m Encode the output using the MIME Base64 algorithm described in
27 STDOUT. If -m is not specified, the historical algorithm
28 described in STDOUT shall be used.
29
32 The following operands shall be supported:
33 decode_pathname
35 The pathname of the file into which the uudecode utility shall
37 place the decoded file. Specifying a decode_pathname operand of
38 /dev/stdout shall indicate that uudecode is to use standard out‐
39 put. If there are characters in decode_pathname that are not in
40 the portable filename character set the results are unspecified.
41 file A pathname of the file to be encoded.
43
46 See the INPUT FILES section.
47
49 Input files can be files of any type.
50
52 The following environment variables shall affect the execution of uuen‐
53 code:
54 LANG Provide a default value for the internationalization variables
56 that are unset or null. (See the Base Definitions volume of
57 IEEE Std 1003.1-2001, Section 8.2, Internationalization Vari‐
58 ables for the precedence of internationalization variables used
59 to determine the values of locale categories.)
60 LC_ALL If set to a non-empty string value, override the values of all
62 the other internationalization variables.
63 LC_CTYPE
65 Determine the locale for the interpretation of sequences of
66 bytes of text data as characters (for example, single-byte as
67 opposed to multi-byte characters in arguments and input files).
68 LC_MESSAGES
70 Determine the locale that should be used to affect the format
71 and contents of diagnostic messages written to standard error.
72 NLSPATH
74 Determine the location of message catalogs for the processing of
75 LC_MESSAGES .
76
79 Default.
80
82 uuencode Base64 Algorithm
83 The standard output shall be a text file (encoded in the character set
84 of the current locale) that begins with the line:
85 "begin-base64 %s %s\n", <mode>, <decode_pathname>
88 and ends with the line:
90 "====\n"
93 In both cases, the lines shall have no preceding or trailing <blank>s.
95 The encoding process represents 24-bit groups of input bits as output
97 strings of four encoded characters. Proceeding from left to right, a
98 24-bit input group shall be formed by concatenating three 8-bit input
99 groups. Each 24-bit input group then shall be treated as four concate‐
100 nated 6-bit groups, each of which shall be translated into a single
101 digit in the Base64 alphabet. When encoding a bit stream via the Base64
102 encoding, the bit stream shall be presumed to be ordered with the most-
103 significant bit first. That is, the first bit in the stream shall be
104 the high-order bit in the first byte, and the eighth bit shall be the
105 low-order bit in the first byte, and so on. Each 6-bit group is used as
106 an index into an array of 64 printable characters, as shown in uuencode
107 Base64 Values .
108 Table: uuencode Base64 Values
110 Value Encoding Value Encoding Value Encoding Value Encoding
112 0 A 17 R 34 i 51 z
113 1 B 18 S 35 j 52 0
114 2 C 19 T 36 k 53 1
115 3 D 20 U 37 l 54 2
116 4 E 21 V 38 m 55 3
117 5 F 22 W 39 n 56 4
118 6 G 23 X 40 o 57 5
119 7 H 24 Y 41 p 58 6
120 8 I 25 Z 42 q 59 7
121 9 J 26 a 43 r 60 8
122 10 K 27 b 44 s 61 9
123 11 L 28 c 45 t 62 +
124 12 M 29 d 46 u 63 /
125 13 N 30 e 47 v
126 14 O 31 f 48 w (pad)──────────
127 15 P 32 g 49 x
128 16 Q 33 h 50 y
129 The character referenced by the index shall be placed in the output
131 string.
132 The output stream (encoded bytes) shall be represented in lines of no
134 more than 76 characters each. All line breaks or other characters not
135 found in the table shall be ignored by decoding software (see uudecode
136 ).
137 Special processing shall be performed if fewer than 24 bits are avail‐
139 able at the end of a message or encapsulated part of a message. A full
140 encoding quantum shall always be completed at the end of a message.
141 When fewer than 24 input bits are available in an input group, zero
142 bits shall be added (on the right) to form an integral number of 6-bit
143 groups. Output character positions that are not required to represent
144 actual input data shall be set to the character '=' . Since all Base64
145 input is an integral number of octets, only the following cases can
146 arise:
147 1. The final quantum of encoding input is an integral multiple of 24
149 bits; here, the final unit of encoded output shall be an integral
150 multiple of 4 characters with no '=' padding.
151 2. The final quantum of encoding input is exactly 16 bits; here, the
153 final unit of encoded output shall be three characters followed by
154 one '=' padding character.
155 3. The final quantum of encoding input is exactly 8 bits; here, the
157 final unit of encoded output shall be two characters followed by
158 two '=' padding characters.
159 A terminating "====" evaluates to nothing and denotes the end of the
161 encoded data.
162 uuencode Historical Algorithm
164 The standard output shall be a text file (encoded in the character set
165 of the current locale) that begins with the line:
166 "begin %s %s\n" <mode>, <decode_pathname>
169 and ends with the line:
171 "end\n"
174 In both cases, the lines shall have no preceding or trailing <blank>s.
176 The algorithm that shall be used for lines in between begin and end
178 takes three octets as input and writes four characters of output by
179 splitting the input at six-bit intervals into four octets, containing
180 data in the lower six bits only. These octets shall be converted to
181 characters by adding a value of 0x20 to each octet, so that each octet
182 is in the range [0x20,0x5f], and then it shall be assumed to represent
183 a printable character in the ISO/IEC 646:1991 standard encoded charac‐
184 ter set. It then shall be translated into the corresponding character
185 codes for the codeset in use in the current locale. (For example, the
186 octet 0x41, representing 'A' , would be translated to 'A' in the cur‐
187 rent codeset, such as 0xc1 if it were EBCDIC.)
188 Where the bits of two octets are combined, the least significant bits
190 of the first octet shall be shifted left and combined with the most
191 significant bits of the second octet shifted right. Thus the three
192 octets A, B, C shall be converted into the four octets:
193 0x20 + (( A >> 2 ) & 0x3F)
196 0x20 + (((A << 4) | ((B >> 4) & 0xF)) & 0x3F)
197 0x20 + (((B << 2) | ((C >> 6) & 0x3)) & 0x3F)
198 0x20 + (( C ) & 0x3F)
199 These octets then shall be translated into the local character set.
201 Each encoded line contains a length character, equal to the number of
203 characters to be decoded plus 0x20 translated to the local character
204 set as described above, followed by the encoded characters. The maxi‐
205 mum number of octets to be encoded on each line shall be 45.
206
208 The standard error shall be used only for diagnostic messages.
209
211 None.
212
214 None.
215
217 The following exit values shall be returned:
218 0 Successful completion.
220 >0 An error occurred.
222
225 Default.
226 The following sections are informative.
228
230 The file is expanded by 35 percent (each three octets become four, plus
231 control information) causing it to take longer to transmit.
232 Since this utility is intended to create files to be used for data
234 interchange between systems with possibly different codesets, and to
235 represent binary data as a text file, the ISO/IEC 646:1991 standard was
236 chosen for a midpoint in the algorithm as a known reference point. The
237 output from uuencode is a text file on the local system. If the output
238 were in the ISO/IEC 646:1991 standard codeset, it might not be a text
239 file (at least because the <newline>s might not match), and the goal of
240 creating a text file would be defeated. If this text file was then car‐
241 ried to another machine with the same codeset, it would be perfectly
242 compatible with that system's uudecode. If it was transmitted over a
243 mail system or sent to a machine with a different codeset, it is
244 assumed that, as for every other text file, some translation mechanism
245 would convert it (by the time it reached a user on the other system)
246 into an appropriate codeset. This translation only makes sense from the
247 local codeset, not if the file has been put into a ISO/IEC 646:1991
248 standard representation first. Similarly, files processed by uuencode
249 can be placed in pax archives, intermixed with other text files in the
250 same codeset.
251
253 None.
254
256 A new algorithm was added at the request of the international community
257 to parallel work in RFC 2045 (MIME). As with the historical uuencode
258 format, the Base64 Content-Transfer-Encoding is designed to represent
259 arbitrary sequences of octets in a form that is not humanly readable. A
260 65-character subset of the ISO/IEC 646:1991 standard is used, enabling
261 6 bits to be represented per printable character. (The extra 65th char‐
262 acter, '=' , is used to signify a special processing function.)
263 This subset has the important property that it is represented identi‐
265 cally in all versions of the ISO/IEC 646:1991 standard, including US
266 ASCII, and all characters in the subset are also represented identi‐
267 cally in all versions of EBCDIC. The historical uuencode algorithm does
268 not share this property, which is the reason that a second algorithm
269 was added to the ISO POSIX-2 standard.
270 The string "====" was used for the termination instead of the end used
272 in the original format because the latter is a string that could be
273 valid encoded input.
274 In an early draft, the -m option was named -b (for Base64), but it was
276 renamed to reflect its relationship to the RFC 2045. A -u was also
277 present to invoke the default algorithm, but since this was not histor‐
278 ical practice, it was omitted as being unnecessary.
279 See the RATIONALE section in uudecode for the derivation of the
281 /dev/stdout symbol.
282
284 None.
285
287 chmod() , mailx , uudecode
288
290 Portions of this text are reprinted and reproduced in electronic form
291 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
292 -- Portable Operating System Interface (POSIX), The Open Group Base
293 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
294 Electrical and Electronics Engineers, Inc and The Open Group. In the
295 event of any discrepancy between this version and the original IEEE and
296 The Open Group Standard, the original IEEE and The Open Group Standard
297 is the referee document. The original Standard can be obtained online
298 at http://www.opengroup.org/unix/online.html .
299IEEE/The Open Group 2003 UUENCODE(P)