Datei-Download HTTP-Header vs. FTP - Dateigröße verschieden

[JennyE]

Hi,

ich habe eine Text-Datei auf dem Server liegen. Einmal liefere ich die als Download über den Webbrowser aus und einmal lade ich sie direkt per FTP auf meinen Rechner. Oberflächlich sind beide Dateien identisch (sagt auch ein Vergleichsprogramm (WinMerge)). Seltsamerweise sind tatsächlich aber beide Dateien unterschiedlich in der Größe und (logischerweise) auch im Hashwert. Der mit dem Browser heruntergeladenen Datei fehlen ein paar Bytes und wird hierdurch unbrauchbar.

Ich kann mir das einfach nicht erklären - wie kommt das?

Dateigröße per Browser: 50.893 Bytes
Dateigröße per FTP: 50.948 Bytes

Wie gesagt: Es handelt sich um ein und dieselbe Datei, die ausgeliefert wird.

LG
Jenny

[tron]

Hi,

ich habe eine Text-Datei auf dem Server liegen. Einmal liefere ich die als Download über den Webbrowser aus und einmal lade ich sie direkt per FTP auf meinen Rechner. Oberflächlich sind beide Dateien identisch (sagt auch ein Vergleichsprogramm (WinMerge)). Seltsamerweise sind tatsächlich aber beide Dateien unterschiedlich in der Größe und (logischerweise) auch im Hashwert. Der mit dem Browser heruntergeladenen Datei fehlen ein paar Bytes und wird hierdurch unbrauchbar.

gib mal bitte ein paar Hintergrundinfos: was für ein Server, System, Browser, etc.

tron

[JennyE]

gib mal bitte ein paar Hintergrundinfos: was für ein Server, System, Browser, etc.

Web-Server: Debian 6.0.7 lamp
Win7 Pro, FileZilla 3.7, Firefox 24.0

LG
Jenny

[Der Martin]

Hallo,

ich habe eine Text-Datei auf dem Server liegen. Einmal liefere ich die als Download über den Webbrowser aus und einmal lade ich sie direkt per FTP auf meinen Rechner. Oberflächlich sind beide Dateien identisch (sagt auch ein Vergleichsprogramm (WinMerge)). Seltsamerweise sind tatsächlich aber beide Dateien unterschiedlich in der Größe und (logischerweise) auch im Hashwert.

vermutlich lädt dein FTP-Client die Datei im ASCII-Modus herunter, wobei Zeilenumbrüche zwischen Unix und Windows angepasst werden - in deinem Fall werden also vermutlich alle \n zu \r\n erweitert. Das ist bei reinen Textdateien normalerweise eine gute Sache, weil dann jedes System die Zeilenumbrüche so vorfindet, wie es sie haben "will".
Möchte man diese Konvertierung verhindern, sollte man im BINARY-Modus herunterladen.

Der mit dem Browser heruntergeladenen Datei fehlen ein paar Bytes und wird hierdurch unbrauchbar.

Wieso unbrauchbar??

Dateigröße per Browser: 50.893 Bytes
Dateigröße per FTP: 50.948 Bytes

Dann scheint die Datei also 55 Zeilen zu haben. Und zwar verdammt lange Zeilen. ;-)

Ciao,
 Martin

[JennyE]

vermutlich lädt dein FTP-Client die Datei im ASCII-Modus herunter, wobei Zeilenumbrüche zwischen Unix und Windows angepasst werden - in deinem Fall werden also vermutlich alle \n zu \r\n erweitert. Das ist bei reinen Textdateien normalerweise eine gute Sache, weil dann jedes System die Zeilenumbrüche so vorfindet, wie es sie haben "will".

Die Erklärung macht Sinn.

Möchte man diese Konvertierung verhindern, sollte man im BINARY-Modus herunterladen.

Habe die verschiedenen Möglichkeiten schon durch - ohne Erfolg.

