Regulärer Ausdruck mit [[:cntrl:]] erfasst chinesische Zeichen

[Micha]

Hallo,

in einem Script werden Nutzereingaben - insbesondere der Nutzername - nach unerwünschten Zeichen durchsucht. Unerwünscht sind u.a. (nicht-druckbare) Steuerzeichen, die mit folgendem Ausdruck detektiert werden sollen:

preg_match("/([[:cntrl:]]|\255)/", $string)

Problematisch wird es, wenn die Zeichenkette auch chinesische Schriftzeichen enthält bspw. 测试汉语, da diese als Steuerzeichen erkennt werden. Was muss ich mir unter einem nicht-druckbaren Zeichen vorstellen mit Hinblick auf die genannte Zeichenfolge? Wie könnte ein Ausdruck aussehen, der weniger aggressiv bzgl. chinesischer Zeichen ist aber gleichzeitig nicht-druckbare Zeichen detektiert?

Schöne Grüße Micha

[Der Martin]

Moin,

in einem Script werden Nutzereingaben - insbesondere der Nutzername - nach unerwünschten Zeichen durchsucht. Unerwünscht sind u.a. (nicht-druckbare) Steuerzeichen, die mit folgendem Ausdruck detektiert werden sollen:

preg_match("/([[:cntrl:]]|\255)/", $string)

bedenke, dass die String- und Regex-Funktionen von PHP genaugenommen von Haus aus nicht Zeichen, sondern Bytes verarbeiten. Es ist daher wichtig zu wissen, in welcher Codierung deine Eingabedaten vorliegen. Naheliegend wäre UTF-8, aber ich kann nur mutmaßen.

Problematisch wird es, wenn die Zeichenkette auch chinesische Schriftzeichen enthält bspw. 测试汉语, da diese als Steuerzeichen erkennt werden.

Das heißt, die Byte-Darstellung dieser Zeichen enthält irgendwo einen der Bytewerte 0x00 .. 0x1F, 0xFF oder 0x7F (gehört AFAIR zu :cntrl: dazu).

Was muss ich mir unter einem nicht-druckbaren Zeichen vorstellen mit Hinblick auf die genannte Zeichenfolge? Wie könnte ein Ausdruck aussehen, der weniger aggressiv bzgl. chinesischer Zeichen ist aber gleichzeitig nicht-druckbare Zeichen detektiert?

Wenn du tatsächlich Eingabedaten in UTF-8 hast, solltest du IMO den Modifier u verwenden, um die Regex-Engine von PHP ebenfalls auf UTF-8 einzustellen.

So long,
 Martin

[Micha]

Hallo Martin,

vielen Dank für Deine Antwort.

Naheliegend wäre UTF-8, aber ich kann nur mutmaßen.

Dass ist korrekt, ja.

Wenn du tatsächlich Eingabedaten in UTF-8 hast, solltest du IMO [den Modifier u verwenden]

Super, Danke! Das hilft weiter.

Schöne Grüße Micha

[Gunnar Bittersmann]

@@Der Martin

Das heißt, die Byte-Darstellung dieser Zeichen enthält irgendwo einen der Bytewerte 0x00 .. 0x1F, 0xFF oder 0x7F (gehört AFAIR zu :cntrl: dazu).

Kann doch eigentlich gar nicht. Die Bytewerte der Bytesequenzen von Nicht-ASCII-Zeichen (i.e. ab U+0080) in UTF-8 sind binär 110xxxxx, 1110xxxx, 11110xxx oder 10xxxxx, also weder 00000000 bis 00011111 noch 11111111 noch 01111111.

Oder hab ich da einen Denkfehler?

LLAP 🖖

[Der Martin]

Hallo,

Das heißt, die Byte-Darstellung dieser Zeichen enthält irgendwo einen der Bytewerte 0x00 .. 0x1F, 0xFF oder 0x7F (gehört AFAIR zu :cntrl: dazu).

