Java Java BufferedWriter fügt leere Zeichen am ende hinzu

exobros · 23. Januar 2015

Hi Leute
Ich hab zur übung ein kleines Programm in Java geschrieben, das Dateien verschlüsselt (per Caesar-Verschlüsselung, nicht unbedingt sicher oder sinnvoll aber ist ja nur ne Übung). Funktioniert prinzipiell auch, ich habe nur gemerkt, dass mein Filewriter ans Ende der Datei jeweils Leere Zeichen (char wert 0) schreibt. Das würde man an sich auch nicht sehen, allerdings stehen dann eben auch leerzeichen in der verschlüsselten Datei, und wenn diese dann entschlüsselt werden, werden die Leerzeichen eben in Sichtbare umgewandelt. Ich wollte mal fragen ob sich das irgendwie verhindern lässt, bzw woran das liegen kann, dass mein BufferedWriter 3 Nullen am Ende anhängt.
Hier ist mein Code:

Code:

		Writer writer = null;

		try {
			writer = new BufferedWriter(new OutputStreamWriter(
					new FileOutputStream(outputFile)));
			writer.write(output);
		} finally {
			try {
				writer.close();
			} catch (NullPointerException npe) {
			}
		}

Gruß Marius

EDIT: Das programm wird übrigens auf einem Macbook ausgeführt, falls das dass Problem darstellen könnte

max40 · 23. Januar 2015

was ist "output" und welche länger hat dieser?
Stimmt die länge mit dem was du wegschreiben willst?

exobros · 23. Januar 2015

output beinhaltet "ABC" und hat die länge die geschrieben werden soll. Die zusätzlichen zeichen sind erst da wenn ich die datei wieder einlese

max40 · 23. Januar 2015

also hast du dir die Datei schon angeguckt und die sieht gut aus?
Wenn ja: Warum zeigt du uns dann dein Code der die Daten schreibt und nicht den Code der die Daten liest?

exobros · 23. Januar 2015

weil es nicht am einlesen liegen kann, da das einlesen beim ersten mal funktioniert, und dort keine leeren zeichen eingefügt werden. ich bin mir relativ sicher dass es am schreiben liegt.

Rossie · 23. Januar 2015

thebigmf11 schrieb:
ich bin mir relativ sicher dass es am schreiben liegt.

Dann überprüfe das doch! Der Output-Code befindet sich hoffentlich in einer eigenen Methode? Dann schreibe dafür einen Unit-Test, der mit verschiedenen, festen Werten die Funktionalität überprüft.

Was wird überhaupt geschrieben? Ein String? Ein char-Array?

Ich würde bei OutputStreamWriter immer das Charset mit angeben. Falls Du Java 7 verwendest, wäre auch ein try-with-resources ratsam.

exobros · 23. Januar 2015

Es wird ein String geschrieben. Ich kenn mich leider nicht so gut aus mit dem schreiben von Dateien, und bin mir auch nicht sicher welches Charset in dem Fall richtig wäre. Ich probiers mal wenn ich UTF-8 angebe

Rossie · 23. Januar 2015

thebigmf11 schrieb:
Es wird ein String geschrieben. Ich kenn mich leider nicht so gut aus mit dem schreiben von Dateien, und bin mir auch nicht sicher welches Charset in dem Fall richtig wäre. Ich probiers mal wenn ich UTF-8 angebe

Solange man das gleiche OS nutzt, ist es egal. Ist aber schlechter Stil, da nicht portabel. UFT-8 bietet sich bei Text natürlich an. Beim Lesen dann natürlich auch verwenden.

exobros · 24. Januar 2015

Habs jetzt mal beim schreiben auf UTF-8 gesetzt. Beim Lesen weiß ich aber nicht ganz wo ich da das charset setzen könnte.
Ich hab nur im Moment auch keine Zeit danach zu schauen. Danke schonmal für die hilfe, ich melde mich später nochmal ^^

hier ist mal noch mein momentaner code:

Code:

	public static String readFile(File inputFile) throws IOException {
		FileReader reader = null;
		String content = null;
		try {
			reader = new FileReader(inputFile);
			char[] chars = new char[(int) inputFile.length()];
			reader.read(chars);
			for(char c : chars){
				System.out.println((int)c);
			}
			content = new String(chars);
		} finally {
			try {
				reader.close();
			} catch (NullPointerException npe) {

			}
		}
		return content;
	}

Code:

public static void writeFile(String output, File outputFile)
			throws IOException {
		Writer writer = null;

		try {
			writer = new BufferedWriter(new OutputStreamWriter(
					new FileOutputStream(outputFile),"UTF-8"));
			writer.write(output);
		} finally {
			try {
				writer.close();
			} catch (NullPointerException npe) {
			}
		}

	}

