# Dateiende erkennen, wie?



## HannsW (9. Feb 2009)

Moin,
ich muss eine SEEEEHr große Datei, deren Struktur ich nicht kenne ( Zahlen und Texte wechseln einander ab )
einlesen, und in mehrere kleinere Dateien zerlegen, um an die Text-teile zu gelangen. Zum Lesen nutze ich dies:

```
try {
        br = new BufferedReader(new FileReader(inFileName));

    } catch (FileNotFoundException e) {
        System.out.println("DateiFehler : " + inFileName);
        System.exit(-1);
}

/****
----
***//
         try {
                str = br.readLine();
                if (str == null)
                    running = false;
            } catch (IOException ioe) {
                System.out.println("Abbruch wegen DateiLeseFehler : " + inFileName);
                System.exit(-2);
            }
```

Beim testen habe ich festgestellt, daß str== null "mittendrin" vorkommt, danach  weitere Nutzdaten.

Gibt es eine Möglchkeit, das Dateiende festzustellen?
TIA Hanns


----------



## Wildcard (9. Feb 2009)

http://java.sun.com/javase/6/docs/api/java/io/BufferedReader.html


> Returns:
> A String containing the contents of the line, not including any line-termination characters, *or null if the end of the stream has been reached*


Das gibt nur dann null, wenn der Stream auch wirklich zu ende ist, oder du irgendetwas einliest, was nicht kompatibel zum Reader ist (Teile der Datei sind binär, falsches Encoding,...).


----------



## HannsW (9. Feb 2009)

Wildcard hat gesagt.:
			
		

> http://java.sun.com/javase/6/docs/api/java/io/BufferedReader.html
> 
> 
> > Returns:
> ...



Ich denke schon,daß Teile davon binär sind.
Wenn ich OHNE den Test auf Null arbeite, läuft das Einlesen länger als mit.

Das konkrete Problem. Ich muss ne repository-Datei von visualAge fpr Java einlesen, und daraus die gespeicherten Textanteile extrahieren.
Das dacht ich halt mit nem bufferedreader zu machen.

Wenn ich nen inputstream nähme. Wie reagiert dieser denn an der Stelle, an der ich jetzt nen null-String erhalte?

Wirbel!


----------



## Wildcard (9. Feb 2009)

Wenn du einen InputStream nimmst, bekommst du kein null. Ein Reader lässt sich nunmal nur auf textuelle Inhalte Anwenden.


----------



## Spacerat (10. Feb 2009)

Man kann doch einen InputStream mit einem Reader schachteln (mit InputStreamReader). Wenn man sich von dem InputStream und dem Reader jeweils eine Instanz behält, kann man vom Reader solange Strings (auch null-Strings) lesen, bis der InputStream eine EOFException wirft, die man eigentlich nur abfangen braucht. Allerdings können so auch Strings gelesen werden, die zufällig irgend einen unleserlichen Kram (eben Binärdaten) enthalten.

mfg Spacerat


----------



## padde479 (10. Feb 2009)

Wie wär's mit der Klasse StreamTokenizer?


----------



## HannsW (10. Feb 2009)

padde479 hat gesagt.:
			
		

> Wie wär's mit der Klasse StreamTokenizer?



Welchen Vorteil brächte ein Streamtokenizer? Ich sehe nicht, wie ich diesen anwenden sollte.

Das Problem mit meiner Datei ist ja, daß ich beim Verwenden eines BufferedReaders das Ergebnis gegen null teste ( == dateiende) ich irgenwie in der Mitte der Datei einen String == null erhalte.

Wenn ich es mit nem InputStram mache, und 
	
	
	
	





```
while ((in = fin.read()) != -1)
```
 laufen lasse. dauert es eeewwig. aber ich bekomme alles gelesen.

Mein nächster Test wird sein:
- über FILE die Dateigröße bestimmen
- Mit bufferedReader Strings einlesen.
- deren Länge summieren,
- und bei Dateigö0e beenden.


Dies zumindest, solange ich nicht weiß, wie die "nichtText"-Daten aufgebaut sind


----------



## Ark (10. Feb 2009)

HannsW hat gesagt.:
			
		

> Wenn ich es mit nem InputStram mache, und
> 
> 
> 
> ...


1. Reader != InputStream, das sind also zwei völlig verschiedene Dinge.
2. Du hattest einen BufferedReader verwendet, deswegen ging das Einlesen auch vergleichsweise schnell. Wenn du Binärdaten ebensoschnell einlesen können willst, musst du einen BufferedInputStream benutzen.

Ark


----------

