Unbekannte Umnlautkodierung
-
tntnet schrieb:
unter http://www.utf8-zeichentabelle.de findest Du alle utf-8 codes. Die Ausgabe des Terminals stimmt. Das Verhalten von Mac OS X ist da eher merkwürdig.
Danke: UTF-8 ist ja auch nicht mein Problem. Sondern diese doofe Kodierung vom Mac.
-
Dies beschreibt das Problem:
http://en.wikipedia.org/wiki/Unicode_equivalenceDas Mac OS nutzt anscheinend NFD, Linux NFC. Der Artikel beschreibt auch Lösungsansätze.
-
SeppJ schrieb:
Dies beschreibt das Problem:
http://en.wikipedia.org/wiki/Unicode_equivalenceDas Mac OS nutzt anscheinend NFD, Linux NFC. Der Artikel beschreibt auch Lösungsansätze.
Supergeil. Das war genau das, was ich gesucht habe. Vielen lieben Dank.
Da kommen ja noch nette Probleme auf mich zu.
Interessant ist: Ich habe mit dem Programm unter OS X eine Datei auf einem Linux-Server (per NFS) erzeugt. Der Samba-Share zeigt ganz normal den Umlaut an. Der Linuxrechner (via Telnet) zeigt das a gefolgt von den Umlautpunkten, OS X das a gefolgt von zwei Fragezeichen (alles mit einer Terminalemulation unter Windows). Von einem Terminal unter OS X zeigen beide Rechner die Umlaute an. Was der Samba-Client unter OS X anzeigt, will ich schon nicht mehr wissen.
Alle möglichen Kombinationen kann man daher nicht testen ich werde daher nur die häufigsten Anwendungsfälle testen. 8-(
mfg Martin
-
mgaeckler schrieb:
Supergeil. Das war genau das, was ich gesucht habe. Vielen lieben Dank.
So als Hilfe zur Selbsthilfe ein Tipp: Bis vor ein paar Stunden wusste ich das selber auch noch nicht. Der Trick ist Google-Fu:
Google: mac os file system umlaut
So schwer ist es nicht, auf solch eine Suchanfrage zu kommen, oder?Interessant ist: Ich habe mit dem Programm unter OS X eine Datei auf einem Linux-Server (per NFS) erzeugt. Der Samba-Share zeigt ganz normal den Umlaut an. Der Linuxrechner (via Telnet) zeigt das a gefolgt von den Umlautpunkten, OS X das a gefolgt von zwei Fragezeichen (alles mit einer Terminalemulation unter Windows). Von einem Terminal unter OS X zeigen beide Rechner die Umlaute an. Was der Samba-Client unter OS X anzeigt, will ich schon nicht mehr wissen.
Also mein Linuxterminal zeigt beides als 'ä' an. Das ist scheint ein Feature* von Telnet zu sein.
Alle möglichen Kombinationen kann man daher nicht testen ich werde daher nur die häufigsten Anwendungsfälle testen. 8-(
Ich hätte vermutet, dass es da irgendwelche Standardfunktionen für gibt. Ich würde das auf keinen Fall selber programmieren.
*: Ich mag es nicht Fehler nennen. Immerhin hast du erst dadurch bemerkt, was überhaupt passiert.
-
SeppJ schrieb:
So als Hilfe zur Selbsthilfe ein Tipp: Bis vor ein paar Stunden wusste ich das selber auch noch nicht. Der Trick ist Google-Fu:
Google: mac os file system umlaut
So schwer ist es nicht, auf solch eine Suchanfrage zu kommen, oder?Natürlich war das erste, was ich gemacht habe, Tante Google zu fragen. Meine Anfrage war aber
Google: Mac OS X file system character encoding
Tja da war ich nicht sehr erfolgreich. Obwohl, jetzt wo ich die Lösung kenne, hätte ich sie auch schon im ersten Treffer finden können.SeppJ schrieb:
Ich hätte vermutet, dass es da irgendwelche Standardfunktionen für gibt. Ich würde das auf keinen Fall selber programmieren.
Vielleicht habe ich ja Glück. Aber wenn es einen Standard gibt, mit dem ich das umwandeln kann, warum nicht selbst kodieren. UTF-8 kann ich ja auch selbst erzeugen bzw. dekodieren. Allerdings schreibt schon der von Dir verlinkte Wikipedia-Artikel, daß das nicht trivial ist.
mfg Martin
-
SeppJ schrieb:
Ich hätte vermutet, dass es da irgendwelche Standardfunktionen für gibt. Ich würde das auf keinen Fall selber programmieren.
Im Cocoa Framework gibt es tatsächlich Funktionen zur Konvertierung. Vorerst habe ich aber eine simple Lösung implementiert. Ich mag das Cocoa Framework noch nicht einbinden, weil ich so derzeit ein und die selbe Codebasis inkl. Makefiles für alle Zielsysteme (Linux, Mac OS X und Windows) benutzen kann (Nur Windows benutzt andere Makefiles, weil ich dort Borland C++ statt Gnu C++ benutze).
Ich suche einfach nach den Mustern für die deutschen Umlaute und konvertiere diese in UTF-8. Die Verzeichnis- und Dateierstellungsroutinen akzeptieren auch UTF-8 und wandeln diese gegebenenfalls um, so daß meine Anwendung auch dann wie gewünscht funktioniert, wenn die Dateinamen deutsche Umlaute enthalten. Bei anderen Sonderzeichen ist das schlimmste, was passieren kann, daß die Anwendung die Dateien löscht, um sie dann gleich aus der Medienbibliothek wieder in das Ziel zu kopieren.
mfg Martin
-
mgaeckler schrieb:
Ich suche einfach nach den Mustern für die deutschen Umlaute und konvertiere diese in UTF-8.
Eh, what? Sicher, dass du das Problem verstanden hast? Es liegt nicht an der Kodierung der Codepoints. Die ist in beiden Fällen UTF-8. Das Problem hier liegt in der Frage welche Codepoints zur Darstellung der gewünschten Strings überhaupt erst verwendet werden. Ein 'ä' beispielsweise lässt sich auf verschiedene Weisen erzeugen: einmal als einzelner Codepoint 0xE4 (LATIN SMALL LETTER A WITH DIAERESIS); alternativ als 'a' (Codepoint 0x61, LATIN SMALL LETTER A) gefolgt von Codepoint 0x308 (COMBINING DIAERESIS).
Zu beachten ist hierbei natürlich, dass ein byteweiser Vergleich der resultierenden UCS-4-Strings Ungleichheit ergeben würde, obwohl die Darstellung auf dem Bildschirm in der Regel identisch ist. Daher definiert Unicode eine Normalform, bei dem jedes Zeichen durch eine eindeutige Repräsentation dargestellt wird. Weil das alles so viel Spaß macht, gibt es sogar mehrere davon: eine "composing" (NFC) und eine "decomposing" (NFD) Normalform (plus jeweils eine Compatiblity-Variante davon).
In der Composing-Normalform wird jedes Zeichen, für das ein einzelner, bereits zusammengesetzer, Codepoint existiert (wie eben 0xE4 für das 'ä') ausschließlich durch diesen dargestellt. Ein Zusammensetzen aus mehreren Codepoints ist für solche Zeichen nicht zulässig. Neben dem Ermöglichen von einfachen Stringvergleichen spart diese Variante natürlich auch Platz.
Umgekehrt wird es in der Decomposing-Normalform gehandhabt. Jedes Zeichen, das sich in mehrere Komponenten zerlegen lässt, muss auch zerlegt werden.
MacOS ist insofern problematisch als dass Apple sich aus irgendeinem Grund für NFD (die Decomposing-Variante) entschieden hat, während der Rest der Welt sich auf NFC geeinigt hat. Außerdem normalisiert MacOS auch Dateinamen, anstatt, wie jedes andere Unix es tut, die übergebenen Bytes einfach so zu speichern, wie sie dem System übergeben wurden.
Mit diesen Dingen im Bewusstsein fällt dir doch bestimmt eine bessere Lösung ein, als nach irgendwelchen Mustern zu suchen.
-
trolololo schrieb:
Eh, what? Sicher, dass du das Problem verstanden hast?
Also so ganz habe ich den Sinn dieser Normalformen noch nicht verstanden, das ist korrekt.
Die Idee meiner Lösung ist folgende:
Ich lese mit opendir(), readdir() etc. den Verzeichnissinhalt. Dabei erhalte ich von Mac OS X die canonische Normalform (NFD) UTF-8 kodiert. Das heißt ein ä wird zu
{ 'a', 0xCC, 0x88 }{ 0xCC, 0x88 } ist in Unicode U+0308 (=COMBINING DIAERESIS)
ich suche daher nach der Bytefolge 0xCC, 0x88 und wenn davor ein a, A, o, O, u oder U ist, mache ich daraus einen Umlaut und setze dessen UTF-8 code in die Zeichenkette statt den gefundenen 3 bytes.
Ich mache sozusagen aus der NFD-Form, die mir das Dateisystem liefert eine NFC-Form. Denn in dieser Form liegen die Quellen, aus denen ich beim Erstellen der Verzeichnisse deren Namen ermittelt habe.
Wie gesagt, so komplett habe ich das ganze noch nicht durchgeblickt. Deshalb habe ich das nur für deutsche Umlaute gemacht. Das genügt mir für erste, da auch ein Datenverlust nicht zu befürchten ist, wenn es mal nicht passt.
mfg Martin
-
Ok, das dürfte für diesen speziellen Fall funktionieren, bricht aber ziemlich schnell zusammen, sobald andere Compositions hinzu kommen. Also warum nicht einfach gleich richtig normalisieren?
Nutzen kannst du dafür z.B. ICU, was man als sowas wie eine Referenzimplementierung betrachten kann. Ist portabel, liberal lizenziert und hat keine nennenswerten Abhängigkeiten. Die entsprechende Funktionalität findest du hier (C-API) oder hier (C++-API).
Ist der Code, um den es dir geht Open Source?
-
trolololo schrieb:
Ok, das dürfte für diesen speziellen Fall funktionieren, bricht aber ziemlich schnell zusammen, sobald andere Compositions hinzu kommen. Also warum nicht einfach gleich richtig normalisieren?
Früher oder später werde ich das wohl umsetzen müssen.
trolololo schrieb:
Nutzen kannst du dafür z.B. ICU, was man als sowas wie eine Referenzimplementierung betrachten kann. Ist portabel, liberal lizenziert und hat keine nennenswerten Abhängigkeiten. Die entsprechende Funktionalität findest du hier (C-API) oder hier (C++-API).
Sieht ziemlich gut aus. Ich denke aber, daß die Bibliothek mit Kanonen auf Spatzen geschossen ist. Mal schaun. Normalerweise tendiere ich eh dazu, sowas selbst zu implementieren.
trolololo schrieb:
Ist der Code, um den es dir geht Open Source?
Den Quelltext meiner Laufzeitbilbiothek will ich derzeit nicht freigeben. Deshalb werden auch alle Anwendungen, die diese nutzen ebenfalls nicht Open Source veröffentlicht, obwohl es mir bei diesen wurscht wäre. Ich bin aber schon am Überlegen, ob ich nicht wenigstens die Libs für Nixen in Binärform veröffentliche, damit ich auch den Quelltext der kleinen Tools hergeben kann und Entwickler diese auch nutzen können. So toll ist das auch alles noch nicht. Die XSLT-Transformation ist noch nicht vollständig. XSchema-überprüfung ist auch noch nicht komplett. Ich erweitere sowas immer erst dann, wenn ich's brauche für das kleine Tool gerade eben, ist das aber nicht notwendig, weil ich die XML-Dateien von iTunes nicht auf Gültigkeit überprüfe. Wenn sie fehlerhaft sind, finde ich halt keine Wiedergabenlisten und keine Musikdateien.
mfg Martin
