mschnell hat geschrieben:Eigentlich müsste eine Sprache, die mit Unicode-Texten arbeitet mindestens zwei Vergleichs-Operatoren haben: gleicher Code und "Äquivalenz" (=gleicher Drucker-Output).
Ein Äquivalenz-Operator für Strings wäre schon sinnvoll, nur würde den wohl kaum jemand beachten. Ich könnte mir vorstellen, dass es Funktionen wie AnsiCompareText/AnsiCompareString für Unicode umgeschrieben werden und dort solche Dinge beachtet werden.
mschnell hat geschrieben:dazu kommen natürlich noch die bekannten Sachen wie Groß/Kleinschreinbung und Länder-typische Umschrift wie ä = ae
Besser nicht. Unicode ist genau dafür da, dass solche Transkriptionen nicht mehr notwendig sind. Bei solchen Dingen ist die Äquivalenz abhängig von der Aufgabe. ß und ss sind äquivalent, wenn ich kein ß zur Verfügung habe. Sobald ich es aber habe, sind die Zeichen(-kombinationen) nicht mehr äquivalent.
Ein Beispiel von Access: Der Textvergleich arbeitet immer Case-Insensitve; dabei werden auch deutsch "Sonder"zeichen zu US-ASCII normalisiert. ß ist in Vergleichen mit ss/SS gleichwertig -- in Tabellen-Primärschlüsseln aber nicht! Hat man also zwei Benutzernamen, die sich nur durch ß und ss unterscheiden, könnte beiden Benutzern die gleichen Berechtigungen zugeteilt werden ...