Suche nach String mit 'decomposed' Character

[Maekkelrajter]

In diesem Thread (Artikel #20) hatte ich bereits das Problem mit unterschiedlich codierten Umlauten thematisiert. Zur Zeit brüte ich über einer Suchfunktion, die in einem TMemo bei einer Suche nach 'Götterdämmerung' sowohl 'Götterdämmerung' (precomposed = Götterdämmerung) als auch 'Götterdämmerung' (decomposed = Götterdämmerung) findet.
Das ist wohl alles andere als trivial, aber es scheint doch möglich zu sein. Das Windows Notepad z. B. findet beide, wenn ich von Hand 'Götterdämmerung' in den Suchdialog eingebe, aber auch wenn ich den Suchstring (in beiden Varianten) per Copy & Paste einfüge.
Ich suche vor allem erstmal überhaupt einen Ansatz.
Wenn ich das Memo mit ANSI füttere, klappt zwar die Suche nach 'Götterdämmerung', aber mit keiner der verfügbaren Codepages werden alle Sonderzeichen korrekt decodiert, also keine Option.
Vielleicht kennt jemand eine Lösung oder auch nur einen Lösungsansatz?

Gruß LP

[jaenicke]

Ich vermute einmal, dass intern auf eine einheitliche Kodierung gewechselt wird. Die Darstellung mit separatem Trema habe ich unter Windows oder Linux z.B. noch nie gesehen.

Zitat:

Zitat von Maekkelrajter (Beitrag 1541835)

Das Windows Notepad z. B. findet beide, wenn ich von Hand 'Götterdämmerung' in den Suchdialog eingebe, aber auch wenn ich den Suchstring (in beiden Varianten) per Copy & Paste einfüge.

Wenn ich den Assemblercode richtig deute, wird dort zeilenweise gesucht und dabei wcsncmp bzw. _tcsncmp oder CompareStringW verwendet, je nachdem, ob Groß- und Kleinbuchstaben unterschieden werden oder nicht.

Meine Assemblerkenntnisse reichen nicht aus, um das genauer zu untersuchen. Und das gilt auch nur für die alte Notepad-Version, nicht für die Variante in Windows 11.

[paule32.jk]

vieleicht hilft ja die Delphi-Komponente TSynEdit weiter ?
diese kommt mit Unicode und Such-Komponenten.

außerdem kann TSynEdit mit größeren Dateien etwas mehr anfangen als TMemo.
soweit ich mich erinnern kann, reicht TMemo das Limit von 64k Texten, weshalb
ich in früheren Tagen meiner Programmiererei TRichEdit verwendet hatte.
TRichEdit kann mehr als 64k Daten sammeln - und auch colorieren.

Aber wie geschrieben: TSynEdit kann das auch - vieleicht ein wenig besser.
Zudem müsste TSynEdit OpenSource und frei verwendbar sein...

[mmw]

Hallo,

hier wäre noch eine kostenlose Memo Komponente (näheres dazu auf der Website, scheint damit zu funktionieren).

http://www.ecmqc.com/plusmemo/pmHome.htm


Bei der Installation in Delphi 12 sollte es reichen die '*.inc' -Datei entsprechend anzupassen.

Gruß

[Gausi]

Zitat:

Zitat von Maekkelrajter (Beitrag 1541835)

Das Windows Notepad z. B. findet beide, wenn ich von Hand 'Götterdämmerung' in den Suchdialog eingebe, aber auch wenn ich den Suchstring (in beiden Varianten) per Copy & Paste einfüge.

Ich kann zwar nichts zur Lösung beitragen, aber wenn ich die Götterdämmerung in den unterschiedlichen Kodierungen in eine Textdatei einfüge, die der Windows-11-Editor wohl als UTF8 ohne BOM speichert, dann findet die Suchfunktion sowohl vom Windows-11-Editor als auch die von Notepad++ nicht beide Varianten, sondern in beiden Fällen nur eine - eben die, die gesucht wurde.

Dass die Kodierung beim Copy&Paste nicht kaputt gegangen ist, kann man in einem HexEditor sehen.

[himitsu]

Es kommt auch drauf an, wie gesucht wird.

Es gibt Stringvergleichsfunktionen, die behandeln auch unterschiedliche Composings.
RegEx tut sowas z.B. nicht und vergleicht nur binär.

Man kann beim Suchen vorher auf den Text und den Suchtext je einmal normalisieren und anschließend vergleichen.



PS:
Delphi und UTF-8 : Nach Umlauten suchen geht nur, wenn die Datei/Unit im Editor bereits geladen ist,
weil dort im Unicode-Buffer des Editors gesucht wird, während die Suchfunktion für direkten Dateizugriff einfach nur bähhhhh ist und Emba das seit vielen Jahren nicht reparieren will. (UTF-8 wird da einfach als blind "ANSI" geladen)

[Maekkelrajter]

Zitat:

Zitat von Gausi (Beitrag 1541842)

Ich kann zwar nichts zur Lösung beitragen, aber wenn ich die Götterdämmerung in den unterschiedlichen Kodierungen in eine Textdatei einfüge, die der Windows-11-Editor wohl als UTF8 ohne BOM speichert, dann findet die Suchfunktion sowohl vom Windows-11-Editor als auch die von Notepad++ nicht beide Varianten, sondern in beiden Fällen nur eine - eben die, die gesucht wurde.
Dass die Kodierung beim Copy&Paste nicht kaputt gegangen ist, kann man in einem HexEditor sehen.

Mein 'Versuchsaufbau':
Eine Stringlist, die beide Codierungsvarianten enthält, wird als 'Unicode' mit BOM gespeichert:

Delphi-Quellcode:

FN := 'content_06-10-2024_15-41.txt'
MyStringlist.SaveToFile(FN,TEncoding.unicode)

Kontrolle mit einem Hexeditor zeigt, dass beide Codierungen in der Datei vorkommen.
Anschließend wird diese Datei mit dem Notepad geöffnet. Notepad erkennt 'UTF-16 LE'
Beide Varianten werden gefunden, wenn ich von Hand 'Götterdämmerung' in den Suchdialog eingebe, aber auch wenn ich den Suchstring (in beiden Varianten) per Copy & Paste einfüge (gerade nochmal ausprobiert).
Mein OS ist allerdings Windows 10.
Edit:
Hier (Artikel #4) ist eine Datei zu finden, die beide Codierungsvarianten enthält: 'MacOS_ItunesContent.txt'

Gruß LP

[Maekkelrajter]

Zitat:

Zitat von mmw (Beitrag 1541841)

Hallo, hier wäre noch eine kostenlose Memo Komponente (näheres dazu auf der Website, scheint damit zu funktionieren).

Hier gibt es eine Demo, mit der es leider auch nicht funktioniert :(
Es handelt sich zwar um die Version 6.6a (2011), aber auch aus dem Changelog bis V 7.2 (2018) läßt sich nicht entnehmen, dass eine der Änderungen das behoben hätte.
Schade, eine Hoffnung weniger!

Gruß LP

[jaenicke]

Ich halte das eher für einen Bug bei der Zeichenkodierung. Ich kenne keine korrekte Möglichkeit, in der 6F 00 08 03 für ein ö steht. Das ist weder UTF-8 noch UTF-16. Das wird offenbar trotzdem richtig gelesen, aber ich verstehe nicht warum.

// EDIT:
08 03 steht für Trema.

[himitsu]

Ich wüsste auch nicht, warum

Delphi-Quellcode:

Götterdämmerung

eine Dekompositation ergeben sollte, vor allem nicht, da ö und ä das Selbe wären.

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
var
  A, B, C, D: string;
begin
  A := 'xö';
  B := 'xo'#$0308;  // o mit compose-¨
  C := 'xo'#$00A8;  // o mit ¨
  if A = B then
    ShowMessage('aa');  // nö
  if AnsiSameStr(A, B) then  // CompareString mit LOCALE_USER_DEFAULT
    ShowMessage('bb');  // jo
  if AnsiSameStr(A, C) then
    ShowMessage('cc');  // nö

  if StrStr(PChar(A), PChar(B)) <> nil then  // PChar-Variante des Pos
    ShowMessage('dd');  // jo

  SetLength(D, 5);
  SetLength(D, NormalizeString(NormalizationC, PChar(B), 4, PChar(D), 5) - 1);
  if A = D then
    ShowMessage('ee' + sLineBreak + A.Length.ToString + ' ' + B.Length.ToString + ' ' + D.Length.ToString + ' ');  // jo
end;

CompareString oder CompareStringEx,
im Gegensatz zu CompareStringOrdinal.

StrStr
FindNLSString
FindNLSStringEx

NormalizeString
FoldString
MAP_PRECOMPOSED = $20; { convert to precomposed chars }
MAP_COMPOSITE = $40; { convert to composite chars }

WideCharToMultiByte
WC_COMPOSITECHECK = $200; { convert composite to precomposed }

MultiByteToWideChar
MB_PRECOMPOSED = 1; { use precomposed chars }
MB_COMPOSITE = 2; { use composite chars }