Format

/juː-ti-ɛf θɜːrtiː-tuː/

noun — "a fixed-length Unicode encoding using 32-bit units."

UTF-32 (Unicode Transformation Format, 32-bit) is a character encoding standard that represents every Unicode code point using a fixed 32-bit code unit. Unlike variable-length encodings such as UTF-8 or UTF-16, each Unicode character in UTF-32 is stored in exactly 4 bytes, providing simple and direct access to any character without the need for parsing multiple bytes or surrogate pairs.

Technically, UTF-32 works as follows:

• Every code point in the range U+0000 to U+10FFFF is encoded as a single 32-bit unit.
• Optional Byte Order Marks (BOM) can indicate little-endian or big-endian ordering for storage and transmission.
• No surrogate pairs or variable-length sequences are required, simplifying indexing, slicing, and random access in text processing.

# example: encoding the character "A" (U+0041) in UTF-32
char = "A"
utf32_bytes = char.encode('utf-32')
# utf32_bytes = b'\xff\xfe\x00\x00\x41\x00\x00\x00'  # includes BOM
# fixed 4-byte representation for each character

Conceptually, UTF-32 is the most straightforward encoding for mapping Unicode characters to machine memory. Each code point corresponds to exactly one fixed-size unit, making character indexing and manipulation trivial. However, this simplicity comes at the cost of storage efficiency, as most text (especially ASCII or BMP characters) uses more bytes than necessary compared to UTF-8 or UTF-16.

UTF-32 is primarily used in internal data structures, programming language APIs, or situations where simplicity and predictable indexing outweigh memory concerns. It is rarely used for network transmission or file storage due to its larger size.

See Unicode, UTF-8, UTF-16, Character Encoding.

/juː-ti-ɛf/

noun — "a family of Unicode Transformation Format encodings."

UTF (Unicode Transformation Format) refers collectively to a set of character encoding schemes designed to represent Unicode code points as sequences of bytes or code units. Each UTF variant defines a method to convert the abstract numeric code points of Unicode into a binary format suitable for storage, transmission, and processing in digital systems. The most common UTFs are UTF-8, UTF-16, and UTF-32, each with different characteristics optimized for efficiency, compatibility, or simplicity.

Technically, a UTF defines:

• How each Unicode code point (U+0000 to U+10FFFF) maps to one or more code units (bytes or 16-/32-bit units).
• Rules for encoding and decoding sequences of code units, including handling multi-unit characters and surrogate pairs (for UTF-16).
• Optional markers such as a Byte Order Mark (BOM) to indicate endianness in UTF-16 and UTF-32.

Examples of UTF variants include:

• UTF-8 — variable-length encoding using 1 to 4 bytes per code point, backward-compatible with ASCII.
• UTF-16 — uses 16-bit units, with surrogate pairs for code points above U+FFFF.
• UTF-32 — fixed-length encoding using 32 bits per code point, simple but space-inefficient.

# example: representing the character "A" in different UTFs
char = "A"                  # code point U+0041
utf8_bytes = char.encode('utf-8')    # b'\x41'
utf16_bytes = char.encode('utf-16')  # b'\xff\xfe\x41\x00'
utf32_bytes = char.encode('utf-32')  # b'\xff\xfe\x00\x00\x41\x00\x00\x00'

Conceptually, UTF is the bridge between Unicode’s abstract set of characters and practical binary storage or communication formats. Each variant balances trade-offs between storage efficiency, processing complexity, and compatibility with existing systems. UTFs ensure that text in any language or script can be represented reliably across platforms, devices, and applications.

In practice, choosing the appropriate UTF depends on the system’s needs. UTF-8 is most common for web and file formats, UTF-16 is used in environments optimized for 16-bit units (e.g., Windows, Java), and UTF-32 provides straightforward indexing at the cost of storage space.

See Unicode, UTF-8, UTF-16, UTF-32, Character Encoding.

/juː-ti-ɛf sɪksˈtiːn/

noun — "a fixed- or variable-length encoding for Unicode using 16-bit units."

UTF-16 (Unicode Transformation Format, 16-bit) is a character encoding standard that represents Unicode code points using sequences of 16-bit units, called code units. It can encode every Unicode character, including those outside the Basic Multilingual Plane (BMP), using either a single 16-bit unit or a pair of units known as a surrogate pair. UTF-16 is widely used in operating systems, programming environments, and file formats where 16-bit alignment provides efficiency and compatibility.