Kann doch eigentlich gar nicht. Die Bytewerte der Bytesequenzen von Nicht-ASCII-Zeichen (i.e. ab U+0080) in UTF-8 sind binär 110xxxxx, 1110xxxx, 11110xxx oder 10xxxxx, also weder 00000000 bis 00011111 noch 11111111 noch 01111111.

ja, das dachte ich eigentlich auch. Deswegen hat mich Michas Beschreibung des Problems auch erst etwas verunsichert. Aber ich dachte, wer weiß - vielleicht matcht :cntrl: ja noch auf 0x80 .. 0x9F, der Bereich ist ja in den ISO-Latin-Codierungen AFAIR auch reserviert oder nicht definiert oder sowas. Genaue Angaben über den Umfang von :cntrl: habe ich nämlich nicht gefunden.

Oder hab ich da einen Denkfehler?

Möglich. Vielleicht denselben wie ich.

Ciao,
 Martin

[dedlfix]

Tach!

Das heißt, die Byte-Darstellung dieser Zeichen enthält irgendwo einen der Bytewerte 0x00 .. 0x1F, 0xFF oder 0x7F (gehört AFAIR zu :cntrl: dazu).

Kann doch eigentlich gar nicht. Die Bytewerte der Bytesequenzen von Nicht-ASCII-Zeichen (i.e. ab U+0080) in UTF-8 sind binär 110xxxxx, 1110xxxx, 11110xxx oder 10xxxxx, also weder 00000000 bis 00011111 noch 11111111 noch 01111111.

Oder hab ich da einen Denkfehler?

Vielleicht ist auch die Erklärung von Martin nicht ausreichend. Ich habe aber auch auf die Schnelle keine Daten für eine stichhaltige finden können. Sprich: die genaue Definition was in :cntrl: enthalten ist. Lediglich eine andere Theorie: Der Bereich 0x80..0x9F ist je nach Zeichensatz nicht belegt (ISO-8859-1), enthält Steuerzeichen (ISO/IEC 6429) oder Zeichen (Windows 1252). Vielleicht kollidieren die mit einigen der "chinesischen Bytes".

dedlfix.

[dedlfix]

Tach!

Problematisch wird es, wenn die Zeichenkette auch chinesische Schriftzeichen enthält bspw. 测试汉语, da diese als Steuerzeichen erkennt werden.

Kann es vielleicht sein, dass du nicht darauf achtest, mit welcher Zeichenkodierung du arbeitest? Ich sehe keinen Modifier, der die RegExp-Maschine in den UTF-8-Modus schaltet. In welcher Kodierung liegen denn die chinesischen Zeichen vor? PHP nimmt ohne besondere Maßnahmen an, dass es mit ISO-8859-1 zu tun hat.

Was muss ich mir unter einem nicht-druckbaren Zeichen vorstellen mit Hinblick auf die genannte Zeichenfolge?

Wenn du mit PHP zu tun hat, solltest du in die PHP-Dokumentation schauen und nicht in die von Oracle. Nicht druckbare Zeichen sind je nach Zeichenkodierung andere. In ASCII-kompatiblen Zeichensätzen sind das die Zeichen unterhalb von Codepoint 32.

Wie könnte ein Ausdruck aussehen, der weniger aggressiv bzgl. chinesischer Zeichen ist aber gleichzeitig nicht-druckbare Zeichen detektiert?

Die Funktion wird in den UTF-8-Modus geschaltet, bekommt UTF-8-kodierte Werte übergeben und das Muster verwendet nicht Posix-kompatible Zeichenklassen sondern die Unicode character properties.

dedlfix.

[Micha]

Hallo dedlfix

Ich sehe keinen Modifier, der die RegExp-Maschine in den UTF-8-Modus schaltet.

Der scheint dann wohl zu fehlen. ;-) Auch Dir danke für Deine Hilfe!

Schöne Grüße Micha

[Christian Kruse]

Hallo Micha,

Ich sehe keinen Modifier, der die RegExp-Maschine in den UTF-8-Modus schaltet. Der scheint dann wohl zu fehlen. ;-) Auch Dir danke für Deine Hilfe!

Nicht vergessen auf die von @dedlfix erwähnten Unicode Character Properties umzustellen!

