Endianness is a tricky matter. A 16-bit int provides a simple example
because there's only two ways around it would normally go:

highbyte lowbyte

or

lowbyte highbyte

To reconstruct it you only need to read into byte variables named
"highByte" and "lowByte", the correct one into each, and then

short result = (((short)highByte)*256) | ((short)lowByte);

and Bob's your uncle. The high byte, times 256, logical-OR'd with the
low byte is correct. (Simply adding the low byte fails if the byte
type is signed, as I think it is in Java, though not in C with e.g.
"typedef unsigned char byte;" -- logical ORing it should work.
Likewise shifting left the high byte should work, but the sign bit of
the high byte is also the sign bit of the short so...)

With Java ints and C longs (32 bits) you've got 24 possible orderings
of the four bytes, because the first can be in any of four places, the
second in any of the remaining three, and the third in either of the
remaining two, before the fourth is forced into the only remaining
place -- 4*3*2 is 24. In practise, the orders you usually see are two
little-endian shorts or two big-endian shorts, with the high short
either first or last (so two independent endian choices and at most
four common byte-orderings).

Any order whatsoever can be dealt with by getting byte1, byte2, byte3,
and byte4 to refer to the LSB, next least significant, and so forth
reading them in whichever order they occur in the data stream (so you
might read byte3 first, depending on the byte order in the stream).
Then left shifting and oring:

int result = (((int)byte4)<<24) || (((int)byte3)<<16) ||
(((int)byte2)<<8) || ((int)byte1)

This should work as long as sign extension isn't used (I think that
requires <<< and is found in Java but not C or C++).

The basic explanation is that you have 32 bits in a line. The first
eight are the high byte, and the last eight are the low byte of the
int. (Java int here; C/C++ users must use long to ensure having 32
bits. Java long is always 64 bits, more than you need here.)

The high byte is cast to an int, which makes it an int with the eight
bits we're interested in the last eight. We need them in the first
eight, and the <<24 shifts them left 24, so the 7th bit (the 7th back
from the end, or first of the interesting eight) is shifted to become
bit 7+24=31, or the leftmost (as there are only 31 bits left of the
last, or zeroth, bit in an int). So the shift moves the eight
interesting bits into the top eight. The shifts on byte3 and byte2
make the bits in them move to the middle positions. The last one isn't
shifted and stays in the lowest position. So after the shifts but
before the logical-ors, we have changed say

file1:  ZWXY

into

byte1:  ...X (. = eight zero bits)
byte2:  ...Y
byte3:  ...Z
byte4:  ...W

(by reading byte3, byte4, byte1, and byte1 in that order)

into

temp1:  ...X
temp2:  ..Y.
temp3:  .Z..
temp4:  W...

and now the logical OR operations just combine them by copying the
nonzero bits into the result at the same place, so Z or . is Z, . or W
is W, etc. and we get:

result: WZYX

with the correct byte order unscrambled from the file's ZWXY order.

you've got two ways from here:
1.) read it in as an integer, and then do mask&shift-magic
on the integer to obtain an endian-swapped version of it.
2.) read four bytes separately, and compose them to an integer.

anyway, you need to be aware of how the separate bits
consitute the final result:
 in the stream you have  b1 b2 b3 b4    four bytes.
The integer value, you want, is:
 0x1*b1 + 0x100*b2 + 0x10000*b3 + 0x1000000*b4
by nature of little ends :-)

Multiplication by these constants is equivalent to
*left*-shifting by 0,8,16,24 bits respectively.
(division would be *right*-shifting)

If you read in the integer canonically from stream, you
actually get this number:
 0x1000000*b1 + 0x10000*b2 + 0x100*b3 + 0x1*b4
by nature of big ends.

So you'd have to do shifting, masking and finally adding
to re-arrange the bit-patterns of the integer.

Sometimes, shifting does the masking for you: if you
divide the whole number by 0x1000000 ( >>24 ), it's obvious,
that only b1 remains.
If you right-shift by 8 bits, then obviously
  0x10000*b1 + 0x100*b2 + 0x1*b3  remains, and after