Technically, UTF-16 encodes Unicode characters as follows:

• Code points U+0000 to U+FFFF (BMP) are represented directly as a single 16-bit code unit.
• Code points U+10000 to U+10FFFF are represented using 2 16-bit units, called a surrogate pair. The first unit is a high surrogate, and the second is a low surrogate, together encoding the full code point.

This system allows UTF-16 to efficiently cover all Unicode characters while maintaining backward compatibility with systems expecting 16-bit aligned text.

# example: encoding the "𝄞" (musical G clef, U+1D11E) in UTF-16
char = "𝄞"
code_point = ord(char)                  # U+1D11E
utf16_bytes = char.encode('utf-16')     
# utf16_bytes = b'\xff\xfe\x34\xd8\x1e\xdd'
# uses a surrogate pair (high: 0xD834, low: 0xDD1E)

UTF-16 may be stored in little-endian or big-endian order. To indicate byte order, a Byte Order Mark (BOM) — code point U+FEFF — is often included at the start of a text stream. This allows systems to correctly interpret multi-byte sequences regardless of platform.

Conceptually, UTF-16 acts as a bridge between Unicode’s abstract code points and machine-level storage using 16-bit units. It is especially effective for languages and scripts where most characters fall within the BMP, as many characters can be represented with a single 16-bit unit. However, for texts containing a significant number of supplementary characters, UTF-16 requires surrogate pairs, making some operations more complex than in UTF-8.

In practice, UTF-16 is widely used in Windows operating systems, Java, .NET, and many internal text-processing systems. It provides efficient access to characters for algorithms optimized for 16-bit units and supports full Unicode interoperability when correctly implemented.

See Unicode, UTF-8, ASCII, Character Encoding.

/juː-ti-ɛf eɪt/

noun — "a variable-length encoding for Unicode characters."

UTF-8 (Unicode Transformation Format, 8-bit) is a character encoding system that represents every Unicode code point using sequences of 1 to 4 bytes. It is designed to be backward-compatible with ASCII, efficient for storage, and fully capable of representing every character defined in the Unicode standard. UTF-8 has become the dominant encoding for web content, software, and data interchange because it combines compatibility, compactness, and universality.

Technically, UTF-8 encodes Unicode code points as follows:

• Code points U+0000 to U+007F (basic ASCII) use 1 byte.
• Code points U+0080 to U+07FF use 2 bytes.
• Code points U+0800 to U+FFFF use 3 bytes.
• Code points U+10000 to U+10FFFF use 4 bytes.

This variable-length structure ensures efficient storage for common characters while still covering all languages and symbols.

# example: encoding "€" (Euro sign) in UTF-8
char = "€"
code_point = ord(char)            # U+20AC
utf8_bytes = char.encode('utf-8') 
# utf8_bytes = b'\xe2\x82\xac'
# 3-byte sequence represents the Unicode code point

UTF-8 is self-synchronizing: the start of a multi-byte sequence can be identified unambiguously, and the encoding prevents accidental misinterpretation of byte streams. This makes it robust for streaming, file storage, and network transmission. Additionally, it preserves ASCII characters exactly, so any ASCII text is already valid UTF-8.

Conceptually, UTF-8 is a bridge between human-readable characters and machine-level binary storage. It allows multilingual text, emojis, symbols, and special formatting characters to coexist in a single, standardized encoding, ensuring interoperability across systems and applications worldwide.

In practice, UTF-8 underpins most web technologies, operating systems, programming languages, and file formats. Its adoption simplifies internationalization, avoids encoding conflicts, and reduces storage overhead for texts that primarily use ASCII characters.

See Unicode, UTF-16, ASCII, Character Encoding.

/ɛks tiː fɔːr/

noun — "modern journaling Linux filesystem."

EXT4, short for Fourth Extended File System, is a Linux filesystem that advances the design of EXT3 by adding features for higher performance, larger volume and file support, and improved reliability. It maintains backward compatibility with EXT3 while introducing extents, delayed allocation, multiblock allocation, and larger timestamps, enhancing efficiency and reducing fragmentation.

