Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

On Mon, 17 Mar 2014 18:39:16 +0100 (CET), Oliver Fromme wrote:
> Polytropon <freebsd(at)edvax.de> wrote:
> > Ich denke mal, es geht um die Handhabbarkeit von Umlauten
> > in Dateinamen unter _widrigen_ Umständen - das sind jene,
> > mit denen man nicht rechnet, die man nicht bedenken mag
> > und von Anfang an wegdiskutiert, nur daß sie einem in
> > einem denkbar unwahrscheinlichen Fall doch plötzlich
> > auf die Füße fallen. :-)
>
> Das ist ausnahmsweise mal ein Fall, wo ich vollkommen nicht
> Deiner Meinung bin. :-)
>
> Dateinamen, die Umlaute enthalten, sind absolut problemlos
> zu handhaben. Ich (und meine Kollegen) arbeiten täglich mit
> sowas. Zu erzählen, es gäbe damit unter ominösen widrigen
> Umständen Probleme, ist nichts weiter als FUD.

Ich hatte ja aus purer Bosheit mal einen Fall zusammen-
konstruiert: Ein englisches Tastaturlayout erlaubt keine
Eingabe, ein unpassender Zeichensatz keine Ausgabe. Es
erscheint ein ? oder ein Klotz.

Lösung - denn es gibt _immer_ eine Lösung -: Verwendung
von Wildcards wie ? oder *. :-)

> Das Gegenteil
> ist der Fall: Wer sich angewöhnt, statt »ä« immer »ae« zu
> tippen, erzeugt damit Probleme, da dies eine verlustbehaftete
> Konvertierung ist, die zu Zweideutigkeiten führen kann und
> die nicht automatisiert rückgängig gemacht werden kann.

Natuerlich ist es verlustbehaftet und kann u. U. der
Eindeutigkeit schaden, z. B. bei Namen ("Andre Mueller" ist
etwas anderes als "André Müller"), aber es gibt Fälle, wo
das keine Rolle spielt. Die traditionelle Ersetzung, die
ich erwähnte, stammt noch aus Fernschreibzeiten, wo man
zusätzlich (und _das_ ist der Verlust, den Du hier als
Knackpunkt ansprichst) noch "(uml)" angeben mußte, wenn
ein "oe" als "ö" gelesen werden sollte.

Andererseits gibt es wenige, jedoch wohlbestimmte Worte,
wo "[aou]e" und "sz" als _richtige_ Schreibweise vorkommen,
so daß man annehmen kann, daß wenn dies nicht der Fall ist,
ein Umlaut vorliegt.

> Jedes mir bekannte gängige Tool, das mit Dateinamen hantiert,
> ist 8bit-clean. Ebenso jede übliche Shell. Wenn jemand
> trotzdem ein Problem hat, ist das nichts weiter als eine
> Folge einer Fehlkonfiguration, die behoben gehört (vermutlich
> LC_CTYPE nicht oder falsch gesetzt, siehe Handbook).

Unter FreeBSD können wir diese Angleichung ja schon seit
Jahren vornehmen. Unter X ist, wenn alle möglichen Schrift-
arten installiert sind, die Ausgabe kein Thema, auch die
Compose-Funktion der Tastatur erlaubt bedarfsweise Eingaben
wie L-Schrägstrich, A-Kreis oder C-Komma.

> Das
> ist maximal eine Ausrede, aber kein Argument.

Eine Ausrede _ist_ ein Argument, wenngleich nicht unbedingt
ein gutes und allanwendbares. :-)

> Und selbst, wenn man den Umlaut nicht eingeben kann, weil
> man eine unpassende Tastaturbelegung hat, dann tippt man halt
> stattdessen "?" und überlässt es dem Globbing der Shell.
> Oder man verwendet die Tab-Completion.

Genau dies ist ja eine Frage der Shell, ob die das so
macht, wie man will. Problematisch ist es z. B., wenn
man ein Archiv entpackt und 100 Dateien namens ????????.MP3
darin findet, d. h. nicht mal ansatzweise ein Unter-
scheidungsmerkmal gegeben ist.

> Die _einzige_ Stelle, wo man mit Umlauten aufpassen muss,
> ist, wenn mehrere verschiedene Betriebssysteme die Dateien im
> Zugriff haben, die unterschiedliche Kodierungen verwenden und
> nicht automatisch dazwischen konvertiert wird. Aber wenn man
> in so einer heterogenen Umgebung arbeitet, dann muss man sich
> mit dieser Thematik ohnehin auseinandersetzen und es einmal
> sinnvoll konfigurieren.