LG,
CK

[pl]

Hallo,

in einem Script werden Nutzereingaben - insbesondere der Nutzername - nach unerwünschten Zeichen durchsucht. Unerwünscht sind u.a. (nicht-druckbare) Steuerzeichen, die mit folgendem Ausdruck detektiert werden sollen:

preg_match("/([[:cntrl:]]|\255)/", $string)

Problematisch wird es, wenn die Zeichenkette auch chinesische Schriftzeichen enthält bspw.

Ich würde hier nicht mit Reg.Ausdrücken arbeiten sondern mit Codepoints bzw. Codepoint-Bereichen.

MfG

[dedlfix]

Tach!

Ich würde hier nicht mit Reg.Ausdrücken arbeiten sondern mit Codepoints bzw. Codepoint-Bereichen.

Warum würdest du das tun? Wie konkret würdest du das tun? Und warum nicht die bereits in Unicode vorhandenen Kategorisierungen über die Unicode character properties verwenden?

dedlfix.

[pl]

Tach!

Ich würde hier nicht mit Reg.Ausdrücken arbeiten sondern mit Codepoints bzw. Codepoint-Bereichen.

Warum würdest du das tun?

Weil es einfacher ist mit Zahlen zu operieren als mit Reg.Ausdrücken.

MfG

[Gunnar Bittersmann]

@@pl

Weil es einfacher ist mit Zahlen zu operieren als mit Reg.Ausdrücken.

Von was für Zahlen sprichst du? Von Bytewerten? Bei einer Multibyte-Codierung, ernsthaft?

Man will mit Zeichen operieren. Und wenn man mit Zeichen operieren will, will man nicht mit Zahlen operieren.

TL;DR: Nein.

LLAP 🖖

[pl]

@@pl

Weil es einfacher ist mit Zahlen zu operieren als mit Reg.Ausdrücken.

Von was für Zahlen sprichst du?

Codepoints sind Zahlen, hier kannst Du sie ermitteln für Zeichen die du eingibst.

Man will mit Zeichen operieren. Und wenn man mit Zeichen operieren will, will man nicht mit Zahlen operieren.

Da irrst Du Dich gewaltig!

[Gunnar Bittersmann]

@@pl

Codepoints sind Zahlen,

Und wie soll die Funktion dann aussehen, die nicht-druckbare Zeichen aus einem String fischt?

Möchtest du ein Liste anlegen? Obwohl es eine solche für reg Suchmuster bereits gibt?

Da irrst Du Dich gewaltig!

Na wenn du’s sagst.

LLAP 🖖

[pl]

@@pl

Codepoints sind Zahlen,

Und wie soll die Funktion dann aussehen, die nicht-druckbare Zeichen aus einem String fischt?

Falsche Frage. Die Frage muss vielmehr lauten wie ein Programmierer mit einer Liste von Zahlen umgeht und wie er dem Endanwender eine ordentliche Meldung rüberbringt.

Zwischen Codepoints und Bytes gibt es klare Zusammenhänge, die vom Unicode-Konsortium geregelt sind.

[Gunnar Bittersmann]

@@pl

Und wie soll die Funktion dann aussehen, die nicht-druckbare Zeichen aus einem String fischt?

Falsche Frage.

Das war die Frage, die sich stellt, wenn man (i.e. du) Michas Anliegen nicht mit Suchmuster lösen möchte.

Wenn die Frage falsch ist, liegt das allein daran, dass der Ansatz falsch ist, das nicht mit Suchmuster lösen zu wollen.

Die Frage muss vielmehr lauten wie ein Programmierer mit einer Liste von Zahlen umgeht

Erstmal steht da die Frage im Raum, wo diese Liste herkommt; s.o.

Zwischen Codepoints und Bytes gibt es klare Zusammenhänge, die vom Unicode-Konsortium geregelt sind.

Ich kenne den UTF-8-Algorithmus. Was aber hat der mit dem Problem zu tun?

LLAP 🖖

[pl]

Die Frage muss vielmehr lauten wie ein Programmierer mit einer Liste von Zahlen umgeht