Technically, EXT4 continues to use the block group structure inherited from EXT and EXT2, with inodes storing metadata including ownership, permissions, timestamps, and pointers to data blocks. Unlike previous versions, EXT4 uses extents—contiguous ranges of blocks—to represent large files, reducing metadata overhead. Delayed allocation postpones block assignment until data is flushed to disk, improving contiguous block allocation and performance. Journaling options include writeback, ordered, and journal modes similar to EXT3, providing crash recovery and consistent metadata. EXT4 supports volumes up to 1 exabyte and individual file sizes up to 16 terabytes, depending on block size and inode configuration.

Operationally, writing a file on an EXT4 filesystem involves allocating an inode, determining optimal extents using delayed allocation, and writing data blocks to disk. The journal records metadata changes before committing them, allowing fast recovery after unexpected shutdowns. Reading files involves translating logical block numbers from inodes or extents into physical disk locations, with the filesystem handling large contiguous blocks efficiently. Administrative tasks are performed using tools like mkfs.ext4, tune2fs, and fsck.

Example workflow for creating and mounting an EXT4 filesystem:

mkfs.ext4 /dev/sdc1
mount /dev/sdc1 /mnt/data
ls -l /mnt/data

This sequence formats a partition as EXT4, mounts it, and verifies its contents. The journaling and extent features ensure high reliability and efficiency for both small and large files.

In practice, EXT4 is widely deployed across modern Linux desktops, servers, cloud environments, and embedded systems. Its combination of backward compatibility, high performance, large volume support, and journaling makes it suitable for high-throughput workloads, database storage, and general-purpose file storage. Features like multiblock allocation and persistent preallocation further optimize performance for intensive write operations.

Conceptually, EXT4 is like a warehouse with smart shelving: blocks of items (data) are stored in contiguous racks (extents), reserved ahead of time (delayed allocation), and changes are logged in a ledger (journal) to ensure consistency and rapid recovery in case of disruption.

See EXT3, EXT2, FileSystem, Journaling, EXT.

/ɛks tiː θriː/

noun — "journaling Linux filesystem."

EXT3, short for Third Extended File System, is a Linux filesystem that builds upon the structure of EXT2 by adding journaling capabilities to improve reliability and reduce recovery time after system crashes. It maintains backward compatibility with EXT2, allowing existing tools, utilities, and data to work seamlessly, while providing enhanced integrity for both metadata and optionally data.

Technically, EXT3 retains the block group organization of EXT2, where each block group contains inodes, data blocks, and bitmaps for free block and inode tracking. The key addition is the journal, a dedicated area that logs filesystem operations before they are committed. This journal can operate in multiple modes: writeback, which journals metadata only; ordered, which journals metadata and ensures data blocks are written before metadata; and journal, which logs both metadata and data for maximum consistency. EXT3 supports block sizes ranging from 1 to 4 kilobytes, enabling volumes up to multiple terabytes depending on block configuration.

Operationally, when a file is created or modified, the intended changes are first recorded in the journal. Once safely logged, the filesystem applies the changes to the main storage structures. If the system crashes unexpectedly, the journal can be replayed during the next mount to complete any pending operations, maintaining consistency without requiring full filesystem checks. Reading files involves accessing inodes to locate data blocks, similar to EXT2. Administrators can manage EXT3 with tools like tune2fs for adjusting filesystem parameters and fsck for integrity verification.

Example workflow for creating and mounting an EXT3 filesystem:

mkfs.ext3 /dev/sdb1
mount /dev/sdb1 /mnt/data
ls -l /mnt/data

This process formats a partition as EXT3, mounts it, and lists its contents, while journaling ensures rapid recovery if a crash occurs.

In practice, EXT3 is widely used in servers, desktops, and embedded Linux systems that need a balance between performance and reliability. Its backward compatibility simplifies upgrades from EXT2, while journaling reduces downtime caused by crashes. Although EXT4 offers newer features like extents and larger file support, EXT3 remains valued for stability and its proven track record.

Conceptually, EXT3 is like maintaining a ledger alongside your main document: intended edits are recorded in the ledger first, ensuring that even if the system fails, work can be completed without corruption.

See EXT2, EXT4, FileSystem, Journaling.

/ɛks tiː tuː/

noun — "second generation Linux filesystem."

EXT2, short for Second Extended File System, is a filesystem designed for Linux that introduced improvements over the original EXT filesystem, including larger volume support, optimized metadata management, and more efficient file storage structures. It does not include journaling, unlike its successors EXT3 and EXT4, but its simplicity offers high performance for certain use cases, particularly on systems where crash recovery is handled externally.

