Abmessungen von Textdatei



  • Ich habe eine Textdatei im Format

    000100101001
    101001001001
    100100110110
    110111010110
    110111011010
    

    Nur ist das ganze viel größer. Jetzt möchte ich herausfinden, WIE groß (also wie viele Zeichen in der ersten Zeile stehen, da alle Zeilen gleich lang sind, und wie viele Zeilen es gibt).

    Mein Ansatz:

    JFileChooser fchDatei = new JFileChooser();
            if (fchDatei.showOpenDialog(null) != JFileChooser.APPROVE_OPTION)
                System.exit(0);
    
            File filDatei = fchDatei.getSelectedFile();
            BufferedReader brdTempDatei = new BufferedReader(new FileReader(filDatei));
    
            int iHoehe = 0;  
            int iBreite = 0; 
    
            boolean bTemp = false;
            for (String strZeile; (strZeile = brdTempDatei.readLine()) != null;)
            {
                if (!bTemp)
                {
                    for (int i=0; i<strZeile.length(); i++)
                        iBreite++;
                    bTemp = true;
                } 
                iHoehe ++;
            }
    

    Die äußere for Schleife zählt die Zeilen, die innere die Zeichen in der ersten Zeile.
    Aber das is ja wohl so doof! Mein Problem ist, dass ich mich nicht mit dem BufferedReader auskenne. Hat der vielleicht eine Funktion, mit der man auf einzelne Zeilen zugreifen kann? Oder eine Funktion, die gleich die Zeilenzahl zurückgibt (.count() oder so)?



  • Vielleicht ginge auhc was wie

    int lenght = line.indexOf ( "\n" );
    


  • snOOfy schrieb:

    int iBreite = 0;  
            [...]          
            for (int i=0; i<strZeile.length(); i++)
                iBreite++;
    

    Wozu um alles in der Welt eine Schleife?

    Würde

    iBreite = strZeile.length();
    

    nicht ausreichen?



  • Ach ja^^
    lol, da hab ich sogar schon .length() als Abbruchbedingung benutzt o_O

    Aber ich habe immernoch das Problem mit der Anzahl der Zeilen.
    Kennt ihr da eine Lösung?



  • int lines = 0;
    while ( ( String str = brdTempFile.readLine ( ) ) != null ) {
       ++lines;
       //...
    }
    


  • naja gut, aber wenn man da die länge der ersten Zeile reinbaut, ist das auch nich kürzer als

    boolean bTemp = false;
            for (String strZeile; (strZeile = brdTempDatei.readLine()) != null;)
            {
                if (!bTemp)
                {
                    iBreite = strZeile.length();
                    bTemp = true;
                }
                iHoehe ++;
            }
    


  • sp00fy schrieb:

    Aber ich habe immernoch das Problem mit der Anzahl der Zeilen.
    Kennt ihr da eine Lösung?

    Naja ist trotzdem etwas eleganter. Und ich sagte nie, dass da was kürzer ist bzw kürzer ginge. 🙂



  • Man könnte höchstens noch die Datei komplett in einen Puffer laden (byte[]) und dann die Anzahl der Zeilenumbrüche ermitteln.

    Weiß jetzt nur nicht 1.) genau, wie man das in Java machen würde und 2.) ob es tatsächlich schneller/performanter wäre. Könnte mir es aber vorstellen.



  • btw, hat es einen tieferen sinn, dass du ++lines statt lines++ schreibst? weil es cooler aussieht? :p



  • Vermutlich ein C++ Auswanderer 🙂 In C++ ist die Präfix-Version der Increment-Operatoren üblicherweise schneller, weil sie keine Kopie des Operanden anlegen muß.



  • awas, einfach dateigroesse / zeilenlaenge...



  • Und wie ermittle ich die Datigröße? Woher weiß ich, wie viele Zeilen es gibt, wenn bei der Rechnung z.B. 1,23kb rauskommen?



  • zum ermitteln gibts bestimmt sowas wie streeam.legnth oder so
    schau halt mal in den docs

    bytezahl nach zeichenzahl haengt von der kodierung ab.
    also wahrscheinlich 1 zu 1.
    sollte es z.b. unicode (utf8) sein und irgendwelche komischen zeichen vorkommen, koennen die auch schonmal mehr byte brauchen.
    aber deine nullen und einsen da sind ziemlich wahrscheinlich 1 byte.



  • aewrwearewr schrieb:

    sollte es z.b. unicode (utf8) sein und irgendwelche komischen zeichen vorkommen, koennen die auch schonmal mehr byte brauchen.

    unicode ist aber nicht das selbe wie utf8....



  • nein, so war das nicht gemeint.
    ich meinte vielmehr:
    falls es unicode ist, und dieser in utf8 (oder auch utf16) gespeichert ist.

    zufrieden? __


Anmelden zum Antworten