Erstmal steht da die Frage im Raum, wo diese Liste herkommt; s.o.

Aus dem erfassten String wird in eine Liste von Codepoints erzeugt: codepoints('äöü€ß'); erzeugt diese Liste:

Array(
    [0] => 228
    [1] => 246
    [2] => 252
    [3] => 8364
    [4] => 223
)

Zwischen Codepoints und Bytes gibt es klare Zusammenhänge, die vom Unicode-Konsortium geregelt sind.

Ich kenne den UTF-8-Algorithmus. Was aber hat der mit dem Problem zu tun?

Er vermittelt zwischen Character- und Bytesemantic.

[Gunnar Bittersmann]

@@pl

Erstmal steht da die Frage im Raum, wo diese Liste herkommt; s.o.

Aus dem erfassten String wird in eine Liste von Codepoints erzeugt:

Gemeint war die Liste der Zeichen, die rausgefiltert werden sollen. (Hatte ich mich da unverständlich ausgedrückt?) Woher kommt die?

Ich kenne den UTF-8-Algorithmus. Was aber hat der mit dem Problem zu tun?

Er vermittelt zwischen Character- und Bytesemantic.

Ja. Aber wozu sollte man das hier brauchen?

LLAP 🖖

[Christian Kruse]

Hallo pl,

Codepoints sind Zahlen,

Und wie soll die Funktion dann aussehen, die nicht-druckbare Zeichen aus einem String fischt?

Falsche Frage. Die Frage muss vielmehr lauten wie ein Programmierer mit einer Liste von Zahlen umgeht und wie er dem Endanwender eine ordentliche Meldung rüberbringt.

Oh man.

„Ich möchte Steuerzeichen erkennen, preg_match macht da einen Fehler?“
„Benutze lieber Code points“
„und wie erkenne ich damit Steuerzeichen?“
„falsche Frage“

facepalm

LG,
CK

[pl]

Mir ist nicht klar welche Frage ich offen gelassen habe?

[Gunnar Bittersmann]

@@pl

Mir ist nicht klar welche Frage ich offen gelassen habe?

Die nach dem Warum.

Warum willst du eine Liste der Steuerzeichen selbst erstellen (und dabei womöglich was zu vergessen) anstatt die RegExp-Engine zu verwenden, wo es eine solche in Form einer benannten Zeichenklasse bereits gibt?

LLAP 🖖

[pl]

Warum willst du eine Liste der Steuerzeichen selbst erstellen (und dabei womöglich was zu vergessen) anstatt die RegExp-Engine zu verwenden, wo es eine solche in Form einer benannten Zeichenklasse bereits gibt?

Weil die RegExp-Funktion nicht funktioniert, wie vom OP angesprochen.

Zudem ist es einfacher und intuitiver mit Codepoints zu arbeiten (siehe dazu hier)

[Gunnar Bittersmann]

@@pl

Weil die RegExp-Funktion nicht funktioniert, wie vom OP angesprochen.

Doch, das tut sie, wie von anderen hier im Thread angesprochen.

Man kann natürlich alle gegebenen Antworten ignorieren und seinen eigenen Kram als Lösung für sämtliche Probleme der Welt darstellen …

Zudem ist es einfacher und intuitiver mit Codepoints zu arbeiten

Da darf ich dich zitieren: Da irrst Du Dich gewaltig!

LLAP 🖖

[pl]

Zudem ist es einfacher und intuitiver mit Codepoints zu arbeiten

Da darf ich dich zitieren: Da irrst Du Dich gewaltig!

So ganz ohne Argumente ist das von dir schon eine ziemlich nutzlose Aussage.

[Gunnar Bittersmann]

@@pl

Da darf ich dich zitieren: Da irrst Du Dich gewaltig!

So ganz ohne Argumente ist das von dir schon eine ziemlich nutzlose Aussage.

Da mach ich dann mal den Jean-Luc^[1].

LLAP 🖖

---

1. Zumindest der @Christian Kruse wird wissen, was ich damit meine. ;-) ↩︎

[pl]

Da darf ich dich zitieren: Da irrst Du Dich gewaltig!