Technically, EXT2 organizes storage into block groups, each containing inodes, data blocks, and bitmaps to track allocation status. Inodes hold file metadata, such as ownership, permissions, timestamps, and pointers to data blocks. Each file occupies one or more contiguous or linked blocks, and directories are implemented as special files containing references to inodes. The filesystem supports block sizes of 1, 2, 4, or 8 kilobytes, allowing volume sizes up to 32 terabytes depending on the block size and inode configuration. Fragmentation can occur over time because EXT2 lacks journaling and advanced allocation strategies.

Operationally, when a file is written, the system allocates an inode, identifies free data blocks via the bitmap, and stores the file data. Reading a file requires accessing the inode and following block pointers to reconstruct the file content. Recovery from crashes relies on external tools like fsck, which scans the filesystem for inconsistencies and repairs allocation tables. Unlike journaling filesystems, EXT2 does not log pending operations, so uncommitted writes may be lost on a system crash.

Example workflow of creating and mounting an EXT2 filesystem:

mkfs.ext2 /dev/sdc1
mount /dev/sdc1 /mnt/storage
ls -l /mnt/storage

This sequence formats a partition as EXT2, mounts it, and lists its contents for verification.

In practice, EXT2 is still used in embedded Linux systems, USB drives, and boot partitions where journaling is unnecessary or could introduce additional wear on flash media. Its lightweight nature and stability make it suitable for read-heavy or static environments, while more dynamic or high-availability systems often prefer EXT3 or EXT4 for crash resilience and journaling.

Conceptually, EXT2 is like a traditional filing cabinet with well-labeled folders: each inode is a folder card pointing to the pages (data blocks) where the file contents are stored. There is no log of in-progress changes, so maintaining integrity requires careful management and external checks.

See EXT, EXT3, EXT4, FileSystem.

/ɛks tɛnˈdɪd/

noun — "Linux filesystem family."

EXT, short for Extended File System, is a series of filesystems primarily used in Linux operating systems. It was designed to improve upon the limitations of early UNIX-like filesystems by introducing features like larger volume support, journaling, and metadata optimization. The family includes EXT2, EXT3, and EXT4, each progressively adding capabilities while maintaining backward compatibility.

Technically, EXT organizes storage into block groups containing inodes, data blocks, and bitmaps that track free and used blocks. Inodes store file metadata, including size, ownership, permissions, timestamps, and pointers to data blocks. The filesystem supports hierarchical directories and symbolic links. Later versions, such as EXT3 and EXT4, implement journaling to record pending changes, which enhances reliability in the event of system crashes. EXT4 introduces extents, larger storage units for contiguous blocks, improving performance for large files, and supports delayed allocation for better fragmentation handling.

Operationally, writing a file on an EXT filesystem involves allocating an inode, assigning data blocks, and updating the block and inode bitmaps. For EXT3 and EXT4, journal entries are first recorded to ensure atomicity of operations. Reading files involves traversing inodes to access data blocks in sequence, with the filesystem translating logical block numbers to physical storage locations using structures like block group tables. Tools like UUID or device identifiers facilitate mounting and managing multiple volumes.

Example of filesystem creation in Linux:

mkfs.ext4 /dev/sdb1
mount /dev/sdb1 /mnt/data
ls -l /mnt/data

This sequence formats a partition as EXT4, mounts it, and lists its contents.

In practice, EXT filesystems are widely used in desktops, servers, embedded Linux systems, and cloud environments due to their stability, robustness, and Linux kernel integration. Administrators benefit from features like journaling, snapshots via LVM integration, and online resizing in EXT4 without unmounting volumes.

Conceptually, EXT is like a well-organized library: inodes act as catalog cards storing metadata, data blocks are the physical pages, and the journal functions as a safety ledger recording ongoing changes to prevent lost work after power failures.

See EXT2, EXT3, EXT4, UUID, FileSystem.

/ˌfæt ˈtwɛlv/

noun — "early File Allocation Table filesystem."

FAT12, short for File Allocation Table 12, is the original variant of the FAT filesystem family, using 12-bit cluster addressing to manage storage on floppy disks and small-volume drives. It organizes data into clusters and tracks their allocation in a linear table, providing a simple yet effective method for file storage and retrieval.

Technically, FAT12 divides a storage medium into fixed-size clusters, each consisting of one or more logical blocks addressed via LBA. The File Allocation Table maintains 12-bit entries for each cluster, specifying the next cluster in a file chain, marking end-of-file, or indicating available clusters. Directory entries store metadata such as filenames, attributes, timestamps, and the starting cluster of each file. This design allows the filesystem to track files efficiently without requiring knowledge of the physical layout of the storage device.

Operationally, writing a file in FAT12 involves allocating free clusters, updating the File Allocation Table to form a cluster chain, and writing the file data into these clusters. Reading a file requires traversing this chain sequentially from the starting cluster to the end-of-file marker. Deletion marks clusters as free, leaving data intact until overwritten, which allows data recovery but can create security considerations. Performance is limited by the linear nature of cluster allocation and by fragmentation, which may slow access as clusters become non-contiguous.

Constraints of FAT12 include a maximum volume size typically around 32 megabytes and file sizes limited by cluster addressing, making it unsuitable for larger storage devices. Its simplicity, however, made it highly compatible across early personal computers, embedded systems, and bootable floppy media. Unlike modern filesystems, FAT12 does not support journaling or advanced metadata.

In practical workflows, FAT12 is mainly encountered in legacy or embedded environments. File systems translate logical file offsets into cluster chains, which are then converted into physical addresses via LBA. Bootloaders and firmware often include routines to read FAT12 volumes directly, providing cross-platform access and enabling early bootstrapping operations on floppy or small drives.

Example of a file cluster chain in FAT12:

File start cluster: 2
FAT[2]  = 5
FAT[5]  = 9
FAT[9]  = EOF

This sequence shows the file occupies clusters 2, 5, and 9, which may be physically non-contiguous but are logically linked via the File Allocation Table.

Conceptually, FAT12 functions like a simple index card system in a small filing cabinet: each card points to the next data location, allowing easy tracking and retrieval, though limited in scale.

See FAT16, FAT32, FileSystem, LBA.

/ˌfæt/

noun — "file allocation table filesystem family."

FAT, short for File Allocation Table, is a family of disk filesystems designed to organize, store, and retrieve files on block-based storage devices using a table-driven allocation scheme. Variants include FAT12, FAT16, and FAT32, each defined by the number of bits used to address clusters. FAT abstracts physical storage layout into logical cluster sequences, enabling operating systems and firmware to manage files without hardware-specific knowledge.

Technically, FAT works by dividing a storage volume into clusters, which are groups of one or more logical blocks addressed using LBA. The File Allocation Table maps each cluster to the next cluster in a file chain, marks the end-of-file, or indicates free space. Directory entries contain file metadata, including names, attributes, timestamps, and starting clusters. The simplicity of FAT allows efficient implementation in operating systems, bootloaders, and embedded devices but provides limited resilience, lacking journaling and advanced metadata features.

Operationally, when a file is written, the filesystem allocates clusters, links them in the File Allocation Table, and writes data to the allocated clusters. Reading a file involves traversing the cluster chain from the starting cluster to the end-of-file marker. Deleting a file marks clusters as free without erasing contents immediately, enabling recovery tools to retrieve deleted files. Performance can be affected by fragmentation, especially on large volumes, because cluster chains may become non-contiguous.

Constraints vary across FAT variants. FAT12 supports small volumes typically for floppy disks. FAT16 increases maximum volume and file sizes using 16-bit cluster addressing. FAT32 further expands addressing with 32-bit clusters, supporting volumes up to approximately 2 terabytes and individual files up to 4 gigabytes minus 1 byte. These addressing limits are intrinsic to the variant and dictate compatibility and performance considerations.

In workflow terms, FAT is widely used in removable media, boot partitions, embedded devices, and cross-platform storage solutions. File systems map logical file offsets to clusters, the operating system translates cluster numbers to LBA addresses, and storage controllers access physical blocks. Partitioning schemes isolate different data sets, while firmware like BIOS or UEFI can directly read FAT volumes for boot purposes.

Example cluster chain for a file on a FAT16 volume:

File start cluster: 4
FAT[4]  = 6
FAT[6]  = 8
FAT[8]  = EOF

Here, the file occupies clusters 4, 6, and 8, which may be non-contiguous physically but are logically linked via the File Allocation Table.

Conceptually, FAT operates like an index in a filing cabinet: each entry points to the next location where data is stored. This approach makes data access predictable and cross-compatible but limits scalability compared to modern journaling filesystems.

See FAT12, FAT16, FAT32, FileSystem, LBA.