Wer Unicode und UTF erfunden hat, gehört erschlagen
Nichts als Ärger mit Mehrdeutigkeit.
Als Security-Mensch habe ich schon immer über Unicode bzw. UTF-8 geflucht. Wer das erfunden hat, gehört wirklich geprügelt und geschlagen. Es ist mir unverständlich, wie man einen solchen Bockmist erfinden kann.
Unicode bzw. die UTF-Codierungen sind nämlich nicht eindeutig. UTF-8 ist so gebaut, daß die normalen ASCII-Zeichen 0 bis 127 normal als ein Byte dargestellt werden, und Zeichen die größere Unicode-Zahlen haben, mit mehren Bytes dargestellt werden, die dann in den oberen Bits ein Erkennungsmerkmal für die Art der Codierung und in den unteren Bits eben ein paar Bits der u codierenden Zahl des Zeichens tragen. So weit, so gut. Das hätte man auch eindeutig machen können, indem man die Codierung in zwei Bytes erst für die Zeichen ab 128 zulässt, mit drei Byte entsprechend höher. Man hat es aber so konstruiert, daß man jedes Zeichen auch mit mehr Bytes als eigentlich nötig codieren kann, woraus sich Mehrdeutigkeiten ergeben. Will man beispielsweise aus einer Zeichenkette Zeichen, die man nicht haben will, filtern oder erkennen (beispielsweise um aus Zeichenketten wie Nachnamen etwas wie ‘ herauszufiltern um SQL-Injection usw. zu vermeiden), reicht es nicht, den einfachen ASCII-Zeichencode 0x27 zu suchen, weil das über die UTF-Codierung auch anders codiert sein könnte. Man muß also erst mal das ganze Ding normalisieren. Häufiges Einfallstor, gerne gebaute Sicherheitslücke. Dabei völlig überflüssig, man hätte das einfach nur eindeutig codieren müssen.
Aber nicht nur in der Codierung der Zeichen an sich, auch in den Zeichentabellen gibt es Mehrdeutigkeiten übler Sorte (und dazu noch Steuerzeichen, die den Zeichenfluß ändern und dazu zu weiteren Sicherheitsproblemen führen). Man kann zusammengesetzte Zeichen wie die deutschen Umlaute (oder alles andere, was irgendwelche Punkte, Akzente, Schnörkel oder was auch immer drauf hat, oder allgemein gesagt aus einem bestehenden Buchstaben und irgendeiner zusätzlichen Verzierung gebaut ist) nämlich auf zwei Weisen darstellen. Nämlich einmal direkt über seinen normalen Zeichencode, und dann als zusammengesetztes Zeichen, erst das normale Zeichen ohne die Verzierung und dann nachträglich die Verzierung dazu. Oder anders gesagt: Man kann ein ä entweder direkt als ä oder aber als a mit nachfolgendem Zeichen für die zwei Punkte darstellen. Herrliches Sicherheitsloch für homograph-Attacken. Nur hatte ich im Normalbetrieb noch nie Probleme mit Kollisionen.
Nun hatte ich zum ersten Mal welche.
Ich habe gerade was (für mich extrem selten) unter Mac OS X zu tun. Und deshalb Arbeitsverzeichnisse zwischen Linux und dem Mac hin und hersynchronisiert, mit meinem Lieblingstool für solche Sachen, Unison (genial, sehr empfehlenswert).
Dabei bin ich gleich auf die Schnauze geflogen, denn Unison hat das gleich mal verweigert. Weil ich im Linux-Verzeichnis Dateien hatte, die bis auf die Groß- und Kleinschreibung den gleichen Namen hatten (also wie Test und Test). Das Dateisystem von Mac OS X ist aber case insensitive, das heißt, daß beide Dateien auf dem Mac auf die gleiche Datei abgebildet werden. Glücklicherweise erkennt Unison das, und warnt einen wenigstens bzw. weigert sich einfach.
Nun ist mir aber noch was anderes dummes aufgefallen:
Habe ich ich auf Linux eine Datei mit Umlauten im Namen, wie z. B. Täst , dann synchronisiert Unison das ohne weiteres vom Linux auf den Mac. Beim nächsten Aufruf von Unison will Unison sie aber vom Mac wieder zurück auf Linux synchronisieren, und zwar als neue Datei! Obwohl sie auf dem Linux-System definitiv existiert.
Gibt man dem Ansinnen (absichtlich oder versehentlich) nach, hat man hinterher auf dem Linux-System zwei Dateien gleichen Namens, also zweimal Täst. Wie kommt das jetzt? Wie können zwei Dateien mit gleichem Namen entstehen? (Also nix mit Leerzeichen hinten dran oder so.)
Des Rätsels Lösung: In den beiden Dateinamen ist das ä unterschiedlich codiert. Im einen Namen ist es so codiert, wie fast alle System das so machen, nämlich mit hex c3 a4 , was eben die UTF-8 codierte Unicode-Ordnungszahl des ä ist. In der anderen Datei ist es aber mit 61 cc 88 codiert, was einem kleine a und dem Code für das nachträgliche Anbringen von Tüpfelchen entspricht. Obwohl die Dateinamen exakt gleich aussehen (und sogar im Gegensatz zu etwa den bekannten homograph-Attacken mit geborgten kyrillischen Zeichen) wirklich die gleichen Zeichen auf dem Bildschirm sind (und nicht nur wie die kyrillischen gleich aussehen), sind es aus technischer Sicht unterschiedliche Dateinamen. Nimmt man noch die Mehrdeutigkeit der UTF-8-Codierungen hinzu, mit der man also jedes der Zeichen auf verschiedene Weisen codieren kann, kann man eine riesige Zahl von Dateien erzeugen, die alle den Dateinamen Täst haben, obwohl es ihn nur einmal geben dürfte.
An welcher Stelle des Hin- und Herkopierens hat sich nun aber diese Variante gebildet?
Machen wir einen einfachen Test unter Mac OS X:
echo -n ä | xxd 0000000: c3a4 ..
Die normale Tastatureingabe verwendet also das normale ä (zumindest wenn man so wie ich gerade eine gewöhnliche PC-Tastatur und eine aus dem Internet geholte Tastaturbelegung verwendet, womöglich ist das mit einer echten Mac-Tastatur anders, bitte mal irgendwer testen, der sowas hat).
Gehe ich aber über das Dateisystem, dann sieht das anders aus:
touch ä ; ls -1 |xxd 0000000: 61cc 880a a...
Das heißt, daß das Dateisystem (das mich schon nervte, weil es case-insensitive ist) hier auch noch die Namen umkodiert, also genau in diese Schreibweise a mit nachlaufenden Tüpfelchen.
Die Datei sieht zwar dann aus wie ä, technisch gesehen heißt sie aber anders.
Übel, übel. Das schreit geradezu nach irgendwelchen fiesen Angriffen.
Apple sollte man also auch gleich noch in den Hintern treten.
44 Kommentare (RSS-Feed)
@HF: Quatsch! Was hat das alles damit zu tun, daß die Codierungen mehrdeutig sind? Mehrdeutige Codierungen hätte es nie geben dürfen, und das hat mit C-Strings und Unix überhaupt nichts zu tun. War ja sowieso nicht rückwärtskompatible. Man hätte das ohne weiteres auch alles eindeutig codieren können.
Und ja, die (nullterminierten) C-Strings soll der Kuckuck holen. Eine enorme Fehlkonstruktion. Wurde kürzlich irgendwo zu einer der folgenreichsten Fehlentscheidungen gekürt.
Ohne Rob Pike und die Erfindung von UTF-8 wären
C-Strings und Unix jetzt Geschichte.
Willst Du das?
UTF-8 selbst ist m.E. eher harmlos, der Witz ist doch gerade,
dass es C- und Ascii- kompatibel ist. Die von Dir beschriebenen
Komplikationen entstehen auch erst dadurch, dass jede Lasagne-Schicht
meint, selber umcodieren zu müssen. Dazu zählt leider auch Schicht 8 beim Betrachten der Bildschirmausgabe.
P.S. Eine Unix-Datei mit einem nicht minimal codierten ‘/’ irritiert
zwar bein Anschauen auf einem schlecht programmierten Terminalprogramm, aber die Tab-Expansion oder Cut&Paste funktionieren.
Wenn, ja wenn, sie nicht versuchen, zu schlau zu sein.
P.P.S: Die Codierung ist Ordnungserhaltend. strcmp() ist der lexikografische Vergleich der Unicodes.
Vielleicht muß man auch welche aus dem Linux-Umfeld erschlagen oder in den Hintern treten, dafür, daß sie Dateinamen nicht normalisieren.
@georgi: Das hast Du falsch verstanden. Linux normalisiert die Dateinamen nicht, sondern läßt sie unverändert (d.h. die gängigen Linux-Dateisysteme). MacOS ist hier der, der sie verändert. Und zwar falsch herum.
Denn die Normalisierung würde in Richtung des normalcodierten ä und nicht bezüglich der Kombination aus a und ” erfolgen.
Generell sollten Dateinamen insbesondere keine andere Kodierung verwenden als die Konsole.
Es ist ein Fehler, wenn man eine Datei unter dem Namen X anlegt und sie dann unter dem Namen Y auftaucht. Das funktioniert unter MacOS nur, weil da die Dateinamen (ähnlich wie bei Windows) nicht eindeutig sind (vgl. Groß- und Kleinschreibung). Das aber ist ein ganz übler Mist. Wenn nämlich das Programm dann nicht erneut nach dem Dateinamen X sucht (und aufgrund des Dateisystems erfolg hat) sondern wie hier das Verzeichnis auflistet und darin X nicht findet, geht’s schief.
darüber bin ich auch schon gestolpert, und zwar bei der gemeinsamen Erstellung von LaTeX Dokumenten. Auf dem Mac wird das als zwei Zeichen gespeichert, aber mein Tool auf Windows interpretiert es eben als zwei Zeichen, und macht dann was anderes draus. Tierisch nervig sowas.
Ich sehe jetzt nicht wo OSX da etwas falsch macht, im Gegenteil. Es ist eindeutig definiert, daß Dateinamen decomposed abgespeichert werden. Aus Nutzersicht ist es auch logisch, daß Dateinamen, die ich durch Lesen am Bildschirm nicht voneinander unterscheiden kann, auch die gleiche Datei referenzieren (kyrillische Buchstaben ignoriere ich jetzt mal).
Ich kann (will) als User nämlich gerade nicht darüber nachdenken, ob ich ein ‘Ä’ im Dateinamen als ‘Ä’ oder als ‘A mit Pünktchen’ eingeben muß um eine bestimmte Datei zu referenzieren.
Bitte wo soll das definiert sein?
Erstens ist es meines Erachtens fehlerhaft, wenn sich das Dateisystem um die Zeichensätze kümmert, weil die vom Environment des Prozesses abhängen und das Dateisystem Kernel-Sache ist.
Zweitens ist meines Wissens die Normalform immer die kürzestmögliche Codierung, und die ist nun mal das ä in zwei und nicht in drei Byte zu speichern.
Drittens ist es unsinnig, wenn beim Auflisten der Datei eine andere Codierung verwendet wird als auf der Konsole. Ich folge Dir ja darin, daß es für den Benutzer verwirrend ist, wenn gleiche Namen nicht auf gleiche Dateien liefen. Das heißt aber nicht, daß beim Lesen eines Directories eine andere als die kürzeste Datei zu verwenden ist. Das von dir gebrachte Argument, daß der Benutzer nicht unterscheiden will sagt erstens nur, daß eine Normalisierung stattfindet und nicht, was die Normalform ist. Zweitens sollten diese Normalisierung das Anwendungsprogramm und nicht das Dateisystem betreiben, denn der User sitzt ja vor dem Programm und nudelt nicht per Maschinensprache auf der Betriebssystemschnittstelle herum.
@Michael: Davon ganz abgesehen argumentierst Du am eigentlich Problem völlig vorbei.
Denn mein Standpunkt ist ja, daß die Codierung in Unicode/UTF eindeutig sein müßte. Und dann gäbe es solche Probleme und die Normalisierung erst gar nicht.
Kann man so einen Fehler im Nachhinein eigentlich beseitigen?
Zumindest hört es sich für mich theoretisch so an, als ob man nur die Doppelcodierung aus der UTF-8-Definition heraus nehmen müßte.
Wie groß wäre der Aufwand?
Bzw., wer hätte ein Interesse daran, die gegenwärtige Definition beizubehalten?
Ich glaube, das bekommt man nicht mehr eingefangen. Viel zu teuer, zu fehleranfällig, zu viele Leute, die man überzeugen müßte.
Als ich mich mit dem Thema Unicode beschäftigt habe, habe ich mich auch nur an den Kopf gefasst, wie man ein einfache Sache so kompliziert kann. Es gibt ja noch UTF-32. Ich wünschte das hätte sich als UTF-Standard durchgesetzt. Ein Zeichen, vier Byte, keine Probleme. Gut dann gäbe es keine Abwärtskompatibilität zu ASCII. Oder doch? In dem die höchsten drei Byte einfach 0 wären? Keine Ahnung, ob man das irgendwie hinbekommen hätte. Aber egal. Dann wäre man eben eine Weile zweigleisig gefahren. Alte Zöpfe usw.
Und ich hätte noch verpflichten die BOM gemacht. Es gibt ja UTF-8 mit und ohne BOM. Wie oft hatte ich schon UTF-8 Dokumente mit BOM für den Browser erstellt, wo der dann gestreikt oder den BOM mit als Formatierung interpretiert hatte.
Nun, Sie plädieren ja völlig zu Recht immer wieder dafür, daß man z.B. erst mal eine sichere Programmiersprache benötigt, um sichere Betriebssysteme zu schaffen, daß es eigentlich keinen Sinn hat, an den gegenwärtigen Systemen herumzudoktern, und daß die Politik endlich genügend Geld in solche Entwicklungen investieren sollte.
Nur wenn man offenbar nicht einmal in der Lage ist, so ein vergleichsweise doch recht einfaches Problem in den Griff zu bekommen, dann haben doch all die Klagen keinen Sinn.
Wir werden nie ein sicheres System haben und sollten uns mit der Realität abfinden. Oder?
@kryptart: Erstens heißt abfinden ja nicht, zu schweigen. Zweitens sollte man auch auf Fehler hinweisen, die nicht wieder geradezubiegen sind, damit man sie wenigstens nicht nochmal macht.
Außerdem bringt es nichts, dazu nichts mehr zu sagen, weil es eben auch irgendwo ein Sicherheitsloch ist, das man einfach kennen sollte. Also muß man es erwähnen.
Das von Dir beschriebene Probleme hat mich auch enorm genervt. Das Problem scheint aber noch komplexer zu sein. Eine Zeitlang gabe bei mir nämlich dieses Problem unter Schneeleopard/Ubuntu überhaupt nicht, est nach dem Einspielen eines Serviceupdates von Apple trat das Problem auf. Anders ausgedrückt, es muß einen Schalter geben, bin dem aber bisher nicht weiter nachgegangen.
Dein sync tool heißt bestimmt “unison” und nicht “union”, oder?
@anonym: GRRRR! Ja, es heißt unison.
Diesmal war’s kein Vertipper von mir. Ich hab zum ersten mal einen Blog-Artikel von einem Mac aus geschrieben und dieser Sch…-Safari-Browser will ständig hinter mir herkorrigieren und ändert ständig, was ich schreibe. Der ändert auch Unison in Union. So ein Mist…
Die Mehrdeutigkeit der UTF-8 Codierung besteht nur theoretisch. Alle Codierungen mit mehr Bytes als nötig sind nämlich nicht erlaubt und eine vernünftige Implementierung eines UTF-8 Parsers sollte sie zurückweisen. Das Problem ist also wie so oft nur Schlampigkeit.
Und auch was die alternative Darstellungen von Umlauten mittels “combining diacritical marks” angeht: man kann das sauber implementieren. Mal ein Beispiel aus meiner Praxis:
mysql>select hex(‘Ä’);
+———–+
| hex(‘Ä’) |
+———–+
| C384 |
+———–+
— ok, mein Terminal spricht also utf8
mysql>select _utf8 0xC384;
+————–+
| _utf8 0xC384 |
+————–+
| Ä |
+————–+
— der UTF-8 Parser funktioniert
mysql>select _utf8 0xE08384;
ERROR 1300 (HY000): Invalid utf8 character string: ‘E08384’
— das war eine unzulässige 3-Byte Sequenz für das ‘Ä’
mysql>select _utf8 0x41CC88;
+—————-+
| _utf8 0x41CC88 |
+—————-+
| Ä |
+—————-+
— hier das ‘Ä’ mal als Kombination aus A und Pünktchen
mysql>select _utf8 0xC384 = _utf8 0x41CC88;
+——————————-+
| _utf8 0xC384 = _utf8 0x41CC88 |
+——————————-+
| 0 |
+——————————-+
— hmm, die default Collation erkennt die Gleichheit nicht
mysql>select _utf8 0xC384 = _utf8 0x41CC88 collate utf8_unicode_ci;
+——————————————————-+
| _utf8 0xC384 = _utf8 0x41CC88 collate utf8_unicode_ci |
+——————————————————-+
| 1 |
+——————————————————-+
— aber wenn ich Unicode-Vergleich verlange, dann funktioniert es
@Arno: Jau, kann man alles programmieren. Müßte man aber nicht, wenn es vernünftig (und eindeutig) gemacht wäre.
Außerdem kann man nicht unterstellen, daß Angreifer vernünftig implementieren, weil deren Ziel es ist, gerade die Ausnahmen auszunutzen.
UTF-8 Löst ein Problem: Abwärtskompatibles encoding beliebiger Strings. Es hat zwar d???????????????????????????????i???????????????????????v?????????????????????????e?????????????????r????????????????????????????????????????s????????????????????????????????e?????????????????? ?????????????????????P??????????????????r????????????????o???????????????????????????b??????????????????????????l??????????????????????????????????e?????????????????????????????????m?????????????????????????????????e???????????????????????????,????????????????????????????????????, aber wenigstens weiß ich, wnen ich eine E-Mail UTF-8-Codiere, kann sie im grunde jeder lesen, selbiges gilt für Webseiten.
In Dateinamen würde ich mir übrigens mal ein Tool wünschen, das sie automatisch in Quoted Printable oder HTML-Escape-Sequences umwandelt. Mich nerven Sonderzeichen in Dateinamen nämlich.
@uxul: Ja, da gibt’s noch so Zeug wie Spiegelschrift und all so’n Kram. Was man auch für Sicherheitsangriffe ausnutzen kann, indem man etwa Angaben aus dem Bildschirm raus verlegt.
Auch nicht zu verachten sind die surrogate pairs!
Hast du mal das “unicode” flag getestet?
http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html
@anonym: Ich hatte extra ne alte Unison-Version verwendet, weil das mit Ubuntu 10.04 LTS synchronisieren soll und da läuft noch die 2.27. Angeblich kommt die 2.40 mit Unicode klar und da müßte das Problem gelöst sein.
Aber es zeigt halt so fiese Stolperfallen auf, insofern war’s ganz gut, darauf aufmerksam geworden zu sein.
Natürlich muß man auf Fehler hinweisen, aber worauf ich hinaus will, ist: Glauben Sie als Informatiker mit langjähriger Praxis eigentlich überhaupt noch daran, daß es jemals ein sicheres Betriebssystem geben wird, oder haben Sie zumindest eine gewisse Hoffnung, das es eines irgendwann geben könnte, wenn man es denn nur wirklich wollte?
Ansich ist die Idee, dass man Zeichen sich “zusammenbasteln” kann doch toll.
Damit erreicht man auf einfache weise eine hohe flexibilität.
Und vermutlich würde jemand, der des Deutschen nicht mächtig ist, aber irgendwo sieht, dass er ein A mit zwei Punkten braucht, auch genau das tun. – Ein A nehmen und zwei Punkte dazumalen.
Ich sehe das auch als Eindeutig an:
Das eine ist Ä und das andere ein A mit zwei Punkten.
Völlig unbegreiflich ist mir, wie _irgendeine_ Popelanwendung diese Zeichen eigenmächtig umübersetzt.
Die Sicherheitsaspekte, die dadurch entstehen, dass ein Ä eben ähnlich aussieht, wie ein A mit zwei Punkten gibt es zwar, aber diese zu finden wäre meiner Ansicht nach Aufgabe im Userspace.
Edit:
Hm, ich sehe gerade, dass ich teilweise am Thema vorbei bin.
Du schreibst Eingangs, dass manche Zeichen verschiedenartig kodiert werden können, das ist ganz klar ein Designfehler.
(Also Zeichen gleich sind und nicht nur gleich aussehen – aber verschiedene kodierungen haben können)
@Alex: Im Artikel steht die Befehlskette “touch ä ; ls -1 |xxd” und daraus resultierend ein komischer Unicode-Dateiname. Daraus meine ich entnehmen zu können, dass nicht das Sync-Tool die Zeichen komisch codiert, sondern MacOS.
Interessant ist, warum die Apfelogeten das so machen: http://jace.zaiki.in/2009/10/14/unicode-precomposition-and-decomposition
@Carsten: Stimmt, macht das MacOS. Aber wenn ich die Webseite von unison richtig verstehe, können neuere Programmversionen das trotzdem so normalisieren, daß sie merken, daß es trotz unterschiedlicher Codierungen derselbe Dateiname ist. Da aber an der ganzen Synchroniererei noch ein Ubuntu 10.04 LTS beteiligt ist, muß ich noch die alte Version von unison einsetzen, die das noch nicht konnte. Nur so ist mir das Problem aufgefallen.
@Carsten
“Völlig unbegreiflich ist mir, wie _irgendeine_ Popelanwendung diese Zeichen eigenmächtig umübersetzt.”
Ja, mir ist unbegreiflich, wieso mac das irgendwie übersetzt
Und das “Argument” weil damit die Suchroutine eben genannter “Popelanwendung” besser läuft lasse ich nicht gelten.
Sollen die Ihre Suchroutinen ordentlich Programmieren.
Dass “e” und “é” in einer sloppy suche ähnlich sein sollen, hat nunmal einfach nichts mit der Zeichensatzkodierung zu tun.
@Alex: Ja! Weil die Suchreihenfolge ja mit Alphabet und Klang zu tun hat, während die Codierung über a und Tüpfelchen sich am optischen Aussehen orientiert, also nicht per se die Sortierreihenfolge unterstützt.
Ziel meiner Kritik war aber weniger das MacOS , sondern die mehrdeutige Codierung in Unicode/UTF.
@Alex: Nur weil die bei Apple immer alles ein bisschen anders machen, als man es mit gesundem Menschenverstand erwarten würde, macht es erstmal anders, aber nicht per se schlechter. Wenn Du sowas als Popelanwendung bezeichnen und dagegen wettern willst, dann wünsche ich Dir viel Spaß beim Kampf gegen die Windmühlen. 🙂
Der Link war eigentlich nicht als Argument gedacht. Ich wollte nur rausfinden, wieso jemand eine so abstruse Codierung verwenden wollen könnte – und dachte, dass der Grund vielleicht auch andere hier interessiert.
@Michael: “Ich sehe jetzt nicht wo OSX da etwas falsch macht, im Gegenteil. Es ist eindeutig definiert, daß Dateinamen decomposed abgespeichert werden.”
Das ist ein Problem. IMHO ist es eine große Überraschung für den Nutzer, wenn er denn tatsächlich genauen Einfluss auf seinen Dateinamen nehmen will, dass das OS diesen Eigenmächtig verändert. Programme sollten nicht ohne Wissen und Einverständnis des Nutzers Daten verändern.
Möglicherweise wollten die MacOS-X-Programmierer aber verhindern, dass gleichaussehende Dateien mit unterschiedlicher Kodierung existieren können, aber …
@Hadmut: Ich sehe nicht als Problem, dass Unicode die Codierung verschiedener Zeichen die gleich aussehen erlaubt. Ein Beispiel hierfür ist das russische ‘s’ (geschrieben ‘?’), welcher wie der lateinische Buchstabe ‘c’ aussieht. Ich möchte nicht, dass diese den gleichen Unicode-Codepoint bekommen, denn semantisch sind sie etwas verschiedenes.
Wo ich Dir zustimmen kann, ist dass es keine Möglichkeit zum Verschmelzen von Zeichen geben sollte. Wenn man ‘ö’ einbaut (und das ist gut, dann kann man meinen Namen Jörgen schreiben), dann braucht man keine Punkte mehr auf nachfolgende Zeichen verschieben.
Es geht nicht darum, dass sie gleich aussehen, sondern dass es verschiedene Codierungen für das gleiche Zeichen sind.
Auf meinem MacBook Pro, Snow Leopard, Standard-Terminal (meine Standard-Shell ist auf zsh gesetzt):
zsh% echo ä | xxd
0000000: c3a4 ..
zsh% bash
bash$ echo ä | xxd
0000000: c3a4 0a …
Ich kenne mich jetzt nicht genügend aus, ob das 0a vom in zsh aufgerufenen bash kommt.
Im Dateisystem wird von beiden 61cc 880a erzeugt.
Probleme beim Codieren von Dateinamen macht sich OSX auch selbst beim Kopieren von unterschiedlichen Geräten (Bsp.: FAT32 USB-Stick), auch weil es externe UTF-Namen beim Einbinden nochmals in UTF umwandelt.
@Yoshimitsu: Danke! (das 0a ist nur der Linefeed, das heißt das Zeilenende, das dafür sort, daß eine neue Zeile angefangen wird und hat mit den Zeichen selbst nichts zu tun, das kannst Du hier in diesem Zusammenhang einfach ignorieren)
Diese Woche das gleiche Problem gehabt, allerdings bei der Nutzung von SVN (ist hier auch beschrieben: http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames).
Im Grunde passiert bei Umlauten im Pfadnamen, dass SVN diese zwar erstmal vom Server kopiert, aber anschließend nicht wieder erkennt und stattdessen zwei Dateien anzeigt, eine lokal (als nicht versioniert ?) und eine auf dem Server als missing.
Updaten etc. scheint allerdings zu gehen, nervt allerdings da diese Dateien immer als verändert angesehen werden (und wahrscheinlich auch jedenfalls hoch und wieder herunter geladen werden, was ich aber bisher nicht überprüft habe)
In meinen Augen sind die vielfachen Codierungsmöglichkeiten aus dem Aspekt der Speicherffizienz sehr sinnvoll. Vergleicht man den Codepoint »ä« (in UTF-8 #c3a4, zwei Bytes) mit der Kombination aus Diaräse (¨) und kleinem a, (UTF-8: #x61cc88, drei Bytes), so ist das einb Unterschied im Speicherverbrauch. Mal ganz abgesehen von der mich ständig aufregenden Tatsache, dass es keine verschiedenen Codepunkte für die semantisch unterschiedlichen Akzente »Umlaut« und »Diärese« gibt, ist dies vorallem bei Sprachen, die sehr viele Akzente verwenden (wie das Vietnamesische) entscheidend. Die Existenz vorgefertigter Codepoints verringert den Speicherplatz. Das Problem ist vielmehr, dass die meisten Programme keine ordentliche Behandlung von UTF-8 durchführen und zum Vergleich und zur Verarbeitung weiterhin mit 8-Bit Chars arbeiten, meistens weil die Programmierer (a) von UTF-8 keinen Plan haben, (b) meinen, dass ein solcher Fall sowieso nicht auftritt oder (c) keine Lust haben, sich in die nötigen Bibliotheken einzuarbeiten.
Nunja, mit ähnlichen Effekten kämpfe ich schon seit Jahren, wenn ich backup und restore von Windowskisten auf Linux mache.
Je nachdem ob man die zu sichernde Kiste von einer liveCD startet oder übers Netzwerk via rsync/unison/samba sichert, hat man zum Schluß verschiedene Codierungen auf dem Linux-Filesystem. Wenn man dann beim Restore nicht den richtigen Weg zurück geht, hat man in Windows zum Schluß ganz “lustige” Zeichen in den Dateinamen.
Datei sind die mount-optionen von NTFS oder die verschiedeneen Optionen von Samba oder Rsync essentiell. Ich wünsche mir auch schon lange eine eindeutige Codierung, meinetwegen auch mit 32bit-chars bei denen mit 0x00000000 bis 0x0000007f durchaus das Standard-Ascii codiert sein darf.
Dazu passend natürlich auch http://geekandpoke.typepad.com/geekandpoke/2011/11/geeks.html
(Über https://www.danisch.de/blog/2011/11/18/wie-sich-it-sicherheitsexperten-im-restaurant-beschweren/ gefunden).
Waren das noch Zeiten, als man einen hexdump noch so lesen konnte (Z80/6502-Code mit ascii-Strings).
Und weil’s so schön ist:
http://geekandpoke.typepad.com/geekandpoke/2011/08/coders-love-unicode.html
😀
@Yoshimitsu: Ich habe kein zsh installiert und kann es nicht selbst testen – kann es sein, dass zsh kein eingebautes echo hat, und /bin/echo benutzt, während die bash das buildin-echo benutzt?
Und dass sich beide eben darin unterscheiden, dass man beim build-in echo -n foo eingeben muss, um die Ausgabe des newline zu unterdrücken?
Oder meintest Du das, als Du ‘bash’ schriebst: “Ich kenne mich jetzt nicht genügend aus, ob das 0a vom in zsh aufgerufenen bash kommt.”
type echo
in der zsh sollte das testbar sein mit type, wenn die zsh ein ‘type’ hat – bash:
type type
type is a shell builtin
Hi Hadmut,
danke für Deine Klarstellung von UTF-8 und was Mac OS daraus macht.
Jetzt wird mir auch klar, warum meine TeX Dokumente nicht sauber getrennt werden können, falls im zu trennenden Namen Umlaute auftreten.
Herr lass Hirn regnen !
Wer sich’s anschauen möchten, findet in meinem ‘Guttenberg’ Artikel den TeX Output und die Quellen. Schrecklich.
https://fehcom.net/fh-frankfurt (Zertifikat akzeptieren)
mfg.
–eh.
Ohne Rob Pike und die Erfindung von UTF-8 wären
C-Strings und Unix jetzt Geschichte.
Willst Du das?
UTF-8 selbst ist m.E. eher harmlos, der Witz ist doch gerade,
dass es C- und Ascii- kompatibel ist. Die von Dir beschriebenen
Komplikationen entstehen auch erst dadurch, dass jede Lasagne-Schicht
meint, selber umcodieren zu müssen. Dazu zählt leider auch Schicht 8 beim Betrachten der Bildschirmausgabe.
P.S. Eine Unix-Datei mit einem nicht minimal codierten ‘/’ irritiert
zwar bein Anschauen auf einem schlecht programmierten Terminalprogramm, aber die Tab-Expansion oder Cut&Paste funktionieren.
Wenn, ja wenn, sie nicht versuchen, zu schlau zu sein.