9
Textdatei mit CRLF gespeichert, kommt aber ohne CRLF an, was ist die Ursache?
Hallo Ihr lieben,
nein ich bin kein Experte und weiß nicht einmal ob ich hier richtig bin, daher bitte ich euch für den leihen verständlich zu Antworten.
Worum geht es:
es geht um ein Gerät das ein Protokoll speichert.
Jeder neue Eintrag wird mit CRLF gespeichert, also in einer neuen Zeile.
Bsp:
Datum;Uhrzeit;Werte...
Datum;Uhrzeit;Werte...
Datum;Uhrzeit;Werte...
diese Textdatei wird auf ein FTP Server hochgeladen, bis hierhin ist alles korrekt, die Datei beinhaltet den Datensatz wie hier hoben im Beispiel.
Jetzt wird die Datei vom Server heruntergeladen und die Datei kommt dann nur noch ohne CRLF an.
Bsp:
Datum;Uhrzeit;Werte...Datum;Uhrzeit;Werte...Datum;Uhrzeit;Werte...
Dadurch kann das Protokoll nicht mehr ausgewertet werden.
Das Tool was diese Textdatei vom FTP Server abholt, wie auch der FTP Server selbst kann es nicht sein, da mehrfach korrekt auf anderen Servern im Einsatz.
Wahrscheinlich werden die Daten als ASCII abgeholt statt Binär, denn dann würde CRLF fehlen.
Die Frage lautet somit, wieso ist das so und wo stellt man dies in Windows auf Binär ein?
Das Tool nimmt es ja so wie Windows eingestellt ist (und läuft auf anderen Server normal ohne das man etwas einstellen muss, daher gibt's dazu auch keine Einstellung).
(Server 2012 R1)
Vielen Dank
RDP
nein ich bin kein Experte und weiß nicht einmal ob ich hier richtig bin, daher bitte ich euch für den leihen verständlich zu Antworten.
Worum geht es:
es geht um ein Gerät das ein Protokoll speichert.
Jeder neue Eintrag wird mit CRLF gespeichert, also in einer neuen Zeile.
Bsp:
Datum;Uhrzeit;Werte...
Datum;Uhrzeit;Werte...
Datum;Uhrzeit;Werte...
diese Textdatei wird auf ein FTP Server hochgeladen, bis hierhin ist alles korrekt, die Datei beinhaltet den Datensatz wie hier hoben im Beispiel.
Jetzt wird die Datei vom Server heruntergeladen und die Datei kommt dann nur noch ohne CRLF an.
Bsp:
Datum;Uhrzeit;Werte...Datum;Uhrzeit;Werte...Datum;Uhrzeit;Werte...
Dadurch kann das Protokoll nicht mehr ausgewertet werden.
Das Tool was diese Textdatei vom FTP Server abholt, wie auch der FTP Server selbst kann es nicht sein, da mehrfach korrekt auf anderen Servern im Einsatz.
Wahrscheinlich werden die Daten als ASCII abgeholt statt Binär, denn dann würde CRLF fehlen.
Die Frage lautet somit, wieso ist das so und wo stellt man dies in Windows auf Binär ein?
Das Tool nimmt es ja so wie Windows eingestellt ist (und läuft auf anderen Server normal ohne das man etwas einstellen muss, daher gibt's dazu auch keine Einstellung).
(Server 2012 R1)
Vielen Dank
RDP
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2737386835
Url: https://administrator.de/contentid/2737386835
Printed on: April 19, 2024 at 22:04 o'clock
9 Comments
Latest comment
das stellst du in windows in deinem FTP client normalerweise ein ... wobei es auch sein kann das dein Editor die Datei verändert, d.h. im zweifel mal mit nem wirklich simplen Editor (z.B. ich meine notepad++ - ich nutz kein win mehr, damals gings iirc) angucken.
daher bitte ich euch für den leihen verständlich zu Antworten
https://www.duden.de/rechtschreibung/LaieAusleihen willst du ja nix.
Mal einen anderen Editor verwendet wie Notepad++ https://notepad-plus-plus.org ?
Dort kann man das gruselige CRLF von Winblows deaktivieren.
Zitat von @148523:
Dort kann man das gruselige CRLF von Winblows deaktivieren.
Dort kann man das gruselige CRLF von Winblows deaktivieren.
Wieso "gruselig"?
https://stackoverflow.com/a/1552775
Okay, "brauchen" tut man vermutlich so einige Sachen nicht (mehr), aber logisch und historisch ist da schon Sinn hinter.
Zitat von @MrCount:
Okay, "brauchen" tut man vermutlich so einige Sachen nicht (mehr), aber logisch und historisch ist da schon Sinn hinter.
Stimmt, bei 'ner analogen Schreibmaschine war noch ein Sinn hinter dem CR. 😛Okay, "brauchen" tut man vermutlich so einige Sachen nicht (mehr), aber logisch und historisch ist da schon Sinn hinter.
Zitat von @TK1987:
Zitat von @MrCount:
Okay, "brauchen" tut man vermutlich so einige Sachen nicht (mehr), aber logisch und historisch ist da schon Sinn hinter.
Stimmt, bei 'ner analogen Schreibmaschine war noch ein Sinn hinter dem CR. 😛Okay, "brauchen" tut man vermutlich so einige Sachen nicht (mehr), aber logisch und historisch ist da schon Sinn hinter.
Oder bei z.B. bei div. Nadeldruckern die man auch heute noch findet (z.B. Listendrucker, Telefon-Anlagen,...). Nur weil du was nicht kennst ist es lange nicht sinnlos...
Rein logisch gesehen macht es schon Sinn den Wagenrücklauf (CR/"Carriage Return") zu veranlassen, da man ja sonst nur die Zeile, nicht aber die Position innerhalb der Zeile wechselt (Zeilenvorschub/LF/"Line Feed").
😛 
Wie schon jemand anderes geschrieben hat: die Umwandlung von Zeilenende-Zeichen initialisiert der FTP-Client.
Alles, was im ASCII-Modus übertragen wird, wird von und zum Server umgewandelt. Mitunter so, dass sowohl CRs als auch LFs komplett fehlen.
Das ist für reine ASCII-Dateien gewünscht, denn Windows will nun mal CRLF und Linux bzw. macOS wollen nur LF. Man spart sich eine manuelle Konvertierung.
Wenn es aber kein ASCII ist, sondern eine Testdatei in ISO-8859 oder UTF-8 bzw. Unicode, dann kann man davon ausgehen, dass der ASCII-Transfermodus die Datei zerstören wird, sobald irgendein Zeichen vorkommt, was nicht mehr ASCII ist (Umlaute zum Beispiel).
Um bei FTP Dateien wirklich 1:1 zu übertragen, muss man entweder auf der Kommandozeile "binary" als Befehl eingeben, oder eine Einstellung im FTP-Tool finden.
Du hast nicht geschrieben, was für den Transfer benutzt wird.
Es gibt ja für fast alles RFCs: https://datatracker.ietf.org/doc/html/rfc959
Alles, was im ASCII-Modus übertragen wird, wird von und zum Server umgewandelt. Mitunter so, dass sowohl CRs als auch LFs komplett fehlen.
Das ist für reine ASCII-Dateien gewünscht, denn Windows will nun mal CRLF und Linux bzw. macOS wollen nur LF. Man spart sich eine manuelle Konvertierung.
Wenn es aber kein ASCII ist, sondern eine Testdatei in ISO-8859 oder UTF-8 bzw. Unicode, dann kann man davon ausgehen, dass der ASCII-Transfermodus die Datei zerstören wird, sobald irgendein Zeichen vorkommt, was nicht mehr ASCII ist (Umlaute zum Beispiel).
Um bei FTP Dateien wirklich 1:1 zu übertragen, muss man entweder auf der Kommandozeile "binary" als Befehl eingeben, oder eine Einstellung im FTP-Tool finden.
Du hast nicht geschrieben, was für den Transfer benutzt wird.
Es gibt ja für fast alles RFCs: https://datatracker.ietf.org/doc/html/rfc959
