Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

On Tue, Mar 18, 2014 at 01:56:29PM +0100, Polytropon wrote:
> 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.

Es ging sogar mal out of the box, sonst wäre ich nie drauf gekommen.
Erst später gab es mal Probleme und seit dem verlasse ich mich nicht
mehr auf die Einstellungen, sondern lese beim login meine xmodmap ein.
Ich benutze für X Deadkeys, also zwei Anschläge für Umlaute.
Da geht dann ohne langem suchen auch mehr, als so eine einfache Deutsche
Belegung hergibt, wobei man diese natürlich auch mit Deadkeys ergänzen
könnte.

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

Wem sagst du das.
Ich bekomme jedesmal einen Schreikrampf, wenn mal wieder eine
invoice.pdf als octet-Stream anhängt und mein mutt entsprechend
kein xpdf über Tempfile aufstartet.

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

Naja, aber die Notwendigkeit auf Umlaute zu verzichten ist halt
irgendwann in den 80'ern endgültig ausgestorben und selbst da
ging es nur um Ausnahmefälle.

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

Meine wesentlichen Showstopper sind nvi und syscons.
Inzwischen ist letzterer wohl nicht mehr das Problem und beim
nvi habe ich das nicht mehr groß verfolgt, aber erinnere mich an Ansätze.
Aber selbst wenn das jetzt alles geht, so habe ich hier doch auch noch
Systeme in meiner NFS-Umgebung, die das eindeutig nicht können.

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

Das ist recht einfach.
Erzeugt werden die vom xterm und angezeigt auch, d.h. die Einstellung
ist zwangsläufig identisch.

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

Ja, aber das ist auf echtenr UNIX-Hardware seltener ein Problem
gewesen.
PCs haben recht lange am Zeichausgabe festgehalten - Meine Sun3
Systeme der Baujahre 87 bis 88 booten mit Textausgabe im Grafikmode.
Und das ist inzwischen auch auf normaler Hardware der Standard.
Grafik braucht halt mehr RAM, aber inzwischen sind die Geräte,
die deswegen auf Grafik verzichten mussten nahezu ausgestorben und
der Hardware-Textmode oftmals nicht mal mehr umgesetzt.

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

Leider hat sich die Bildröhre zerlegt - habe ich noch nie gesehen sowas,
aber das Glas hat den Jahren nicht stand gehalten.

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

Neh, das kann nur passieren, wenn man es zumindest versucht.
Die haben was jenseits der Umlaute verbockt.

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

Da ist zumindest das Encoding sauber geregelt.

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

Naja - mein TeX versteht sowohl UTF-8, als auch LATIN1, je nach
Bedarf.

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

Besonders spassig, wenn ein und die selbe Serversoftware internationale
User bedienen muss.

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

Wenn man konsequent ist bleibt man bei Papier.
Aber man will ja nicht auf der Stelle stehen bleiben.

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