Hallo,

ich möchte per Shellskript in regelmäßigen Abständen im Hintergrund Dateien auf einen Webserver hochladen.
Dazu verwende ich SFTP. Nun habe ich aber Probleme mit Dateinamen, die Umlaute enthalten. Die Daten kommen auf dem Server immer irgendwie beschädigt an. Jedenfalls lassen sich die Dateien zum Beispiel nur noch per "rm *.pdf" löschen.

Verwende ich hingegen meinen Standard SFTP-Client Fetch zum Upload kommen die Daten einwandfrei an ... Die Dateien lassen sich auch ohne Probleme wieder löschen.

Hat jemand eine Idee was da schief läuft? Sowohl der Debian-Lenny-Server als auch mein Mac OS 10.6 arbeiten mit UTF-8.

Danke für Eure Ideen!

Grüße
Christian

1. Warum verwendest Du da überhaupt Umlaute? Auf die Idee, die Dateinamen VORHER einfach so umzubenennen, dass da weder Umlaute noch Sonderzeichen noch Leerzeichen drin enthalten sind, bist Du nicht gekommen?
Wenn die auf einem Webserver liegen sollen und dann später mit einem Browser abgerufen werden sollen -- Dir ist schon klar, dass auch das evtl. zu Problemen führen kann, weil der betreffende abrufende Browser damit evtl. nicht so zurandekommt (Stichwort: IDN und Punycode)?

2. Gib bitte mal ein genaues Beispiel, sowohl einen problemmachenden Dateinamen betreffend als auch die genaue Syntax, mit der Du das Ganze per sftp auf den Server schiebst...

Ich wollte das Skript so einfach wie möglich halten (und es muss doch möglich sein ... wenn Fetch das schafft ...). Deshalb werden die Dateien erst nach dem Upload und dem Einlesen in die Datenbank auf dem Webserver umbenannt. - Der Ursprüngliche Dateiname wird als Text für den Download-Link verwendet.

Ein entsprechender Dateiname ist z.B. töst.pdf

Mein Upload-Skript sieht so aus:

Die Frage, die sich gleich als zweites stellt ist: ist es denn -- genaz egal, ob nun technisch möglich oder nicht -- überhaupt und generell sinnvoll, hier überhaupt Umlaute zu verwenden bzw. zuzulassen?
Warum nicht einfach ganz generell solche Umlaute vermeiden bzw. vorher durch einen entsprechenden Zusatz im Script eliminieren und z.B. mittels egrep oder so ähnlich zuvor ersetzen?

Aha. OK. Na dann...

Ist sftp denn von Haus aus bzs. in der Mac-Implementierung überhaupt UTF-fähig? Wenn ich mir die Manpage dazu anschaue, dann finde ich erstmal keinen Hinweis darauf oder irgendeinen Schalter, der hier diesbzgl. drauf hinweisen könnte, dass man das ein- oder ausschalten oder sonstwie beeinflussen könnte... Oder ich hab's übersehen...

und wenn Du statt des sftp-Kommandos das deutlich mächtigere und mir viel mehr Konfigurationsmöglichkeiten ausgestattete curl-Kommando verwendest? Das kann sowohl download als auch upload und ebenfalls sftp bzw. SSH/SSL.
Lies Dir davon mal die Manpage durch ('man curl').

Und das Thema der Maskierung der Umlaute und Leerzeichen in den Dateinamen stünde dann ja in beiden Fällen evtl. da auch noch zur Verfügung... Eventuell. Ohne es jetzt tatsächlich weiter überdacht oder ausprobiert zu haben.

Tritt das Problem auch nach einem "scp /lokale/verzeichnis/*.pdf user@ip-adresse:./../entferntes/verzeichnis/" auf?

Also Leute, ich hab's. Vielen Dank für Eure Mithilfe.

Zunächst mal: es lag nicht an sftp. Bevor ich es damit versucht hatte, habe ich auch scp probiert, auch damit ohne Erfolg.
Eine Maskierung der Dateinamen mit sed funktionierte auch nicht. Die Umlaute wurde einfach nicht erkannt und entsprechend auch nicht ausgetauscht. Spätestens da dämmerte es mir, dass wohl Mac OS X schuld war. Irgendwann fand ich dann diesen netten Bericht hier:


Mac OS verwendet also mit NFD eine andere UTF-8-Version als andere Betriebssysteme, die auf NFC setzen (z.B. mein Debian). Man erkennt das aber nicht an den Dateinamen, was eine Lösung nicht gerade offensichtlich macht.

Anders als in dem Artikel beschrieben, ist das Problem aber durchaus lösbar. Es gibt nämlich mit Convmv ein Tool, mit dem man Dateinamen von UTF-8-NFD nach UTF-8-NFC konvertieren kann und umgekehrt. Weil das in der Anleitung nicht so recht rüberkommt hier der entsprechende Kommandozeilenbefehl, um alle Pdf-Dateien im Verzeichnis umzuformen:


Das nur, falls jemand anders mal das Problem haben sollte. Denn wie in dem Artikel oben beschrieben, entsteht das Problem ja nicht nur hier, sondern auch beim Datenaustausch mit Windows-Systemen.

Sowas ähnliches hatte ich im Sinn als ich oben schrieb:



Statt Convmv könntest Du übrigens auch iconv (Manpage dazu: 'man iconv' oder auch online hier: ) nehmen ("The iconv program converts text from one encoding to another encoding."). Das hat MacOSX von Haus aus an Bord, und das liegt unter /usr/bin/iconv.

Beispiel:

Zum Thema siehe auch bzw. .

Wo ist Kermit geblieben

http://de.wikipedia.org/wiki/Kermit

Urlaub