[solved] Umlaute bei Dateinamen in ZIP Archiven (aus Windows

Wenn ich unter Windows Dateien mit Umlauten im Namen zippe und diese dann unter SUSE 10.1 mit unzip entpacke, sind die Umlaute in den Dateinamen merkwürdigerweise komplett verschwunden oder durch irgendwelche Sonderzeichen ersetzt.
Wie kann ich mir da behelfen und zips entpacken ohne Umlaute zu verlieren? Gibt es dafür einer bestimmte unzip Option?
Konnte leider keine Lösung finden. Freue mich über jede Idee.

Grüße,
Bernd

Dass die Umlaute unter Linux nicht dargestellt werden können liegt daran, dass Linux Dateinamen standardmäßig in UTF-8 kodiert ablegt, während dein Windows wahrscheinlich ISO-8859-1 verwendet.
Probiere für die entpackten Dateien mal
aus. Wenn dir das den richtigen Dateinamen zurückgibt, kannst du mit der zusätzlichen Option --notest den Dateinamen ändern.

Am besten erst gar nicht sowas unschönes wie Umlaute, Leerzeichen usw in die Dateinamen aufnehmen. Macht das Leben mit verschiedenen Zeichensätzen wesentlich einfacher.

Aber nur, bis alle UTF-8 gefunden haben ;-) Dann kann man doch _endlich_ froh sein, dass man auch みかちゃん im Dateinamen haben kann, so wie das heute schon der Fall mit /usr/X11R6/lib/X11/fonts/truetype/みかちゃん.ttf ist.

Hehe... Bis alle UTF-8 gefunden haben brauchen wir keine Umlaute mehr. Dann ist ohnehin Englisch die Weltsprache...

Was aber nicht heisst, dass Chinesich außen vor bleibt: Link :-D

Der Tipp von Odyszeus mit "convmv -f iso-8859-1 -t utf-8 dateiname" klang sehr vielversprechend leider löst sich das Problem dadurch nicht.

Folgendes Szenario:
1. ich erstelle unter Windows eine MP3-datei mit dem Namen "Umlauteäüödavor.mp3" und zippe diese nun: "Umlauteäüödavor.zip"
2. dieses zip-ARchiv kopiere ich dann auf mein Suse 10.1 System. Auch dort finde ich nun die Datei mit Umlauten als "Umlauteäüödavor.zip" vor. nach dem "unzip -d ..." entsteht nun jedoch eine Datei, die in der bash als
"Umlaute???davor.mp3" angezeigt wird (in Nautilus werden die Stellen, an denen eigentlich Umlaute sind einfach komplett weggelassen: "Umlautedavor.mp3")
3. wende ich nun "convmv -f iso-8859-1 -t utf-8 Umlaute???davor.mp3" an ergibt sich die
Ausgabe:
d.h. die Umlaute bleiben verschwunden bzw. werden durch komische Zeichen ersetzt. Wo liegt mein Fehler?

Da ist wohl im Verständnis schief gelaufen: Unter 8859-1 gibt es keine Umlaute, von daher kann das Programm auch nichts konvertieren. Unter Windows wird meistens ein "western windows-1252" verwendet.
Unter SuSE ist es soweit ich weiß Standard, dass Unicode verwendet wird, zumindest war es ab der 8er so eingestellt und man mußte sich ganz schön verrenken um das zu ändern.

Also brauchst Du mutmaßlich einen Konvertierer der 1252 im utf-8 wandelt. Google mal danach.

Geier0815 schrieb:

Unter 8859-1 gibt es keine Umlaute

Zum Vergrößern anklicken....

Unter ISO-8859-1 gibt es sehr wohl Umlaute. Was es nicht gibt ist das EUR Zeichen.

Geier0815 schrieb:

Also brauchst Du mutmaßlich einen Konvertierer der 1252 im utf-8 wandelt. Google mal danach.

Zum Vergrößern anklicken....

