PrintWriter.println() schreibt mehrere Zeilen

[szmast3r]

Hallo,

ich habe leider das Glück, Textdateien verarbeiten zu müssen, wo eine Zeile über 10.000 Zeichen hat. Der Benutzer soll anschließend die Möglichkeit haben, von Ihm ausgewählte Zeilen zu kopieren. Daraus soll eine neue Textdatei (temporär) erstellt werden. Nun das Problem: Ich benutze zum Schreiben einer einzelnen Zeile PrintWriter.println() (für mich eigentlich recht logisch). Öffne ich aber die Textdatei, macht er aus dieser einen Zeile mehrere. Kopiere ich die Zeile von Hand mittels standard Windows Texteditor, macht er daraus ebenfalls mehrere!! Anders siehts beim WordPad oder Notepad++ aus. Benutzt PrintWriter den Texteditor?? Programmintern bleibt es immer eine einzige Zeile. Erst nach dem wegspeichern, sind in der Datei mehrere Zeilen. Nach dem Auslesen dieser Datei, sind programmintern (logischerweise) auch mehrere Zeilen.

Mir fällt einfach keine Lösung ein.. Das einzige Problem was mir einfallen würde wäre, dass PrintWriter mit dem Windows Texteditor arbeitet, aber kann das wirklich der Fall sein?

MfG

szmast3r

 

[Joose]

Kann es sein das dein String ein "\n" enthält? Diese würde auch bei "println()" zu einem Zeilenumbruch führen.
Sprich auch wenn du nur eine Zeile schreibst per Writer, je nachdem wieviele "\n" drinnen sind können es mehrere Zeilen in der Datei sein.

 

[szmast3r]

Leider ist es nicht so einfach, hab auch kein \n drin :/ Außerdem würde das \n keine Auswirkungen haben, wenn ich es händisch einfüge.

Hab festgestellt, dass jede Zeile in der Textdatei 1024 Stellen hat. 1024 ist sicher kein Zufall... Ich möchte aber sehr stark annehmen, dass ich schon mehrmals Textdateien in der Hand hatte, die mehr als 1024 Stellen in einer Zeile hatten... Außerdem sind sie auf dem Server auch in einer Zeile hinterlegt.
Programmintern bleibt es auch eine Zeile... nur in der Textdatei leider nicht.

MfG

 

[VfL_Freak]

Moin,

Poste doch mal den relevanten Code ..... Quiz machen wir erst NACH Feierabend :noe:

Gruß Klaus

 

[szmast3r]

Werde ich morgen schicken, liegt derzeit auf Arbeit :/

MfG

 

[szmast3r]

Also ich nehme stark an, dass er einfach nicht die gesamte Zeile in einer Zeile wegspeichern kann, weil diese schlichtweg zu Groß ist (2299 Zeichen). Er schneidet ab 2027 ab und beginnt eine neue Zeile.

Hier mal der wegschreibe Code:

[Java] public boolean generateFile(ArrayList<String> rows, String name) throws IOException {
File datei = new File(name + ".txt");
FileWriter fw = new FileWriter(datei);
BufferedWriter bw = new BufferedWriter(fw);
PrintWriter pw = new PrintWriter(bw);
for(int i = 0;i<rows.size();i++){
System.out.println("###Ausgabe" + rows.get(i));
if(i != rows.size()-1){
pw.println(rows.get(i));
}else{
pw.print(rows.get(i));
}
}
pw.flush();
pw.close();
pw = null;
if(datei.exists()){
System.out.println("Datei erstellt");
return true;
}
else{
System.out.println("Datei NICHT erstellt");
return false;
}
}[/Java]

Er schreibt tatsächlich auch nur diese eine Zeile rein (dafür spricht die Ausgabe). In der Textdatei landen aber mehrere, da diese anscheinend zu lang ist.

MfG

 

[VfL_Freak]

Moin,

