Scanner für große Textdatei

[techdevil]

Hi,

hier ein simpler Code zum zählen der Zeilen in einer Textdatei.

	public static int getNumLines(String inputPath) throws IOException{
		
		int res = 0;
		String test = null;
		
		Scanner input = new Scanner(new File(inputPath));
		
		while(input.hasNextLine()){ //input.hasNext() liefert das gleiche Problem
			
			input.nextLine();

			res++;
		} 
		
		input.close();
		return res;		
	}

Funktioniert gut bei bei vielen, auch beliebig großen Files - aber u.a. nicht bei folgender Wortliste.
105MB große Wortliste. Pass: 4gulli Die Liste hat pro Zeile ein Wort.

Die While-Schleife stoppt zu früh. Die letzten gelesenen Zeilen sind:

...
abbuiati
abbuiato
abbuiava
abbuiavano
abbuino
abb

Wobei das letzte Wort eigentlich laut normalem Texteditor "abbuio" heißen sollte. Die Methode liest aber nach dem zweiten "b" anscheinend ein Carriage Return und danach liefert hasNextLine() false. Die Ausgabe 648034 passt aber trotzdem nicht. Laut Texteditor befindet sich "abbuino" in Zeile 648104.

Hat das mit fehlerhaften Zeilenumbruch-Zeichen oder vielleicht mit der eingestellen Codierung zu tun?
Der Texteditor (Linux Gedit) lässt an der Stelle nichts vermuten.

Gruß

 

[kaetzacoatl]

Lass dir doch mal die Zeichen der letzten Zeilen ausgeben.
(Als bytes!)

 

[Ark]

Laut vim befindet sich in Zeile 648104 der Eintrag "abbyland^M" (das ^M deutet auf einen Windows-Zeilenumbruch hin, gehört also nicht wirklich zur Zeile). In Zeile 648034 steht bei mir "abbuio^M".

Ich weiß gerade nicht, ob es was mit dem Problem zu tun hat, aber anscheinend wechselt ab und zu mal die Kodierung. So steht z.B. das Wort "abbrände" doppelt drin: einmal mit ä in UTF-8-Kodierung und einmal mit ä in einer Kodierung, die ich noch nicht identifizieren konnte (im Folgenden Ausschnitt von vim als <84> wiedergegeben):

   647917 abbrv^M
   647918 abbr<84>nde^M
   647919 abbr<94>ckeln^M
   647920 abbr<94>ckelnd^M
   647921 abbr<94>ckelnde^M
   647922 abbr<94>ckelnden^M
   647923 abbr<94>ckelnder^M
   647924 abbr<94>ckelndes^M
   647925 abbrände^M
   647926 abbröckele^M
   647927 abbröckeln^M
   647928 abbröckelnd^M
   647929 abbröckelnde^M
   647930 abbröckelndem^M
   647931 abbröckelnden^M
   647932 abbröckelnder^M
   647933 abbröckelndes^M
   647934 abbröckelst^M
   647935 abbröckelt^M
   647936 abbröckelte^M
   647937 abbröckelten^M
   647938 abbröckeltest^M
   647939 abbröckeltet^M
   647940 abbröckle^M
   647941 abbrühen^M
   647942 abbs^M

Möglicherweise steht da also irgendwo eine Zeile, bei der die Zeichen so kodiert sind, dass dann (wegen der Kodierung) fälschlicherweise ein Zeilenumbruch erkannt wird, wo keiner sein sollte.

Ark

 

[techdevil]

Mit welchen Parametern hast du Vim gestartet?
Ohne jegliche Config-Parameter liefert Vim mir von deiner Ausgabe abweichende Zeilennummerierungen und keine "^M"

Das Wort "abbuio", wo die Java-Methode oben hakt, beinhaltet laut Vim aber kein Zeilenumbruchzeichen.
Vim zeigt das ganz normal an.

@kaetzacoatl: Kannst du mir vielleicht nen Tip geben, wie ich das am besten mache? BufferedReader und Scanner liefern ja nur Strings zurück. Und bei einem Inputstream wirds sicher schwer die passende Zeile zu finden, oder?

 

[Ark]

Ehrlich gesagt: Ich kenne mich da gerade auch nicht so gut aus. 😀 Aber vielleicht helfen folgende Ausgaben:

22:42:35 ark@tiger:~$ cat .vimrc 
set number
set listchars=tab:\|\ ,trail:.,extends:>,precedes:<,nbsp:_
set list
syntax on
set shiftwidth=4
set tabstop=4
set autoindent
set nowrap
set scrolloff=8
set sidescrolloff=4
set showtabline=2
set foldcolumn=2
set showmode
set whichwrap=b,s,<,>
set wildmenu

22:42:57 ark@tiger:~$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
22:43:00 ark@tiger:~$

Ark

 

[Pentalon]

Hi Devil

An der Datei liegt das eher nicht.
Ich habe das ganze zuerst mit Deiner Datei getestet, danach habe ich aus dieser die ersten ca. 30 zeilen rausgelöscht und dann passiert der selbe Fehler etwas weiter unten.
Ich vermute, dass es hier intern zu einem Überlauf kommt.
Ich habe Dein Prorgramm etwas verändert:

