Your Options to Solving the Endian Problem: a Summary

In a binary file, there are no separators between fields. The files are in binary, not readable ASCII.

What do you do if you want to read data not in this standard format, usually prepared by some non-Java program?

You have five options:

1. Rewrite the export program that is providing the imported file. It might export directly in either big-endian binary DataOutputStream or character DataOutputSream format. See binary formats.
2. Write a separate translator program that reads and rearranges bytes. You could write this in any language.
3. Read the data as bytes, and rearrange them on the fly.
4. Use LEDataInputStream, LEDataOutputStream and LERandomAccessFile analogs of DataInputStream, DataOutputStream and RandomAccessFile that work with little-endian binary data. You can read about LEDataStream. You can download the code and source free. You can get help from the File I/O Amanuensis to show you how to use the classes. Just tell it you have little-endian binary data. This is the easiest way.
5. If you are using JDK 1.4+, you can use nio and the ByteBuffer. order( ByteOrder.LITTLE_ENDIAN ) technique. This the most efficient way.

You Probably Don’t Even Have a Problem!

The only time endianness becomes a concern is in communicating with legacy little-endian C/C++ applications.

The following code will produce the same result on either a big or little endian machine:

// take 16-bit short apart into two 8-bit bytes.
short x = 0xabcd;
byte high = (byte)(x >>> 8);
byte low = (byte)x;/* cast implies & 0xff */
System.out.println( "x=" + x + " high=" + high + " low=" + low );

Reading Little-Endian Binary Files

I had to implement routines parallel to those in java.io. DataInputStream which reads raw binary, in my LEDataInputStream and LEDataOutputStream classes. Don’t confuse this with the java.io.DataInput human-readable character-based file-interchange format.

If you wanted to do it yourself, without the overhead of the full LEDataInputStream and LEDataOutputStream classes, here is the basic technique:

Reading Little-Endian Shorts

short readShortLittleEndian( )
   {
   // clever version
   // 2 bytes
   int low = readByte() & 0xff;
   int high = readByte();
   // avoid masking here
   return(short)( high << 8 | low );
   }

Reading Little-Endian Longs

Reading Little-Endian Chars

Reading Little-Endian Ints

Reading Little-Endian Doubles

Reading Little-Endian Floats

Reading Little-Endian Bytes

byte readByteLittleEndian( )
   {
   // 1 byte
   return readByte();
   }

Nio and ByteBuffer for handling Little Endian Files

Unicode

History

Those in the big-endian camp (most significant byte stored first) include the Java VM virtual computer, the Java binary file format, the IBM 360 and follow-on mainframes such as the 390, and the Motorola 68K and most mainframes. The Power PC is endian-agnostic.

Blefuscudians (big-endians) assert this is the way God intended integers to be stored, most important part first. At an assembler level fields of mixed positive integers and text can be sorted as if it were one big text field key. Real programmers read hex dumps, and big-endian is a lot easier to comprehend.

In the little-endian camp (least significant byte first) are the Intel 8080, 8086, 80286, Pentium and follow ons and the MOS 6502 popularised by the Apple ][.

Lilliputians (little-endians) assert that putting the low order part first is more natural because when you do arithmetic manually, you start at the least significant part and work toward the most significant part. This ordering makes writing multi-precision arithmetic easier since you work up not down. It made implementing 8-bit microprocessors easier. At the assembler level (not in Java) it also lets you cheat and pass addresses of a 32-bit positive ints to a routine expecting only a 16-bit parameter and still have it work. Real programmers read hex dumps, and little-endian is more of a stimulating challenge.

If a machine is word addressable, with no finer addressing supported, the concept of endianness means nothing since words are fetched from RAM in parallel, both ends first.

What Sex Is Your CPU?

Four Byte Sexes

reverseBytes

Learning More