PrintWriter schreibt keine in Strings enthaltenen Zeilenumbrüche

[Co]

Hallo zusammen 🙂

ich brauche eure Hilfe bei folgendem Code (etwas abgespeckt):

public static void save(String[][] decryptedStrings, int counter){
	try(PrintWriter printer=new PrintWriter(FILEPATH)){
		for(int i = 0; i < counter; i++){
			printer.println(decryptedStrings[i][0]);
		}
	}
	catch(FileNotFoundException fnf){
		System.out.println("File not found!");
	}
}

Das Array "decryptedStrings" enthält mehrere Strings, die per TextArea in einer GUI eingegeben, anschließend bearbeitet wurden und auch Zeilenumbrüche enthalten können.
Diese Zeilenumbrüche werden beim Aufruf der Methode "save()" allerdings nicht in die Textdatei geschrieben, sondern einfach ignoriert.

Wenn ich testweise vor dem try-Block die Zeile

System.out.println(decryptedStrings[0][0]);

eintrage und der String an der Array-Position [0][0] einen Umbruch enthält, wird der auch wie gewollt auf der Konsole ausgegeben. Also existiert der Umbruch auch noch beim Aufruf des Befehls "printer.println()".

Warum wird er dann nicht in die Datei geschrieben? Was muss ich an dem Code ändern?

Viele Grüße,

Co

 

[JeromeC]

Du schreibst an dieser Stelle

printer.println(decryptedStrings[i][0]);

nicht einen String sondern eine Array-Zeile in deine Datei (also String[]).

Versuch mal die einzelnen Strings wegzuspeichern und gucke, wie es sich dann verhält.
Dafür benötigst du eine weitere for-Schleife.

LG

 

[Co]

Danke für die schnelle Antwort!

Leider funktioniert es auch nicht, wenn ich die Methode "save" mit einzelnen Strings füttere.
Ich habe mir gedacht, dass es vielleicht an der TextArea liegt. Deshalb habe ich manuell einen String "Zeile1\nZeile2" erstellt und den in "save" geschickt, leider auch ohne Erfolg.
Ich habe die Vermutung, dass es an PrintWriter liegen muss. "System.out.println" funktioniert ja ohne Probleme.

 

[Tobse]

Wie stellst du denn fest ob da zeilenumbrüche in der Datei sind? Unter Windows wird eine Neue Zeile durch

\r\n

, unter Linux durch [c]\n[/c] und unter Macintosh durch

\r[/c] ausgedrückt. Je nachdem ob ein [URL="http://de.wikipedia.org/wiki/Byte_Order_Mark"]BOM[/URL] in der Datei ist und mit welchem Editor du die Datei betrachtest kann das stark variieren.

 

[Co]

Ich benutze Windows 8 und speicher die Strings in einer .txt-Datei, welche ich mit dem Standard-Texteditor öffne.
Von Byte Order Marks höre ich gerade das erste mal. Aktiv/ bewusst verwenden tue ich also keine.
Umbrüche stelle ich zur Laufzeit gar nicht fest. Erst nach Programmende öffne ich die .txt-Datei und stelle fest, dass alle Umbrüche innerhalb eines Strings einfach ignoriert wurden. 🙁

Viele Grüße,

Co

 

[Tobse]

Dann versuch mal folgendes:

printer.println(decryptedStrings[i][0].replace("\n", "\r\n");

 

[kaoZ]

warum nicht einfach Plattformunabhängig mit

final static String DELIMITER = System.getProperty("line.separator");

arbeiten ? insofern ich mich jetzt nicht verlesen habe.

 

[Tobse]

warum nicht einfach Plattformunabhängig mit

final static String DELIMITER = System.getProperty("line.separator");

arbeiten ? insofern ich mich jetzt nicht verlesen habe.

Das mit dem Platformunabhängigen Line-Delimeter macht natürlich mehr sinn. Mit meinem Post wollte ich aber erstmal das Problem des TE "remote-debuggen" 😀

 

[kaoZ]

Naja, ging ja eigentlich nur darum warum man (der TO) nicht einfach die schon vorhandenen Resourcen nutzt ^^

Aber ich kenne das nur zu gut ich probiere Stundenlang irgendwas aus um dann zu merken , das es diese Funktionalität bereits irgendwo gibt, ist aber nicht weiter tragisch , so lernt man ja schließlich wie etwas funktioniert, und bildet so Verständnis für diese dinge 😀

 

[Co]

Habe gerade beides getestet und beides funktioniert auch :toll:
Macht im Nachhinein aber auch Sinn :idea:

Das Problem kenne ich aber auch: Man bastelt sich komplizierte Methoden zurecht, ist glücklich wenn es endlich läuft und stellt dann fest, dass man sie einfach hätte importieren können :autsch:
Aber sowas macht auch Spaß 🙂

Vielen Dank euch!
Viele Grüße,

Co