import java.io.File;
import java.io.IOException;
import java.util.Scanner;

public class Test5 {

    public static int getNumLines(String inputPath) throws IOException{
        
        int res = 0;
        int bytes = 0;
        String test = null;
        
        Scanner input = new Scanner(new File(inputPath));
        
        while(input.hasNextLine()){ //input.hasNext() liefert das gleiche Problem
            
            test = input.next();
            bytes = bytes + test.length()+2;			 // Bytes aufaddieren inkl. CRNL
            System.out.println("Gelesener String->"+test+" Länge->"+test.length()+" Gesamt gelesen->"+bytes);
 
            res++;
        } 
        
        input.close();
		System.out.println("Anzahl der Bytes= "+bytes);
        return res;     
    }
    
    public static void main(String[] args) throws IOException {
		System.out.println("Anzahl der Zeilen= "+Test5.getNumLines("c:\\temp\\wordlist-final1.txt"));	
	}
}

Anstelle von nextLine habe ich dann einmal next() verwendet. Damit kommt man auch nicht weiter, jedoch erscheint dann bei mir eine Fehlermeldung:

[WR]Gelesener String->abburattate Länge->11 Gesamt gelesen->6520684
Gelesener String->abburattati Länge->11 Gesamt gelesen->6520697
Gelesener String->abburattato Länge->11 Gesamt gelesen->6520710
Gelesener String->abburattatore Länge->13 Gesamt gelesen->6520725
Exception in thread "main" java.util.NoSuchElementException
at java.util.Scanner.throwFor(Unknown Source)
at java.util.Scanner.next(Unknown Source)
at rumprobieren.Test5.getNumLines(Test5.java:19)
at rumprobieren.Test5.main(Test5.java:32)[/WR]

Wie gesagt, an der Datei liegt das aus meiner Sicht eher nicht, sonst würde der Fehler weiterhin an der Stelle auftreten, auch wenn ich die Datei etwas kürze. Ausserdem sagt diese Exception, dass der Scanner nicht mehr weiss, wo er zu lesen hat. Ich hab aber leider auch keine Erfahrung mit so riesigen Dateien.

PS: Sieht ja wie eine Wortliste für eine Brute Force Attacke aus 🙂

Pentalon

 

[Pentalon]

Hi Devil

Hier eine Variante die Dein Textfile bis zum Ende lesen kann:

	public static int getNumLines1(String inputPath) {
        int res = 0;
        int bytes = 0;
		String test;
        
		try {
			BufferedReader in = new BufferedReader(new FileReader(inputPath));

			while ((test = in.readLine()) != null) {
				
	            //bytes = bytes + test.length()+2;			 // Bytes aufaddieren inkl. CRNL
	            //System.out.println("Gelesener String->"+test+" Länge->"+test.length()+" Gesamt gelesen->"+bytes);
				res++;
			}
		} catch (IOException e) {
			e.printStackTrace();
		}
		
		return res;
	}

Ich habe den Ausdruck und das Addieren der Bytes auskommentiert, weil die Ausgabe das Programm sehr langsam macht und das Zählen schnell überläuft.
Ohne die Ausdrucke ist die Datei schnell bis zur letzen Zeile gelesen (dauer ca 2 Sekunden bei mir).

[TIPP]Anzahl der Zeilen= 9586053 <--- Das ist die letzte Zeile !!! [/TIPP]

Ich hoffe das hilft Dir.

Pentalon

 

[techdevil]

OK also an der größe der Datei allein kanns nicht liegen, habe gerade eine 1gb große 10^8 zeilige Textdatei erfolgreich und korrekt gescannt.

BufferedReader kommt erheblich weiter. Weiß der Geier warum. Aber ob das wirklich die korrekte Anzahl Zeilen ist?

Vim sagt was anderes: 9588099

Das sind immerhin 2046 Zeilen mehr.

 

[Pentalon]

Das ist die Korrekte Anzahl.
Ich habe die Datei mit Notepad++ angesehen und die letzte Zeilennummer stimmt mit dem Zähler des Programmes überein.

Pentalon

 

[Pentalon]

Ich hab mir jetzt mal eben VIM installiert.
Er zeigt die selbe Zeilenanzahl wie es auch Notepad++ und das Programm anzeigen (9586053).

Pentalon

 

[techdevil]

Danke für die Mühe! Dann wird das wohl korrekt sein.

Mein Vim unter Linux liegt falsch:

 

[Ark]

Mein vim spuckt die gleiche Zahl aus wie Notepad++ (laut Pentalon):

  9586043 ÿùóðêà^M
  9586044 ÿùóðíûé^M
  9586045 ÿùóðîì^M
  9586046 ÿùóðó^M
  9586047 ÿÿ^M
  9586048 ÿÿ3ÿ^M
  9586049 ÿÿ3ÿÿfÿÿ^M
  9586050 ÿÿìÿ^M
  9586051 ÿÿìÿÿÿ^M
  9586052 ÿÿÿ^M
  9586053 ÿÿÿÿÿ^M

Ark