masking with 0xff00, only 0x100*b2 remains, another one
of the parts which your desired result consists of.

That is: to extract the b1 from that wrong-endian int,
 you'll just to first *right*-shift it by 24 bits, the
 other bits vanishing themselves, so no masking necessary
 here.  For b2, you'd shift the original number only 8 bits
 to the *right*, (to change it's factor from 0x10000 to 0x100),
 and then mask it with 0xff00, (adapted to b2's bits' target
 position.
 For b3 you first mask (again the original value) with 0xff00
 and then *left*-shift 8 bits and for b4 you only need to
 *left*-shift the original number by 24 bits, like b1 no
 masking necessary.
All these separately shifted octets are then re-assembled,
either with or-operator "|", or (in this case equivalently) by adding.

I hope, it helped and wasn't itself more complicated than the
original problem ;-)

see http://mindprod.com/jgloss/endian.html

for general background an bit fiddling see
http://mindprod.com/jgloss/binary.html

An interesting viewpoint, binary data as an "archaic" file structure. I wonder
how you would store your data in a non-binary form. Don't forget that a "text"
file is simply binary interpreted in a very specific way, and one persons
(ASCII) "text" file may be another persons (EBCDIC) binary garbage.

I will do my best to explain - without using any code.

Endian-ness is fun. It adds excitement and joy to the otherwise tedious task of
developing portable code to read arbitrary binary data formats. Java has made
the life of the data processor much less interesting by taking this task and
wrapping it up in the ByteBuffer class. However, for the purposes of learning
it is a good thing to understand what it going on behind the scenes.

There are [essentially] two types of endianess, big-endian and little-endian.
Big-endian hardware stores bytes in memory in their "natural" format, with the
"big" end on the "left" (lower memory address). Little-endian hardware was
designed to do the opposite, just to be awkward.

Lets assume we have 3 variables, containing a char, a 16bit int ("short") and a
32bit int ("long"). We'll assign the hex. values of 0x11, 0x1122 and 0x11223344
to these variables respectively. If these variables occupied consecutive memory
addresses (or were output to binary file in sequence) on big-endian hardware
the contents of memory would be 0x11, 0x11, 0x22, 0x11, 0x22, 0x33, 0x44. On
little-endian hardware the values would be 0x11, 0x22, 0x11, 0x44, 0x33, 0x22,
0x11. As you can see, little-endian hardware has reversed the bytes of each
value. (NOTE: If you write binary data from Java it is *always* output in
big-endian order).

If you write the data to a file and read it back on the same hardware using the
same variable types [and the same language] then there is no problem. The bytes
will be stored in the correct locations and the variables will have the correct
contents. The fun comes when you read the data as a byte array, or attempt to
read it on the other type of hardware or use a language which makes different
assumptions about the type of data.

To see how it all goes horribly wrong lets try to read the little-endian data
file (written by some language other than Java) into Java. Remember, the order
of the bytes in the little-endian binary file is 11221144332211. So we read the
first byte and treat it as a byte, and this is ok. Next we read the two bytes
0x22 and 0x11 and get the short integer 0x2211, not what we wanted at all. The
situation is the same for the "long" integer which will contain 0x44332211.
This is where byte shifting and masking becomes necessary (if you don't use
Java or don't use ByteBuffer in Java), the contents of the "short" and "long"
integers have to be reversed.

You can do this more easily by reading into a byte array and extracting the
correct bytes. For example, for the 4-byte "long" integer, reading the bytes
into a byte array you will get array[0]=0x44, array[1]=0x33, array[2]=0x22 and
array[3]=0x11. To construct the correct integer (0x11223344) you need to shift
array[3] left 24 places so it becomes 0x11000000, combine that with array[2]
left shifted 16 bits (0x220000) etc. How you write the code to do this is up to
you, I said I wouldn't use any code.