Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

On Tue, 18 Mar 2014 13:19:13 +0100, Bernd Walter wrote:
> On Tue, Mar 18, 2014 at 08:16:24AM +0100, Polytropon wrote:
> > 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.
>
> Ich arbeite hier mit einer US-Tastatur unter X.
> Die Eingabe von Umlauten ist kein Problem.

Out of the box schon, mit entsprechender Konfiguration
(z. B. xmodmap) ist es aber sehr einfach.

> > > 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.
>
> Als Jemand, der in Moers wohnt (ja das schreibt sich oe) und
> dessen Großeltern Drüen (ja, da kommt ein e hinter dem ü)
> hiesen, kenne ich verdammt viele Spielarten dieses Datenverlustes.

Das sind sehr gute Beispiele. Der historische Göethe hätte
da auch gut gepaßt. :-)

Aber um genau das zu vermeiden, ist die Option "(uml)" im
Fernschreibverkehr angegeben worden, z. B.

        herr drueen (uml) aus moers

Bei mehreren Umlauten wäre "(uml)" dann auch mehrfach anzu-
geben gewesen.

> > 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.
>
> Unsere Umlaute und die eine Ligatur sind noch handlich.
> Aus der Praxis kann ich aber sagen, dass man keine deutsche
> Sprache annehmen kann.
> Es gibt da durchaus den verständlichen Anwendungsfall, dass
> jemand einen Brief schreibt und den Namen des Empfängers mit in
> den Dateinamen setzen möchte.

Oder Anhänge an Bewerbungsschreiben, die nicht einfach
"bewerbung.pdf" heißen, sondern den Namen des Bewerbers
beinhalten, also Noël-André von Čzerwýnski-Müller. :-)

> Selbst wenn das ein deutschsprachiger Brief ist kann der
> Familienname des Empfängers non-ASCII beinhalten und da gibt
> es auch Fälle, die nicht mal mehr LATIN1 sind.
> Du hast ja selber schon einen Namen als Beispiel gegeben.

Richtig, und hier hat man dann lediglich die Option,
die "Haken" und "Punkte" an Zeichen fallenzulassen,
was sich aber dann wieder rächt, wenn man über Datei-
namen sucht und den _korrekten_ Namen der Person als
Suchmuster verwendet.

Wie man's auch macht, ist es falsch. :-)

> Ich habe hier eindeutig Showstopper für UTF8 vorliegen und bin
> daher bei ISO8859-1 geblieben.

Also genau das Gegenteil von Olivers Empfehlung. Man
kann sagen: Solange man nur "weitgehend deutsch" bleibt,
sollte ISO8859-1 ausreichen, aber sobald man mit Leuten
kommuniziert, die UTF-8 verwenden (also _beide_ Parteien
kommunizieren "irgendwie deutsch"), gehen die Probleme
los, A-Tile ein Viertel oder Klotz Klotz. Derartige
Probleme sieht man meist nicht bei E-Mails, aber sehr
schnell bei gemeinsam bearbeiteten Dokumenten oder
im IRC.

> Das grundsätzliche Problem in einer UNIX-Umgebung ist, dass
> man das nur extrem schwer unterschiedlich handhaben kann.
> Ich habe hier einen Shell-alias auf 8859-1 vs UTF8 und kann im
> xterm leicht im Kontextmenü die Ausgabe umschalten, aber voll-
> ständig mit UTF8 arbeiten kann ich nicht und der Wechsel nervt.
> Das Problem fängt ja schon an, wenn man per ssh auf einen anderen
> Rechner wechselt.

Problematisch ist sicher auch, was passiert, wenn Du
zum Beispiel ein "Ö" verwenden willst: Wird dann eine
1-Byte- oder 2-Byte-Sequenz erzeugt? Und werden sowohl
das 1-Byte-"Ö" als auch das 2-Byte-"Ö" ordnungsgemäß
angezeigt? Und: Kann man sie noch voneinander unter-
scheiden?

> > > > 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! :-)
>
> ASCII kann durchaus Umlaute, die Leute haben das nicht vergessen,
> sondern (wie bei einer Schreibmaschine) durch mehrfach-Anschläge
> an einer Position umgesetzt.

Die 8-Bit-Erweiterung beinhaltet ja Umlaute, neben anderen
Zeichen wie dem Yen oder dem Pfund. Nur ist hier wieder der
Knackpunkt, daß der Bildschirmzeichensatz da mitmachen muß.

Mehrfachanschläge sind übrigens ein typisches Mittel der
Generierung von "Befehlszeichen" unter APL. Furchtbar, wie
alt ich jetzt wirken muß! :-)

> Deshalb gibt es sowohl Backspace als auch Delete und das ist
> nicht zufällig 0x7f, sondern so gewählt, dass man durch nach-
> trägliches Stanzen aller Löcher in Lochkarten ein Zeichen
> invalidieren kann.

