You need to know the type of data you are dealing with. For example, if you want to open a .wav file, you find the specification (https://ccrma.stanford.edu/courses/422-winter-2014/projects/WaveFormat/) and then you write your program to the specification.

It says first 4 bytes are the ID, then next 4 bytes are the size, then next 4 are the format... etc. etc. etc.

If somebody just hands you a blob of data and tells you to interpret it, then you are correct to be confused. You'd have no idea what the bytes mean.

Also, if you open a file in the wrong program, it interprets the bytes in the wrong way and you just get nonsense. Open a .exe file in notepad and it's just crazy characters all over the screen.

You’re completely correct that it could either be 9 or a 2 then a 1. The issue is that you’re assuming that the is no context.

In storage, there are conventions (e.g. ASCII) that say that basic text is 8 bits per letter. Similarly, other data is stored in fixed-length intervals.
In RAM, whoever is writing to it determines how it is used. It could be any length. The program (and programmer) using it needs to make sure they’re using it correctly.

There are also ways to compress things like text, where bit length is dynamic. But that’s a bit complex, so let me know if you want that explanation as well.

Not dumb, a great question.

On the microprocessor level the hardware is designed to always read a certain number of digits, called "bits" in this case, and 4 bits become a "nibble", 8 bits are a "byte".

So a 16 bit microprocessor would read the value "one" as

0000 0000 0000 0001

and read "ten" as

0000 0000 0000 1010

So in older days, the processor size was a big deal, I played a lot of video games so I remember that the Nintendo was 8-bit, we then 16-bit systems (Sega and Super Nintendo). and then 32/64 bit processors with Nintendo 64, etc.

For the most part we've stuck at 64 bit for our processors for many reasons.

At the absolute lowest level, it's built into the architecture of the system - when we say a "32-bit" or "64-bit" processor or architecture, what we are saying is that the native instruction set is encoded in that number of bits, with a bit being a discrete 1 or 0 - in other data sets that don't need that much, we will have code that defines the length of a piece of data.

That problem is not specific to computers. 123 456 can be either one single number or 123 & 456 taken separately. Heck, negro can be dark if you read in Portuguese or black if you read in Spanish. You will know which one is the right one by using context.

In the digital world it’s up to the software to decide what 1001 means, based on context. That’s why if you open a png file with mspaint you see a picture but if you open it with notepad you see gibberish

You are 100% right about your question.

I developed on slow CPU (think about microwave, remote control, ...) and desktop.

There is two parts you need to know.

The first one, what everyone will repeat in this thread, everything work as a multiple of 8 bits. (8 to 64 nowday). Like, you can't send 7 or 9 bits, you need to ask a multiple of 8. See it like a box. You have specific boxes size to ship your stuff and worst case fill it with garbage.

Then, it is where you are right, the meaning on those numbers all depends on the CPU or software.

You need to read the CPU manual (called datasheet) to know how those bits will be interpreted because they could be 3 numbers within that 8 bits (like your example).

As for the software, well somebody (like me) programmed it to read it in a specific way to interpret part of that 8bits as I would like. So, the software know how to read it and interpret it.

For the ELI5, you can also see CPU as a software... Running human software

For desktop applications, except when size (bandwidth, space storage, ...) may become big really fast, you don't bother at all to try to squeeze as many numbers into one of those 8 bits multiple. We prefer readability over space nowday.

As for CPU... It can be quite common to have bits different meanings like your question. Again, you must read the datasheet (CPU manual).

Depends on what it's reading. If it knows in advance to expect ASCII text, then it will count out 8 bits to each letter.

The simplest ruleset which doesn't limit you at all would be that, after ten letters, there is a single bit which says whether or not the message continues. This ruleset is inefficient as hell but shows a simple solution.

It's divided up, and any remaining space is filled with zeroes.

You may have heard the terms "bit," "byte," "megabyte," etc. A bit is one digit; a byte is 8 digits, and multiples of that are named with their SI prefixes ("kilobyte", "gigabyte", etc).

So when the computer reads, it's reading in multiples of 8 digits. In your case, the computer might read one byte that has the binary data "1001" stored in it. To the computer, this would show up as "00001001", but 2 would just be "00000010" and 1 would be "00000001."

Note that I'm talking about bytes for simplicity, but computers generally run off a "word" size (which is itself some multiple of 8 bits), and sometimes the first digit is flipped to 1 even if the data doesn't fill the whole space. You can ignore that for now, that's not important for this answer. Specifics aside, the point is that the computer is reading specific numbers of digits at a time and the data is padded with 0s if it doesn't fill all of the digits the computer's reading.

[deleted]

[removed]

You would write in known lengths such as "each number will be 8 bits," as well as extra numbers here and there that might say things like "the first number X is how long the list is, the next X numbers are the list, the number Y after that is how many letters there are, followed by Y number of letters."

The programmer gets to determine all of these things and make up the rules. It's what makes things like reverse engineering file formats difficult, since the file could be laid out in any format.

If you want to see this being done in real time, check out the Metroid Prime Modding Discord. They've been reverse engineering the original GameCube game for years, and recently the remastered dropped so they're currently in the process of tearing that apart and figuring out how the data is laid out so they can read it.

The most accurate short answer is "it depends."

At the processor level, everything is standard lengths and all the interpretation is physically wired into the chip. As an example, many ARM processors (used mostly in phones and such) operate with 32-bit long instructions. A specific part of those 32 bits contains what's called an opcode, which tells the processor how to interpret the rest of the bits.

At the programming level, you need some way to keep track of what format each piece of data is in. If you're programming in assembly (the lowest level language), it's up to you and you alone to make sure everything is being read properly. In something like Java, the language makes you to choose what type of data a variable is and then keeps track of it for you. In something like Python, the interpreter automatically assigns and keeps track of it without you having to do anything.

At the file level, the program you're feeding the data will try to read the file based on its extension. Most file types also have a "header" which is basically a special part at the start of the file that tells you about how to read it. For example, a text file will have a header that tells you which encoding it's using, which lets the program know things like how many bits there are per letter, and which patterns mean which letters.

Bytes are usually organized into words which can be multiple bytes and are the basic unit handled by computers (primary width of the registers used by the CPU usually). The computer itself just performs the requested operation on the word whether that is some arithmetic, logical, store, rotation, shift. The computer does NOT care what the data represents it it just does what it's told.

Interpretation of the data is left up the the software. I (or my compiler) will frequently stuff multiple items within a single word. I do a lot of microcontroller stuff and we are very limited on the amount of program and data memory available. My code will know that my data is located in bits 4 through 8 of the word--because I wrote the code and designed it that way. To access this data I need to do extra operations like shifting the word 4 bits to the right and then masking (setting to zero) all the bits 4 and greater of the word. This leaves me with the data of bits four through eight.

In the example above I've reduced the required data memory by packing the data into just the required bits; however, I've slowed down my code--it requires extra operations to access the data. On modern computers, the memory is essentially limitless and you'd never really bother to pack the data. Speed is more important so you'd just put your 4-bits of data in its own word and waste the unused bits. (I'm talking simple program data/variables--if you're doing movies or something you will likely compress the hell out if it).

Modern computers, in terms of data storage and processing, basically only operate on bytes (groups of 8 binary digits [bits]). So at least in most cases you can assume that 00001001 should be treated as a single value.

Beyond that, it's really up to the software interacting with that data to determine how to process it. This is where file formats come into play. The file format is a specification that clearly defines how to interpret the data in a file. So it will tell you what each byte in a file means.

Sometimes the rules are very strict, like a format will say "Every byte of the file represents a character of the alphabet, here's an ANSI table that maps binary numbers to characters". Or it might be less rigid, like "The first section of the audio file is free text ANSI metadata, which ends when the null byte (00000000) is encountered. The next section..."

Without some context as to what the data represents, it's meaningless. Often this can be conveyed by following the conventions for file extensions - the part of the file name after the last dot (eg .txt is universally recognised as text data encoded with the ANSI or Unicode standards). Often there is also a specific pattern of data at the very beginning of the file (a magic number) that indicates what type of file it is. The file is stored in a file system, which is a particular arrangement of data on a storage device following file system standards. Programs are stored using standard data formats built into the operating system, which in turn send a series of electrical signals to the CPU and other processors following a standard instruction set. It's standards all the way down.

Binary data is ultimately just a series of binary digits - an abstract representation of on/off electrical signals - that the program (by way of the programmer and/or user) has to figure out what to do with. If your friend came to you and blurted out "Eleven! Seventy four! Two! Five thousand, nine hundred and sixty six!" it's not going to mean anything without context.

It's predefined. There is a fascinating (or not) history to and technical justification for how technology developers settled on an "8 bit byte" which then also became a 16, 32, 64, 128, or bigger bit byte, but in every case the answer is the same: it's predefined how many digits the reader will consider.

The actual ELI5 answer: the same reason you understand 4803 as 4803 and not 48 and 3.

1. Separators: in this case, spaces or special sequences between words

2. Conventions: we use byte-sized words, so each 8 bits is a separate word

Of course, these have to be agreed upon by the sender and receiver.

I'll just add -- during the floppy disk era, you couldn't even easily transfer a text document between systems. Every system had their own encoding schemes, not to mention their own disk formatting schemes. It was annoying.

[deleted]

Short Answer: There is an index.

Long Answer: The index is in a fixed location on the disk so the drive knows where to look for it every time. Then for variable width files (images, video, music, text docs) the index gives starting/stopping locations around the disk as files are rarely contiguous these days, especially since SSDs came out. The disk then knows how to translate the start/stops/inbetweens to exact (positions on platters, locations on chip) where the 0/1's are stored to then stream the file as requested.