Mal 'ne Frage zur ByteOrder

[Rock Lobster]

Servus,

nehmen wir an, ich öffne eine Datei und möchte prüfen, ob es sich um eine WAV-Datei handelt. Da diese immer mit den 4 Byte 'RIFF' anfangen, bietet es sich natürlich an, dies zu überprüfen.

Jetzt stellt sich aber die Frage, wie das genau mit der ByteOrder läuft. Wenn ich die Datei mit dem Hex-Editor öffne, dann kann ich 'RIFF' im Klartext lesen. Da es sich schlicht und einfach um eine Datei handelt, müßte diese ja auf jedem System erstmal exakt gleich sein (da die Anordnung der Bytes bei einer Datei ja nunmal "in Stein gemeißelt" ist und sich nicht einfach so ändert, wenn man sie irgendwoanders hinkopiert).

Aber wenn ich diese 4 Byte nun direkt als Zahl interpretiere, dann ist das je nach ByteOrder entweder "52 49 46 46" oder aber "46 46 49 52".

1) Nun, was passiert, wenn ich einfach aus einem InputStream per "read" in ein Byte-Array lese, das 4 Byte groß ist? Dann müßte doch eigentlich in [0] die 0x52 stehen und im [3] eine 0x46, da ja einfach aus der "feststehenden" Datei Byte für Byte rausgenommen und in mein Array geschrieben wird. Ist das so korrekt? In dem Fall müßte also ein Java-Code, der diese 4 Byte in einen String umwandelt (mit der Reihenfolge [0], [1], [2], [3]), auf jeder Plattform exakt das gleiche Ergebnis liefern, also bräuchte ich mir ja hierbei keine Gedanken machen, ist das richtig?

2) Es gibt z.B. den DataInputStream (und sicherlich auch noch andere Klassen), die die Methode readInt() anbieten. Was muß ich hier erwarten? Kriege ich dann auch mit Sicherheit immer denselben Wert (also 0x52494646) oder kann das auf anderen Plattformen anders ausgehen?

3) Gibt es andere Situationen, wo man etwas beachten muß? Gerade wenn man Dateien auslesen und dann z.B. ein paar Byte korrekt als Integer interpretieren will? Kann man da immer ganz intuitiv vorgehen, weil ja Dateien eine feste Struktur haben, die sich ja nicht einfach so ändert? Oder kann das auch mal schiefgehen, wenn ja, wann und warum?

EDIT: Beispiel zu Frage 3: Ich lese nun 4 Byte aus einer Datei, und will diese als Integer interpretieren. Dann muß ich von den 4 Byte das letzte um 24 Bit nach links shiften. Das müßte ich ja aber auf einem anderen System u.U. genau umgekehrt machen, und über ByteOrder.nativeOrder() kann ich ja rausfinden, welche ByteOrder das System nutzt und dann entsprechend reagieren. Ist auch das korrekt gedacht? Ich kann's leider nicht auf unterschiedlichen Architekturen testen.

Hier ein Beispiel, so hab ich's derzeit in meinem Code drin. Fraglich ist jetzt, ob das überhaupt nötig ist (die bool "bigEndian" ist bei mir false):

boolean bigEndian = (ByteOrder.nativeOrder() == ByteOrder.BIG_ENDIAN);

// ---

if (bigEndian)
    return  (bytes[0] << 24 & 0xFFFFFFFF) +
            (bytes[1] << 16 & 0x00FFFFFF) +
            (bytes[2] <<  8 & 0x0000FFFF) +
            (bytes[3]       & 0x000000FF);
else
    return  (bytes[3] << 24 & 0xFFFFFFFF) +
            (bytes[2] << 16 & 0x00FFFFFF) +
            (bytes[1] <<  8 & 0x0000FFFF) +
            (bytes[0]       & 0x000000FF);

 

[Rock Lobster]

Niemand hier, der hierfür ein paar Antworten parat hätte?

 

[byte]

Vielleicht hilft Dir das hier weiter: http://mindprod.com/jgloss/endian.html

Most people new to Java coming from C think that they need to code differently depending on whether the machine they are using internally represents integers as big or little endian. In Java it does not matter. Further, without resorting to native classes, there is no way you can even tell how they are stored. The JVM may store them either way internally but Java is cleverly constructed so that it never matters. Java has no struct I/O and no unions or any of the other endian-sensitive language constructs.

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