copy-Befehl mag keine Umlaute?

[PascalDragon]

Wenn AllowedChars und AString UTF-8 kodiert ist, dann ist das Iterieren mittels Enumerator aber gefährlich: angenommen AString enthält ein ö, dann enthält ch als aller erstes ein #$c3 (das erste Byte des kleinen ö). Nun suchst du mittels UTF8Pos nach #$c3 und dieses wird dir dann (falls dieses Zeichen nicht eh als ungültig von UTF8Pos zurückgewiesen wird) das #$c3 des ß(!) aus AllowedChars zurück geben. Danach wird dann nach dem zweiten Byte des ö (#$b6) gesucht, welches dann auch tatsächlich bei der Position des ö gefunden wird. Aber je nachdem wie dein AllowedChars aussieht (zum Beispiel kein ö, aber ein anderes Zeichen, welches #$b6 enthält) könntest du hier False Positives oder False Negatives haben.

Ich verwende den in der LazUnicode-Unit implementierten Enumerator. Der geht jeweils um ganz UTF8-"Blöcke" weiter. Wichtig ist, dass die Iterations-Variable (ch in meinem Beispiel) ein String ist, kein char - aber sehe gerade, dass genau das falsch eingetragen ist... So wäre es richtig:

Wenn es den richtigen Enumerator nutzt, dann geht das natürlich, aber auch nur dann

Ich verwende den in der LazUnicode-Unit implementierten Enumerator. Der geht jeweils um ganz UTF8-"Blöcke" weiter. Wichtig ist, dass die Iterations-Variable (ch in meinem Beispiel) ein String ist, kein char - aber sehe gerade, dass genau das falsch eingetragen ist... So wäre es richtig:

Es gibt in LCLType noch den Typ TUTF8Char, wie er auch z.B. von OnUTF8KeyPress verwendet wird. Es ist ein String[7].
Das wäre wohl die Krönung, einfach weil dann von der Deklaration her schon klar ist, was es werden soll.
Aber String geht schon auch.

Der Enumerator in LazUnicode ist eben einfach nur für String als Laufvariable definiert.

[wp_xyz]

PascalDragon, warum ist ein TUTF8Char hier eigentlich ein String[7] und kein String[4]? Ein UTF8-Codepoint kann doch nur 4 Byte umfassen.

[PascalDragon]

PascalDragon, warum ist ein TUTF8Char hier eigentlich ein String[7] und kein String[4]? Ein UTF8-Codepoint kann doch nur 4 Byte umfassen.

Steht doch dabei

Code: Alles auswählen

TUTF8Char = String[7]; // UTF-8 character is at most 6 bytes plus a #0

Das liegt daran, dass UTF-8 erst im November 2003 auf die Zeichen 0 bis $10ffff beschränkt wurde, davor waren prinzipiell auch 5 und 6 Byte Sequenzen möglich (siehe hier, letzter Absatz). Der Typ TUTF8Char wurde zwar erst im September 2004 hinzugefügt (also fast ein Jahr später), aber ich weiß, dass auch in der Wikipedia zu UTF-8 lange Zeit auch noch die 5 und 6 Byte Kodierungen angegeben waren, also entweder hatte Mattias da nichts von mitbekommen oder er hat sich gedacht „better safe than sorry”.

[wp_xyz]

(siehe hier, letzter Absatz).

Etwas weiter oben steht: "and now Microsoft recommends (programmers) use UTF-8." Dann wird demnächst wieder eine größere Umstellung bei Delphi anstehen, und endlich den durch Lazarus gesetzten Standard zu erfüllen.

„better safe than sorry”.

Gute Einstellung

[theo]

Ich verwende den in der LazUnicode-Unit implementierten Enumerator. Der geht jeweils um ganz UTF8-"Blöcke" weiter. Wichtig ist, dass die Iterations-Variable (ch in meinem Beispiel) ein String ist, kein char - aber sehe gerade, dass genau das falsch eingetragen ist... So wäre es richtig:

wenn es den richtigen Enumerator nutzt, dann geht das natürlich, aber auch nur dann

Habe das jetzt einmal ausprobiert. Ein bisschen "tricky" ist das schon.
Wenn die Iterationsvariable nicht exakt vom Typ (Ansi-)String, also z.B. ein UTF8Char ist, oder wenn ich "uses LazUnicode" vergesse einzutragen oder wieder entferne, dann passiert einfach kommentarlos nichts.
Das birgt doch einiges an Bug-Potenzial.