1.\" $NetBSD: uuencode.5,v 1.13 2019/03/04 05:37:08 rin Exp $ 2.\" 3.\" Copyright (c) 1989, 1991, 1993 4.\" The Regents of the University of California. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. Neither the name of the University nor the names of its contributors 15.\" may be used to endorse or promote products derived from this software 16.\" without specific prior written permission. 17.\" 18.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 19.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 20.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 21.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 22.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 23.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 28.\" SUCH DAMAGE. 29.\" 30.\" @(#)uuencode.format.5 8.2 (Berkeley) 1/12/94 31.\" 32.Dd March 4, 2019 33.Dt UUENCODE 5 34.Os 35.Sh NAME 36.Nm uuencode 37.Nd format of an encoded uuencode file 38.Sh DESCRIPTION 39Files output by 40.Xr uuencode 1 41consist of a header line, 42followed by a number of body lines, 43and a trailer line. 44The 45.Xr uudecode 1 46command 47will ignore any lines preceding the header or 48following the trailer. 49Lines preceding a header must not, of course, 50look like a header. 51.Pp 52The header line starts with the word 53.Dq begin , 54a space, 55a file mode (in octal), 56a space, 57and finally a string which names the file being encoded. 58.Pp 59The central engine of 60.Xr uuencode 1 61is a six-bit encoding function which outputs an 62.Tn ASCII 63character. 64The six bits to be encoded are treated as a small integer and added 65with the 66.Tn ASCII 67value for the space character (octal 40). 68The result is a printable 69.Tn ASCII 70character. 71In the case where all six bits to be encoded are zero, 72the 73.Tn ASCII 74backquote character \` (octal 140) is emitted instead of what 75would normally be a space. 76.Pp 77The body of an encoded file consists of one or more lines, 78each of which may be a maximum of 86 characters long (including the trailing 79newline). 80Each line represents an encoded chunk of data from the input file and begins 81with a byte count, 82followed by encoded bytes, 83followed by a newline. 84.Pp 85The byte count is a six-bit integer encoded with the above function, 86representing the number of bytes encoded in the rest of the line. 87The method used to encode the data expands its size by 88133% (described below). 89Therefore it is important to note that the byte count describes the size of 90the chunk of data before it is encoded, not afterwards. 91The six bit size of this number effectively limits the number of bytes 92that can be encoded in each line to a maximum of 63. 93While 94.Xr uuencode 1 95will not encode more than 45 bytes per line, 96.Xr uudecode 1 97will tolerate the maximum line size. 98.Pp 99The remaining characters in the line represent the data of the input 100file encoded as follows. 101Input data are broken into groups of three eight-bit bytes, 102which are then interpreted together as a 24-bit block. 103The first bit of the block is the highest order bit of the first character, 104and the last is the lowest order bit of the third character. 105This block is then broken into four six-bit integers which are encoded one by 106one starting from the first bit of the block. 107The result is a four character 108.Tn ASCII 109string for every three bytes of input data. 110.Pp 111Encoded lines of data continue in this manner until the input file is 112exhausted. 113The end of the body is signaled by an encoded line with a byte count 114of zero (the 115.Tn ASCII 116backquote character \`). 117.Pp 118Obviously, not every input file will be a multiple of three bytes in size. 119In these cases, 120.Xr uuencode 1 121will pad the remaining one or two bytes of data with null characters until 122a three byte group is created. 123The byte count in a line containing 124null padding will reflect the actual number of bytes encoded, making 125it possible to convey how many bytes are null. 126.Pp 127The trailer line consists of 128.Dq end 129on a line by itself. 130.Sh SEE ALSO 131.Xr mail 1 , 132.Xr uudecode 1 , 133.Xr uuencode 1 , 134.Xr ascii 7 135.Sh HISTORY 136The 137.Nm 138file format appeared in 139.Bx 4.0 . 140.Sh BUGS 141The interpretation of the 142.Nm 143format relies on properties of the 144.Tn ASCII 145character set and may not work correctly on non-ASCII systems. 146