Ergänzung (24. Januar 2015)

Grade noch gesehen, dass es sein kann, dass garkeine Zusätzlichen Zeichen eingefügt werden, sondern, das quasi nur die länge der Datei falsch ist. Wenn quasi "(int) inputFile.length()" 6 zurück gibt obwohl nur 3 Zeichen in der Datei sind.

Ergänzung (24. Januar 2015)

Vielleicht liegts ja doch an dem einlesen. nur versteh ich nicht, warum es dann beim ersten mal funktioniert hat.

Rossie · 24. Januar 2015

thebigmf11 schrieb:
Habs jetzt mal beim schreiben auf UTF-8 gesetzt. Beim Lesen weiß ich aber nicht ganz wo ich da das charset setzen könnte.

Das Charset hat nichts mit dem Problem zu tun. Ist wie gesagt schlechter Stil, da abhängig vom Betriebssystem. Wenn nur mit einem Betriebssystem gearbeitet wird, ist es egal (solange bei allen Operationen durchgängig das Standard-Encoding hergenommen wird, ich würde, wenn Du den Aufwand scheust, UTF-8 sein lassen). Deshalb habe ich es erwähnt. Das gleiche gilt für die Verwendung von try-with-resources.

Wie man beim Lesen das Encoding setzt, ist in der API-Doku von FileReader übrigens erwähnt.

thebigmf11 schrieb:
Ergänzung (24. Januar 2015)

Grade noch gesehen, dass es sein kann, dass garkeine Zusätzlichen Zeichen eingefügt werden, sondern, das quasi nur die länge der Datei falsch ist. Wenn quasi "(int) inputFile.length()" 6 zurück gibt obwohl nur 3 Zeichen in der Datei sind.

Dass die Dateilänge mit der Anzahl der geschriebenen Zeichen nicht übereinstimmt, wäre sehr ungewöhnlich, aber dann wohl ein Problem beim Schreiben. Aber das lässt sich ja leicht überprüfen.

thebigmf11 schrieb:
Ergänzung (24. Januar 2015)

Vielleicht liegts ja doch an dem einlesen. nur versteh ich nicht, warum es dann beim ersten mal funktioniert hat.

Du scheinst gerne herum zu raten. Kann man machen. Aber bringt Dich das weiter?

Du hast eine Aufgabe mit mehreren Teilproblemen. Diese kann man isolieren und einzeln testen. Lesen und Schreiben stecken schon mal in unterschiedlichen Methoden, die man getrennt voneinander testen kann. Leg z.B. mit einem Text-Editor zwei, drei Dateien an (auf das richtige Encoding achten!) und lese Sie mit Deiner Methode ein. Funktioniert dies, gehst Du zum Schreiben über. Du könntest z.B. den gleichen Inhalt wie bei den Dateien vorher mit Deiner Routine schreiben, aber andere Dateinamen verwenden und den Inhalt der Dateien dann jeweils vergleichen. Stimmt alles, liegt das Problem nicht bei den I/O Operationen.

Das ist vielleicht eine halbe Stunde Aufwand. Wie viel Zeit hast Du bisher mit Raten verbracht? Gibt ja wohl noch andere Fehlerquellen?

Darlis · 24. Januar 2015

Dass die Länge der Datei von der Zeichenanzahl abweicht ist normal wenn man UTF-8 verwendet. Umlaute z.B. werden mit 2 Zeichen geschrieben. Und dann ist da noch die (optionale) 2-Byte BOM.

Also lieber nicht auf die Länge schauen sondern einen entsprechenden Reader einsetzen/konfigurieren, sodass schon mit dem richtigen Encoding gelesen wird.

Rossie · 27. Januar 2015

Darlis schrieb:
Dass die Länge der Datei von der Zeichenanzahl abweicht ist normal wenn man UTF-8 verwendet. Umlaute z.B. werden mit 2 Zeichen geschrieben. Und dann ist da noch die (optionale) 2-Byte BOM.

Holla, an was hatte ich denn dabei gedacht?

Darlis schrieb:
Also lieber nicht auf die Länge schauen sondern einen entsprechenden Reader einsetzen/konfigurieren, sodass schon mit dem richtigen Encoding gelesen wird.

Beim Testen also unbedingt darauf achten, Sonderzeichen o.ä. zu verwenden, damit der Fehler sich zeigt. Das wird der Unterschied zwischen ersten und zweiten Mal gewesen sein.

Suche

Java Java BufferedWriter fügt leere Zeichen am ende hinzu

exobros

Ensign

max40

Ensign

exobros

Ensign

max40

Ensign

exobros

Ensign

Rossie

Commodore

exobros

Ensign

Rossie

Commodore

exobros

Ensign

Rossie

Commodore

Darlis

Commodore

Rossie

Commodore

Ähnliche Themen