Stringvergleich nicht wie gewünscht

[RavenIV]

Zitat von ripper8472:

wenn das einer nach delphi uebersetzen kann, viel spass damit. hab ich ausm netz gefischt.
funktioniert eventuell besser als das vorgefertigte etwas aus der borland-trickkiste.

das wird ihn nicht begeistern, weil er sich ja auch für Gross/Kleinschreibung interessiert...

[dfried]

Ich glaub das ist nich das was er wollte, weil da die Groß-/Kleinschreibung NICHT berücksichtigt wird (tolower)!

edit: Shit RavenIV war schneller

[Grishnak]

Stringvergleich unter Beachtung der Groß-/Kleinschreibung:

if S1 = S2 then ... Stringvergleich ohne Beachtung der Groß-/Kleinschreibung:

if UpperCase(S1) = UpperCase(S2) then ... Wo liegt das Problem?

[dfried]

Zitat von Grishnak:

Wo liegt das Problem?

Das Problem liegt darin, dass dein aufgezeigter Vergleich abhängig vom eingestellten Gebietsschema ist, CompareStr aber "wird vom aktuellen Gebietsschema nicht beeinflusst" (Zitat aus der OH).

[RavenIV]

war mir doch so, dass das "=" auch Gross/Kleinschreibung beachtet
als Referenz: Delphi-Referenz -> im unteren Drittel:

Zitat:

Das Vergleichen von zwei Strings erfolgt mit dem Gleichheitszeichen. Dabei wird Groß- und Kleinschreibung beachtet.

[Grishnak]

@dfried: Kannst du mir mal ein Beispiel zeigen, wie das Gebietsschema einen Stringvergleich beeinflussen kann? Da kann ich mir nix drunter vorstellen Und: ist das hier überhaupt wichtig?

[dfried]

@Grishnak
Ein konkretes Beispiel kann ich dir leider so spontan auch nicht geben. ABer vielleicht einen Teil aus der OH zum Thema (zu finden bei der Funktion AnsiCompareStr)

Zitat:

Hinweis: Bei den meisten Gebietsschemas haben Kleinbuchstaben einen kleineren Wert als die entsprechenden Großbuchstaben. Dies widerspricht der ASCII-Sortierfolge, in der Kleinbuchstaben einen größeren Wert haben. Wenn Sie S1 auf 'a' und S2 auf 'A' setzen, gibt AnsiCompareStr daher einen Wert kleiner als Null zurück, während CompareStr mit denselben Argumenten einen Wert größer als Null liefert.

Borland hat warscheinlich nicht ohne Grund die Funktion CompareStr und AnsiCompareStr geschaffen

Ob das hier von Bedeutung ist, muss dir padavan beantworten!
Ich bin nur darauf eingegangen weil er in seinem Post selbst schon CompareStr erwähnt hat.

[Grishnak]

@dfried: ich dachte, es geht hier darum, zu prüfen ob zwei Strings gleich sind (oder nicht), aber nicht, wie "ungleich" sie sind! Naja, lassen wir den Thread-Ersteller zu Wort kommen...

[padavan]

Wow, "eure" Diskussion liest sich spannender als Harry Potter.

Also danke für das Wort.
Ich meinte für meinen Fall das schon so, das zwei Strings auf Gleichheit überprüft werden sollen.
Wie ungleich sie sind, wäre mir dann eigentlich egal.
Bei einen Passwort ist es ja das gleiche, Groß-Kleinschreibung und die Länge sind da ja auch relevant.

Comparestring vergleicht also auf Gleichheit unter allen Gesichtpunkten?
(ich kann´s erst heute Abend prüfen, hab auf der Arbeit leider kein Delphi)

Dann hätte ich einfach nur einen anderen Fehler gemacht.....

[Puhbaehr]

Wenn ich 'A' und 'B' ('A' = 'B') vergleiche wird intern ja auch der ASCII-Code nämlich 65 und 66 verglichen.
Somit wird auch 'A' und 'a' auf den ASCII-Code "überpürft" nämlich 65 und 97.
Ich kann ja auch zu 'A' eins dazu addieren --> 'A' + 1 = 65 + 1 = 66 = 'B'.
Ich könnte auch 'A' und 'B' miteinander addieren --> 'A' + 'B' = 65 + 66 = 131 = 'ƒ'
Wobei hier der Compiler wegen Typeninkompatiblität meckern sollte (habs in Delphi noch nicht ausprobiert).
Also warum sollte es bei längeren Zeichenketten nicht funktionieren?

Oder meint ihr es hängt von der verwendeten ASCII-Tabelle ab? Aber in welcher Tabelle würde dann 'A' = 'a' sein