Der mit dem Browser heruntergeladenen Datei fehlen ein paar Bytes und wird hierdurch unbrauchbar.

Wieso unbrauchbar??

Es ist eine Import-Datei für eine WaWi. Siehe die Bilder ..
Datei per HTTP gedownloadet ahut er die Artikelnummern kaputt:

Datei per FTP gedownloadet ist alles in Ordnung:

Dann scheint die Datei also 55 Zeilen zu haben. Und zwar verdammt lange Zeilen. ;-)

Ja, es sind halt Artikelbeschreibungen drin.

LG
Jenny

[tron]

Jenny, der erste Eintrag in der Artikelliste, ist der richtig? Leider sind die Screenshots vom Ende der Liste. Beides wäre interessant gewesen.

[JennyE]

Jenny, der erste Eintrag in der Artikelliste, ist der richtig? Leider sind die Screenshots vom Ende der Liste. Beides wäre interessant gewesen.

Das "Ende" der Liste ist der erste Eintrag. Der ist also richtig. Danach sind ALLE Einträge kaputt. Es wird schon was mit den Zeilenumbrüchen zu tun haben, wenn FTP selbstständig konvertiert, was der Browser ja nicht macht.

Wenn ich Martin richtig verstanden habe, wollen alle Programme \n\r haben, richtig?

LG
Jenny

[Der Martin]

Mahlzeit,

vermutlich lädt dein FTP-Client die Datei im ASCII-Modus herunter, wobei Zeilenumbrüche zwischen Unix und Windows angepasst werden - in deinem Fall werden also vermutlich alle \n zu \r\n erweitert. Das ist bei reinen Textdateien normalerweise eine gute Sache, weil dann jedes System die Zeilenumbrüche so vorfindet, wie es sie haben "will".
Die Erklärung macht Sinn.

... aber sie passt nicht zu deiner Situation, wie ich jetzt sehe. Ich hatte deine ursprüngliche Beschreibung missverstanden; ich dachte, per HTTP sei es okay und per FTP nicht. Außerdem hast du kein Wort darüber verloren, welcher Art die Verstümmelung ist.

Datei per HTTP gedownloadet ahut er die Artikelnummern kaputt:

Datei per FTP gedownloadet ist alles in Ordnung:

Oh, verdammt. Das sieht nach allerlei seltsamen Dingen aus, aber nicht (nur) nach falschen Zeilenumbrüchen. Wobei ... was du hier zeigst, ist ja nicht die originale Textdatei, sondern das, was deine Software beim Import daraus interpretiert.

Kannst du die beiden Dateivarianten mal im Hexdump vergleichen? Oder, falls du dazu nicht die Möglichkeit hast, beide Dateien (nach FTP- und HTTP-Download) mal zur Analyse zur Verfügung stellen?

Wenn ich Martin richtig verstanden habe, wollen alle Programme \n\r haben, richtig?

Andersrum: \r\n ist üblich unter Windows, \n\r führt auch oft zu merkwürdigen Ergebnissen. Und nicht alle, denn manche kommen auch mit Unix-Zeilenumbrüchen \n ganz gut klar.

So long,
 Martin

[JennyE]

Kannst du die beiden Dateivarianten mal im Hexdump vergleichen? Oder, falls du dazu nicht die Möglichkeit hast, beide Dateien (nach FTP- und HTTP-Download) mal zur Analyse zur Verfügung stellen?

Also beim Hex-Vergleich der beiden Dateien sieht man eindeutig, dass sie verschieden sind. Der FTP-Transfer fügt Zeichen ein, die in der Browser-Version nicht vorhanden sind - warum, wieso, weshalb: Keine Ahnung.

Die Dateien kann ich nicht so ohne Weiteres hier einstellen, denn es handelt sich um vertrauliche Firmendaten mit EK-Preisen usw. Ich werde mal sehen, ob das mit neutralen Daten reproduzierbar ist. Melde mich gleich nochmal.

Danke bis hierher.

