WebDAV - Zeichensatz

P

peterg

Aktives Mitglied
Thread Starter
Dabei seit
02.03.2005
Beiträge
3.116
Reaktionspunkte
396
Hallo,

der Zugriff auf den Speicherplatz bei HostEurope per WebDAV funktioniert nun grundsätzlich. So weit, so gut.

Merkwürdig nun das Verhalten: Kopiere ich Dateien/Verzeichnisse mit Umlauten auf den WebDAV-Server, so wird alles korrekt angezeigt. Lade ich sie per WebDAV wieder herunter ist auch alles wie erwartet. Bleibe ich in WebDAV, dann ist alles ok.

Wenn ich nun aber per ftp auf den Server zugreife, dann werden die entsprechenden Dateien/Verzeichnisse ganz merkwürdig angezeigt: die Umlaute werden durch andere Zeichen ersetzt. Ein gemischter Betrieb von WebDAV/ftp erscheint mir daher nur möglich zu sein, wenn ich in Kauf nehme, dass die Namen furchtbar "verhunzt" werden. Der Haken "Datei- und Ordnernamen kodieren und dekodieren" beim ftp-Client führt nun zu einem neuen dritten Format, das aber immerhin alle Zwecke erfüllt: beim Upload und Download per ftp sowie in der Anzeige und Download per WebDAV erscheint alles erwartungsgemäß. Nur die Anzeige im ftp-Client bleibt gewöhnungsbedürftig.

Die Option "Datei- und Ordnernamen kodieren und dekodieren" gibt es aber wohl nicht bei allen ftp-Clients, z.B. nicht bei FileZilla (oder ich habe es einfach nicht gefunden). Das Problem ist aber wohl WebDAV - das geht mit den Sonderzeichen anders um als ftp-Clients. Mein vorläufiges Fazit: ein gemischter Einsatz von WebDAV und ftp ist nicht sinnvoll, wenn man Umlaute und Sonderzeichen in Dateinamen nicht ausschließen will. Ist das korrekt oder gibt es irgendwo einen Haken, den man setzen kann?

Peter
 
Da viele Dienste im Internet immer noch (und möglicherweise aufgrund ihrer Historie unabänderlich) auf 7 Bit basieren, sollte m.E. auch heute noch wann immer möglich, die Disziplin gewahrt werden, bei Dateiennamen auf andere als ASCII-Zeichen zu verzichten – und die Namen nicht länger als 31 Zeichen (samt einzigen Punkt vor, und einschl. der Dateinamenerweiterung) werden zu lassen.

Die 31-Zeichen-Grenze sollte Mac-Anwendern aus dem klassischen MacOS bekannt vorkommen – von dem das WWW und http 1990 diese Begrenzung geerbt hatten.
 
Bei WebDAV werden Dateinamen URL-kodiert und mit einem HTTP PUT auf den Webserver übertragen.

Wie der lokal die Dateinamen im Filesystem abbildet spielt keine Rolle.
Er könnte das sogar in einer Datenbank und die Dateien würden durchnummeriert.

Das hat mit 7 Bit und Dateinamen und deren Länge nunmal gar nichts zu tun.
Er muss ja nicht den Finder als WebDAV client benutzen.
 
Hallo,

vielen Dank erst mal. Meine Recherchen im Netz haben das vorläufige Ergebnis gebracht, dass das Problem die UTF-8-Codierung im Dateisystem des Mac darstellt: Diakritische Zeichen werden "decomposed" gespeichert, d.h. ein ä wird ein a mit einem folgenden Zeichen für die Pünktchen. Windows und Linux verwenden aber "composed", d.h. ein ä wird als ä gespeichert. Der älteste Thread, den ich fand, stammte aus 2007 und dort wurde auf ein Modul der Implementation auf Seite des WebServers verwiesen.

Doch stimmt meine Schlussfolgerung: Entweder ich beschränke mich auf Datei- und Verzeichnisnamen ohne Umlaute und kann dann WebDAV und ftp nutzen oder ich beschränke mich auf WebDAV.

Nebenbei: Es gibt ungezählte Anleitungen, wie man WebDAV auf dem Mac nutzt. Doch mir ist bisher noch nirgends ein Hinweis auf ein Zeichensatz-Problem untergekommen.

Peter
 
Transmit z.B. von Panic Inc. oder etliche andere FTP-Tools, die vielfach auch auf WebDAV zugreifen können.
 
Hallo,

vielen Dank. ftp nutze ich nun schon seit vielen Jahren und natürlich weiß ich, dass viele ftp-Programme auch auf WebDAV-Server zugreifen können.

Vielleicht muss ich etwas zum Hintergrund sagen: Seit nun gut vier Jahren nutze ich eine DropBox. Dort haben sich fast 5 GB Daten angesammelt. Nun versuche ich, die Daten auf einen Server zu bekommen, der den deutschen Datenschutz-Bestimmungen unterliegt und dessen Anbieter für die deutsche Rechtsprechung auch erreichbar ist. Dieser Teil ist erledigt, die Daten sind umgezogen.

