Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 19 Einführung in Dateien und Datenströme
Pfeil 19.1 Alte und neue Welt in java.io und java.nio
Pfeil 19.1.1 java.io-Paket mit File-Klasse
Pfeil 19.1.2 NIO.2 und das java.nio-Paket
Pfeil 19.1.3 java.io.File oder java.nio.*-Typen?
Pfeil 19.2 Dateisysteme und Pfade
Pfeil 19.2.1 FileSystem und Path
Pfeil 19.2.2 Die Utility-Klasse Files
Pfeil 19.3 Dateien mit wahlfreiem Zugriff
Pfeil 19.3.1 Ein RandomAccessFile zum Lesen und Schreiben öffnen
Pfeil 19.3.2 Aus dem RandomAccessFile lesen
Pfeil 19.3.3 Schreiben mit RandomAccessFile
Pfeil 19.3.4 Die Länge des RandomAccessFile
Pfeil 19.3.5 Hin und her in der Datei
Pfeil 19.4 Basisklassen für die Ein-/Ausgabe
Pfeil 19.4.1 Die vier abstrakten Basisklassen
Pfeil 19.4.2 Die abstrakte Basisklasse OutputStream
Pfeil 19.4.3 Die abstrakte Basisklasse InputStream
Pfeil 19.4.4 Die abstrakte Basisklasse Writer
Pfeil 19.4.5 Die Schnittstelle Appendable *
Pfeil 19.4.6 Die abstrakte Basisklasse Reader
Pfeil 19.4.7 Die Schnittstellen Closeable, AutoCloseable und Flushable
Pfeil 19.5 Lesen aus Dateien und Schreiben in Dateien
Pfeil 19.5.1 Byteorientierte Datenströme über Files beziehen
Pfeil 19.5.2 Zeichenorientierte Datenströme über Files beziehen
Pfeil 19.5.3 Die Funktion von OpenOption bei den Files.newXXX(…)-Methoden
Pfeil 19.5.4 Ressourcen aus dem Modulpfad und aus JAR-Dateien laden
Pfeil 19.6 Zum Weiterlesen
 

Zum Seitenanfang

19.3    Dateien mit wahlfreiem Zugriff Zur vorigen ÜberschriftZur nächsten Überschrift

Dateien können auf zwei unterschiedliche Arten gelesen und modifiziert werden: zum einen über einen Datenstrom, der Bytes wie in einem Medien-Stream verarbeitet, zum anderen über wahlfreien Zugriff (engl. random access). Während der Datenstrom eine strenge Sequenz erzwingt, ist dies beim wahlfreien Zugriff egal, da innerhalb der Datei beliebig hin und her gesprungen werden kann und ein Dateizeiger verwaltet wird, den wir setzen können. Da wir es mit Dateien zu tun haben, heißt das Ganze dann Random Access File, und die Klasse, die wahlfreien Zugriff anbietet, ist java.io.RandomAccessFile.

 

Zum Seitenanfang

19.3.1    Ein RandomAccessFile zum Lesen und Schreiben öffnen Zur vorigen ÜberschriftZur nächsten Überschrift

Die Klasse deklariert zwei Konstruktoren, die mit einem Dateinamen oder File-Objekt ein RandomAccessFile-Objekt anlegen. Im Konstruktor bestimmt der zweite Parameter eine Zeichenkette für den Zugriffsmodus; damit lässt sich eine Datei lesend oder schreibend öffnen (siehe Tabelle 19.1). Die Angabe vermeidet Fehler, da eine zum Lesen geöffnete Datei nicht versehentlich überschrieben werden kann.

Modus

Funktion

r

Die Datei wird zum Lesen geöffnet. Wenn sie nicht vorhanden ist, wird ein Fehler ausgelöst. Der Versuch, auf diese Datei schreibend zuzugreifen, wird mit einer Exception bestraft.

rw