LG
Jenny

[JennyE]

Oder, falls du dazu nicht die Möglichkeit hast, beide Dateien (nach FTP- und HTTP-Download) mal zur Analyse zur Verfügung stellen?

So, die beiden Varianten stehen zum Download bereit. Habe die Daten gekürzt und verschleiert, aber vom Prinzip her ist die Datei genauso aufgebaut wie das Original.

Importdateien.zip

Die Datei lxArtikel_FTP.csv wurde mit FileZilla, die Datei lxArtikel_HTTP.csv per Browser heruntergeladen. Bin gespannt, was die Fachleute dazu sagen.

Dank im voraus.

LG
Jenny

[Der Martin]

Hallo nochmal,

So, die beiden Varianten stehen zum Download bereit. Habe die Daten gekürzt und verschleiert, aber vom Prinzip her ist die Datei genauso aufgebaut wie das Original.
Importdateien.zip

ich gehe mal davon aus, dass die per HTTP heruntergeladene Version -auch wenn sie nicht "funktioniert"- die unverfälschte Originaldatei ist, weil mir nichts bekannt ist, was bei einem HTTP-Download die Nutzdaten verändert (im Gegensatz zu FTP, wie schon erläutert).

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.

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.

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.

Good luck,
 Martin

[Steel]

Hi!

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.

'Repariert' Filezilla evtl. die Datei?

[Der Martin]

Hallo,

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.
'Repariert' Filezilla evtl. die Datei?

hmm, "repariert"?
"If it ain't broken, fix it until it is." ;-)

Nein, die beiden Demo-Dateien von Jenny unterscheiden sich tatsächlich nur an zwei Stellen. Im mutmaßlichen Original ist die erste Zeile mit \n abgeschlossen, und ganz am Ende steht noch ein \n. Beide sind in der kaputten FTP-übertragenen Version durch \r\n ersetzt, dadurch ist diese Datei um zwei Bytes länger.
Die Zeilen dazwischen, die mit \r abgeschlossen sind, bleiben unverändert.

Ich unterstelle mal, dass die FTP-übertragene Datei mit dem unbrauchbaren Original identisch wäre, wenn man im BINARY-Modus überträgt.

Ciao,
 Martin

[JennyE]

Ich unterstelle mal, dass die FTP-übertragene Datei mit dem unbrauchbaren Original identisch wäre, wenn man im BINARY-Modus überträgt.

Absolut richtig, Martin, habe es gerade ausprobiert:
ASCII-Modus: 2.112 Byte
Binary-Modus: 2.110 Byte

Aber eine Text-Datei im Binary macht doch aber eigentlich gar keinen Sinn, bzw. kann ja im schlimmsten Fall (wie in diesem) eine unbrauchbare Datei anliefern. Ich seh den Wald vor lautern Bäumen nicht mher :(

LG

[dedlfix]

Tach!

Aber eine Text-Datei im Binary macht doch aber eigentlich gar keinen Sinn, bzw. kann ja im schlimmsten Fall (wie in diesem) eine unbrauchbare Datei anliefern.

Alles andere als der Binary-Modus bei der FTP-Übertragung ist das eigentlich sinnlose. Da macht ein Automatismus etwas, und das noch dazu in der Voreinstellung, das der Anwender nicht weiß. Manchmal ist es richtig, die Zeilenenden zu übersetzen, manchmal aber nicht. Was Text und was kein Text ist, kann das FTP-Programm auch nur anhand von Indizien wie der Datei-Endung raten.

Am besten ist jedenfalls, alles binär zu übertragen und die Zeilenenden selbst zu pflegen. Dafür gibt es nur einen unbrauchbaren Editor unter Windows, und das ist der mitgelieferte Notepad. Der ist auch ansonsten unkomfortabel, weswegen es sowieso ratsam ist, sich ein ordentliches Pendant zuzulegen. Und dann kann man für Webprojekte auf Unix-Servern generell Unix-Zeilenenden verwenden.

dedlfix.

[JennyE]

Alles andere als der Binary-Modus bei der FTP-Übertragung ist das eigentlich sinnlose. Da macht ein Automatismus etwas, und das noch dazu in der Voreinstellung, das der Anwender nicht weiß. Manchmal ist es richtig, die Zeilenenden zu übersetzen, manchmal aber nicht. Was Text und was kein Text ist, kann das FTP-Programm auch nur anhand von Indizien wie der Datei-Endung raten.

Naja, meitens ist der Nutzer ja der, der rät und dann z.B. *.csv als ASCII-Mode zuweist. Aber Du hast recht - es ist die Unwissenheit, die einen das tun lässt. :)

