Umlaute – ein ewiges Problem

Titelgrafik

Wie ich schon im Artikel vor ein paar Tagen angekündigt hatte, möchte ich mich heute ein wenig über den SSH-Zugriff auf den Mac auslassen. Da ich ja lange Zeit das Problem hatte, bei Samba-Dateitransfers Datenverlust zu erleiden, habe ich irgendwann einmal begonnen, auf SSH/SCP zurück zu greifen. Für dieses Protokoll existieren zahllose Clients (Cyberduck, FileZilla, …), es ist schnell, verschlüsselt die Übertragung und ist sehr weit verbreitet.

Um den SSH-Zugriff auf Mac OS X zu ermöglichen, wählt man in den Systemeinstellungen den Punkt »Sharing« und aktiviert dort die »Entfernte Anmeldung«. Damit sind für den Zugriff eigentlich schon alle Wege geebnet. Die Transfers laufen verhältnismäßig schnell und problemlos ab und insgesamt war ich von dieser Lösung sehr angetan. SSH-Server und Clients gibt es ja sowieso für jedes Betriebssystem, also muss es nicht unbedingt Samba sein.

Doch eines Tages ist mir unter Windows XP und FileZilla etwas aufgefallen. Ich hatte mit Dateien zu tun, die Umlaute im Dateinamen haben. Ja ich weiß, das ist etwas böses aber in Zeiten von Unicode und Konsorten sollte man davon ausgehen können, dass auch so etwas funktioniert. Das tut es im Grunde auch, aber es gibt da trotzdem eine Kleinigkeit, bei der man aufpassen sollte. Um das Ganze zu veranschaulichen, habe ich das jetzt noch einmal nachgestellt.

Dateien mit Umlauten auf dem Schreibtisch

Auf dem Schreibtisch meines Macs liegen die im Bild zu sehenden Ordner, die alle irgendwelche Umlaute und Sonderzeichen im Namen haben. Bei einem Zugriff von Windows via SSH sieht das Ganze dann wie folgt aus. Werft einmal einen genauen Blick auf die Umlaute bzw. die Position der Punkte darüber.

FileZilla zeigt seltsame Umlaute

Seht ihr es? Mir ist erst nach unzähligen Dateiübertragungen aufgefallen, dass die Umlaut-Punkte nicht genau über den Buchstaben sitzen. Doch das, was ich zunächst nur für einen Darstellungsfehler hielt, machte doch etwas mehr Probleme. Dateien, die ich vom Mac auf den PC kopiert hatte, konnten von einigen Programmen nicht geöffnet werden, wenn ein Umlaut im Namen war. Ein weiterer genauer Blick zeigte mir, dass auch im Explorer die Punkte nicht exakt über den Buchstaben sind. Sehen wir uns die fraglichen Ordner mal in der Eingabeaufforderung an.

Eingabeaufforderung zeigt diakritische Zeichen extra an

Plötzlich sind die Diakritika nicht mehr »ein bisschen daneben« sondern stehen als eigener Buchstabe da. Ich hielt das zunächst für ein nur Windows betreffendes Problem. Gerüchteweise kommt das ja des öfteren einmal vor, dass sich Microsoft irgendwo nicht an die Standards hält und … ach lassen wir das. Werfen wir lieber einen Blick auf Linux, in diesem Fall Ubuntu 9.10 – wie sieht die Sache dort aus?

Korrekte Darstellung im Nautilus

Im Nautilus-Dateimanager werden die Umlaute der Dateien, die auf meinem Mac lagern, problemlos angezeigt. Interessant! Da aber die Mutter der Dateiverwaltung unter Linux noch immer Textkonsole heißt, musste ich natürlich auch diese Variante ausprobieren. Und siehe da, wieder Probleme mit den Umlauten.

Gnome Terminal mit Umlautproblemen

Der erste Aufruf von »ls« zeigt anstelle jedes diakritischen Zeichens zwei Fragezeichen an. Beim zweiten Befehl erzwinge ich das Ausgeben der Escape-Sequenzen der »nicht druckbaren Zeichen« und bekomme die nackten Zeichencodes zu Gesicht. Alles höchst interessant. Was ist, wenn wir jetzt am Mac »ssh localhost« ins Terminal tippen?

SSH-Verbindung auf Localhost

Es präsentiert sich dasselbe Bild wie unter Ubuntu. Allerdings liegt das mit Sicherheit nicht am Terminal selbst, weil wenn ich lokal ein »ls« ausführe, zeigt er alles ganz korrekt an.