So ganz ohne Argumente ist das von dir schon eine ziemlich nutzlose Aussage.

Da mach ich dann mal den Jean-Luc[^1].

Anstelle von Argumenten weichst du jetzt mit irgendwelchen Insider-Jokes aus?

Armselig.

[Gunnar Bittersmann]

@@pl

Da mach ich dann mal den Jean-Luc[^1].

Anstelle von Argumenten weichst du jetzt mit irgendwelchen Insider-Jokes aus?

Yep.

LLAP 🖖

PS: Der Joke ist aus Gründen ein Insider-Joke geblieben.

[Der Martin]

Hi,

Da mach ich dann mal den Jean-Luc.

Zumindest der @Christian Kruse wird wissen, was ich damit meine. ;-)

zumindest hat Christian ungefähr die gleiche Frisur wie Jean-Luc alias Patrick Stewart. :-)

Ciao,
 Martin

[Christian Kruse]

Hallo Martin,

Da mach ich dann mal den Jean-Luc.

Zumindest der @Christian Kruse wird wissen, was ich damit meine. ;-)

zumindest hat Christian ungefähr die gleiche Frisur wie Jean-Luc alias Patrick Stewart. :-)

Ganz so viel Glatze hab ich noch nicht, ich lasse immer 3mm stehen ;-)

LG,
CK

[dedlfix]

Tach!

Ich würde hier nicht mit Reg.Ausdrücken arbeiten sondern mit Codepoints bzw. Codepoint-Bereichen.

Warum würdest du das tun?

Weil es einfacher ist mit Zahlen zu operieren als mit Reg.Ausdrücken.

Ich dachte mir schon, dass du an so etwas denkst. Aber ich kann mir noch nicht vorstellen, wie das aussehen soll. Deswegen habe ich ja noch zwei weitere Fragen gestellt, die du geflissentlich ignoriert hast. Wie also soll die einfachere Lösung aussehen, also einfacher als ein einzeiliger preg_match()-Aufruf mit Unicode character properties als Suchmuster?

dedlfix.

[pl]

Tach!

Ich würde hier nicht mit Reg.Ausdrücken arbeiten sondern mit Codepoints bzw. Codepoint-Bereichen.

Warum würdest du das tun?

Weil es einfacher ist mit Zahlen zu operieren als mit Reg.Ausdrücken.

Ich dachte mir schon, dass du an so etwas denkst. Aber ich kann mir noch nicht vorstellen, wie das aussehen soll. Deswegen habe ich ja noch zwei weitere Fragen gestellt, die du geflissentlich ignoriert hast. Wie also soll die einfachere Lösung aussehen, also einfacher als ein einzeiliger preg_match()-Aufruf mit Unicode character properties als Suchmuster?

Deine Fragen hab ich alle beantwortet. Wie ich das machen würde, zeigt mein Tool und hier ist eine entsprechende Library, die Du auch gerne erweitern kannst. Somit kann dem Benutzer ganz konkret hingewiesen werden, an welcher Stelle er ein unerwünschtes Zeichen eingegeben hat und welches Zeichen das ist. Im Übrigen legt das Unicode-Konsortium auch Namen für Zeichen fest, bei einer Fehlermeldung würde ich auch den Namen ausgeben.

Mit einer Zeile preg_match() kriegst Du solch Komfort nicht hin.

MfG

[dedlfix]

Tach!

Deine Fragen hab ich alle beantwortet.

Nein, du hast ein anderes Thema angeschitten, das nicht direkt Gegenstand der Aufgabenstellung war.

Wie ich das machen würde, zeigt mein Tool und hier ist eine entsprechende Library, die Du auch gerne erweitern kannst.

Das zeigt lediglich wie du die Codepoints aus UTF-8-kodierten Zeichen ermittelst. Die Frage, wie man Steuerzeichen in der Eingabe erkennt, beantwortet das jedoch noch nicht.

Somit kann dem Benutzer ganz konkret hingewiesen werden, an welcher Stelle er ein unerwünschtes Zeichen eingegeben hat und welches Zeichen das ist.

