ASCII Encoding

Encoding the unsigned integer checksum into an ASCII string that may legally be embedded in a FITS header is a matter of dividing each initial byte into four bytes--this permits each quarter of the original 8-bit byte to fit within the range of the ASCII alphanumerics, including a hex 30 offset to start at ASCII 0 (zero). The ASCII special characters are avoided by the encoding algorithm implemented in appendices A and B of this proposal, as shown in Figure 1. Restricting the encoded value to the ASCII alphanumerics is not required by the FITS standard (see §5.3 in ref. 5), but rather promotes human readability and transcription.

The reason that this encoding works is that unlike the more familiar uuencode or binhex schemes for representing binary data as printable ASCII characters, this is not just encoding the meaning of the binary data, but the checksum's actual 32-bit unsigned integer value itself. This integer is divided into 4 equal pieces that are placed in four successive integer aligned fields in the (otherwise ASCII) header.

Dividing each of the 4 bytes of the original integer value into 4 separate bytes results in sixteen total bytes. (Any remainder from each bytewise division is added to the first byte in each of the four quartets.) The division by 4 allows each of the 16 bytes to fit within the range of the ASCII alphanumeric characters - with room to spare since there is a range of 75 from ASCII 0 (zero) at hex 30 to ASCII z at hex 7A. Only a range of 64 is needed to quarter each original byte. The spare room in the ASCII chart allows excluding non-alphanumeric characters. The trick is to offset the zero of the character encoding to ASCII zero (hex 30) before accumulating the checksum. This offset is subtracted back out again when the ASCII zeroes are replaced by the final complemented checksum.

The key concept is that dividing the byte into four bytes means dividing the integer value by four, with three bytes having a value one-fourth of the original byte (the quotient of dividing by four) and the final byte, quotient plus remainder. Before ASCII zero is added, the four bytes sum to the original. Adding ASCII zero (hex 30) restricts the character value of the bytes to be printable ASCII. The adjustment to further restrict each character in the string to only the ASCII alphanumerics consists of decrementing one byte and incrementing another byte by the same amount. Then, when the ASCII zero is subtracted (at the receiving end), the four new bytes will still add to the original number. This whole thing is repeated for all four bytes of the original checksum.

Alternate interpretations of the ASCII encoding algorithm are possible, see §3.6.