Re: Umlaute und andere Sonderzeichen in Dateinamen konvertieren?

On Tue, 18 Mar 2014 17:19:51 +0100 (CET), Oliver Fromme wrote:
> 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?

Praxis - das ist ein gutes Stichwort! Mir ist vor ein paar
Jahren mal Arztpraxis-Software untergekommen, wo man zwar
Umlaute in Namen eingeben konnte, dieser bei jeglichen
Druckausgaben aber fehlten. Herr "Jrg Mller" mußte also
als "Joerg Mueller" eingegeben werden.

Ein anderes Beispiel ist ein Programm aus dem Bereich der
Buchhaltung, in welches man Dateien, die Umlaute beinhalten,
nicht importieren konnte; änderte man sie, ging es.

Beide Programme waren "Windows"-Programme.

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

Wie ursprünglich gesagt: Das Dateisystem macht alles mit.
Es ist also vorrangig eine Frage der persönlichen Präferenz
und möglicherweise von durch Dritte festgelegte Rahmen-
bedingungen, keine technische Limitierung.

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

Wie hast Du das konfiguriert + welcher Editor ist es, daß
das so reibungslos funktioniert?

Für mich war das bisher immer eine Entweder-Oder-Situation,
d. h. entweder läuft die Sitzung als ISO-8859-15, dann sind
Umlaute mit 1 Byte codiert und werden so angezeigt, während,
je nach Programm und Terminal, 2-Byte-Zeichen entweder
angezeigt oder als Ersetzung dargestellt werden (im
schlimmsten Fall als Klotz, hängt aber wie gesagt vom
jeweiligen Problemprogramm ab). Oder die Sitzung läuft
im UTF-8-Modus, dann ist die Darstellung der 1-Byte-Zeichen
kaputt, aber UTF-8-Zeichen können problemlos eingegeben und
angezeigt werden...

Der "Königsweg" würde mich ier mal interessieren, also
quasi "maximale Kompatibilität" ohne Umschalten.

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

Es ist _extrem_ häßlich, aber praktisch bei widrigsten
Umständen und furchtbar begrenzten Möglichkeiten.

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

Ich vermute, es geht nur durch eine grausame Ersetzungs-
schreibweise wie Ho"ecker oder Ho:ecker, aber dem muß
wieder eine _separate_ Konvention zugrundeliegen. Oder
man läßt die Punkte weg und schreibt "Hoecker", damit ein
überschlaues Programm "Höcker" daraus macht. :-)

> > Genau dies ist ja eine Frage der Shell, ob die das so
> > macht, wie man will.
>
> Naja, sogar die krude csh/tcsh kann das.

Plus daß zur deutlichen Darstellung auch das Terminal noch
mitmachen sollte. :-)

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

Chinesische Musik vom chinesischen MP3-Player. Hören.
Nur sind die ID3-Tags auch mit ?????? gefüllt gewesen,
so daß da auch kein Informationsgehalt... :-)

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

Und dann schreibt ein "Experte" ein Programm und nennt darin
diesen Zeichensatz "ANSI" - im obigen Beispiel der 2. Fall. :-)

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

Ja, ich bin alt genug, um den zu kennen. :-)

> Und nein, die
> Z3 lief nicht mit US-ASCII.

Nein, die lief mit zerlöchertem Filmstreifen. :-)

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

Ach schade, ich dachte nur. Jedenfalls hast Du den Unsinn
zweifelsfrei als solchen erkannt. Das ist heute keine
Selbstverständlichkeit mehr.

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

EBCDIC und ASCII sind ja nicht die einzigen Codierungs-
varianten, aber mit Sicherheit die prominentesten, die
es außerdem bis heute noch gibt.

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

Meines Wissens ist das eine Folge der SEPA-Umstellung.
Bei den alten (nationalen) Überweisungen war es möglich,
Umlaute zu codieren, aber nur in Großbuchstaben. Mit
SEPA gibt es jetzt Kleinbuchstaben, aber keine Umlaute
mehr. Das nennt man dann "europäisch", weil es die Sprach-
vielfalt bei internationalen Überweisungen stützt. :-)

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