Die Datei wird zum Lesen oder Schreiben geöffnet. Eine existierende Datei wird dabei geöffnet, und hinten können die Daten angehängt werden, ohne dass die Datei gelöscht wird. Existiert die Datei nicht, wird sie neu angelegt, und ihre Startgröße ist null. Soll die Datei gelöscht werden, so müssen wir dies ausdrücklich über delete() der File-Klasse selbst tun.

Tabelle 19.1    Zwei Modi für den Konstruktor von »RandomAccessFile«

Zusätzlich lässt sich bei rw noch ein s oder d anhängen; sie stehen für Möglichkeiten, beim Schreiben die Daten mit dem Dateisystem zu synchronisieren.

class java.io.RandomAccessFile

implements DataOutput, DataInput, Closeable
  • RandomAccessFile(String name, String mode) throws FileNotFoundException

  • RandomAccessFile(File file, String mode) throws FileNotFoundException

    Öffnen die Datei. Ob die Datei zum Lesen oder Schreiben vorbereitet ist, bestimmt der String mode mit gültigen Belegungen r oder rw. Ist der Modus falsch gesetzt, zeigt eine IllegalArgumentException dies an. Lösen eine FileNotFoundException aus, falls die Datei nicht geöffnet werden kann.

  • void close()

    Schließt eine geöffnete Datei wieder.

 

Zum Seitenanfang

19.3.2    Aus dem RandomAccessFile lesen Zur vorigen ÜberschriftZur nächsten Überschrift

Um Daten aus einer mit einem RandomAccessFile verwalteten Datei zu bekommen, nutzen wir eine der readXXX(…)-Methoden. Sie lesen direkt das Byte-Feld aus der Datei oder mehrere Bytes, die zu einem primitiven Datentyp zusammengesetzt sind. readChar() etwa liest hintereinander 2 Byte und verknüpft diese zu einem char.

class java.io.RandomAccessFile

implements DataOutput, DataInput, Closeable
  • int read() throws IOException

    Liest genau ein Byte und liefert es als int zurück.

  • int read(byte[] b) throws IOException

    Liest b.length() viele Bytes und speichert sie im Feld b.

  • int read(byte[] b, int off, int len) throws IOException

    Liest len Bytes aus der Datei und schreibt sie in das Array b ab der Position off im Array. Die gelesene Größe wird immer zurückgegeben, auch wenn weniger als len Bytes gelesen wurden.

  • final boolean readBoolean() throws IOException

  • final byte readByte() throws IOException

  • final short readShort() throws IOException

  • final int readInt() throws IOException

  • final long readLong() throws IOException

  • final char readChar() throws IOException

  • final double readDouble() throws IOException

  • final float readFloat() throws IOException

    Lesen einen primitiven Datentyp.

  • final int readUnsignedByte() throws IOException

    Liest ein als vorzeichenlos interpretiertes Byte.

  • final int readUnsignedShort() throws IOException

    Liest zwei als vorzeichenlos interpretierte Bytes.

  • final void readFully(byte[] b) throws IOException

    Versucht, den gesamten Puffer b zu füllen.

  • final void readFully(byte[] b, int off, int len) throws IOException

    Liest len Bytes und speichert sie im Puffer b ab dem Index off.

Zum Schluss bleiben zwei Methoden, die eine Zeichenkette liefern:

  • final String readLine() throws IOException

    Liest eine Textzeile, die das Zeilenendezeichen \r oder \n bzw. eine Kombination \r\n abschließt. Die letzte Zeile muss nicht so abgeschlossen sein, denn ein Dateiende zählt als Zeilenende. readLine() interpretiert die Zeichen nicht als Unicode, sondern übernimmt die Zeichen einfach als ASCII-Bytes. (Ohne die Konvertierung verschiedener Codepages, etwa von einer Datei in einem ungewohnten IBM-Format, liest readLine() nicht die korrekten entsprechenden Unicode-Zeilen heraus. Diese Byte-in-Char-Umwandlung müsste manuell vorgenommen werden.) Auch weil RandomAccessFile nicht puffert, bietet sich aus Geschwindigkeitsgründen eine zeilenweise Verarbeitung von ASCII-Dateien über readLine() nicht an, und die passende Klasse Scanner oder BufferedReader sollte Verwendung finden.

  • final String readUTF()

    Liest einen modifizierten UTF-kodierten String und gibt einen Unicode-String zurück. Ein UTF-String fasst entweder 1, 2 oder 3 Byte zu einem Unicode-Zeichen zusammen. Der übernächste Abschnitt, »Die UTF-8-Kodierung«, erklärt die Kodierung genauer.

