Es ist weiterhin ein Rätsel

[JennyE]

Hallo nochmal,

Dann scheinst du aber mit den Originaldaten schon ein Problem zu haben. Ich betrachte mal das Ende der ersten Zeile (HTTP):

Offset    Zeichen           Hex-Dump

00000098  z;Internet;B/N.9  7A 3B 49 6E 74 65 72 6E 65 74 3B 42 2F 4E 0A 39

Man sieht, dass das Zeilenende bzw. der Zeilenumbruch nach B/N durch ein einzelnes 0A, also \n dargestellt wird. Das ist für Unix/Linux normal. In der per FTP übertragenen Dateifassung steht an der Stelle die Kombination 0D 0A, also \r\n, der übliche Windows-Zeilenumbruch.

So siehts aus - entweder fügt FTP das dort ein oder HTTP löscht was raus - sehr sehr seltsam!

Aber dann wird's konfus. Die zweite Zeile endet nämlich mit einem einzelnen 0D, also \r. Der eine oder andere Editor schluckt sowas klaglos, aber es passt absolut nicht ins Konzept. Das ist auch weder für Unix, noch für Windows ein üblicher Zeilenumbruch. Kein Wunder, dass manche Programme Blödsinn daraus machen.

Das "manche Programme" ist die csv-Importfunktion von Lexware Financial Office Pro. Diese Software ist insgesamt schon von Haus was "ganz besonderes".

Du solltest also bei der Erstellung der Originaldatei ansetzen. Da läuft irgendwas schief. Es sollte nicht sein, dass die erste Zeile mit \n beendet wird, alle weiteren aber mit \r. Sorge dafür, dass die Zeilenumbruche einheitlich sind, und wenn du die Datei in der Windows-Welt weiterverarbeiten und nutzen willst, dann vorzugsweise als \r\n.

Bringt die Einflussnahme denn überhaupt was, denn das alles passiert ja durch die unterschiedlichen Methoden des Downloads ein und derselben Datei?! Wie Steel auch schon sagt: Repariert FileZilla da was?! Wenn man das nun wüsste wäre es sehr interessant zu wissen WAS genau repariert wird. Wie gesagt - vielleicht geht ja auch umgekehrt etwas verloren. Ohne da genaues zu wissen, kann das nur ein längeres try & error werden (was ich ja eh schon betreibe).

Jedenfalls vielen Dank für's Drüberschauen.

LG
Jenny