fileinputstream-konzept

FileInputStream

Kurz: Ein Byte-Stream zum rohen, ungepufferten Lesen einer Datei — liest die Datei byteweise, unabhängig davon, ob der Inhalt Text, ein Bild oder ein beliebiges anderes Binärformat ist.

Genauer: Weil ein reiner Byte-Stream ohne Zwischenspeicher arbeitet, ist er bei vielen kleinen Lesezugriffen langsam — in der Praxis wird er deshalb meist mit einem gepufferten Wrapper kombiniert. Für reinen Text ist ein zeichenbasierter Reader (der die Zeichenkodierung korrekt berücksichtigt) meist die passendere Wahl als ein roher Byte-Stream.

Im Detail

Der Kern eines FileInputStream ist bewusst minimal: Er liefert genau eine Operation — das nächste Byte lesen (oder einen Block von Bytes auf einmal) — ohne jede Interpretation, was diese Bytes bedeuten. Ein Byte hat keinen “Zeichensatz”, kein “Format”, es ist einfach eine Zahl zwischen 0 und 255. Genau das macht diesen Stream universell einsetzbar für JEDE Art von Datei, egal ob Text, Bild, Audio oder ein proprietäres Binärformat.

try (FileInputStream fis = new FileInputStream("bild.png")) {
    int naechstesByte;
    while ((naechstesByte = fis.read()) != -1) {
        verarbeite(naechstesByte);
    }
}

Der Rückgabewert -1 beim Aufruf von read() signalisiert typischerweise das Ende der Datei (EOF) — ein klassisches Beispiel für einen Fehlercode als Rückgabewert, der aber hier gar keinen Fehler bedeutet, sondern einen normalen, erwarteten Zustand (Datei zu Ende).

Der Grund für die “ungepufferte” Charakterisierung: Jeder einzelne Aufruf von read() kann (je nach Implementierung) tatsächlich bis zum Betriebssystem durchreichen, um das nächste Byte physisch vom Datenträger zu holen. Bei Millionen einzelner Byte-Lesezugriffe summiert sich dieser Overhead massiv — deshalb wird ein FileInputStream in der Praxis fast immer in einen BufferedReader bzw. einen gepufferten Byte-Stream eingepackt, der intern größere Blöcke auf einmal liest und einzelne Anfragen daraus bedient.

Für reinen Textinhalt ist ein FileInputStream selten die richtige Wahl, weil er nicht weiß, wie Bytes in Zeichen umgewandelt werden sollen (welche Zeichenkodierung gilt) — ein “é” kann je nach Kodierung (UTF-8, Latin-1, …) aus einem oder mehreren Bytes bestehen. Ein zeichenbasierter Reader übernimmt diese Umwandlung automatisch korrekt, ein roher Byte-Stream würde die Bytes stattdessen unverändert und potenziell falsch interpretiert weitergeben.

Siehe auch: I/O Streams, BufferedReader, FileOutputStream