tut es auch
Also falls die Dateinamen in Codepage 1252 kodiert sind, dann hilft

macht aus den "???" korrekt "äüö". Allerdings hab ich nun noch Probleme mit Punkten im Dateinamen. Der convmv Befehl bricht dann immer mit
ab. Anführungszeichen ("") um den Dateinamen haben hier leider nicht geholfen. Gibt es hierfür auch eine Lösung?

ohrobot schrieb:

Allerdings hab ich nun noch Probleme mit Punkten im Dateinamen. Der convmv Befehl bricht dann immer mit

Code:

bash: !...-_: event not found

ab. Anführungszeichen ("") um den Dateinamen haben hier leider nicht geholfen. Gibt es hierfür auch eine Lösung?

Zum Vergrößern anklicken....

Wie genau sieht denn dieser Dateiname aus? Ich hab das grade mal getestet, und ein Problem mit Punkten ist mir nicht aufgefallen. Mein Windows verwendet zwar Codepage 1252 (eine Microsoftvariante von ISO-8859-1), aber der Punkt als ASCII-Zeichen ist eigentlich in allen mir bekannten Zeichensätzen an der gleichen Position untergebracht, muss also gar nicht umkodiert werden.

Einfache Hochkommata verwenden! (')

Ich habe nun einige Tests mit verschiedenen Dateinamen gemacht. Das Problem ist, dass ich immer noch keine Handhabe gefunden habe, alle möglichen Dateien einheitlich mit einem Befehl nach ISO 8859-1 zu konvertieren. Mal benötige ich Hochkommas (etwa bei Dateinamen mit "!" oder natürlich Leerzeichen), während bei Dateinamen, in denen ursrprügnlich Umlaute vorkamen (angezeigt wird vor der Konvertierung ja nur "?" als Platzhalter) ein Konvertieren mit convmv nur stattfindet, wenn der Dateiname nicht in Hochkommas steht. Das finde ich sehr merkwürdig!

Dazu folgende Testfälle mit Ausgaben:

zu konvertierende Datei: "Datei!Ausrufezeichen!.mp3" angegeben mit Hochkomma (=> funktioniert)

zu konvertierende Datei: "Dateimit???Umlauten.mp3" (unter Windows: DateimitäüöUmlauten.mp3) angegeben mit Hochkomma => Fehler

angegeben ohne Hochkomma => kein Fehler - exakte Ausgabe (inkl. der merkwürdigen Verschiebungen):

Die Frage ist nun wieso kann ich nicht für alle Fälle normale Hochkommas verwenden bzw. gibt es eine Schreibweise mit der ich gegen beide Eventualitäten gewappnet bin?

Vielen vielen Dank soweit..vielleicht klappts ja bald. eine Idee?

schöne Grüße,
Bernd

Leg doch einfach alle Dateien in einen Ordner, und mach dann Solange deine Dateien nicht mit einem Punkt anfangen, sollte das gehen. Und wenn du Dateien mit einem Punkt am Anfang hast (was allerdings nicht besonders sinnvoll wäre), kannst du danach ja nochmal drüberlaufen lassen.

Mal 'ne ganz doofe Frage am Rande: Warum konvertierst Du nicht schon unter Windows? Frag mich nicht nach Werkzeugen dafür, aber ich vermute das ein Teil der Probleme daher kommt das der Zeichensatz erst in die "fremde" Umgebung gebracht wird und dann geändert werden soll. Ansonsten würde ich an deiner Stelle erstmal versuchen rauszufinden in welchem Zeichensatz das Ganze unter Windows geschrieben wurde, irgendwie klingen deine ganzen Versuche danach als wenn Du nicht den richtigen Ausgangszeichensatz verwenden würdest.

Odyszeus - you're THE MAN ... das ist genau das, was ich gesucht hab. Danke! aber auch danke an alle anderen, die sich mit dem Problem befasst haben.