Rückgabe –1 und EOFException *

Die Methoden liefern nicht alle einen Fehler, wenn die Datei schon fertig abgearbeitet wurde und keine Daten mehr anliegen. Im Fall von int read(), int read(byte[]) oder int read(byte[], int, int) gibt es einfach den Rückgabewert –1 und keine Exception. Ähnliches gilt für readLine(). Die Methode liefert null am Dateiende. Für die anderen Lesemethoden gilt, dass sie eine bestimmte Anzahl Bytes erzwingen, etwa readLong() 8 Byte oder auch nur 1 Byte für readByte(), sodass im Fall eines Dateiendes eine EOFException folgt. Bis auf wenige Ausnahmen gibt es kaum weitere Einsatzgebiete von EOFException in der Java-Bibliothek.

Die UTF-8-Kodierung *

writeUTF(String) und readUTF() sind zwei Operationen, die die Schnittstellen DataOutput und DataInput vorschreiben. Neben RandomAccessFile implementiert DataOutputStream die Schnittstelle DataOutput und DataInputStream die Schnittstelle DataInput.

Java verwaltet Unicode-Zeichen über den Datentyp char, der (immer noch[ 265 ](Eine Anspielung, da Java seit Version 5 Unicode 4 mit 32-Bit-Zeichen unterstützt und wir für die Umsetzung erheblich tricksen müssen. )) 16 Bit lang ist. In unseren Breiten stammen die meisten Zeichen aus den herkömmlichen 8 Bit des Latin-1-Zeichensatzes. Würden die Zeichen als Unicode (also 2 Byte) versendet, bestände der 16-Bit-Datenstrom im Wesentlichen zur Hälfte aus Nullen. Aus diesem Grund gibt es eine alternative Kodierung, die jedes 16-Bit-Unicode-Zeichen platzsparend schreibt und in Abhängigkeit von der Belegung 1, 2 oder 3 Byte lang ist. Die Kodierung der Zeichen richtet sich nach der Belegung der Bits wie folgt:

  • '\u0001' bis '\u007F': Die Zeichen werden direkt mit einem Byte geschrieben. Texte in europäischen Sprachen, die zum Großteil in 7-Bit-ASCII verfasst sind, lassen sich somit kompakt schreiben.

  • '\u0080' bis '\u07FF': Die Zeichen werden mit 2 Byte kodiert.

  • '\u0800' bis '\uFFFF': Die Zeichen werden mit 3 Byte kodiert.

Die Kodierung, die Java wählt, ist an UTF-8 angelehnt und wird im Folgenden einfach UTF-8-Kodierung genannt.

[»]  Hinweis

Würden die Zeichenfolgen lediglich mit der vorgestellten Kodierung geschrieben, wüsste der Zeichenleser nicht, wann das Ende der Zeichenfolge erreicht ist. Daher beginnt writeUTF(String) mit einer Längenkennung. Zum Lesen von Zeilen ist readUTF() von Vorteil, denn readLine() führt keine korrekte Unicode-Konvertierung durch.

 

Zum Seitenanfang

19.3.3    Schreiben mit RandomAccessFile Zur vorigen ÜberschriftZur nächsten Überschrift

