Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

Polytropon <freebsd(at)edvax.de> wrote:
> 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.

Wie wär's, wenn Du mal einen Fall nennst, der heutzutage in
der Praxis vorkommt, anstatt irgendwas zu konstruieren?

Bei jeden Betriebssystem, das ich in den letzten zehn Jahren
installiert habe, wird man bereits während der Installation
nach dem Locale gefragt. Da wählt man hierzulande natürlich
"Deutsch", was sonst? Manche Installer bieten US-ASCII gar
nicht mehr als Option an. Windows (und ich glaube auch MacOS)
benutzen intern ohnehin Unicode.

Ja, ich musste auch schon auf (Kunden-)Systemen arbeiten, wo
kein Locale konfiguriert war (die Leute dort hatten aber auch
keinen Bedarf für Dateinamen mit Umlauten). Das ist aber
wirklich eine selten anzutreffende Ausnahme, sogar in den USA
sind inzwischen die meisten Systeme Unicode-fähig.

Übrigens, ich persönlich beschränke mich bei Dateinamen auf
ISO 8859-15, gerne aber auch mit Leerzeichen, Umlauten usw.
(wie gesagt: es gibt keinen vernünftigen Grund, der dagegen
spricht). Das heißt aber nicht, dass ich nicht auch mit
UTF8-Dateinamen umgehen kann, wenn mir solche unterkommen.

Beim Inhalt (nicht Namen) von Textdateien verwende ich entweder
ISO 8859 oder UTF-8, je nach Einzelfall. Mein Editor macht
das in der Regel automatisch; Mails und Skripte z.B. werden in
ISO 8859 verfasst, bestimmte andere Dokumente dagegen in UTF-8
inkl. BOM.

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

Und ich dachte schon, es geht nicht mehr hässlicher.
Eindeutig ist das natürlich auch nicht, oder wie wird da der
Entertainer Bernhard Hoëcker kodiert, ohne dass man ihn mit
Höecker (oder gar Hoecker oder Höcker) verwechseln kann?
Entweder, es geht nicht, oder es sieht _noch_ schlimmer aus.

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

Hierzulande genügt es ja den meisten Leuten schon, wenn sie
Umlaute eingeben können (L-Schrägstrich oder was auch immer
ist gar nicht notwendig). Und das funktioniert praktisch
out-of-the-box.

> Genau dies ist ja eine Frage der Shell, ob die das so
> macht, wie man will.

Naja, sogar die krude csh/tcsh kann das.

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

Wenn man regulär mit Dateien hantieren muss, die ausschließlich
asiatische, kyrillische oder arabische Zeichen verwenden, dann
gehe ich davon aus, dass man die entsprechende Sprache spricht
und sein System auch passend eingerichtet hat, d.h. die Zeichen
sollten dann auch korrekt angezeigt werden. Wenn nicht, was
willst Du dann mit den Dateien, wenn Du ohnehin kein Russisch
(oder was auch immer) sprichst?

Und selbst wenn: Im Notfall numeriert man die Dateien durch
(auch dafür gibt es Tools), so dass dann da 001-???????.MP3,
002-???????.MP3 usw. stehen, und dann kannst Du an der Shell
"spielab 003-*.MP3" tippen.

Oder starte halt X und klick auf die Datei. Wie ich das letzte
Mal X "from scratch" installiert habe, wurden schon per Default
kyrillische, asiatische, arabische und diverse andere Schrift-
arten mitinstalliert.

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

Das ist im prinzip nichts weiter als eine Erweiterung von 8859-1.
Microsoft-typisch: Man nimmt sich einen Standard und dichtet
noch etwas dazu ...

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

Schonmal von einem gewissen Herrn Zuse gehört? Und nein, die
Z3 lief nicht mit US-ASCII.

Ja, ich habe Deinen Smiley gesehen. Aber ich finde nicht,
dass das Dahintersetzen eines Smileys es gestattet, jeden
beliebigen Unsinn zu schreiben. ;-)

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

Nö, die Standardisierungen von EBCDIC und ASCII sind ziemlich
genau gleich alt. Es ist nur einem Zufall zu verdanken, dass
IBM damals aufgrund von Lieferproblemen bei Hardwarekomponenten
EBCDIC statt ASCII wählte, obgleich IBM durchaus federführend
im ASCII-Komitee vertreten war.

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

