Working with filesFrom the window to the file · 7 min read

From bits to letters

We already know that in a text file each little group of bits represents a character. The obvious question is still open: how does the machine know that this group of zeros and ones is an "h"?

With a table. That is all.

A list where every letter is assigned a number, and that number is written in binary. The original table is from 1963 and still works exactly the same: the A is 65, the a is 97, the space is 32.

That agreement is everything needed for a file written on one machine to be read on another, sixty years later, with neither of them knowing anything about the other.

Hn.º 7201001000
on.º 11101101111
ln.º 10801101100
an.º 9701100001

They all fit in 8 bits.

01001000011011110110110001100001

Each slice is a number, and each number a letter in the table.

A strip of zeros and ones cut into slices of eight.

Accents and the ñ are the odd case. The first 128 numbers were enough for English and nothing else. Everything that came later — accents, ñ, emoji — is stored with two, three or four groups of bits instead of one.

That is the reason behind the old advice not to put accents in file names: if the file travels to a system that reads those bytes with a different table, the accent breaks.

And that is the reason for the string of symbols. When you open a PDF with Notepad, those bits described a chunk of compressed image. Notepad has no way of knowing that, so it does the only thing it knows: cut every eight and look up the table.

The table always returns something — and that something is the garbage you see.

How does the program know where one letter ends and the next begins?

The machine does not know where a letter ends: it assumes.

snack 5 of 9 · The extension

Powered by KlugerByte