Backspace, "Rückschritt", setzt den Cursor zunächst mal ja
nur ein Zeichen zurück, das geht auch ohne Überschreiben.
Auf klassischen druckenden Terminals konnte man da nichts
machen - das Zeichen stand ja schon auf dem Papier. Aber
nun konnte man noch ein weiteres Zeichen drüberdrucken
und so ein Kombi-Zeichen erzeugen. Um nochmal auf APL
zurückzukommen: Bildschirmterminals mit APL-Zeichensatz
emulieren diese Funktionsweise, indem sie die "Kombina-
tionszeichen" darstellen können und die Rückschritt-
Funktion diese "altbackene" Bedeutung beibehält.

> Die USA sind ein Einwanderungsland - die haben selber durchaus
> mehr Bedarf.

Die haben ihre Einwanderer schon schön erzogen, daß da
keine Begehrlichkeiten nach korrekter Darstellung von
Namen kommen. :-)

Dazu vielleicht noch ein kleiner Exkurs:

http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

Aber selbst in "deutscher Markensoftware" sieht das nicht
viel besser aus. :-)

> Ich habe hier ein ADM3 Terminal stehen, welches vollständig ohne
> CPU auskommt und als Bildschirmspeicher, je nach Modell, nur
> 6-bit oder 7-bit pro Zeichen speichert.
> Der Zeichenspeicher mit den Bitmap-ROMs ist dann auch entsprechend
> nur für 64 oder 128-Zeichen bestückt.

Das ist ja ein richtiger Hingucker! Ich selbst kann nur mit
einem langweiligen dec VT101 dienen. :-)

> Das ist aber letzlich deren Problem.
> Digikey macht z.B. auch gerne Namen zu Großbuchstaben.
> Bekomme ich jedes mal zu viel bei, aber immerhin kommt sowas noch
> an.
> Es da gab es bei anderen US-Firmen gar noch schlimmere Sachen, wo
> Anschriften zwischen Auftragsbestätigung und Versandanschrift
> verstümmelt wurden, sodass es mich gewundert hat, dass überhaupt
> noch was angekommen ist.
> Ich traue mich daher nicht bei einer bestimmten großen Firma noch
> mal was zu bestellen.

Du meinst die SCHLATILDEFRACTERSTRASSE in Berlin?
Das war doch irgendwie eine Mischung von UTF-8 nach
ISO-8859-1 nach HTML und hin und zurück... :-)

> Unsere Umlaute in Unicode sind durchaus ein Problem.
> Es gibt unser 'ä' im LATIN1 Bereich als 0x000000e4, was auch
> üblicherweise benutzt wird.
> Aber Unicode hat das Überschreiben in Form von kombinatorischen
> Zeichen wieder eingeführt und so gibt es noch eine zweite (und
> zwar die normalisierte!) Kodierung von 'ä' als Punkte über Zeichen
> plus 'a', nämlich 0x0000030b + 0x00000061.
> Zum Glück ist mir die zweite Variante bislang noch nie in der
> Praxis begegnet.

Da auch Umlaute in URLs zulässig sind, ist die Spielwiese
der Spitzbuben eröffnet. :-)

Unter LaTeX sind die Ersetzungsschreibweise \"{a} und deren
Kurzform "a eine Implementierung dieser Idee, nur daß dafür
eben kein zusätzliches Zeichen erforderlich ist. Will oder
muß man in internationalem Kontext mit beschränkten Mitteln
arbeiten, ist das z. B. eine Möglichkeit. Andererseits
bieten Tastaturen wie die von Sun mit der Compose-Taste
eine bequeme Möglichkeit, "ä" als "Compose : a" einzugeben.
Die verwendete Bildschirmschriftart erlaubt dann die
korrekte Anzeige des Zeichens. (Hinweis: Beide Fälle kenne
ich noch aus realem Kontext.)

> > > 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. :-)
>
> Die Sortierfolge ist eh Sprachabhängig.

Und daher immer wieder für eine Überraschung gut. Auch
hier ein Beispiel: Das Sortierprogramm läuft unter einer
anderen $LANG-Einstellung als man denkt, die Ergebnisse
sind "durcheinander". (Etwas derartiges habe ich mal in
den Innereien eines "Web-Service" gesehen.)

> > > > 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.
>
> Ich kann aus persönlicher Erfahrung sagen, dass das Suchen in
> so einem Mischmasch aus Umlaute (weil man es haben will) und
> Ersatzzeichen, weil man externe Datenquellen dabei hat, ein
> echter Graus ist.

Ja, konsequent sein sollte man mit der getroffenen Entscheidung
schon. Man muß sich darauf verlassen können, daß "Müller" und
"Mueller" zwei verschiedene Namen sind, nicht "versehentlich"
zwei Schreibweisen ein und desselben Namens. "Doppelte Daten-
haltung" rückt damit in greifbare Nähe...

-- 
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