Auf welches führende Unternehmen spielst Du jetzt an?
Microsoft kann es nicht sein; die sind ja schon längst auf
den Unicode-Zug aufgesprungen.

Aber schwarze Schafe, die technisch nicht auf der Höhe sind,
gibt es natürlich immer. Ich finde es auch total peinlich,
dass meine Bank bei Überweisungen (auch inländischen) die
Umlaute nach "ae" usw. konvertiert. So ein Pfusch hat im
21. Jahrhundert nichts mehr verloren. Nunja, bei Banken gibt
es noch viel mehr Pfusch, aber das würde jetzt zu weit führen ...

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

Im Idealfall sollte das vollkommen egal sein. Mein Text-Editor
erkennt auch automatisch, ob eine Datei in ISO 8859 oder UTF-8
kodiert ist. Das ist im Notfall auch dann möglich, wenn dies
nicht anhand von Metainformationen (BOM) kenntlich gemacht ist.

> oder als 2-Byte-Zeichen mit UTF-8, mit der Prämisse der
> Umstellung auf UTF-16 in einigen Jahren?

Warum sollte man für deutschsprachige Texte von UTF-8 auf UTF-16
umstellen wollen?

> Lustig wird es, wenn man z. B. Dateinamen konstruiert, die
> zwar wie "normale deutsche" Dateinamen aussehen, aber andere
> Zeichen benutzen.

Wenn man's drauf anlegt, kann man immer "böse Sachen" machen;
das geht in vielfältiger Weise auch schon mit US-ASCII.
Das ist aber kein Argument gegen die sinnvolle und korrekte
Verwendung von Zeichen, die über US-ASCII hinausgehen.

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

Nein, wenn man die Umlaute vermurkst, findet man eher nichts
mehr. Oder man findet zu viel.

> Dabei sehen Dateinamen natuerlich
> nicht mehr so "schön" aus (Umlautkonvertierung, _ statt
> Leerzeichen usw.), aber das müssen sie auch nicht.

Warum nicht? Ich schreibe anderen Usern nicht vor, wie sie
ihren Dateien benennen. Und unter Windows ist es vollkommen
üblich, Leerzeichen in Dateinamen zu verwenden. Kein Mensch
verwendet da Unterstriche. Die meisten haben auch keine
Hemmungen, die Umlauttasten zu verwenden, die sich auf ihrer
Tastatur befinden. Und das ist gut so.

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

Der Duden hat zwar keine eigene authoritative Macht, aber er
dokumentiert die Regeln der amtlichen Rechtschreibung, die vom
Rat für deutsche Rechtschreibung festgelegt werden. Ich habe
deswegen auf den Duden verwiesen, weil ihn die meisten daheim
im Regal stehen haben, im Gegensatz zum amtlichen Regelwerk.
Inhaltlich dürfte es weitgehend übereinstimmen.

> Die Schreibweise "sz" statt "ß" stammt aus der Fernschreibzeit

Nochmal: Wir leben im 21. Jahrhundert.

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

Es _war_ mal eine Ligatur. Heutzutage wird es aber weitgehend
als eigenständiger Buchstabe angesehen. Auch "w" war mal eine
Ligatur, ist allerdings noch etwas länger her.

Übrigens gibt es seit ein paar Jahren "ß" auch in Form eines
Großbuchstaben (Code 1E9E). Allerdings hat er noch keine
ausreichende Verbreitung gefunden; das amtliche Regelwerk
erlaubt weiterhin die Verwendung des kleinen "ß" in Kontexten,
wo Großbuchstaben verwendet werden. Es gibt aber bereits
diverse Normen für das große "ß", z.B. eine DIN-Norm, die
vorschreibt, wo es sich auf der Tastatur befindet.

Eine Shell interessiert sich für das ganze Zeug ohnehin nicht,
da keines dieser Zeichen eine spezielle Bedeutung für die
Shell haben. Jedes Shell-Skript sollte daher auch ohne
besondere Maßnahmen mit Dateinamen zurechtkommen, die Umlaute
oder andere nicht-ASCII-Zeichen enthalten, sofern es nicht
versucht, die Dateinamen zu interpretieren.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart
FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd
"The last good thing written in C was
Franz Schubert's Symphony number 9."
        -- Erwin Dieterich
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message