png unzippen

[cime]

Hallo,

ich habe hier ein ganz kleines Progrämmchen, dass aus einem Ziparchiv verschiedene png auslesen und speichern soll.

Code: Alles auswählen

import zipfile as zip
import os
f=zip.ZipFile('zips/100.zip')
if not os.path.isdir('zips/100'):
    os.mkdir('zips/100')
for i in f.namelist():
    if i.endswith('.png'):
        path=os.path.join('zips',i)
        new=open(path,'w')
        new.write(f.read(i))
        new.close()
f.close()

nun habe ich aber das kleine Problem, dass wenn ich mit einem ganz normalen Bildbearbeitungsprogramm diese dann öffnen möchte, funktioniert das nicht

Meine Frage: weiß jemand warum und kann es mir erklären???

schon einmal Danke im voraus ....

mfg cime

[rayo]

Hi

Ich rate einfach mal darauf los:
probier mit "wb" anstatt mit "w" zum schreiben öffnen (binary mode)

Gruss

[cime]

Danke, jetzt klappts ... aber wieso? ich habe mich noch nicht mit dem binary mode beschäftigt, wo ist der unterschied zum normal mode???

mfg cime

[Clython]

Der normale Modus schreibt in Bytes, der Binary-Mode in Bits...

[modelnine]

Der normale Modus schreibt in Bytes, der Binary-Mode in Bits...

Quark.

Der Normale (oder auch bei den meißten Leuten, da nicht "normal," Text-)Modus genannte Modus unterscheidet sich bei einigen Betriebssystemen von einem Binär-Modus. Unter anderem ist ein solches Betriebssystem Microsoft Windows.

Wo es evident wird dass der Text- und Binär-Modus unterschiedlich sind ist zum Beispiel bei EOF-Zeichen in der Ausgabe/Eingabe. Wenn man eine Datei im Binär-Modus öffnet wird das EOF so gelesen als wäre es ein ganz normales Zeichen, wenn eine Datei im Text-Modus geöffnet wird scheint es so als wäre die Datei ein Zeichen vor dem EOF zu Ende.

Es gibt noch ein paar andere Unterschiede zwischen Binär- und Text-Modus, aber die sind eher trivial. Das Problem des OP wird gewesen sein dass er eben ein EOF geschrieben hat, und da er die Datei im Text-Modus geöffnet hatte hat das dem Betriebssystem (oder der libc) signalisiert, dass hier die Datei zu Ende ist, und hat dementsprechend die Ausgabe korrumpiert, wobei auch noch andere Faktoren zum tragen gekommen sein könnten wie zum Beispiel dass bei einem \n ein \r\n in die Ausgabe geschrieben wird, und ähnliches.

Unter Unix gibts zwar auch Binär- und Text-Modus, aber auf den allermeißten Systemen sind diese Modi identisch (es gibt also keine Unterscheidung von Binär- und Text-Daten). POSIX hat zwar theoretisch auch den Hinweis dass Text- und Binär-Modus sich unterscheiden können, aber wie gesagt, im Normalfall tun sie das auf Unix-Systemen nicht. Es ist aber, gerade wenn man plattformübergreifend entwickeln will, nicht falsch, überall das Binär-Flag beim öffnen einer Datei mitzugeben.

Womit Text- und Binär-Modus jedoch garnichts zu tun haben ist die Art und Weise wie geschrieben wird. Es geht wie hoffentlich hiernach klar ist nur um eine Übersetzung oder Andersbehandlung von manchen Steuersequenzen (=mehrere auf einander folgende Zeichen wie z.B. \r\n) oder einzelne Zeichen, die im einen Modus eingeschaltet, im anderen ausgeschaltet ist. Beim Text-Modus wird sozusagen noch ein Filter zwischen das Anwendungsprogramm und die Datei auf der Platte geschaltet.

[Clython]

Tja, schlecht geraten

[modelnine]