Und noch auf viele andere Sachen achten. :-)

> Ich habe z.B. mein Samba daheim so
> eingestellt, dass Umlaute, die per SMB von Windows-Kisten
> kommen, funktionieren und auch korrekt wieder per NFS an die
> anderen nicht-Windows-Rechner exportiert werden. Das ist
> keine Zauberei.

In diesem Kontext fand ich Deinen Hinweis auf noch ein
weiteres Codierungsverfahren ("Windows-1252") sinnvoll.

> > Man könnte auch sagen: Irgendwann hat mal jemand die
> > englische Sprache und damit den 7-Bit-ASCII-Zeichensatz
> > zum Maß aller Dinge in der Computerwelt bestimmt, also
> > sollte man es nicht wagen, da "mehr" zu wollen. :-)
>
> Nein. ASCII wurde vor genau 51 Jahren aus der Taufe gehoben,
> und zwar von einem US-amerikanischen Komitee.

Sage ich doch! Die USA, das Heimatland der Computer, die
wo man alles erfunden tun haben. Da hat sich gefälligst
jeder unterzuordnen! :-)

> Es war für
> Telegraphie-Zwecke in den USA gedacht, nicht mehr und nicht
> weniger.

Richtig, das sieht man, wenn man sich den Lochstreifen dazu
anschaut. EBCDIC ist - und hier treibe ich wieder böse Spiel-
chen mit der Geschichte - eh älter, heute aber "nur" in der
Großrechnerwelt von Bedeutung (also von wachsender). Ich
muß unglaublich als wirken... ;-)

> Sich heute immer noch auf US-ASCII einschränken zu wollen,
> ist ein sinnloser Anachronismus.

Sag das mal einem US-Amerikaner, dessen führendes Unternehmen
Marktführer in der Erbringung internationaler Dienstleistungen
im Marktsegment ist. :-)

> Wir leben in Deutschland,
> und zu unserer Sprache gehören Umlaute, und es gibt keinen
> Grund, warum man gezwungen sein sollte, darauf zu verzichten.

Die Frage ist nur: Wie codieren wir das? Als 1-Byte-Zeichen
mit ISO-8859-1 (oder -15, wenn wir das Euro-Zeichen dabei-
haben wollen, das ja mittlerweile lebensbestimmend ist),
oder als 2-Byte-Zeichen mit UTF-8, mit der Prämisse der
Umstellung auf UTF-16 in einigen Jahren?

> Die Russen verwenden auch munter kyrillische Zeichen und
> haben damit keine Probleme.

Das machen die aus purer Bosheit, weil ihre Schriftsprache
"zu weit entfernt" vom US-ASCII ist. :-)

Lustig wird es, wenn man z. B. Dateinamen konstruiert, die
zwar wie "normale deutsche" Dateinamen aussehen, aber andere
Zeichen benutzen. Dann erbringen Sortier- und Auswahlprogramme
schonmal andere Ergebnisse, als man erwarten würde. Das
liegt einfach daran, daß, obwohl Zeichen gleich aussehen,
sie für den Rechner doch andere Zeichen _sind_. Hier prallen
Mensch und Wirklichkeit aufeinander. :-)

> > [...] kannst Du Dir sicher vorstellen, was
> > für Probleme man konstruieren kann, wenn man sich
> > nur genug anstrengt. :-)
>
> Eben, das ist doch alles arg konstruiert.

Man weiß bekanntlich nie.

> Mit der gleichen Argumentation könnte man sich auch auf den
> Standpunkt stellen, dass man Groß- und Kleinschreibung in
> Dateinamen vermeiden sollte. Das könnte sonst unter widrigen
> Umständen auch mal zu Problemen führen. Schließlich gibt
> es Dateisysteme, die nicht zwischen Groß- und Kleinbuchstaben
> unterscheiden können, was zu Kollisionen führen kann.

Ja, und die Shift-Taste könnte auch klemmen bzw. nicht korrekt
übertragen werden. Aus aktuellem Anlaß: Brief1.DOC, brief1.DOC,
Brief 1.DOC, Brief 1(Kopie.DOC, Brief2.DOC usw. :-)

> Und
> am besten sollte man Dateinamen nicht länger als acht Zeichen
> plus drei Zeichen Suffix machen. Das könnte sonst unter
> widrigen Umständen ... Schließlich gibt es ... Genau.

Genau, gibt es, z. B. in MP3-Playern und "Smart TVs", da
habe ich solche Dinge schon bewundern dürfen. Alles ganz
tolle Produkte f?r den deutsc~1 Markt. :-)

Frage ist immer: Anwendung?

