Zone Bits and Why EBCDIC Letters Are Not Contiguous

Six-bit character codes came first, because six bits hold sixty-four characters and a card reader’s 64-row interpretation fits them exactly. When the byte became the unit of addressability, the character set had to grow into eight bits, and the question was how to spend the extra two. ASCII answered by treating the byte as a seven-bit index into a table of eighty-odd printable characters plus thirty-three control codes, ordered so that the alphabet appears as one contiguous run. EBCDIC answered differently, and the difference is not arbitrary: it came from a punched-card heritage in which a character was already the combination of a zone punch and a digit punch, and the byte preserved that structure rather than flattening it.

A byte is two nibbles with different jobs

In EBCDIC the high nibble of a byte is the zone and the low nibble is the digit. For the ten decimal digits the zone is 0xF and the digit nibble is the value: 0 through 9 occupy 0xF0 to 0xF9. For letters the digit nibble carries a position within a group of nine and the zone nibble carries which group. The uppercase alphabet is split into three zones, and the lowercase alphabet into three more, offset from the uppercase by a fixed difference in the zone nibble.

The mapping for the uppercase letters is the clearest way to see the structure:

zone  digit     letters
0xC   1 .. 9    A B C D E F G H I
0xD   1 .. 9    J K L M N O P Q R
0xE   2 .. 9    S T U V W X Y Z

Two features of that table matter more than the specific values. First, the digit nibble restarts at 1 for each zone, so it is not an index into the alphabet: I has digit nibble 9, J has digit nibble 1. Second, the third zone holds only eight letters, so its digit nibble runs from 2 to 9; the positions below that in the same zone carry other characters, not letters. Nothing about the digit nibble alone distinguishes I from R; only the pair does.

The layout is a direct descendant of the card. On an 80-column card a letter is one zone punch (the 12, 11, or 0 row) over one digit punch (rows 1 through 9), and the letter’s identity is exactly that pair. Punched-card sorters compared columns mechanically, and a column containing a letter had both punches present. Encoding the pair as two nibbles preserved the ability to sort a deck and the ability to read a column as a zone-and-digit combination. ASCII, which came from teleprinter practice rather than card practice, had no such constraint and could place A at 0x41 and run the alphabet upward without interruption.

What contiguity buys, and what the gaps cost

Contiguous alphabets allow arithmetic. In ASCII, converting an uppercase letter to its ordinal position is c - 'A', and converting between cases is a single subtraction of 0x20, whose validity depends on the alphabet being a contiguous run with a fixed offset between the two cases. In EBCDIC the first operation fails outright: c - 'A' is not the position of the letter for anything past I. Case conversion, oddly, is the one thing that does work arithmetically, because the lowercase range sits exactly 0x40 below the uppercase range in the zone nibble, so adding 0x40 to a lowercase letter yields its uppercase form and subtracting it goes back. The catch is that the shift runs opposite to ASCII: uppercase bytes are numerically greater than lowercase bytes, so a byte comparison sorts A after a, where ASCII sorts it before.

The consequence is that programs written for one character set and moved to the other break in ways that are invisible until data arrives. Code that indexes a table of twenty-six letters by subtracting a base character works on ASCII and silently mis-indexes on EBCDIC. This is why portable C of the period did not assume contiguity: the standard’s guarantee that the digits 0 through 9 occupy consecutive values and increase in order is deliberate and narrow, and it is the only ordering guarantee the language makes about the collating sequence. Nothing is promised about letters. Programs that need the position of a letter in the alphabet use a lookup, and the reason is EBCDIC.

Digits are contiguous in both sets, which is why arithmetic on character data is portable and alphabet arithmetic is not.

Byte order is not collating order

Sorting exposes the rest of the structure. In ASCII, byte comparison gives an order in which space precedes punctuation, punctuation precedes digits, digits precede uppercase letters, and uppercase precedes lowercase. That is already wrong as a dictionary order for mixed text, but it is at least monotone within each class.

EBCDIC places the digits at the top of the range, 0xF0 to 0xF9. Byte comparison therefore sorts digits after every letter. A file of part numbers such as A1, A2, A10 sorted by byte value gives an order determined first by the zone of the letter, then by its digit nibble, then by the zone and digit of the numeric character, and the result interleaves letters and digits in a way no reader would predict. Blank is 0x40, which sorts after every control character and before every graphic character, so a leading blank precedes a letter but a trailing one follows every digit.

Nothing here is a defect in the encoding; it is the encoding doing exactly what a card sorter did. A card sorter given a column with a zone punch over a digit punch sorts it by the zone first, because the zone row is above the digit rows. The byte order reproduces the card order. Collation for a specific purpose is therefore a separate operation layered on top, and it is implemented as a table or as a sequence of weights, not as a comparison of bytes. Programs that sort by comparing bytes and then expect the answer to match a printed index are wrong on both character sets, but they are wrong differently.

Translation is a table, and the table has national variants

Because the structure is not arithmetic, conversion between EBCDIC and ASCII is a 256-entry table, and there is no way to derive the table from a formula. That much is common to every single-byte conversion. What makes EBCDIC harder is that the table is not unique.

The character set defines the letters and digits. It does not fix every position. Several byte values are assigned differently in different national code pages: the positions holding the currency symbol, the commercial at, the brackets, the exclamation mark, and a handful of accented letters vary between the code pages used in different countries. A file of source code containing [ and ] translated with the wrong page yields a different pair of characters, and the resulting text compiles differently or not at all. The page identifier travels with the data in the system’s own metadata, or it does not travel at all, and when it does not, the reader has to guess from context.

The translation table is also not symmetric in cost. Converting ASCII to EBCDIC and back through mismatched pages is not a round trip; each direction can lose information if the target set has no position for a character in the source. Characters outside the seven-bit ASCII set have no EBCDIC position at all unless the page was defined with them, and a conversion routine that maps unrepresentable characters to a substitute does so silently unless it is written to report them.

Where the boundary between code and character falls

Two practical rules follow from the layout, and both are about not assuming the alphabet.

The first is that any operation depending on letter order must consult a collating table rather than compute from the character value. This includes sorting, range checks such as “is this character a letter”, and case conversion. The C library functions for these exist precisely because the language refuses to promise contiguity, and their behaviour is defined by the current locale’s collating sequence rather than by the byte values.

The second is that a program storing character data in a file must record which code page produced it, and a record layout written as fixed-length character fields has the same problem in a different form: blocked tape records carry no field descriptions either, because the bytes alone do not say. A file of EBCDIC text and a file of ASCII text are both sequences of bytes in the same range, and no header distinguishes them; the difference is entirely in the interpretation. Systems that carry the encoding as metadata on the file are making an explicit choice to avoid the guessing, and systems that do not are relying on the reader knowing where the file came from.

The zone-and-digit structure survives into the arithmetic representations that were built on top of it. Packed decimal, described in packed and zoned decimal arithmetic, takes the same two-nibble idea and gives the low nibble of the final byte a new job: it holds the sign instead of a digit. The encoding of characters and the encoding of numbers share a shape because they were both designed to be read off a card.