Da RandomAccessFile die Schnittstellen DataOutput und DataInput implementiert, werden zum einen die readXXX(…)-Methoden, wie bisher vorgestellt, implementiert und zum anderen eine Reihe von Schreibmethoden der Form writeXXX(…). Diese sind analog zu den Lesemethoden:

  • write(byte[] b)

  • write(int b)

  • write(byte[] b, int off, int len)

  • writeBoolean(boolean v)

  • writeByte(int v)

  • writeBytes(String s)

  • writeChar(int v)

  • writeChars(String s)

  • writeDouble(double v)

  • writeFloat(float v)

  • writeInt(int v)

  • writeLong(long v)

  • writeShort(int v)

  • writeUTF(String str)

Der Rückgabetyp ist void, und die Methoden können eine IOException auslösen.

 

Zum Seitenanfang

19.3.4    Die Länge des RandomAccessFile Zur vorigen ÜberschriftZur nächsten Überschrift

Mit zwei Methoden greifen wir auf die Länge der Datei zu: einmal schreibend (verändernd) und einmal lesend.

class java.io.RandomAccessFile

implements DataOutput, DataInput, Closeable
  • void setLength(long newLength) throws IOException

    Setzt die Größe der Datei auf newLength. Ist die Datei kleiner als newLength, wird sie mit unbestimmten Daten vergrößert; wenn die Datei größer war als die zu setzende Länge, wird die Datei abgeschnitten. Dies bedeutet, dass der Dateiinhalt mit setLength(0) leicht zu löschen ist.

  • long length() throws IOException

    Liefert die Länge der Datei. Schreibzugriffe erhöhen den Wert, und setLength() modifiziert ebenfalls die Länge.

 

Zum Seitenanfang

19.3.5    Hin und her in der Datei Zur vorigen ÜberschriftZur nächsten Überschrift

Die bisherigen Lesemethoden setzen den Datenzeiger automatisch eine Position weiter. Wir können den Datenzeiger jedoch auch manuell an eine selbst gewählte Stelle setzen und damit durch die Datei navigieren.

[zB]  Beispiel

Erzeuge eine Datei, und setze an die Stelle 1.000 das Byte 0xFF:

Listing 19.5    src/main/java/com/tutego/insel/io/CreateBigFile.java, main()

try ( RandomAccessFile file = new RandomAccessFile("c:/test.bin", "rw" ) ) {

file.seek( 999 );

file.write( 0xFF );

}

Da skipBytes(int) den Dateizeiger nicht »hinter« die Datei stellen kann, funktioniert die Lösung nur mit seek(long).

Die nachfolgenden Lese- oder Schreibzugriffe setzen dann dort an. Die im Folgenden beschriebenen Methoden haben etwas mit diesem Dateizeiger und seiner Position zu tun:

class java.io.RandomAccessFile

implements DataOutput, DataInput, Closeable
  • long getFilePointer() throws IOException

    Liefert die momentane Position des Dateizeigers. Das erste Byte steht an der Stelle null.

  • void seek(long pos) throws IOException

    Setzt die Position des Dateizeigers auf pos. Diese Angabe ist absolut und kann daher nicht negativ sein. Falls doch, wird eine Ausnahme ausgelöst. file.seek(file.length()); setzt den Zeiger auf das Ende der Datei.

  • int skipBytes(int n) throws IOException

    Im Gegensatz zu seek() positioniert skipBytes() relativ. n ist die Anzahl, um die der Dateizeiger bewegt wird. Ist n negativ, werden keine Bytes übersprungen. Eine relative Positionierung mit positivem und negativem n für ein RandomAccessFile raf erreicht raf.seek(raf.getFilePointer() + n). Die Summe darf aber nicht negativ sein, sonst gibt es von seek() eine IOException. Die Rückgabe gibt die tatsächlich gesprungenen Bytes zurück, was nicht mit n identisch sein muss! Es ist schon interessant, dass seek(long) mit long parametrisiert wird, skipBytes(int) aber nur mit int.

Setzt seek(long) den Zeiger weiter, als es möglich ist, wird die Datei dadurch nicht automatisch größer. Sie verändert jedoch ihre Größe, wenn Daten geschrieben werden.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.

Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de



Cookie-Einstellungen ändern