Verzeichnisnamen mit Umlauten

[SittingDuck]

Hallo zusammen.

Ich bekomme aus einer SQLite Datenbank einen Dateinamen geliefert (wie ich meine) im UTF8 Format und der soll mal am Ende so aussehen: "Base Flats Ändern.txt". Aktuell sieht er jedoch noch so aus: "Base Flats Ändern.txt". Als Hexwerte dargestellt, ergibt der Name der Datei (nicht der Inhalt, der ist uninteressant) folgende Zahlenreihe: "42 61 73 65 20 46 6C 61 74 73 20 41 CC 88 6E 64 65 72 6E 2E 74 78 74".

Das Problem ist der Umlaut "Ä" bzw. die "41 CC 88". Wenn ich die Funktion UTF8ToString auf diesen Text anwende, kommt zwar am Ende ein "Ä" raus, aber irgendwas stimmt da nicht: "Base Flats Ändern.txt". Die Ä-Pünktchen sind irgendwie extra, hinter dem 'A', obwohl es wie ein "Ä" aussieht. Auf jeden Fall ist es nicht das Gleiche, wie ein normales "Ä" mit sämtlichen daraus resultierenden Konsequenzen.

Wo ist mein Denkfehler?

[Coffeecoder]

Zitat:

Zitat von SittingDuck (Beitrag 1153746)

.. der soll mal am Ende so aussehen: "Base Flats Ändern.txt". Aktuell sieht er jedoch noch so aus: "Base Flats Ändern.txt". ...

Hi, und warum nicht einfach : "Base Flats Aendern.txt"?
Ich finde im Allgemeinen sollte man Umlaute vermeiden, sowohl bei Verzeichnissnamen,in Email-Adressen und so weiter...

[Bernhard Geyer]

Zitat:

Zitat von SittingDuck (Beitrag 1153746)

Das Problem ist der Umlaut "Ä" bzw. die "41 CC 88".

De-UTF8t kommt Hex-Technisch 0041 0308 raus.
D.h A + ̈ sind 2 Zeichen.
Das ̈ wir im UTF8-Standard so beschrieben:

COMBINING DIAERESIS (Dialytika)
= double dot above, umlaut
= Greek dialytika
= double derivative
x (diaeresis - 00A8)

[SittingDuck]

Hallo nochmal ...

@Coffeecoder: Ja klar, wenns nach mir ginge, dann würde ich das auch ohne Umlaute regeln ... geht aber leider in diesem Fall nicht. :(

@Bernhard Geyer: Danke für die Erklärung.

Gibt es denn keine Konvertierungs-Funktion, die aus "Base Flats Ändern.txt" wieder eine normale Darstellung macht, also mit einem simplen "Ä"? UTF8ToString liefert ja leider dieses Dialytika-Ä ...

[Bernhard Geyer]

Zitat:

Zitat von SittingDuck (Beitrag 1153796)

Gibt es denn keine Konvertierungs-Funktion, die aus "Base Flats Ändern.txt" wieder eine normale Darstellung macht, also mit einem simplen "Ä"? UTF8ToString liefert ja leider dieses Dialytika-Ä ...

UTF8ToString macht das schon korrekt. Wie sind denn die Daten reingekommen? Dort wird schon diese Daten mit den 2-Zeichen Ä eingetragen worden sein

Ansonsten selbst einen "simplyfy"-Funktion schreiben. Sowas wird es vermutlich nicht fertig geben.

[Gustav.R]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1153810)

Zitat:

Zitat von SittingDuck (Beitrag 1153796)

Gibt es denn keine Konvertierungs-Funktion, die aus "Base Flats Ändern.txt" wieder eine normale Darstellung macht, also mit einem simplen "Ä"? UTF8ToString liefert ja leider dieses Dialytika-Ä ...

UTF8ToString macht das schon korrekt. Wie sind denn die Daten reingekommen? Dort wird schon diese Daten mit den 2-Zeichen Ä eingetragen worden sein

Ansonsten selbst einen "simplyfy"-Funktion schreiben. Sowas wird es vermutlich nicht fertig geben.

Als D5'ler bin ich da wohl nicht kompetent genug, um das Geraffel zu durchleuchten, aber ich würde auf den String "Base Flats Ändern.txt" halt mal sieben StringReplaces loslassen für AÖÜäöüß

Ob das was bringt, ist natürlich völlig unklar. Was liefert die SQLite Datenbank denn sonst noch an ungültigen Daten?

GG

[Bernhard Geyer]

Zitat:

Zitat von Gustav.R (Beitrag 1153858)

Als D5'ler bin ich da wohl nicht kompetent genug, um das Geraffel zu durchleuchten, aber ich würde auf den String "Base Flats Ändern.txt" halt mal sieben StringReplaces loslassen für AÖÜäöüß

Und die 50000 anderen Zeichen wie z.B. Arabisch, Chinesich, ....?

Zitat:

Zitat von Gustav.R (Beitrag 1153858)

Was liefert die SQLite Datenbank denn sonst noch an ungültigen Daten?

Wies sollen die Daten ungültig sein? Wenn das schreibende Programm genau dies rein geschrieben hat muss das auch so wieder raus kommen.

[Gustav.R]

Zitat:

Wies sollen die Daten ungültig sein? Wenn das schreibende Programm genau dies rein geschrieben hat muss das auch so wieder raus kommen.

Genau!

Hast Du eine besseren Vorschlag als mein siebenfaches StringReplace?

[Bernhard Geyer]

Wenn ich verhindern will das Sonderzeichen (alles über 0x007F) als Verzeichnis/Dateiname verwendet werden soll nimm ich oft eine URLEncode-Funktion. D.h. ich Codiere die Daten so wie es ein Webserver in seiner URL auch machen würde.

[Gustav.R]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1153868)

Wenn ich verhindern will das Sonderzeichen (alles über 0x007F) als Verzeichnis/Dateiname verwendet werden soll nimm ich oft eine URLEncode-Funktion. D.h. ich Codiere die Daten so wie es ein Webserver in seiner URL auch machen würde.

Schön, daß Du so codierst. Aber der TE bekommt die Daten bzw. den Dateinamen "so geliefert". Also, was tun?

MfG
Gustav

[Bernhard Geyer]

Zitat:

Zitat von Gustav.R (Beitrag 1153871)

Schön, daß Du so codierst. Aber der TE bekommt die Daten bzw. den Dateinamen "so geliefert". Also, was tun?

Sieh Post #7. Wie kommen die daten rein? Wenn das Schreibprogramm mist baut sollte man den Fehler dort korrigieren. ein DB wird nicht von sich aus umcodierungen vornehmen (ist mir jedenfalls beim Test vor 2-3 Jahren mit SQLite auch mit sonderzeichen etc. nicht aufgefallen).

[Gustav.R]

Okay, man/Du bekommst nie Daten, die seltsam aussehen.

Bin jetzt besser raus hier.

GG

[Bernhard Geyer]

Zitat:

Zitat von Gustav.R (Beitrag 1153884)

Okay, man/Du bekommst nie Daten, die seltsam aussehen.

Permanent. Aber zu 99% werden die Fehler in den Vorsystemen korrigiert anstatt diese Fehler noch die nächsten 10/20 Jahre zu "pflegen".
Unsere Kunden haben oft von Systemen die Nase voll bei denen die Entwickler nicht auf diese Fehler hinweisen so das diese korrigiert werden und stattdessen immer nur um diese Fehler rumprogramieren.

[SittingDuck]

Danke schon mal für Eure Ideen ...

also eingtragen in die SQLite Datenbank wurde der Pfadname vom iPhone also von iOS5. Eine Sache an der ich jetzt nichts ändern kann. Mit meinem Tool "iTwin" (www.i-twin.de) hole ich diese Daten reverse-engeneering-mäßig da wieder raus und zeige sie an. Leider beschränkt sich das Problem nicht nur auf ÄäÖöÜüß sondern es kann mal wieder alles vorkommen ... Chinesisch, Japanisch, Russisch etc. so dass der einfache StringReplace leider ausscheidet.

Ich hatte einen Teilerfolg hiermit:

Delphi-Quellcode:

Path := String(WideStringToString(UTF8ToString(RawByteString(Path))));

und für einen Moment dachte ich das isses, weil mit diesem (zugegebenerweise fragwürdigen) Konstrukt aus meinem komischen Ä ein vernünfiges Ä gemacht wurde, aber diese Zeile versagt natürlich bei sämtlichen andern Zeichen wie z.B. Kyrill. Zur Erklärung: WideStringToString ist eine Routine aus der DP, welche ein WideCharToMultiByte mit entsprechender Codepage meiner Wahl durchführt. Ich habe nicht nur 1252 und 1201 sondern auch zahlreiche andene Codepages durch getestet ... nix Vernünftiges bzw. Universelles, leider.

Aus jetziger Sicht scheint ein einfaches UTF8ToString mit anschießendem StringReplace einen Großteil meiner Probleme, bis auf Weiteres zu lösen. Ganz korrekt ist das jedoch nicht ... Mal abwarten, wie lange es gut geht :shock:

[Bernhard Geyer]

Gut für das mehr an Kontext :-)

Also ich denke die Anwendung die die DB befüllt will sich damit das Sortierungsproblem lösen das ä nach a einsortiert wird.

Letzendlich brauchst du eine Mappingtabelle wie es LMD schon (teilweise) realisiert hat.
Dort kann zu jedem zu jedem (combined) Zeichen die (bis zu 3) uncombined Zeichen definiert. Ein Funktion würde dann für jedes Zeichen im String suchen ob es dafür ein Combined Zeichen gibt und dieses dann verwenden und die uncombined Zeichen entfernen.

[p80286]

Wenn ich das richtig verstanden habe, werden Umlaute und Akzente mit Hilfe der sog. Deadkeys gebastelt. Ich hatte angenommen, das diese Technik seit dem Aussterben der Matrixdrucker ebenfalls tot ist.
Also solltest Du keine Probleme bekommen, wenn Du diese "aus 2 mach eins" Aktion auf genau abgestimmte Pärchen losläßt.
(das daß nicht das Gelbe vom Ei ist sollte allerdings auch klar sein)

Gruß
K-H

[SittingDuck]

So, das ganze Problem ist doch komplexer als man erstmal so denkt, vor allem, wenn man es richtig machen will ... Zumindestens hat das Kind aus meiner Sicht jetzt erstmal einen Namen: "NormalizeString" und entsprechende Details darüber habe ich hier bei stackoverflow gefunden.

Gut, ich bin zwar nicht der einzige mit Wunsch einen Unicodestring wieder zu vereinfachen, aber hilfreiche, selbst gebastelte, oder sogar fertige API Routinen habe ich leider dennoch nicht ausgraben können ...