> > Bei Umlauten haben wir glücklicherweise die Situation,
> > daß wir sie recht angenehm durch "Standardzeichen"
> > umschreiben können (z. B. "ae" statt 'ä', "sz" statt
> > 'ß' usw.),
>
> Das nennst Du "recht angenehm"? Ich finde das furchtbar und
> völlig inakzeptabel.

Wie gesagt: Sollte man was _nicht_ so funktionieren, wie
es soll, kann man mit diesem Mittel noch immer relativ
gut suchen und finden. Dabei sehen Dateinamen natuerlich
nicht mehr so "schön" aus (Umlautkonvertierung, _ statt
Leerzeichen usw.), aber das müssen sie auch nicht.

> Übrigens, laut Duden wird "ß" mit "ss" umschrieben (nicht
> "sz"), wenn es aus technischen Gründen erforderlich ist.
> Früher war mal "sz" bei Zweideutigkeiten erlaubt, aber diese
> Ausnahmeregelung wurde abgeschafft, seit "ß" in Eigennamen
> auch als Großbuchstabe verwendet werden darf (R160 im Duden).

Der Duden ist eine Publikation eines privaten Wörterbuchverlags
und hat mit Urteil des BVerfG im Jahre 1997 jegliche authoritative
Wirkung verloren ("Fall des Duden-Monopols), ist daher nur ein
schwaches Argumentationsmittel. Es wurde also nichts abgeschafft,
es wird vom Duden-Verlag lediglich _empfohlen_, es nicht zu tun,
aber andere, genau so "maßgebende" Verlage und Hausorthographien,
die dieselbe Daseinsberechtigung haben, dürfen da durchaus auch
andere Vorschläge machen. :-)

Die Schreibweise "sz" statt "ß" stammt aus der Fernschreibzeit
und nutzt den Vorteil, daß es weniger Worte gibt, in denen "sz"
als _richtige_ Schreibweise vorkommt, als Worte mit "ss" an der
entsprechenden Stelle, z. B. "Busse" = "Busse" (Pl. von "Bus")
oder "Buße"; "Busze" ist hier eindeutig; "Auszeichnung" ist
auch eindeutig, da "Außeichnung" allenfalls nach "neuer Recht-
schreibung" als "richtig" gewertet werden würde. :-)

Übrigens: In der Schweiz hat man das Eszett selbst ab-
geschafft, hier wird ausschließlich "ss" geschrieben,
"Busse" und "Busse" unterscheiden sich nicht mehr in
der Schreibweise, sondern nur noch in der Aussprache,
was mal wieder zeigt, daß die deutsche Schriftsprache
keine Lautsprache ist. Verfechter der "Anlauttabelle"
bekommen jetzt einen Tobsuchtsanfall ("Topsutsannval"). :-)

Da das ß eine Ligatur von Lang-s und Rund-s ist und bei
Großschreibung zu diesen zerfällt (Darstellung: zwei "S",
da der Großbuchstabe S keine Land/Rund-Unterscheidung
kennt), ist seine Verwendung als Großbuchstabe durchaus
kritisch zu sehen, da es eine Ligatur und _kein_ Buchstabe
ist. In einigen Schriftarten erkennt man sogar noch die
vorgenannten Bestandteile dieses Zeichens.

Fazit: Programme und Menschen sollten durchaus mit allen
möglichen Sonderzeichen in Dateinamen (Umlaute, 'ß', '\n',
Shell- / Kommandozeichen, internationale Unicode-Zeichen)
klarkommen. Die Erfahrung, wann und wo das nicht paßt
oder nicht wunschgemäß funktioniert, muß wohl jeder
selbst machen. Je internationaler man wird (was auch
heißt: je mehr Wert man auf "Deutschigkeit" legt),
desto schwieriger und unpassender wird der Versuch,
Zeichen zu ersetzen. Die Ersetzung hat den Vorteil,
auch so gut wie jede Konvertierung zu "überleben"
(da keine stattfindet), nur kann die Interpretation
eben deutlich leiden, und dann leiden die Nutzer
dieser Dateinamen, was direkt auf den Sysadmin ab-
gestrahlt wird, wir alle kennen das. :-)

Addendum:

Von Joel Spolsky gibt es einen interessanten Artikel
zu diesem Thema:

http://www.joelonsoftware.com/articles/Unicode.html

Die beiden Artikel hinsichtlich der Shell-Geschichten
von D. Wheeler hatte ich ja schon beigesteuert. Wenn
man sich daran hält, sollte eigentlich von technischer
Seite her nichts schiefgehen.

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message