Am besten ist jedenfalls, alles binär zu übertragen und die Zeilenenden selbst zu pflegen.

Ich verwende notepad++ und bin damit ziemlich zufrieden.

Vielen Dank an dich für den Tipp.

LG
Jenny

[dedlfix]

Tach!

Am besten ist jedenfalls, alles binär zu übertragen und die Zeilenenden selbst zu pflegen.
Ich verwende notepad++ und bin damit ziemlich zufrieden.

Der kann die Zeilenenden aus beiden Welten wunderbar verarbeiten. Noch ein Grund weniger, die ASCII-Übertragung zu verwenden.

dedlfix.

[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

[unknown]

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.

Das was Der Martin vermutlich viel interessanter findet, wo kommt die Datei her?

[Der Martin]

Hi,

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

nein, denn schon die Originaldatei ist unbrauchbar - zumindest ist das nach der bisherigen Faktenlage meine Überzeugung. Beim HTTP-Transfer wird sie exakt 1:1 übertragen, beim FTP-Transfer *kann* sie verändert werden.

Wie wird denn diese Datei erzeugt? Ich bin bisher davon ausgegangen, dass diese Erzeugung in deiner Verantwortung liegt und du folglich selbst Hand anlegen kannst/musst.

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.

Es ist eigentlich ganz einfach:
FTP im ASCII-Modus    konvertiert \n zu \r\n (bzw. umgekehrt)
FTP im BINARY-Modus   konvertiert nichts, überträgt exakt 1:1
HTTP                  konvertiert nichts, überträgt exakt 1:1

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

"Da nich für". :-)

Ciao,
 Martin

[JennyE]

Wie wird denn diese Datei erzeugt? Ich bin bisher davon ausgegangen, dass diese Erzeugung in deiner Verantwortung liegt und du folglich selbst Hand anlegen kannst/musst.

Ja, die Erzeugung liegt in meiner Hand. fputcsv() erzeugt sie nach einer entsprechenden Datenbankabfrage und einem daraus erzeugtem Array. Habe aber gerade schon auf php.net gelesen, dass einige mit fputcsv() und korrekten "\r\n" Schwierigkeiten haben. Das wird auch in diesem Fall das Problem sein.

Vielen Dank an Martin für das Führen auf den richtigen Weg. :)

LG an Alle, die mitgeholfen haben.
Jenny

[Der Martin]

Hi,

Wie wird denn diese Datei erzeugt? Ich bin bisher davon ausgegangen, dass diese Erzeugung in deiner Verantwortung liegt und du folglich selbst Hand anlegen kannst/musst.
Ja, die Erzeugung liegt in meiner Hand. fputcsv() erzeugt sie nach einer entsprechenden Datenbankabfrage und einem daraus erzeugtem Array.

das PHP-Manual sagt dazu:

"fputcsv() formats a line (passed as a fields array) as CSV and write it (terminated by a newline) to the specified file handle."

Entscheidend ist hier IMO die Klammer "terminated by a newline". Ich würde erwarten, dass newline hier der auf dem Server-System übliche Code für einen Zeilenumbruch ist - auf einem Linux-Host wie in deinem Setup also \n. Tatsächlich enthält deine Datei aber \r stattdessen. Sehr merkwürdig.

