Hallo!
Ich bin gerade dabei, ein Skript zu schreiben, dass sowohl unter Windows als auch Linux die md5-Summe von Dateien (rekursiver Durchlauf der Ordner) berechnen soll. Dabei geht es darum, dass die Dateien von Windows nach Linux transferiert und automatisch die Prüfsummen der Kopie mit dem Original verglichen werden soll.
Nun stellt sich mir die Frage, ob es Probleme mit Umlauten in Dateinamen bei der Berechnung der md5-Summen geben könnte. Auf was muss ich achten?
Vielen Dank,
maxpower
md5sum berechnen umlaute etc.
Geht der Name denn in die Prüfsumme mit ein? Falls ja ist es auf jeden Fall eine Quelle für Probleme, weil die Prüfsumme über Bytes und nicht über Buchstaben berechnet wird, und die Zuordnung Byte<->Buchstabe von der Kodierung abhängt.
Danke schon mal für die Antwort!
Ich denke nicht, dass der Name in die Prüfsumme eingeht (oder doch?). Die Dateien werden mit eingelesen und anschließend jeweils deren md5sum analog zum code snippet auf [wiki]MD5 sum bilden[/wiki] berechnet.
Könnte es Probleme bzgl. des Einlesens der Dateinamen mit Umlauten unter Linux und Windows geben?
P.S.: Sry, muss das ganze natürlich auch noch testen, ist aber momentan noch nicht möglich...
Ich denke nicht, dass der Name in die Prüfsumme eingeht (oder doch?). Die Dateien werden mit
Code: Alles auswählen
f = open(nextfile,'rb')
Könnte es Probleme bzgl. des Einlesens der Dateinamen mit Umlauten unter Linux und Windows geben?
P.S.: Sry, muss das ganze natürlich auch noch testen, ist aber momentan noch nicht möglich...
Dateinamen mit "ungewöhnlichen" Zeichen über Systemgrenzen hinweg sind ein fragile Angelegenheit. Leute die so etwas machen, sollten halt wissen was sie da tun und mit den Konsequenzen leben.
Also, bei dem gezeigten Snippet geht der Name der Datei nicht in die Prüfsumme mit ein, so wie ich das sehe.
@lunar: Im Snippet geht der Name nicht mit in die Prüfsumme ein, aber für den Verwendungszweck aus dem ersten Beitrag muss man auf jeden Fall den Dateinamen der entsprechenden Prüfsumme zuordnen und diese Information auch auf das Zielsystem übertragen. Und ob da dann der Dateiname bei der Zuordnung Dateiname<->Prüfsumme noch zu dem Dateinamen auf der Platte passt, ist nicht sichergestellt.
Beispiel: 'hällö.txt' auf einem Windows-Rechner. Dateiname und Prüfsumme werden cp1252 kodiert in eine Datei geschrieben. Das ganze wird auf ein Linux-System mit UTF-8 als Systemeinstellung kopiert. Wenn dort bei einem `ls` der Name 'hällö.txt' richtig angezeigt wird, passt der als Bytefolge nicht mehr zu dem Dateinamen in der Datei mit den Prüfsummen.
Beispiel: 'hällö.txt' auf einem Windows-Rechner. Dateiname und Prüfsumme werden cp1252 kodiert in eine Datei geschrieben. Das ganze wird auf ein Linux-System mit UTF-8 als Systemeinstellung kopiert. Wenn dort bei einem `ls` der Name 'hällö.txt' richtig angezeigt wird, passt der als Bytefolge nicht mehr zu dem Dateinamen in der Datei mit den Prüfsummen.
Ok, in diesem Fall sollte man Dateinamen vielleicht über in einheitliche Utf-8 Strings umkodieren.BlackJack hat geschrieben:@lunar: Im Snippet geht der Name nicht mit in die Prüfsumme ein, aber für den Verwendungszweck aus dem ersten Beitrag muss man auf jeden Fall den Dateinamen der entsprechenden Prüfsumme zuordnen und diese Information auch auf das Zielsystem übertragen. Und ob da dann der Dateiname bei der Zuordnung Dateiname<->Prüfsumme noch zu dem Dateinamen auf der Platte passt, ist nicht sichergestellt.
Verwenden neuere Windows-Systeme nicht UTF-16?Beispiel: 'hällö.txt' auf einem Windows-Rechner. Dateiname und Prüfsumme werden cp1252 kodiert in eine Datei geschrieben.
Im Dateisystem? Kann sein, aber `os.listdir()` liefert in der Regel Byteketten in der Systemkodierung. Selbst wenn Unicode-Zeichenketten benutzt werden, hat man immer noch das Problem, dass Dateinamen unter Unix Byteketten sind. Deren Bedeutung wird von der Anwendung bestimmt. Wenn man also den Dateinamen in der Datei mit den Prüfsummen so kodiert, dass alle Unicode-Zeichen abgedeckt sind, weiss man immer noch nicht wie diese Datei auf dem Datenträger ansprechbar ist. Das ein Linux als Systemeinstellung UTF-8 benutzt, heisst ja nicht zwangsläufig, dass die Dateinamen alle UTF-8 kodiert sein müssen. Die Datei kann ja auch auf einer Wechselplatte, oder einem älteren FAT-Dateisystem auf einem USB-Stick liegen. Oder aus einem Archiv entpackt worden sein, wo keine UTF-8 kodierten Namen drin standen.
Das ist das gleiche Problem wie bei Textdateien. Das sind einfach Bytes und wenn man nicht *weiss* wie der Text kodiert ist, kann man nur raten.
Das ist das gleiche Problem wie bei Textdateien. Das sind einfach Bytes und wenn man nicht *weiss* wie der Text kodiert ist, kann man nur raten.
Stimmt, aber wenn die Systemcodierung utf8 ist, dann sieht der Anwender per ls die Dateinamen, so wie utf-8 sie decodiert. Deswegen kann man sys.getfilesystemencoding ruhig als Ausgangsbasis für die Berechnung der Prüfsumme nehmen.
Wobei ich bezweifle, dass die Prüfsumme des Dateinamens notwendig ist. In der Regel möchte man doch die Veränderungen man Inhalt aufspüren...
Wobei ich bezweifle, dass die Prüfsumme des Dateinamens notwendig ist. In der Regel möchte man doch die Veränderungen man Inhalt aufspüren...
Nicht? Wo liegt dann das Problem?BlackJack hat geschrieben:Darum den Dateinamen mit in die Prüfsumme einzubeziehen ging es doch gar nicht.
Wenn es nur um die Zuordnung geht, dann kann man den Dateinamen doch einfach utf8 kodiert abspeichern und beim einlesen entsprechend umwandeln. Zur Not ist die Zuordnung ja auch manuell korrigierbar.
Genau der letzte Punkt ist es: Die Zuordnung muss man im Zweifelsfall manuell machen, da es nicht zuverlässig automatisch geht.