Implement two programs:
Both programs should read from stdin and write to stdout.
The Base64 encoding is described by the following section from the Network Working Group RFC 2045, entitled "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies".
6.8. Base64 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be humanly
readable. The encoding and decoding algorithms are simple, but the
encoded data are consistently only about 33 percent larger than the
unencoded data. This encoding is virtually identical to the one used
in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.)
NOTE: This subset has the important property that it is represented
identically in all versions of ISO 646, including US-ASCII, and all
characters in the subset are also represented identically in all
versions of EBCDIC. Other popular encodings, such as the encoding
used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741], and
the base85 encoding specified as part of Level 2 PostScript, do not
share these properties, and thus do not fulfill the portability
requirements a binary transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right, a
24-bit input group is formed by concatenating 3 8bit input groups.
These 24 bits are then treated as 4 concatenated 6-bit groups, each
of which is translated into a single digit in the base64 alphabet.
When encoding a bit stream via the base64 encoding, the bit stream
must be presumed to be ordered with the most-significant-bit first.
That is, the first bit in the stream will be the high-order bit in
the first 8bit byte, and the eighth bit will be the low-order bit in
the first 8bit byte, and so on.
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the
output string. These characters, identified in Table 1, below, are
selected so as to be universally representable, and the set excludes
characters with particular significance to SMTP (e.g., ".", CR, LF)
and to the multipart boundary delimiters defined in RFC 2046 (e.g.,
"-").
Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
The encoded output stream must be represented in lines of no more
than 76 characters each. All line breaks or other characters not
found in Table 1 must be ignored by decoding software. In base64
data, characters other than those in Table 1, line breaks, and other
white space probably indicate a transmission error, about which a
warning message or even a message rejection might be appropriate
under some circumstances.
Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a body. When fewer than 24 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 6-bit groups. Padding at the end of
the data is performed using the "=" character. Since all base64
input is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Because it is used only for padding at the end of the data, the
occurrence of any "=" characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No
such assurance is possible, however, when the number of octets
transmitted was a multiple of three and no "=" characters are
present.
Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data
Grading will be based upon completed, correct functionality:
For each program you will not receive any credit for the "additional" functionality or the error handling unless you received full credit for the "basic" functionality.
In the encode program, output 60 characters per line. That is, output 60 characters and then a newline character. Of course, the last line may have fewer than 60 characters. Be sure to output exactly one newline for this last line.
In the decode program, if you encounter a character outside the Base64 alphabet (which includes the newline character), issue an error message to stderr that gives the line number on which the bogus character was encountered and then ignore the bogus character.
In the decode program, if you encounter a line longer than 76 characters, issue an error message to stderr that gives the line number. After issuing the error message, continue processing.
In the decode program, you should also detect other errors in the structure of the file. For example, the proper number of equal signs should appear. And an equal sign cannot appear in the middle of the file. (Are there any other potential problems?) If a problem is detected, issue an error message to stderr that gives the line number where the error was detected.
Both encode and decode should process an empty input file (file length is zero) into an empty output file.
You will need to create your own test files. All test files to be used for grading will be hidden.
Your program will be graded primarily by testing it for correct functionality. However, you may lose points if your program is not properly structured or adequately documented.
Before starting, be sure you understand that the input to encode is likely to be a binary file (i.e. not an ASCII file) and is therefore likely not to be viewable using the standard editing tools or by sending it to an ASCII display device.
You may find using the od command helpful for analyzing binary files. In particular, using the -tx1 flag will display the bytes of a file, one byte at a time, in hexadecimal.
You must write your programs in C. The source for program encode should be placed into a file called "encode.c". The source for program decode should be placed into a file called "decode.c".
You must submit a Makefile (called "Makefile") so that I can conveniently build your programs. The Makefile goal of "encode" should build an executable called "encode" and the goal of "decode" should build an executable called "decode". This Makefile will be worth 10 points.
Your assignment should be submitted for grading from a
CIS Alpha machine (e.g. cisunix.unh.edu).
To turn in this assignment, type:
~cs611/bin/submit prog1 encode.c decode.c Makefile
Do not turn in any other files!
Submissions can be checked from a CIS Alpha machine by typing:
~cs611/bin/scheck prog1
To receive full credit for the assignment, you must turn in your files prior to 8am on Monday February 11. Late submissions will be accepted at the penalty of 5 points per day up to one week late.
Your programs will be graded using a CIS Alpha machine (e.g. cisunix.unh.edu) so be sure to test in that environment.
Remember: as always you are expected to do your own work on this assignment. Copying code from another student or from sites on the internet is explicitly forbidden!
If you developed your code on a DOS/Windows system, be sure to appropriately transfer your files to the CIS Alpha systems before submitting them. You need to convert the DOS ASCII file format to UNIX format. If you need help with this, please see me.
Comments and questions should be directed to hatcher@unh.edu