Ich habe aber fputcsv() selbst noch nicht benutzt und kann daher nicht viel dazu sagen.

Habe aber gerade schon auf php.net gelesen, dass einige mit fputcsv() und korrekten "\r\n" Schwierigkeiten haben. Das wird auch in diesem Fall das Problem sein.

Wo hast du das gelesen? Ich vermute, du beziehst dich auf diese Passage:

"Note: If PHP is not properly recognizing the line endings when reading files either on or created by a Macintosh computer, enabling the auto_detect_line_endings run-time configuration option may help resolve the problem."

Das betrifft dann aber nicht das Erzeugen einer CSV-Datei mit fputcsv(), sondern das Lesen einer solchen mit fgetcsv(), wenn sie auf einem Mac erzeugt wurde. Tatsächlich haben alte MacOS-Versionen ein einzelnes \r als Zeilenumbruch verwendet. Das ist aber AFAIK schon lange passé.

Ciao,
 Martin

[JennyE]

Entscheidend ist hier IMO die Klammer "terminated by a newline". Ich würde erwarten, dass newline hier der auf dem Server-System übliche Code für einen Zeilenumbruch ist - auf einem Linux-Host wie in deinem Setup also \n. Tatsächlich enthält deine Datei aber \r stattdessen. Sehr merkwürdig.

Ich habe das ebenfalls erwartet und mir deshalb keinen Kopf um Schwierigkeiten in dieser Richtung gemacht.

Habe aber gerade schon auf php.net gelesen, dass einige mit fputcsv() und korrekten "\r\n" Schwierigkeiten haben. Das wird auch in diesem Fall das Problem sein.

Wo hast du das gelesen? Ich vermute, du beziehst dich auf diese Passage:

Nein, ich beziehe mich auf einen User-Comment darunter:
[quote]
 - the original function didn't correctly return the length of the data outputted
[/quote]

Wie auch immer, ich erzeuge die Daten jetzt nicht mehr mit fputcsv(), sondern nach Alter-Väter-Sitte von "Hand" mit den entsprechend Zeilenumbrüchen.

  
[schnipp]  
$line = '';  
foreach ($csvList as $fields) {  
//    fputcsv($fp, $fields, ";", "'");  
	foreach($fields as $k => $v) {  
		if($k < 15) {  
			$line .= is_string($v) ? "\"".$v."\";" : $v.";";  
		} else {  
			$line .= is_string($v) ? "\"".$v."\"\r\n" : $v."\r\n"; $v."\r\n";  
		}  
	}  
}  
[schnapp]  

Mit dem Ergebnis daraus ist alles gut und Lexware importiert korrekt. :)

Vielen Dank nochmal bei der Analyse und damit verbundenen Lösung des Problems.

LG an Alle
Jenny

[Baba]

You say, it cannot be love if it isn't for ever.
But let me tell you: Sometimes, a single scene can be more to remember than the whole play.

Kennst du den Autor?

Cheers,
Baba

[Der Martin]

Hallo,

You say, it cannot be love if it isn't for ever.
But let me tell you: Sometimes, a single scene can be more to remember than the whole play.

Kennst du den Autor?

leider nein, aber der Aussage kann ich aus ganzem Herzen zustimmen.

Ciao,
 Martin

[tron]

hallo martin,

vermutlich lädt dein FTP-Client die Datei im ASCII-Modus herunter, wobei Zeilenumbrüche zwischen Unix und Windows angepasst werden - in deinem Fall werden also vermutlich alle \n zu \r\n erweitert. Das ist bei reinen Textdateien normalerweise eine gute Sache, weil dann jedes System die Zeilenumbrüche so vorfindet, wie es sie haben "will".
Möchte man diese Konvertierung verhindern, sollte man im BINARY-Modus herunterladen.

daran dachte ich auch sofort. Allerdings stimmen ja die Daten via FTP laut OP. Nur über den Web-Browser nicht.