Tja, schlecht geraten

Am besten gar nicht raten, sondern entweder die Klappe halten, oder sich schlau machen und dann antworten... *grr*

[Clython]

Schlechter Tag?

[modelnine]

Schlechter Tag?

Nö, eigentlich sogar ein ziemlich guter...

Aber ich finds echt nicht gut wenn man einfach auf eine Frage antwortet ohne eigentlich zu wissen worum's geht (zumindest wenn ich Deine Antwort lese hast Du genau das gemacht).

Du musst bedenken dass wir uns eben, wie einige andere zwar meinen, aber die spinnen in meinen Augen, nicht in einem Forum zum Diskurs über die philosophischen Betrachtungen von Python und deren Auswirkungen auf das metaphysische Gleichgewicht von Kindersärgen befinden, sondern in einem Forum in dem über Programmieren und Python gesprochen wird. Es gibt bei der Art von Begriffen (wie zum Beispiel Text- und Binär-Modus) genau ein richtig, und ganz viele falsch, und wenn man nicht weiß was richtig ist, sollte man es am besten lassen zu antworten, weil man im Endeffekt keinen Bewertungsspielraum hat, sondern es entweder weiß was es bedeutet, oder eben nicht.

Ich geh auch nicht rum und erzähl Dinge zu wxPython (meine Beiträge in dem Sub-Forum sind verdammt rar gesäht, wie man vielleicht bemerkt), weil ich im Endeffekt wenig bis keine Ahnung von wxPython habe, und das eben auch so gut einschätze dass ich zwar eine blubber-Antwort geben könnte, aber es sein lasse weil es keinem was bringt und da ich nicht weiß was zum Beispiel ein wxTreeCtrl alles an Methoden hat ich auch nicht darauf antworte wenn eine Frage kommt.

Wenn ich in einem solchen Forum antworte hab ich entweder vorher selbst noch mal nachgeguckt was die Frage ist (ich greife sozusagen dem Poster unter die Arme indem ich für ihn die Google-Suche mache, aus eigenem Interesse), oder aber ich wusste es noch aus irgendwelchen anderen Posts die ich gelesen habe oder aus eigener Erfahrung, oder aber ich lass es ganz bleiben zu antworten und schaue zu dass jemand anderes reagiert.

Entschuldige wenn ich ein bisschen schroff geklungen hab, aber es ist wirklich nervig wenn Du mal mit jemandem arbeiten mußt der im Endeffekt immer solides "Halbwissen" (bis Nichtwissen) in den Ring wirft, allerdings damit immer so weit an der Wahrheit vorbei liegt dass man im Endeffekt auf seine Expertise auch verzichten kann, bzw. sogar muß. Ich will Dir nicht den Mund verbieten, nur eben überleg Dir inwiefern es echt nicht sinnvoller ist darauf zu reagieren wovon Du eine Ahnung hast, und dann einen entsprechenden Beitrag zu schreiben...

Vielleicht verstehst Du jetzt auch warum ich so wehement gegen qweet gewettert hab... (wenn Du den entsprechenden Thread mitverfolgt hast) qweet hat (aus meiner Sicht) keinerlei Einsicht gezeigt dass die philosophische Sammlung von Informationen zu einem Begriff einer Programmiersprache absolut sinnlos ist, sondern hat immer fröhlich weitergemacht Halbwissen in den Ring zu streuen, und so gehts echt nicht. Zumindest nicht wenn man über mathematisch/informatisch exakte Begriffe redet.

So, genug des OT-Geblubbers. Nimms mir bitte nicht tragisch, ich mag Dich trotzdem, auch wenn ich manchmal etwas... direkt bin...

[Clython]

Ich fand meine Antwort gar nicht so blöd.

Mir ist schon klar, dass Python im Endeffekt immer binäre Daten schreibt. Der Punkt ist aus meiner Warte, dass wenn du ein Textfile schreibst oder liesst, tust du das in "Blöcken" (Bytes), da ein Zeichen je nach Codierung 8 bis ähm 32 Bit hat. Wenn du aber ein binäre schreibst, dann geht das eben direkt, ohne dass der Interpreter diese noch filtert, wofür er den Bitstrom in Bytes unterteilen muss.

Wie du selbst sagst:

Womit Text- und Binär-Modus jedoch garnichts zu tun haben ist die Art und Weise wie geschrieben wird. Es geht wie hoffentlich hiernach klar ist nur um eine Übersetzung oder Andersbehandlung von manchen Steuersequenzen (=mehrere auf einander folgende Zeichen wie z.B. \r\n) oder einzelne Zeichen, die im einen Modus eingeschaltet, im anderen ausgeschaltet ist. Beim Text-Modus wird sozusagen noch ein Filter zwischen das Anwendungsprogramm und die Datei auf der Platte geschaltet.

[modelnine]

Mir ist schon klar, dass Python im Endeffekt immer binäre Daten schreibt. Der Punkt ist aus meiner Warte, dass wenn du ein Textfile schreibst oder liesst, tust du das in "Blöcken" (Bytes), da ein Zeichen je nach Codierung 8 bis ähm 32 Bit hat.

Du verwechselst einen Unicode-Codec (im Endeffekt ein Filter) mit dem standard Text-Modus einer Datei. In den beiden Fällen (sprich Binär- und auch Text-Modus) werden eine Menge von Octets (also 8bits pro Zeichen, genauer gesagt der C-Datentyp char, so in der POSIX-Spezifikation definiert) gelesen und auch geschrieben, unabhängig davon in welcher Kodierung die Datei abgelegt ist.

Nur werden manche Octets anders behandelt je nachdem ob man im Binär- oder im Text-Modus ist, im Binär-Modus werden die Octets verbatim behandelt (sprich so ausgegeben wie Du das .write() sagst mittels des Python-Strings, oder so gelesen wie sie auf der Platte stehen in einen Python-String). Im Text-Modus werden manche Octets eben gesondert behandelt, indem zum Beispiel aus dem Octet \x0a auf der Platte ein EOF gemacht wird, was dann bedeutet dass für die Applikation die die Datei liest es so aussieht als ob die Datei hier enden würde.

Unabhängig davon: der Filter, der im Text-Modus dazwischen sitzt, sitzt nicht im Python-Interpreter, sondern entweder direkt im Betriebssystem (also in den Syscalls für Dateizugriff) oder in der C-Bibliothek. Und Bitströme kann man nicht schreiben. Man kann ganz egal in welchem Modus eine Datei geöffnet ist immer nur Octets (also Zeichen von 8-bit Länge schreiben). Die Interpretation des Dateiinhalts (wie zum Beispiel dass der Inhalt einer Datei Unicode ist mit mehreren Bytes pro eigentlichem Zeichen) macht die Applikation, nicht das Betriebssystem oder der Python-Interpreter, und erst recht nicht der Binär- oder Text-Modus in dem eine Datei geöffnet ist...

EDIT: Lies bitte kurz mal in den entsprechenden Spezifikationen (vor allen POSIX) nach was Text- und Binär-Modus ist. Das ist nichts was Python-spezifisch ist, sondern eben eine Eigenheit des POSIX-Standards (und früherer Betriebssysteme die eben Text- und Binär-Dateien unterschiedlich gespeichert/behandelt haben).

[Clython]

Ja werde mich mal vermehrt mit C und POSIX rumschlagen. Zuerst muss ich aber noch Kursunterlagen schreiben.

[rayo]

Hi

Irgendwie weiss ich warum ich nicht geantwortet habe .

Ich wusste zwar das es etwas mit \n zu tun hat aber nicht genau was, danke für die erklärung.

Gruss

[cime]

Von mit auch ein Danke für die Erklärung.

mfg cime