Hinter dem ATTACKIERE folgt ein c2a0, das wird wahrscheinlich nicht als whitespace erkannt: https://en.wikipedia.org/wiki/Non-breaking_space - ich dachte, die werden entfernt, und falls Du wirklich zu attackieren versucht hast (zweite Meldung), scheint das ja zumindest teilweise zu funktionieren. Gucke ich mir also gelegentlich mal an.

Einfachste Lösung: Keine seltsamen unsichtbaren Zeichen verwenden.

Das ist seltsam - ich nutze die Autovervollständigung von Magellan, keine Ahnung warum das mit einem mal Probleme machen sollte.

Nutzt Du denn auch den Versand aus Magellan, oder irgendwelchen Webmail-Mist?

Ich habe den Versand aus Magellan eingestellt wegen der Spam Klassifizierung. Aber über Webmail gehe ich auch nicht, ich kopiere direkt nach Thunderbird. Das habe ich aber auch schon früher gemacht, ohne Probleme. Keine Ahnung wie sich das Zeichen jetzt eingeschlichen hat. Halte ich aber auch nicht weiter für wichtig solange es nicht wieder passiert, und der Agriff wurde ja auch durchgeführt. => Forensische IT kann beendet werden ;-)

Ich kann mir immer noch nicht vorstellen, dass das mit der Spam-Klassifizierung an Magellan liegt, aber Spamfiltern ist ja eher eine Pseudowissenschaft, da soll man nicht zu viel vermuten. Wenn der Versand aus Thunderbird den Text ändert, dann versuch es doch mal mit den Befehlen als Attachment an der Mail. Das sollte der Befehlsempfang kapieren.

In einer Neuauswertung mit aktuellem Code auf meinem Rechner (Windows) tritt das Problem nicht auf. Auf dem Originalrechner (Linux) aber schon. Sicher ein Unterschied in der C standard library, in sowas wie isspace() oder isctrl()?

Für das Zeichen sind iswspace und iswcntrl auf Linux beide 0. Das Problem scheint in unicode_utf8_trim zu sein, aber auch in der parse_token Schleife könnte man das schon überspringen?

char_trimmed(160) ist true in Windows, false in Linux.

https://stackoverflow.com/questions/50952142/why-are-no-break-space-and-others-ispunct-in-glibc

Na, da habe ich ja was losgetreten ;-)

Ich habe eine Lösung gewählt, die ohne die unzuverlässige iswspace Funktion auskommt, und die drei fehlenden Zeichen in char_trimmed() hart kodiert. Das Problem ist, dass iswspace entscheidet, ob ein Zeichen eine Trennung zwischen zwei Worten erlaubt (also z.b. einen Zeilenumbruch im Report), was nicht das Gegenteil der Frage ist, ob es Teil eines Wortes ist. Da es keinen Sinn macht, diese Zeichen an Anfang oder Ende eines Wortes zu setzen, kann ich sie aber getrost löschen, wenn sie das erste oder letzte Zeichen sind (wozu char_trimmed benutzt wird). Testreport zeigt jetzt, dass der Befehl nicht mehr abgelehnt wird!