Zeichenkette vergleichen

Finnegan

@DocShoe sagte in Zeichenkette vergleichen:

Wir machen das so, dass wir intern mit std::wstring arbeiten, damit wir solche Probleme wie von @Finnegan beschrieben nicht haben.

Auch mit std::wstring und sogar mit 32-Bit Code Units wird man immer noch das Problem mit der Normalisierung haben. Es kann natürlich sein, dass die verarbeiteten Strings alle aus einer Datenquelle stammen, wo diese bereits normalisiert sind (das ist vermutlich der Fall, wenn man nur Strings verarbeitet, die z.B. alle aus einem RDBMS kommen). Oder die Daten wurden alle auf die selbe Art eingegeben (ich tippe, dass z.B. ein Windows-Eingabefeld ein ä immer direkt als diese Zeichen und nicht als a mit Verbindungszeichen erzeugt). Gut möglich, dass das Problem einfach noch nicht aufgetreten ist. oder Zumindest nicht so, dass es aufgefallen wäre. Man braucht halt auch erstmal zwei Strings mit unterschiedlichen Codierungen des selben Zeichens.

Was das "ein Zeichen, ein String-Index" angeht, so funktioniert das mit wstring wahrscheinlich auch häufig. Zumindest für Zeichen aus der Basic Multilingual Plane, die schon eine ganze Menge abdeckt. Aber streng genommen ist das ja auch eine UTF-Format, bei dem ein Zeichen aus mehreren Codepoints bestehen kann. Genau wie bei UTF-8 auch. Wenn man also Unicode vollständig unterstützen will, muss man das sowieso auch mit UTF-16 genau so wie bei UTF-8 berücksichtigen. Das ist auch eines der Argumente von utf8everywhere.org, dass man da auch gleich UTF-8 nehmen kann.

Von dem, was ein "Zeichen" ist, und dass die auch mit 32-Bit-Codierung mehr als ein Codepoint und damit mehr als einen String-Index haben können fange ich besser nicht an.
Aber man kommt durchaus auch mit wstring durch, solange man auf keine Sonderfälle stößt. Es ist halt nur leider nicht vollständig korrekt.

Finnegan

@DocShoe sagte in Zeichenkette vergleichen:

Vielleicht haben wir die Probleme auch nur, weil wir gewachsene Software mit "konventioneller" String-Behandlung haben, wenn man das modern machen wollte müssten wir vermutlich alles, was irgendwie mit Strings zu tun hat, anfassen.

Ja, das wird denke ich ziemlich kompliziert. Ich sehe auch noch viel "gewachsene" Software, die z.B. noch Probleme mit Umlauten hat. Gerade kürzlich wieder in einer Autodesk-Software gesehen bei der Benennung von Objektgruppen.

Eigentlich müsste man auch einzelne "Zeichen" immer als Substring handhaben. Direkter Index-Zugriff ist da nicht möglich, außer mit einer speziellen String-Datenstruktur die Zeichen-Positionen auf String-Indizes mappt. Das ist immer Suchen+Substring-Operation. Selbst den Index eines "Zeichens"¹ (bzw. "Graphem-Cluster" oder wie auch immer man Zeichen definiert muss man erst "suchen").

¹ Ich hatte ja vor einiger Zeit mal ein Beispiel gebracht wie übel das mit den "Zeichen" in Unicode theoretisch werden kann: https://www.c-plusplus.net/forum/topic/353091/sollte-man-heute-mehr-wstring-anstellen-von-string-einsetzen/17. Dass der Browser das überhaupt korrekt rendern, man da beim Text-Markieren auch tatsächlich ganze "Zeichen" intuitiv auswählen und mit der Textsuche sogar mit einem Suchstring ohne die ganzen Akzente den Text finden kann, zeigt schon, wie viel zum Handling von Unicode-Text dazu gehört.

Gestalt

@Finnegan allerdings

UTF8String utf8 = U"Last äkschn Hero";
utf8.Insert(U"Ä", 4);
//utf8[4] = 'Ä'; ergibt nur Müll
ShowMessage( utf8);

DocShoe

@Gestalt
Das ist das Tolle an UTF8, die ersten 127 Zeichen sind ASCII und damit kompatibel zu allem, was mit ASCII umgehen kann.

Gestalt

@omggg Ein Anwendungsbeispiel und zwar eins wo ich sage das wird niemals passieren aber daran erkennst Du das ein Vergleich über die STL nicht perfekt funktioniert.

Du wolltest es so

Dein Programm welches in die Windows-Registry folgendes schreibt "C:\Toolß\test.exe" um einen Autostart zu bewältigen wenn Windows gestartet wird.
Die test.exe wird gestartet und ließt sogleich aus der Registry diesen Pfad aus und vergleicht diesen mit ihren eigenen Pfad, also "C:\Toolß\test.exe".
Der Vergleich ist TRUE und in den Optionen der test.exe wird eine CheckBox gesetzt die den Anwender zeigt - ich werde automatisch gestartet.