[Java] public boolean generateFile(ArrayList<String> rows, String name) throws IOException {
File datei = new File(name + ".txt");
// FileWriter fw = new FileWriter(datei);
// BufferedWriter bw = new BufferedWriter(fw);
PrintWriter pw = new PrintWriter( new File(name + ".txt") ); // reicht das nicht auch ??
for(int i = 0;i<rows.size();i++){
System.out.println("###Ausgabe" + rows.get(i));
if(i != rows.size()-1){
pw.println(rows.get(i));
}else{
pw.print(rows.get(i));
}
}
pw.flush();
pw.close();
pw = null;
if(datei.exists()){
System.out.println("Datei erstellt");
return true;
}
else{
System.out.println("Datei NICHT erstellt");
return false;
}
}[/Java]
Er schreibt tatsächlich auch nur diese eine Zeile rein (dafür spricht die Ausgabe). In der Textdatei landen aber mehrere, da diese anscheinend zu lang ist.

So auf Anhieb sehe ich da nichts wirklich Falsches (mal vom Kommentar oben abgesehen) !

Wie sieht denn der Inhalt der ArrayList konkret aus?
Sind da eventuell schon Zeilenumbrüche drin?
Und wie schaut die konkrete Ausgabe und die Ausgabedatei aus ?

Gruß Klaus

 

[CSHW89]

Öffne ich aber die Textdatei, macht er aus dieser einen Zeile mehrere. Kopiere ich die Zeile von Hand mittels standard Windows Texteditor, macht er daraus ebenfalls mehrere!! Anders siehts beim WordPad oder Notepad++ aus.

Mal ne ganz blöde Frage, da du sagst, dass es im WordPad oder Notepad++ anders aussieht. Ist im Windows Texteditor vielleicht einfach der WordWrap aktiviert?

 

[VfL_Freak]

Moin,

so, habe mir den Eingangspost nochmals durchgelesen, was bei mir immer mehr Fragen aufwirft :joke:

ich habe leider das Glück, Textdateien verarbeiten zu müssen, wo eine Zeile über 10.000 Zeichen hat. Der Benutzer soll anschließend die Möglichkeit haben, von Ihm ausgewählte Zeilen zu kopieren.

Wenn es wirklich EINE Zeile ist, wie sollen dann mehrere ausgewählt werden ???:L

Öffne ich aber die Textdatei, macht er aus dieser einen Zeile mehrere ...

Leider fehlt hierzu jeglicher Code !
Mit "Öffnen" meinst du jetzt "file.Open()" ???:L
Wer ist hier "er" und was bedeutet "er macht mehrere Zeilen ???:L

Kopiere ich die Zeile von Hand mittels standard Windows Texteditor, macht er daraus ebenfalls mehrere!! Anders siehts beim WordPad oder Notepad++ aus. Benutzt PrintWriter den Texteditor??

Wiederum die Frage: Wer ist hier "er" ???:L
Und was hat das händische Kopieren mit Deinem Code zu tun ???:L

