We'll focus on C and Java as they show this concept very clearly.

From Files to Streams

Because files are just bytes, the operating system expose them to programs as streams.

A stream = data that flows sequentially, byte by byte.

You can think of it like drinking water through a straw, you don't grab the whole drink at once instead you sip it continuously. Similarly, programs don't load files magically but open a stream and sequentially read bytes.

Low-level view in C

C is very close to the OS, so you can see the concept directly.

Opening a file:

FILE *f = fopen("data.txt", "rb");

Mode rb means:

• r -> read

• b -> binary (treat as raw bytes)

Reading bytes:

unsigned char buffer[5];

fread(buffer, 1, 5, f);

What we get:

buffer = [72, 101, 108, 108, 111]

C has no idea that this is "hello". Thus, if we want text, then we must interpret it:

printf("%s", buffer);

The program decides that bytes represent characters. This is the purest example of unstructured bytes.

Text is just a convenience layer

C provides helpers like:

fgets(line, 100, f);

This feels like "reading a line of text" but internally it is still reading bytes and stopping when it sees byte value 10 (newline). So the "lines" don't exist in files - programs invent them.

Java - adds abstraction layers

Java hides raw bytes behind InputStreams and Readers. This is where the concept becomes very important.

FileInputStream = raw bytes

FileInputStream fis = new FileInputStream("data.txt");

int b = fis.read();

b is an int 0-255

Again, Java is reading one byte.

Example output:

72

101

108

108

111

Still just numbers.

Converting bytes to text

Humans don't want numbers, we want characters. So Java adds another layer:

InputStreamReader reader = new InputStreamReader(fis, "UTF-8");

Now Java knows:

interpret bytes as UTF-8 characters.

Then we wrap again:

BufferedReader br = new BufferedReader(reader);

String line = br.readLine();

Now we can read:

Hello

But notice the stack:

File -> bytes -> characters -> lines

Multiple layers added by software.

Why Java has many stream classes

Because files are just bytes, Java lets you build pipelines. A common chain would be something such as:

FileInputStream -> raw bytes from file

InputStreamReader ->bytes to characters

BufferedReader -> characters to lines

This layered design exists because files are unstructured.

Binary file example (image)

Reading an image in Java:

FileInputStream fis = new FileInputStream("photo.jpg");

byte[] data = fis.readAllBytes();

Java does NOT know it's an image. But this does:

BufferedImage img = ImageIO.read(new File("photo.jpg"));

Why? Because ImageIO understands JPEG format.

Again: OS gives bytes, library interprets bytes.

Streams are everywhere (not just files)

Once you understand this, a huge realization happens: these are all byte streams:

Source Why

Files bytes from disk

Network bytes from internet

Keyboard bytes from user input

Camera bytes from hardware

This is why Java uses streams for file I/O, sockets, HTTP and pipes. Everything is just flowing bytes.

Deep insight

Hence the famous Unix idea explains everything:

Everything is a file

Examples in Linux:

/dev/keyboard

/dev/mouse

/dev/random

/dev/sda

Hardware devices behave like files.

Big takeaway

When your program reads a file:

1. OS gives raw bytes

2. Language adds abstractions

3. Libraries interpret structure

4. Your program gets meaningful data

Flow:

Disk -> Bytes -> Encoding -> Structure -> Meaning

Why this matters in real projects

You now understand:

• encoding bugs

• corrupted files

• file parsing

• network protocols

• serialization

• databases

• APIs

They all start with streams of bytes.

In the next article we will advance this concept and connect it to serialization (JSON, XML, protobuf) which is the next layer above byte streams.

TAKEAWAY: The meaning of bytes is decided by the program that's reading the file and not the operating system.

The beginning: What is a byte

A byte = 8 bits = a number between 0 to 255

Example byte sequence:

72 101 108 108 111

Only when you interpret it in ASCII format does the byte sequence become:

Hello

But the OS does NOT know this is text. It only sees the numbers.

Why "unstructured"?

Well, because the OS does not impose any format or structure such as lines, words, images, tables, records, etc,.

Those structures only exist in file formats, which are basically software created conventions and so, the same bytes can mean completely different things depending on the program reading them.

For instance, consider these bytes:

50 51 10

Possible interpretations:

Program reading it Meaning

Text editor Characters "23\n***"***

Image viewer Corrupted image

Music player Noise

Compiler Source code fragment

As you can see the OS doesn't care - it just stores bytes.

Text vs Binary files

Now, people will often say text files and binary files. From the OS perspective there is no difference, both are just bytes. The difference only exist in how software interprets them.

For example:

File Reality

.txt bytes interpreted as characters

.jpg bytes interpreted as image encoding

.mp3 bytes interpreted as sound encoding

.exe bytes interpreted as machine instructions

Example: A picture file

A JPEG image is not "a picture" on disk. It's just bytes like:

FF D8 FF E0 00 10 4A 46 49 46 ...

When an image viewer reads these bytes, it:

1. Recognizes JPEG format

2. Decodes bytes

3. Renders pixels

And so without the viewer, it's just meaningless numbers.

Why OS uses this design

This design is powerful and flexible.

1. Simplicity

The OS just needs to provide basic operations:

• Open file

• Read bytes

• Write bytes

• Close file

Thus removes the need to understand or support thousands of formats.

1. Portability

Programs can just define their own formats and they are guaranteed to work across systems.

In essence, any program can store any kind of data such as text, video, databases, AI models or compressed archives, all using the same interface.

How programs add structure

Programs impose structure using file formats. Here is are examples of structures added on top of raw bytes:

Example 1: Text file structure

Hello\nWorld

Structure added:

• Characters

• Lines

• Encoding (UTF-8)

Example 2: CSV structure

Name,Age

Alice,25

Bob,30

Structure added:

• Rows

• Columns

• Delimiter rules

Example 3: Database file

Structure added:

• Pages

• Indexes

• Schemas

• Records

All still just bytes underneath.

Why this matter in programming

This simple yet noble concept explains many real behaviors such as:

• Why file extensions don't matter

Renaming: photo.jpg -> photo.txt

doesn't change the file - only how programs try to interpret it.

• Why corrupted files exist

If some bytes change, then the program cannot correctly interpret structure and thus the file appears broken.

• Why encoding issues happen

Consider these bytes: C3 A9

in UTF-8 = "é"

in ASCII = "é"

Same bytes, different interpretation.

Summary

In short, we can conclude that files are:

• Just sequence of bytes

• With no built-in structure

• The OS is format-agnostic

• Structure is defined by software that reads the file

In the follow-up article, I'll try practically connect this very concept to how Java and C read files and streams.

References
"... and the notion of files as unstructured streams of bytes" (Kerrisk, The Linux Programming Interface, p. 2).