# PrintWriter.println() schreibt mehrere Zeilen



## szmast3r (23. Mrz 2015)

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 (23. Mrz 2015)

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 (23. Mrz 2015)

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 (23. Mrz 2015)

Moin,

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

Gruß Klaus


----------



## szmast3r (23. Mrz 2015)

Werde ich morgen schicken, liegt derzeit auf Arbeit :/

MfG


----------



## szmast3r (24. Mrz 2015)

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 (24. Mrz 2015)

Moin,



szmast3r hat gesagt.:


> [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);
> ...


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 (24. Mrz 2015)

szmast3r hat gesagt.:


> Ö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 (24. Mrz 2015)

Moin,

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



szmast3r hat gesagt.:


> 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



szmast3r hat gesagt.:


> Ö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



szmast3r hat gesagt.:


> 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 (24. Mrz 2015)

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 (24. Mrz 2015)

Moin,



szmast3r hat gesagt.:


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


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



szmast3r hat gesagt.:


> 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?



szmast3r hat gesagt.:


> 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?) ?



szmast3r hat gesagt.:


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


Was bedeutet 'intern' ? :bahnhof:



szmast3r hat gesagt.:


> 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 (24. Mrz 2015)

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 (24. Mrz 2015)

szmast3r hat gesagt.:


> 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 "print*ln*" 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));
}
```



szmast3r hat gesagt.:


> 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 (25. Mrz 2015)

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 (25. Mrz 2015)

Moin,


szmast3r hat gesagt.:


> 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!!



szmast3r hat gesagt.:


> 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 ??



szmast3r hat gesagt.:


> 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?



szmast3r hat gesagt.:


> 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 (25. Mrz 2015)

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 (25. Mrz 2015)

Moin,



szmast3r hat gesagt.:


> 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 .....



szmast3r hat gesagt.:


> 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 !!



szmast3r hat gesagt.:


> 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 (25. Mrz 2015)

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 (25. Mrz 2015)

Moin,


szmast3r hat gesagt.:


> 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




szmast3r hat gesagt.:


> 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 (25. Mrz 2015)

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)!


----------

