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