UUENCODE(1POSIX)
๐ UUENCODE(1POSIX) ๐
okay bestie, we're doing the POSIX Programmer's Manual version of uuencode โ that's the manual name right there in the title, so now you know. Let's get into it ๐ซถ
โจ PROLOG โจ
So like, heads up: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux at all. ngl that's just how it is. ๐
๐ธ NAME ๐ธ
uuencode โ encode a binary file
๐ SYNOPSIS ๐
uuencode [-m] [file] decode_pathname
๐ DESCRIPTION ๐
okay so the uuencode utility shall write an encoded version of the named input file, or standard input if no file is specified, to standard output. like, it takes your file and makes it into text, iconic behavior honestly.
The output shall be encoded using one of the algorithms described in the STDOUT section (they're down there, we'll get to them ๐) and shall include the file access permission bits โ in chmod octal or symbolic notation โ of the input file, plus the decode_pathname, all so the file can be re-created on another system that conforms to this volume of POSIX.1โ2017. it's giving "pack it up, ship it out" โจ
๐ OPTIONS ๐
The uuencode utility shall conform to the Base Definitions volume of POSIX.1โ2017, Section 12.2, Utility Syntax Guidelines. yes bestie, the rules of the land.
The following option shall be supported by the implementation:
-mโ Encode the output using the MIME Base64 algorithm described in STDOUT. If-mis not specified, the historical algorithm described in STDOUT shall be used. so like,-mis the modern glow-up, no-mis the vintage vibe ๐
๐ฆ OPERANDS ๐ฆ
The following operands shall be supported:
- decode_pathname โ The pathname of the file into which the
uudecodeutility shall place the decoded file. Specifying a decode_pathname operand of/dev/stdoutshall indicate thatuudecodeis to use standard output. โ ๏ธ If there are characters in decode_pathname that are not in the portable filename character set, the results are unspecified โ so like, don't be chaotic, stay in the portable filename character set fr fr. - file โ A pathname of the file to be encoded.
๐ STDIN ๐
See the INPUT FILES section. (yes, it's a little scavenger hunt, we love a cross-reference ๐)
๐ INPUT FILES ๐
Input files can be files of any type. any type!! zero restrictions, main character energy.
๐ 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 POSIX.1โ2017, 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. it's the boss of the other locale vars, periodt.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 ofLC_MESSAGES.
โจ ASYNCHRONOUS EVENTS โจ
Default. (aka, nothing special, carry on ๐ซถ)
๐ฅ 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> characters. no sneaky spaces bestie, not even one ๐
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 Table 4-22, uuencode Base64 Values.
๐ Table 4-22: uuencode Base64 Values ๐
- Value
0โA,1โB,2โC,3โD,4โE,5โF,6โG,7โH,8โI,9โJ,10โK,11โL,12โM,13โN,14โO,15โP - Value
16โQ,17โR,18โS,19โT,20โU,21โV,22โW,23โX,24โY,25โZ,26โa,27โb,28โc,29โd,30โe,31โf - Value
32โg,33โh,34โi,35โj,36โk,37โl,38โm,39โn,40โo,41โp,42โq,43โr,44โs,45โt,46โu,47โv - Value
48โw,49โx,50โy,51โz,52โ0,53โ1,54โ2,55โ3,56โ4,57โ5,58โ6,59โ7,60โ8,61โ9,62โ+,63โ/ - Value
(pad)โ=
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). yes, decoding software is chill like that ๐
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:
- 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. - 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. - 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. it's the little goodbye wave ๐โจ
๐ธ 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> characters. again with the no sneaky spaces rule ๐
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.) the way it's just doing character set translation on the fly, obsessed ๐ง
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. forty-five, remember that number bestie โญ
๐ STDERR ๐
The standard error shall be used only for diagnostic messages. that's it, that's its whole job.
๐ OUTPUT FILES ๐
None. (nope, zero, nada ๐)
๐ฆ EXTENDED DESCRIPTION ๐ฆ
None. (again: nothing here, we keep it moving โจ)
๐ EXIT STATUS ๐
The following exit values shall be returned:
0โ Successful completion. slay. ๐>0โ An error occurred. ๐ญ
๐ CONSEQUENCES OF ERRORS ๐
Default.
The following sections are informative. (yes, that's the actual line, we're not done yet โ more parts coming, don't go anywhere bestie ๐ซถ)
๐ APPLICATION USAGE ๐
okay bestie, real talk: this file gets expanded by 35 percent (every three octets turn into four, plus some control info on top), which means it's gonna take longer to transmit. it's giving "worth it but plan accordingly" โจ
so the whole vibe here is that this utility exists to make files you can swap between systems that might have totally different codesets, and to turn binary data into a text file. because of that, the ISO/IEC 646:1991 standard got picked as a midpoint in the algorithm โ a known reference point, iykyk. ๐
and listen, the output from uuencode is a text file on the local system. if the output were in the ISO/IEC 646:1991 standard codeset instead, it might not be a text file โ at minimum because the <newline> characters might not match โ and then the whole goal of creating a text file would be defeated. ๐ญ imagine.
if that text file then gets carried over to another machine with the same codeset, it's perfectly compatible with that system's uudecode. slay. but if it's transmitted over a mail system, or sent to a machine with a different codeset, the assumption is that โ just like 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. ๐ซ
heads up bestie: that translation only makes sense from the local codeset, NOT if the file has already been put into a ISO/IEC 646:1991 standard representation first. order of operations matters, fr fr.
and one more cute thing: files processed by uuencode can be dropped into pax archives, intermixed with other text files in the same codeset. adorable, flexible, iconic. ๐
๐ธ EXAMPLES ๐ธ
None.
(yeah. nothing. the void. we stan a minimalist king ๐)
๐ง RATIONALE ๐ง
okay so story time: a new algorithm was added at the request of the international community, to parallel work in RFC 2045 (MIME). โจ
just like 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 (sorry bestie, it's not for you, it's for the machines ๐).
a 65-character subset of the ISO/IEC 646:1991 standard is used, which enables 6 bits to be represented per printable character. and the extra 65th character, '=', is there to signify a special processing function. ๐
this subset has a really important property: it's 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 โ and that's literally the reason a second algorithm was added to the ISO POSIXโ2 standard. periodt. ๐
and why the weird ending? the string "====" was used for termination instead of the end used in the original format, because that original end string could be valid encoded input. can't have ambiguity, no cap. ๐ฆ
fun little history moment: in an early draft, the -m option was named -b (for Base64), but it got renamed to reflect its relationship to RFC 2045. there was also a -u present to invoke the default algorithm, but since that was not historical practice, it was omitted as being unnecessary. we love a glow-up. โจ
oh and if you want the derivation of the /dev/stdout symbol, go see the RATIONALE section in uudecode. it's all connected bestie, it's giving lore. ๐
๐ฎ FUTURE DIRECTIONS ๐ฎ
None.
(nothing on the horizon. the future is a blank canvas and honestly? vibe. ๐)
๐ SEE ALSO ๐
chmodmailxuudecode
and also: The Base Definitions volume of POSIX.1โ2017, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines ๐
๐ COPYRIGHT ๐
okay legal bestie moment, gotta say it properly:
Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 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 .
Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .
aaaand that's the whole page bestie, we made it ๐ซถ this masterpiece was brought to you by IEEE/The Open Group, dated 2017, and it lives under the name UUENCODE(1POSIX) โ go forth and encode, you absolute icon ๐๐โจ
๐ฆ where this page comes from
- debian bookworm: manpages-posix 2017a-2 ยท Other
- debian trixie: manpages-posix 2017a-2 ยท Other
- ubuntu jammy: manpages-posix 2017a-2 ยท Other
- ubuntu noble: manpages-posix 2017a-2 ยท Other
- ubuntu resolute: manpages-posix 2017a-2build1 ยท Other
- ubuntu stonking: manpages-posix 2017a-2.1 ยท Other
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms