unicode und encodings, wie so oft..

[fhoech]

Auch das ist ja eben nur "raten", wenn vielleicht auch ein ganz "gutes".

Ist mir bewusst. Deshalb schrieb ich ja auch "auch"

Jedoch kannst Du dem OP ja nicht unterstellen, dass er geraten hat. Evtl. stand ja in der Doku zum speziellen Programm, was es erwartet

Das war ja jetzt keine "böswillige" Unterstellung (bzw. nicht so gemeint), und ich gebe zu, ich habe nicht extra in die 7zip-Doku geschaut. Aber Tatsache ist, das subprocess bei meinem Beispieldateinamen (mit u"\u2022") bei "iso-8859-1" einen Fehler wirft, daher meine Annahme (mit 'mbcs' oder eben sys.getfilesystemencoding funktioniert es).

[Gremlin]

Hm, ich hab aber geraten, naja gut, bevor ich diese Behauptung aufgestellt habe hab ichs schon getestet, aber beweisen könnt ichs trotzdem nicht

[Leonidas]

Aber Tatsache ist, das subprocess bei meinem Beispieldateinamen (mit u"\u2022") bei "iso-8859-1" einen Fehler wirft, daher meine Annahme (mit 'mbcs' oder eben sys.getfilesystemencoding funktioniert es).

Naja, vielleicht liegt es auch daran, dass ISO 8859-1 einfach kein "U+2022 BULLET" kennt. Warum sollte es auch?

[fhoech]

Aber Tatsache ist, das subprocess bei meinem Beispieldateinamen (mit u"\u2022") bei "iso-8859-1" einen Fehler wirft, daher meine Annahme (mit 'mbcs' oder eben sys.getfilesystemencoding funktioniert es).

Naja, vielleicht liegt es auch daran, dass ISO 8859-1 einfach kein "U+2022 BULLET" kennt. Warum sollte es auch?

Klar, das ist ja gerade der Knackpunkt

Edit: Ups, da hab ich ja tatsächlich Blödsinn geschrieben, sorry. Hast natürlich recht, nicht subprocess wirft den Fehler, sondern natürlich die encode()-Methode. Hab mich da nicht gut ausgedrückt. Worauf ich eigentlich hinaus wollte, ist, dass Dateinamen Zeichen enthalten können, die nicht in (z.B.) ISO 8859-1 vorkommen.