Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

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.

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

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.

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

Ich habe hier eindeutig Showstopper für UTF8 vorliegen und bin
daher bei ISO8859-1 geblieben.
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.

> > 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! :-)
 
ASCII kann durchaus Umlaute, die Leute haben das nicht vergessen,
sondern (wie bei einer Schreibmaschine) durch mehrfach-Anschläge
an einer Position umgesetzt.
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.
Die USA sind ein Einwanderungsland - die haben selber durchaus
mehr Bedarf.
Die Funktionalität ist erst durch Bildschirme verloren gegangen,
die einfach aus Hardwaregründen nicht mehrere Zeichen überlagert
ausgeben konnten.
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.
 
> > 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. :-)

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.

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

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.

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

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

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message