Irgendwie finde das Ganze immer unklarer ... ;(

Gruß Klaus

 

[szmast3r]

Bin froh dass endlich Fragen kommen, da sonst immer welche offen sind

Also zu 1. Der Benutzer kann MEHRERE Zeilen Auswählen. Die jeweils in eine Textdatei gespeichert werden.
Beispiel: Er wählt Zeile 1 und Zeile 2 -> Das Tool durchläuft eine Schleife in der er ERST Zeile 1 als EINE Zeile abspeichert, darunter die nächste Zeile. (pw.println(bla)). 1 Kopierte Zeile soll also eine Zeile in der Textdatei entsprechen. Derzeit geht EINE kopierte Zeile nach dem Wegspeichern in der Textdatei über MEHRERE Zeilen.

2. Mit öffnen meine ich die Textdatei auf dem Rechner per Doppelklick öffnen (nicht programmtechnisch) Er ist bei mir leider immer mein Tool Tut mir leid

3. Ich glaube, dass es garnicht an meinem Code liegt, da es intern Funktioniert (Beim händischen kopieren -> selber Fehler)... erst nach dem Wegspeichern und erneuten Einlesen geht alles kaputt... Ich hoffe nur, dass ihr vielleicht eine Lösung kennt

MfG

 

[VfL_Freak]

Moin,

Bin froh dass endlich Fragen kommen, da sonst immer welche offen sind

Bite, gerne ... hier sind noch mehr :lol:

Also zu 1. Der Benutzer kann MEHRERE Zeilen Auswählen. Die jeweils in eine Textdatei gespeichert werden.
Beispiel: Er wählt Zeile 1 und Zeile 2 -> Das Tool durchläuft eine Schleife in der er ERST Zeile 1 als EINE Zeile abspeichert, darunter die nächste Zeile. (pw.println(bla)).
Eine Kopierte Zeile soll also eine Zeile in der Textdatei entsprechen. Derzeit geht EINE kopierte Zeile nach dem Wegspeichern in der Textdatei über MEHRERE Zeilen.

Wo werden die Zeilen ausgewählt? In Deinem Tool?
Wie liegen die Daten dort vor? TextArea oder etwas ähnliches?

2. Mit öffnen meine ich die Textdatei auf dem Rechner per Doppelklick öffnen (nicht programmtechnisch) Er ist bei mir leider immer mein Tool Tut mir leid

Und dann geht Dein Tool auf oder doch irgendein Standardeditor (wenn ja, welcher?) ?

3. Ich glaube, dass es garnicht an meinem Code liegt, da es intern Funktioniert (Beim händischen kopieren -> selber Fehler)...

Was bedeutet 'intern' ? :bahnhof:

erst nach dem Wegspeichern und erneuten Einlesen geht alles kaputt...

Da stellt sich dann auch die Frage, ob es am Speichern oder doch am Einlesen liegt ...

Poste hier doch mal eine Textdatei, so wie sie nach den Speichern ausschaut !!

Gruß Klaus

 

[szmast3r]

Frag ruhig. ich kann leider keine Fragen stellen, ohne offene Fragen zu hinterlassen Vielleicht kommt das noch

zu 1. Die Zeilen werden in einer JTable ausgewählt und liegen als String vor

2. Ich öffne eine .txt, es öffnet sich also der Standart Windows XP Editor (Behörden sind da etwas veraltet)

3. Mit intern meine ich innerhalb des Tools bzw. Quellcodes. Also wenn ich zb. sage intern ist es eine zeile meine ich den String, den ich mir per "system.out" ausgeben lasse.

4. Es liegt am speichern, da ich ja nach dem Speichern die Textdatei händisch (Windows editor) öffnen kann und sehe es ist falsch. Er führt dennoch nur ein mal pw.println(bla) aus. Deswegen vermute ich, dass es nicht am Code liegt

Die Textdatei werde ich morgen mal schicken, da ich leider wieder Feierabend habe und darauf keinen Zugriff habe, außer auf Arbeit.

Danke, dass du dich durch die schwierige Fragestellung hangelst und genug Ausdauer hast

MfG

 

[VfL_Freak]

4. Es liegt am speichern, da ich ja nach dem Speichern die Textdatei händisch (Windows editor) öffnen kann und sehe es ist falsch. Er führt dennoch nur ein mal pw.println(bla) aus. Deswegen vermute ich, dass es nicht am Code liegt

Nun ja, ich habe hier kein XP mehr und kann somit auch nicht prüfen, ob sich durch das Öffnen des WinEditors ggf. Zeilenumbrüche einschleichen, würde mich allerdings auch wundern!
Auf der anderen Seite ist es beim einen "println" nun mal IMMER ein Zeilentrenner geschrieben wird!
Ob nur nur 0xa oder 0xd oder doch beide hängt beispielweise auch von jeweiligen OS ab!

Und prinzipiell kann auch in den Tableeinträgen schon ein ZU vorhanden sein. Grundlegend ausschließen kannst Du erstmal goar nix!!

Sonst häng' Dich doch mal mit 'nem Debugger an diese Stelle und schau, was konkret in "rows(i)" steht

System.out.println("###Ausgabe" + rows.get(i));
if(i < rows.size() ) // reicht als prüfung übrigens völlig aus !!
{
    pw.println(rows.get(i));
}else{
pw.print(rows.get(i));
}

Danke, dass du dich durch die schwierige Fragestellung hangelst und genug Ausdauer hast

Habe zu Glück ab Karfreitag Urlaub :bae: :lol:

Gruß Klaus

 

[szmast3r]

Ich hoffe wir sind bis Karfreitag durch mit dem Thema

Ich kann es ausschließen, weil:
1. in rows(i) befindet sich IMMER nur jeweils eine Zeile (die auch korrekt ist)
2. Der Zeilenumbruch kommt auch, wenn ich die Ausgabe von rows(i) in der Konsole kopiere und in einer Textdatei auf dem Desktop händisch einfüge.

Println() ist schon richtig, weil er jeden Eintrag in rows(i) (EINE Datensatzzeile) in eine Zeile packen soll. Der Zeilenumbruch liegt ja an 2037, Stelle. Egal welche Zeile, wielang, was drinn steht oder sonst was. Ab 2037 Stellen geht er in die nächste Zeile.

Kann es sein dass ASCII da irgendeine Begrenzung hat oder sonst was? Ich habe die leise Vermutung es hat mit dem Format etwas zutun...

MfG

 

[VfL_Freak]

Moin,

Ich kann es ausschließen, weil:
1. in rows(i) befindet sich IMMER nur jeweils eine Zeile (die auch korrekt ist)

Schön ... nur wie sehen diese Einträge konkret aus??
Enthalten sie am Ende sowas wie 0xa oder 0xd oder beides??
Dan kann Dir - wie ich bereits schrieb - nur der Debugger an der Stelle sagen!!

2. Der Zeilenumbruch kommt auch, wenn ich die Ausgabe von rows(i) in der Konsole kopiere und in einer Textdatei auf dem Desktop händisch einfüge.

Mit 'Ausgabe' meist Du jetzt dies hier: "System.out.println("###Ausgabe" + rows.get(i));" ??
Und 'Kopieren' bedeutet konkret per Zwischenablage ??

Println() ist schon richtig, weil er jeden Eintrag in rows(i) (EINE Datensatzzeile) in eine Zeile packen soll. Der Zeilenumbruch liegt ja an 2037, Stelle. Egal welche Zeile, wielang, was drinn steht oder sonst was. Ab 2037 Stellen geht er in die nächste Zeile.

Wirklich beim Speichern?

Kann es sein dass ASCII da irgendeine Begrenzung hat oder sonst was? Ich habe die leise Vermutung es hat mit dem Format etwas zutun...

ASCII nun mal bestimmt nicht, da dies nur eine ZEICHEN-Kodierung ist ... sich also immer nur auf genau EIN Zeichen bezieht!
American Standard Code for Information Interchange – Wikipedia

Wenn dann eher durch die Darstellung beim Öffnen mit einem Editor!
Ist es jedesmal NotePad ??

Gruß Klaus

 

[szmast3r]

Die Ausgaben kann bzw. darf ich hier leider nicht Posten, aber es genügt zu wissen, dass ab der 2027. (nicht 2037.) Stelle ein Zeilenumbruch eingefügt wird

2. Genau so war es gemeint

3. Kann mir nichts anderes erklären, da es vor dem Speichern noch eine Zeile ist, nach erneutem Einlesen erst mehrere Zeilen (meist 2).


Das könnte doch an ASCII liegen.... Wir haben ein Tool um solche Textdateien zu verarbeiten (gerade gefunden). Dort steht ein Hinweis, dass bei Textdateien solcher Art ASCII_Long verwendet werden soll. Ich habe noch nie ASCII_Long gehört... kann man den Schuster irgendwo einstellen? :/

MfG

 

[VfL_Freak]

Moin,

Die Ausgaben kann bzw. darf ich hier leider nicht Posten, aber es genügt zu wissen, dass ab der 2027. (nicht 2037.) Stelle ein Zeilenumbruch eingefügt wird

Nein, das genügt nicht zur Fehlersuche !
Kannst Du nicht irgendwelche Pseudo-/Testdaten erzeugen, die Du hier posten könntest ???:L

Ok, ohne die konkreten Daten bleibt hier nur noch(mal) der Hinweis auf den Debugger!!

System.out.println("###Ausgabe" + rows.get(i));
if(i < rows.size() ) // reicht als prüfung übrigens völlig aus !!
{
pw.println(rows.get(i));
}else{
pw.print(rows.get(i));
}

Setze hier einen Breakpoint und schau, wie dann der String "rows.get(i)" konkret ausschaut .....

Das könnte doch an ASCII liegen....

Nein, kann es nicht !!
Wie ich bereits schrieb, geht es in der ASCII-Tabelle jeweils nur um genau EIN Zeichen !!
Ob zahl, Buchstabe, Sonderzeichen oder die Zeilenumbruch-Zeichen (CR und LF) ist völlig egal !!

Wir haben ein Tool um solche Textdateien zu verarbeiten (gerade gefunden). Dort steht ein Hinweis, dass bei Textdateien solcher Art ASCII_Long verwendet werden soll. Ich habe noch nie ASCII_Long gehört... kann man den Schuster irgendwo einstellen? :/

Was für ein Tool ???:L
Was bedeutet denn bitte "solche Textdateien" ???:L
Es ist doch nur ganz normaler ASCCI-Text .....
Hast Du Dir die Textdatei mal in einem Hex-Editor angeschaut ???:L (PSPad wäre bspw. sowas)

ASCII_Long kenne ich auch nicht, vermute aber, das extend ASCCI gemeint ist!

Die 'normale' ASCCI-Tabelle beschreibt alle 7-bit-Zeichen, also von 0 - 127 (oder hex: 0x0 - 0x7f).
Extended ASCCI sind dann 8-bit-Zeichen von 128 - 255 (also 0x80 - 0xff)

Die Länge eines Textes hat damit nun aber auch rein gar nichts zu tun ..... :noe:

Ich klinke mich hier jetzt mal aus, da ohne weitere Details nur rumgeraten werden kann !
Gruß Klaus

 

[szmast3r]

Sorry musste mir das Debuggen erstmal ansehen. Bin aber darauf gestoßen, dass der PrintWriter einen writeBufferSize von 1024 hat. Kann man diesen vielleicht irgendwie hochschrauben?

Die Ausgabe beim Debuggen ist die Selbe, wie die bei System.out.println("###Ausgabe" + rows.get(i)); genau die Zeile die er schreiben soll, also alles richtig....

MfG
Jede X-beliebige Textdatei mit mehr als 2030 Stellen ist zum Testen geeignet...

Das Tool dient dazu, Textdateien auf einem BS2000-Großrechner hochzuladen (was mein Tool auch erledigt). Dort steht ausdrücklich der Hinweis, dass bei Textdateien solcher Art (Internes Testverfahren, bedeutet dass der Aufbau der Textdateien in diesem Verfahren gleich sind -> gleiche anzahl an Stellen) ASCII_Long verwendet werden muss, da die Zeilen sonst automatische umbrüche machen. Genau mein Problem :/.

 

[VfL_Freak]

Moin,

Sorry musste mir das Debuggen erstmal ansehen. Bin aber darauf gestoßen, dass der PrintWriter einen writeBufferSize von 1024 hat. Kann man diesen vielleicht irgendwie hochschrauben?

Also in der API (Java Platform SE 7) habe ich auf die Schnelle nix gefunden ...
Aber ein kurzes Googlen nach "PrintWriter writeBufferSize" liefert div. Ergebnisse .... vielleicht ist ja das Erste gleich was für Dich?
JAVA printwriter increase buffer size from 8192 bytes - Stack Overflow

Das Tool dient dazu, Textdateien auf einem BS2000-Großrechner hochzuladen (was mein Tool auch erledigt). Dort steht ausdrücklich der Hinweis, dass bei Textdateien solcher Art (Internes Testverfahren, bedeutet dass der Aufbau der Textdateien in diesem Verfahren gleich sind -> gleiche anzahl an Stellen) ASCII_Long verwendet werden muss, da die Zeilen sonst automatische umbrüche machen. Genau mein Problem

Und wir haben hier auch alle einen Rechner mit BS2000 rumstehen .... :shock:
Dann solltest Du DA mal schauen, was die damit meinen ...

Gruß Klaus

 

[Flown]

Also ich hab jetzt das Thema bis jetzt verfolgt und ich kann ein wenig dazu sagen:

- Zeilenumbrüche werden nicht automatisch eingefügt (ich hab das auch ausgiebig mit 200.000 Zeichen großen Zeilen getestet - Ein- und Auslesen funktioniert tadellos)
- Automatic Line wrapping haben manche Texteditoren, heißt aber nicht das das File verändert wird (außer sie haben die Funktion automatisch Zeilenumbrüche einzufügen und du speicherst das File danach)
- Ascii_Long gibts nicht: Desweiteren hat das Encoding nichts wirklich gar nichts mit Umbrüchen zu tun

Meine Frage dazu wäre dann, wo treten bei dir die Fehler auf? Wenn du ein File öffnest und es mit Notepad++ einwandfrei angezeigt werden kann, wo liegt das Problem?

Manche Konsolen (auch die in IDEs) können einen maximale Länge haben und zeigen dann zu lange Zeichenketten nicht mehr an (falls das dein Problem war)!