Working with files › From the window to the file · 7 min read
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.
They all fit in 8 bits.
Each slice is a number, and each number a letter in the table.
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