Nein, kann man noch nicht, weil die Prüfung auf "unerwünscht" nicht in dem Tool enthalten ist.

Im Übrigen legt das Unicode-Konsortium auch Namen für Zeichen fest, bei einer Fehlermeldung würde ich auch den Namen ausgeben.

Und nun? Diese Namen ermittelt dein Tool nicht.

Mit einer Zeile preg_match() kriegst Du solch Komfort nicht hin.

Den Komfort kann man vielleicht hinzufügen, wenn die grundlegend gewünschte Funktionalität vorhanden ist. Die war, Steuerzeichen zu erkennen. Diese Aufgabe ist in deinem Antwortzweig weiterhin ungelöst.

Also wie kommt man nun mit deiner Methode zum Ergebnis, ob in der Eingabe ungewünschte Zeichen enthalten sind?

Zusatzfrage zu deinem Ansatz der Codepoint-Ermittlung: Du wolltest die Namen der Zeichen anzeigen. Wie ermittelst du diese?

dedlfix.

[pl]

Tach!

Deine Fragen hab ich alle beantwortet.

Nein, du hast ein anderes Thema angeschitten, das nicht direkt Gegenstand der Aufgabenstellung war.

Wie ich das machen würde, zeigt mein Tool und hier ist eine entsprechende Library, die Du auch gerne erweitern kannst.

Das zeigt lediglich wie du die Codepoints aus UTF-8-kodierten Zeichen ermittelst. Die Frage, wie man Steuerzeichen in der Eingabe erkennt, beantwortet das jedoch noch nicht.

Das sind Codepoints unter 0x32 und noch ein paar Weitere, siehe UnicodeData.txt unter <control>

Somit kann dem Benutzer ganz konkret hingewiesen werden, an welcher Stelle er ein unerwünschtes Zeichen eingegeben hat und welches Zeichen das ist.

Nein, kann man noch nicht, weil die Prüfung auf "unerwünscht" nicht in dem Tool enthalten ist.

Im Übrigen legt das Unicode-Konsortium auch Namen für Zeichen fest, bei einer Fehlermeldung würde ich auch den Namen ausgeben.

Und nun? Diese Namen ermittelt dein Tool nicht.

doch (sofern die Namen verfügbar sind)

Also wie kommt man nun mit deiner Methode zum Ergebnis, ob in der Eingabe ungewünschte Zeichen enthalten sind?

indem man die Oktettenwertigkeiten bzw. die resultierenden Codepoints prüft.

Zusatzfrage zu deinem Ansatz der Codepoint-Ermittlung: Du wolltest die Namen der Zeichen anzeigen. Wie ermittelst du diese?

Das Unicode-Konsortium veröffentlicht diese Namen in einer Datei UnicodeData.txt Tipp: Suchbegriff control (70 Treffer und in der Ergebnistabelle steht auch, welche Oktetten das sind)

[pl]

Den Komfort kann man vielleicht hinzufügen, wenn die grundlegend gewünschte Funktionalität vorhanden ist. Die war, Steuerzeichen zu erkennen. Diese Aufgabe ist in deinem Antwortzweig weiterhin ungelöst.

Mit dem Suchbegriff control findest Du eine Liste von 70 Steuersequenzen. Und da gibts welche die Du mit Regulären Ausdrücken gar nicht erfassen kannst, weil sie faktisch gar keine Zeichen sind -- die kannst Du nur über den entsprechenden Codepoint rausfiltern.

Schönen Abend noch!

[Christian Kruse]

Hallo pl,

Mit dem Suchbegriff control findest Du eine Liste von 70 Steuersequenzen. Und da gibts welche die Du mit Regulären Ausdrücken gar nicht erfassen kannst, weil sie faktisch gar keine Zeichen sind -- die kannst Du nur über den entsprechenden Codepoint rausfiltern.

I call bullshit. Auch wenn es non-printables sind, Regexen können jedes Zeichen finden. Im schlimmsten Fall gebe ich den Codepoint des Zeichens halt direkt an, z.B.: /\N{U+263D}/

LG,
CK