Korrekte Ansicht der Umlaute im Terminal

Heißt das, dass Mac OS X nicht zu sich selbst kompatibel ist? Nach längerer Recherche im Internet bin ich dann auf die Ursache des Rätsels gestoßen. Und anscheinend können Client bzw. Server von SSH nicht korrekt mit den Verschiedenen System zur Umlaut-Speicherung umgehen.

Eigentlich alle modernen Betriebssysteme unterstützen UTF8 in Datei- und Ordnernamen. Allerdings gibt es zwei grundlegend verschiedene Ansätze, wie man Umlaute sehen kann. Die eine Fraktion sieht Umlaute als eigenständige Zeichen, während die zweite Fraktion der Meinung ist, dass ein »Ö« nicht mehr ist, als ein »O« mit zwei Punkten.

Für jede dieser Fraktionen bietet Unicode bzw. UTF8 beim Speichern von Zeichen Möglichkeiten. UTF8-NFC (»Composed«) speichert Umlaute als ein einzelnes Zeichen ab. Die zweite Variante nennt sich UTF8-NFD (»Decomposed«), wo Basisbuchstabe und Diakritika getrennt gespeichert werden, also den Speicherplatz von zwei Buchstaben belegen.

Die aktuelle Situation ist, dass Mac OS X bei der Speicherung auf UTF8-NFD setzt, welches die Umlaute als eigene Buchstaben behandelt. Und die anderen beiden großen Systeme? Richtig, Windows und Linux verwenden anscheinend UTF8-NFC, wo Umlaute eigene Zeichen sind. Soweit zur Theorie dahinter.

Lösung? Ja, das ist ein guter Punkt! Die beste Lösung ist vermutlich, in gemischten Umgebungen einfach auf Umlaute in Dateinamen zu verzichten. Es erscheint zwar nicht angenehm und für das dritte Jahrtausend alles andere als zeitgemäß, aber es vermeidet viele potentielle Probleme. Solange man eine Datei nur einmal kopiert, mag das egal sein.

Wenn man allerdings Dateien öfter hin und her kopiert, ist am Schluss der Dateiname nicht mehr der Originale. Nicht nur für den Benutzer verwirrend, kann das auch Backupprogramme ein wenig bei ihrer Arbeit behindern (Stichwort: »inkrementelle Backups«). Ach ja, das wollte ich noch erwähnen: Für gewisse Programme, beispielsweise das populäre rsync, existieren speziell gepatchte Versionen, die UTF8-NFC in UTF8-NFD und umgekehrt während des Kopierens konvertiert.

Fazit: Auch, wenn einem oft suggeriert wird, dass man heutzutage bedenkenlos überall Umlaute und Sonderzeichen verwenden kann, sollte man trotzdem ein wenig auf der Hut sein. Jedes Betriebssystem handhabt diese Zeichen anders. Außerdem sind die nicht erlaubten Zeichen in Dateinamen auch auf jedem System andere.

Siehe auch:
http://en.wikipedia.org/wiki/UTF-8

4 Kommentare Schreibe einen Kommentar

  1. Hallo Christoph,

    vielen Dank, auch wenn Du keine Lösung (oder sollte ich schreiben Loesung) für dieses Problem gefunden hast, sind die Ursachen klasse recherchiert.

    Und das kann ja dem ein oder anderen helfen einen Weg zu finden.

    Beste Grüße

  2. Sehr interessant, danke! Interessant wäre jetzt natürlich noch eine Diskussion, wer denn da nachbessern sollte: Löst man dieses Problem im sshd oder in darauf aufsetzenden Programmen?

    Ich werde mal suchen, ob es brauchbare Workarounds gibt. Eine der angenehmsten Seiten von MacOS war für mich immer, dass es sich “wie ein normales UNIX” verhält, aber diese Codierungsgeschichte ist schon ein Stolperstein…

  3. Die Frage, wer nachbessern sollte, ist durchaus interessant. Das Problem ist, dass keiner der Ansätze zur Codierung von Umlauten falsch ist – es sind lediglich zwei verschiedene.

    Wie erwähnt gibt es eine gepatchte Version von rsynch, die damit umgehen kann. Auch bei Samba-Freigaben aus Mac OS X heraus werden die Umlaute korrekt übertragen. Also Lösungsansätze gibt es ebenfalls auf “beiden Seiten”.

    Für Tipps bezüglich brauchbarer Workarounds bin ich natürlich immer dankbar. :)

Hinterlasse eine Antwort


Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>