Editing Endianness (section)

=== Files and filesystems ===

The recognition of endianness is important when reading a file or filesystem created on a computer with different endianness.

Fortran sequential unformatted files created with one endianness usually cannot be read on a system using the other endianness because Fortran usually implements a [[storage record|record]] (defined as the data written by a single Fortran statement) as data preceded and succeeded by count fields, which are integers equal to the number of bytes in the data. An attempt to read such a file using Fortran on a system of the other endianness results in a run-time error, because the count fields are incorrect.

[[Unicode]] text can optionally start with a [[byte order mark]] (BOM) to signal the endianness of the file or stream. Its code point is U+FEFF. In [[UTF-32]] for example, a big-endian file should start with {{code|00 00 FE FF|class=nowrap}}; a little-endian should start with {{code|FF FE 00 00|class=nowrap}}.

Application binary data formats, such as [[MATLAB]] ''.mat'' files, or the ''.bil'' data format, used in topography, are usually endianness-independent. This is achieved by storing the data always in one fixed endianness or carrying with the data a switch to indicate the endianness. An example of the former is the binary [[XLS file]] format that is portable between Windows and Mac systems and always little-endian, requiring the Mac application to swap the bytes on load and save when running on a big-endian Motorola 68K or PowerPC processor.<ref>{{cite web |url=http://download.microsoft.com/download/0/B/E/0BE8BDD7-E5E8-422A-ABFD-4342ED7AD886/Excel97-2007BinaryFileFormat(xls)Specification.xps |title=Microsoft Office Excel 97 - 2007 Binary File Format Specification (*.xls 97-2007 format) |year=2007 |publisher=Microsoft Corporation |access-date=2014-08-18 |archive-date=2008-12-22 |archive-url=https://web.archive.org/web/20081222093136/http://download.microsoft.com/download/0/B/E/0BE8BDD7-E5E8-422A-ABFD-4342ED7AD886/Excel97-2007BinaryFileFormat(xls)Specification.xps |url-status=live }}</ref>

[[TIFF]] image files are an example of the second strategy, whose header instructs the application about the endianness of their internal binary integers. If a file starts with the signature {{code|MM}} it means that integers are represented as big-endian, while {{code|II}} means little-endian. Those signatures need a single 16-bit word each, and they are [[palindrome]]s, so they are endianness independent. {{code|I}} stands for [[Intel]] and {{code|M}} stands for [[Motorola]]. Intel CPUs are little-endian, while Motorola 680x0 CPUs are big-endian. This explicit signature allows a TIFF reader program to swap bytes if necessary when a given file was generated by a TIFF writer program running on a computer with a different endianness.

As a consequence of its original implementation on the Intel 8080 platform, the operating system-independent [[File Allocation Table]] (FAT) file system is defined with little-endian byte ordering, even on platforms using another endianness natively, necessitating byte-swap operations for maintaining the FAT on these platforms.

[[ZFS]], which combines a [[filesystem]] and a [[logical volume manager]], is known to provide adaptive endianness and to work with both big-endian and little-endian systems.<ref>{{cite AV media |url=http://open-zfs.org/wiki/Documentation/Read_Write_Lecture |title=FreeBSD Kernel Internals: An Intensive Code Walkthrough |author=Matt Ahrens |year=2016 |publisher=OpenZFS Documentation/Read Write Lecture |access-date=2016-03-30 |archive-date=2016-04-14 |archive-url=https://web.archive.org/web/20160414051047/http://open-zfs.org/wiki/Documentation/Read_Write_Lecture |url-status=live }}</ref>