Jetzt möchte ich natürlich auch halbwegs komfortabel auf die Daten zugreifen können. Da hatte ich an WebDAV gedacht: Der Server ist im Finder wie ein ganz normales Laufwerk eingebunden und Werkzeuge wie FolderSynchronizer (faktisch ein grafisches Frontend für die mit Unix im Mac OS eingebauten Dienste) kann ich wie gewohnt anwenden. Außerdem kann ich im Bedarfsfall aus jedem Programm heraus auf die entfernten Daten zugreifen.

Das scheint nun so nicht zu funktionieren: die Umlaute in Datei- und Verzeichnisnamen werden nicht korrekt verarbeitet. Übrigens auch dann nicht, wenn ich mit CyberDuck per WebDAV auf den Server zugreife. ftp scheint mit allen mir bekannten Programmen zu funktionieren.

Also - auf den Komfort von WebDAV verzichten und wie gehabt mit ftp-Programmen arbeiten. Natürlich mit ftp mit TSL/SSL :cool:

Was mich tatsächlich ärgert: die vielen hundert Seiten zu WebDAV mit dem Mac verlieren nicht eine Silbe zum Problem. Das hat mich nun viele Stunden gekostet, auch wenn ich dabei viel gelernt habe.

Peter
 
Hast du in Cyberduck schon in den Einstellungen/Verbindung "UTF-8" für die Zeichenkodierung eingestellt?

Hast du auch schon mal deinen Hoster kontaktiert und das Problem geschildert? Eventuell muss da noch eine Einstellung am Server getätigt werden. Wenn das so ist, dann bist du dort nicht der erste mit dem Problem und die Leute wissen schon, wie man da Abhilfe schaffen kann.
 
Hallo,

der Stand der Dinge:

(1) Mac OS X verwendet im Dateisystem - im Gegensatz z.B. zu Windows oder Linux - zwar UTF-8-Codierung - aber „decomposed“, d.h. diakritische Zeichen wie „ä“ werden durch zwei Zeichen dargestellt (im Gegensatz zu „composed“, wo solche Zeichen durch das entsprechende Zeichen im Unicode-Zeichensatz dargestellt werden).

(2) WebDAV auf dem Mac konvertiert diese Zeichensätze nicht automatisch und eine solche Konversion ist in den entsprechenden Bibliotheken der Server auch nicht vorgesehen.

(3) Werden also Dateien und Verzeichnisse mit Umlauten über WebDAV mit dem Mac gespeichert, ist alles ok.

(4) Wird auf diese Dateien und Verzeichnisse dann aber mittels ftp zugegriffen, dann erscheinen diese Dateien und Verzeichnisse mit kryptischen Zeichen. Dateien und Verzeichnisse mit Umlauten, die über ftp auf den Server hochgeladen werden, sind unter WebDAV auf dem Mac unsichtbar. Werden sie über WebDAV noch einmal hochgeladen, sind sie auf dem Server zwei Mal gespeichert - einmal mit Umlauten (wie sie per ftp hochgeladen wurden) und ein weiteres Mal mit kryptischen Zeichen (wie per WebDAV hochgeladen wurden).

(5) Das Problem ist bekannt und kann in meinem Fall vom Betreiber des Servers (= HostEurope) nicht behoben werden.

(6) Wer also auf Daten auf einem entfernten Server mittels WebDAV und ftp zugreifen will, sollte die Zeichensatzfrage vorher genau testen. Die Beschreibungen der Server-Betreiber weisen auf das Problem normalerweise nicht hin. Inwieweit das Problem durch einen gemischten Betrieb von Windows, Linux und Mac OS verschärft wird, habe ich nicht geprüft.

Peter
 
Danke für die Erläuterungen. Ich schließe mich zu 95% an.
Gut erklärt ist das auch hier in diesem Beitrag:
http://de.wikipedia.org/wiki/Utf8


Es gibt aber auch noch die Mischformen und Abwandlungen von UTF-8 und UTF-32und Mischformen wie etwa UTF-16 Little Endian.
Das Hauptproblem an der Sache ist einfach, dass z.B. der WEBDAV-Server halt nicht weiss unter welchem OS der CLient läuft und es unterschiedliche Interpretationen gibt zum Codieren der Zeichen.

Theoretisch könnten alle mit UTF-8 oder gar UTF-32 arbeiten, aber das würde die gesamte IT deutlich verlangsamen und den Speicherbedarf von allem ziemlich nach oben pushen.
 
Dann muss ich wohl froh sein, dass ich mich damals gegen Hosteurope und für all-inkl entschieden habe. Die beschriebenen Probleme habe ich nämlich nicht. Es ist egal, ob ich Dateien per FTP (Cyberduck) oder WebDAV (Finder bzw. Cyberduck) hochlade, herunterlade, mir anzeigen lasse – die Umlaute in den Dateinamen werden immer korrekt angezeigt. Vielleicht macht es aber auch einen Unterschied, dass es sich in meinem Fall um eine OwnCloud handelt. Keine Ahnung, ob das eine Rolle spielt …
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten