Verzeichnisnamen mit Umlauten

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