Warum sollte man für deutschsprachige Texte von ISO-8859-1 oder -15
auf UTF-8 umstellen wollen? Weil... wenn man typographische
Zeichen wie Ellipse, Halbgeviertstrich, Anführungszeichen
oben und unten oder Ligaturen mit einbacken will, und das
direkt im Textverarbeitungsprogramm oder Editor, dann
reicht das nicht aus. Daß etwas nicht ausreicht ist der
Motor der Weiterentwicklung und Veränderung, daher
denke ich, daß bis zur Ankunft von UTF-64 noch ein
paar Jahre bleiben, dann aber... :-)

> > 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 geht sogar nett mit HTML-E-Mails und Spielereien
mit der Auswahl der "richtigen" Schriftart, wo "I",
"l" und "1" schön gleich aussehen...

> Das ist aber kein Argument gegen die sinnvolle und korrekte
> Verwendung von Zeichen, die über US-ASCII hinausgehen.

Sinnvoll und korrekt - da stimme ich völlig zu. Die
Realität zeigt aber immer wieder durch besonders "schöne"
Beispiele, daß das auch nach hinten losgehen kann. Alles
weitere erfährst Du in der Schlatildefracterstrasse in
Berlin. :-)

> Und unter Windows ist es vollkommen
> üblich, Leerzeichen in Dateinamen zu verwenden.

Das war schon bei der Amiga möglich, wenn ich mich da
noch richtig erinnere...

> Kein Mensch
> verwendet da Unterstriche.

Selbst wenn - moderne MP3-Player-Programme (und sogar
alte wie XMMS) ersetzen bei der Anzeige die Unterstriche
durch Leerzeichen.

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

Das tut er nicht mehr. Er gibt vielmehr die Empfehlungen
des Duden-Verlags (als einer von vielen, neben Bertelsmann
und anderen) wieder. Die amtlichen Regeln finden sich
lediglich noch in den "historischen Dokumenten" aus der
Zeit von ca. 1996, als das Bundesverfassungsgericht das
bekannte Urteil fällte, welches de facto die "Rechtschreib-
reform" (korrekt: Reformen) für null und nichtig erklärte.
Nach den amtlichen (!) Regeln schreibt niemand. Außerdem
treffen die _Länder_ die Festlegungen, was richtig ist,
nicht der mittelgalaktische Kunstklaubeirat, in welchem
die Funktionäre der Verlage sitzen, die jedes Jahr neue
Wörterbücher verkaufen wollen. Ansonsten ist hier das
"maßgebliche Gremium" die KMK. Für den Bund gilt die
Fassung von kurz vor 2000, in den Bundesländern kann
eine abweichende, neuere Version möglich sein. Verbindlich
für "normale Menschen" ist nichts davon, und die, für die
es gelten sollte, scheren sich nicht drum - also ist
es vom "Regelcharakter" her vollkommen egal. Jeder
wie er mag.

Glüglicher Weise kahn jetz ja, Jeder schreim wie er vil
es giept da keyne Rägel`n mehr andi Mann sich hallten
mu's. :-)

> Ich habe
> deswegen auf den Duden verwiesen, weil ihn die meisten daheim
> im Regal stehen haben, im Gegensatz zum amtlichen Regelwerk.

Dabei ist es auch wichtig, welche _Ausgabe_ es ist, da
diese sich sehr stark widersprechen bzw. unterscheiden,
sowohl vom amtlichen Regelwerk als auch von sich selbst
untereinander. Duden ist also nicht gleich Duden! :-)

> Inhaltlich dürfte es weitgehend übereinstimmen.

Nach genauer Lektüre würdest Du dies widerlegt finden,
und zwar stärker, je mehr Du in der Auflagennummer
voranschreitest. Auch wirst Du feststellen, daß Schreiben
von Behörden, die eigentlich in der amtlichen Schreibung
verfaßt sein sollten, dies typischerweise nicht sind.
Regionale Abweichungen machen die Sache noch spannender.

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

Das darf man so sehen. Dann ist die Frage, wieviele Buchstaben
das deutsche Alphabet hat, aber mit "27" zu beantworten (oder
mit "30", wenn man die Umlaute auch als Buchstaben ansieht).
Mit UTF-8 ist jedenfalls die Zuordnung Buchstabe <-> Zeichen
nicht mehr 1:1 möglich (z. B. "ffl"-Ligatur als 3 Buchstaben,
ligatuiert, aber 1 Zeichen im Datenstrom, 2 Byte lang). Wenn
dieses Konzept programmseitig korrekt umgesetzt wird, ist
das unproblematisch. Die Frage ist nur: Ist das so? Das
muß die Realität im Einzelfall zeigen.

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