Nun, weil ich ja nix anderes zu tun habe als zu testen und lange Weile habe ändere ich auf der Festplatte den Ordnernamen von "Toolß" nach "Toolẞ" um.

Beim nächsten Windows-Neustart startet wie gewohnt die "test.exe", sie ließt aus der Registry den unveränderten Eintrag "C:\Toolß\test.exe" aus.
Der Vergleich per STL oder Boost schlägt diesmal aber fehl und in den Optionen der test.exe wird die Checkbox nicht gesetzt und dem Anwender gezeigt das dieses Programm nicht automatisch mit Windows startet.

wob

@DocShoe sagte in Zeichenkette vergleichen:

wir gehen davon aus, dass sich alle Zeichen als 16bit-Zeichen in der aktuell verwendeten locale darstellen lassen

na dann... füg doch mal einen Violinschlüssel ein, weil du was mit Musik machen willst. Ach, geht nicht?

Das ist ja genau das Argument, warum wstring eben nicht die Lösung sind. Sie laden zu solchen "halbrichtigen" Lösungen ein. Nehmt doch einfach ASCII und chars. Das ist dann "viertelrichtig"?

omggg

Vielleicht wäre Java doch das richtige Werkzeug ... die Jungs können das nämlich.

Aber, mehr als ein "Ich möchte, dass das funktioniert, habe aber keine konkrete Anwendung dafür", kann ich erst mal nicht erkennen ... Man kann das große Eszett ja noch nicht einmal über die Tastatur eingeben! ... Andererseits bin ich selber oft auch sehr ehrgeizig, wenn es um Herausforderungen geht - das muss nicht per se ein schlechter Charakterzug sein.

oxide

@omggg sagte in Zeichenkette vergleichen:

Aber, mehr als ein "Ich möchte, dass das funktioniert, habe aber keine konkrete Anwendung dafür", kann ich erst mal nicht erkennen ... Man kann das große Eszett ja noch nicht einmal über die Tastatur eingeben! ... Andererseits bin ich selber oft auch sehr ehrgeizig, wenn es um Herausforderungen geht - das muss nicht per se ein schlechter Charakterzug sein.

Also die Anwendungsfälle könnten durchaus Personalausweise und eID Verfahren sein. Dort sind nämlich viele Angaben in Großbuchstaben angegeben. Dann findet man auch das "ẞ" vor.

Was man übrigens sehr leicht mit der Kombination ALT GR + Shift + ß eingeben kann.

Ich schlage vor, vor dem Posten einfach mal nachzudenken.

omggg

Glaube, du hast da ein obligatorisches Downvote vergessen...

DocShoe

@wob sagte in Zeichenkette vergleichen:

na dann... füg doch mal einen Violinschlüssel ein, weil du was mit Musik machen willst. Ach, geht nicht?

Das ist ja genau das Argument, warum wstring eben nicht die Lösung sind. Sie laden zu solchen "halbrichtigen" Lösungen ein. Nehmt doch einfach ASCII und chars. Das ist dann "viertelrichtig"?

wchar_t ist das, womit wir aktuell klarkommen und keine Probleme haben. Sobald man (wie auch schon oben beschrieben) vollständig UTF kompatibel sein möchte muss man sich von der Vorstellung ein Zeichen = ein char/wchar_t verabschieden und ggf. die komplette Textbehandlung der Software umkrempeln. Und das ist ein Aufwand, den wir nicht mal abschätzen können, also bleiben wir dabei, solange keine Probleme auftreten.

Quiche Lorraine

@Finnegan sagte in Zeichenkette vergleichen:

a (U+0061 Kleiner lateinischer Buchstabe A) + ̈ (U+0308 Verbindungszeichen Diärese) = ä ≠ ä (U+00E4 Kleiner lateinischer Buchstabe A mit Diärese)

Interresanterweise hatte ich vor kurzem das Problem.

Finnegan

@Quiche-Lorraine sagte in Zeichenkette vergleichen:

@Finnegan sagte in Zeichenkette vergleichen:

a (U+0061 Kleiner lateinischer Buchstabe A) + ̈ (U+0308 Verbindungszeichen Diärese) = ä ≠ ä (U+00E4 Kleiner lateinischer Buchstabe A mit Diärese)

Interresanterweise hatte ich vor kurzem das Problem.

Wie ich schon erwähnte, Normalisierung ist hier die Lösung, z.B. mit ICU oder den Windows-API-Funktionen. Ich plädiere aber auch nicht dafür, dass man jetzt jede Software komplett umschreiben muss, ich habe da vollstes Verständnis für den Standpunkt von @DocShoe, bei dem es wahrscheinlich weitaus dringlichere Dinge auf der Prioritätsliste gibt.

Aber es ist nicht verkehrt, sich der Problematik bewusst zu sein, daher habe ich sie hier (vielleicht etwas zu wortreich) angesprochen. Besonders für neuen Code oder als mögliche Erklärung für einen mysteriösen Bug.