Unterstützung bei kleinem RegEx

[schmadde]

Das liegt daran, dass es keine Verallgemeinerung für reguläre Ausdrücke gibt,

Doch, es gibt die "reinen" Regular Expressions, das stammt aus der Automatentheorie. Wenn Du grep ohne "-e" nutzt, wirst Du auch nur genau die bekommen.

sondern diese immer auf einem Dialekt beruhen. Aber meiner ist schon recht allgemein ...

Ja, es gibt schon einige verschiedene Erweriterungen. Deine Beispiele sind aber eindeutig PCRE, die sich um Quasi-Standard gemausert haben, weil eine Zeit lang Perl die am weitesten verbreitete Sprache war für Sachen, bei denen man viel mit RegEx gemacht hat - was wiederum als Replacement für awk gebaut wurde, das ebenfalls eine Erweiterung von RegEx beinhaltete - aber eben eine andere. Viele Tools und Libraries haben dann die PCRE Syntax übernommen, sodass viele Leute auch gar nix anderes mehr kennen.

Aber es gibt auch immer noch viele, die das nicht verstehen und vieles kann man auch so schreiben, dass es auch mit anderen RegEx Engines funktioniert. \S kann man auch ohne Probleme als [^ ] schreiben (EDIT: keine Ahnung wie man einen TAB hier ins Posting packt, der gehört natürlich auch noch in die Klammern)

Es wäre schon wichtig zu wissen, mit welchem Tool das genutzt wird.

 

[floq0r]

\S kann man auch ohne Probleme als [^ ] schreiben

Da gibt es aber noch einige andere white-space character die das umfasst

 

[schmadde]

@floq0r In realen Textdateien in üblichen Encodings sind es üblicherweise nur Space und Tab (newline und linefeed sind ja per default bereits als Zeilentrenner genutzt). Welche anderen schweben Dir denn vor bei ISO-8859-15 und dem entsprechenden Subset von UTF-8)?

 

[floq0r]

newline und linefeed sind ja per default bereits als Zeilentrenner genutzt

Was meinst du damit? Die werden von \s (klein s) auch gematcht.

 

[CyborgBeta]

Also, zumindest das Ä und ä (die Umlaute (ß (großgeschrieben) ist noch mal ein Sonderfall)) sollte in jedem UTF-8-Zeichensatz sein. Und sogar im ASCII-256-Zeichnsatz sind die Umlaute enthalten. Also, darüber würde ich mir weniger Sorgen machen ...

Und das \s (kleines s) matcht zum Beispiel in Java: [ \t\n\x0B\f\r], das sind eigentlich alle Whitespaces: https://docs.oracle.com/javase/tutorial/essential/regex/pre_char_classes.html

Dementsprechend macht man es sich mit der Umkehrung [^ <tab>] ein wenig zu einfach ...

Aber bitte ... bevor es hier weitergeht, sollte der TE erst die Sprache und die genaue Definition, was gematcht und was nicht gematcht werden soll, angeben ... sonst tappen wir hier doch noch ziemlich im Dunkeln.

 

[schmadde]

Was meinst du damit? Die werden von \s (klein s) auch gematcht.

Theoretisch werden die gematcht, richtig. In der Praxis liest nahezu jedes Programm, das RegEx verarbeitet (und die stardardmäßig Nutzung der entsprechenden Sprachen/Libraries) den Input Zeilenweise ein, sodass der RegEx-Automat die Newlines gar nicht mehr zu Gesicht bekommt.

Also, zumindest das Ä und ä (die Umlaute (ß (großgeschrieben) ist noch mal ein Sonderfall)) sollte in jedem UTF-8-Zeichensatz sein.

Ja, wenn es UTF-8 ist. ISO-8859-* ist allerdings noch recht weit verbreitet, vor allem wenn älterer Programmcode oder Datenbankschemata im Spiel sind. Hin und wieder liegt ein ISO-8859-* Zeichen auch in 7 Bit Quoted-Printable Codierung vor, wenn auch seltener.

ISO vs. UTF-8 Verwechslung habe ich schon sehr sehr oft gesehen, da muss man wirklich sicher sein, wie die Daten vorliegen.

Und sogar im ASCII-256-Zeichnsatz sind die Umlaute enthalten. Also, darüber würde ich mir weniger Sorgen machen

Es geht nicht darum, ob sie enthalten sind, sondern wie sie codiert sind, da muss die Regex Engine das selbe Verständnis der Codierung haben wie das Daten erzeugende Programm.

Bei ASCII Zeichen 0-127 ist das idR kein Problem, da die Zeichen in allen gebräuchlichen 8 Bit Codierungen gleich gemappt sind. Und ob 16 Bit Codierungen im Spiel sind sieht man eh sofort.

Und das \s (kleines s) matcht zum Beispiel in Java: [ \t\n\x0B\f\r], das sind eigentlich alle Whitespaces:

Da steht also noch ein Form Feed und ein Non breaking space drin, das wird man in einem String so eher selten zu Gesicht bekommen - und will es vielleicht auch gar nicht matchen. Mein Punkt war: Wenn man nicht ganz sicher ist, welche Regex-Erweiterung zur Verfügung steht, ergibt es Sinn, nur das Subset zu verwenden, das auch ohne Erweiterung geht. Die meisten der PCRE spezifischen Ausdrücke sind einfach Shortcuts, die den Ausdruck kürzer/übersichtlicher machen, aber sind nicht wirklich notwendig.

Bei der Nutzung von Extended RE und PCRE ist allerdings zu bedenken, dass das Escaping von Klammern unterschiedlich ist, drum ist es schon wichtig zu wissen, was man denn jetzt vor sich hat.

 

[floq0r]

Theoretisch werden die gematcht, richtig. In der Praxis liest nahezu jedes Programm, das RegEx verarbeitet (und die stardardmäßig Nutzung der entsprechenden Sprachen/Libraries) den Input Zeilenweise ein, sodass der RegEx-Automat die Newlines gar nicht mehr zu Gesicht bekommt.

Zumindest bei Notepad++ ist das nicht so (es gibt aber eine Option in der Suchmaske). Das fände ich für eine tiefere Bearbeitung auch problematisch. Hier und auch an andere Stelle hatte ich auch schon mit unprintable characters zu tun die auch keine Breite eingenommen haben.

 

[Miximus]

Fur sowas ist chatgpt/eine KI ganz interessant

Mit Sicherheit nicht. Hört auf diesen Blödsinn zu promoten!

 

[CyborgBeta]

@Miximus siehe #10 und #12:

Also, eine KI kann eben nur "ungefähr richtige Antworten" geben, und das ist bei regulären Ausdrücken ganz schlecht ... es sei denn, man überprüft sie noch einmal genau.

ChatGPT dafür einzusetzen, wäre total Banane!

Ich verstehe auch nicht, warum #13 die meisten Likes bekommt, obwohl mein Ausdruck deutlich kürzer ist.

Aber jeder wie er möchte. 🤷‍♂️ (Wollte erst, jedem das seine, schreiben ... aber das verstehen dann auch wieder manche falsch)

 

[CaptainPighead]

Danke für die ganzen Rückmeldungen! Sehr spannend - hätte ich nicht gedacht, dass sich daraus solch eine lebhafte Diskussion ergibt, finde ich cool. Ich wollte das Thema mit meinem Mini-RegEx jetzt auch nicht breit treten - es waren hier schon enige tolle RegExes mit denen ich weiter experimentieren kann - lieben Dank hierfür.

Da jemand eine simple OR Verknüpfung aller 4 gesuchter Strings gepostet hatte: klar kann ich sowas machen, aber ich wollte es eben kompakt mit einem Einzelausdruck abbilden. Finde ich a) schöner und b) ging es mir auch drum bei diesem Fal,l noch mal mein doch sehr angestaubtes RegEx Wissen etwas aufzufrischen. Mit Euren Vorschlägen kann ich weiter in regex101.com oder regexr.com das Ganze ausprobieren - hat mir also in jedem Fall geholfen.

Ich wollte den RegEx auch nicht in einer Programmiersprache selber coden, sondern alles was ich dazu weiss ist die Beschreibung der automatischen Kategorisierung meines Bankingtools - wenn ich bei verschiedenen Bäckern einkaufe per elektr. Kartenzahlung, sollten die Umsätze automatisch kategorisiert werden. In der Doku ist nur das zu finden:

Ich habe es zeitlich noch nicht geschafft, damit weiter zu testen, würde aber denken, dass das klappt, solange der RegEx nicht zu exotisch ist und dem PCRE Standard entspricht. Ich probiere damit in Kürze noch mal rum.

Wie gesagt, wollte da auch keine Wissenschaft draus machen - finde RegExe einfach interessant und würde damit gerne das eine oder andere in meine automatische Kategorisierung einbauen - und dabei gleich noch ein wenig Lernen. Das Beispiel mit der "Bäcker-Kategorisierung" für meine täglichen Brötcheneeinkäufe schien mir dazu gut geeignet. 😇

 

[BeBur]

Da jemand eine simple OR Verknüpfung aller 4 gesuchter Strings gepostet hatte: klar kann ich sowas machen, aber ich wollte es eben kompakt mit einem Einzelausdruck abbilden. Finde ich a) schöner und b) ging es mir auch drum bei diesem Fal,l noch mal mein doch sehr angestaubtes RegEx Wissen etwas aufzufrischen.

Ist aber nicht sinnvoll, das mit nichttrivialen regulären Ausdrücken zu lösen. Würde in einem professionellen Setting nicht durch ein gewissenhaftes Review durchgehen. Du kennst die 4 Strings die du suchst, dann suche einfach danach.

Ich verstehe auch nicht, warum #13 die meisten Likes bekommt,

Weil es der einzige sinnvolle Ansatz ist.

Mit Euren Vorschlägen kann ich weiter in regex101.com oder regexr.com das Ganze ausprobieren - hat mir also in jedem Fall geholfen.

Du wirst halt zu 99% einen Fehler einbauen.

PS.: Achso, für dich privat um Umsätze zu kategorisieren. Ja, da kannst du so ein "mehr oder weniger richtiges" RegEx natürlich einsetzen. Werden halt ggf. mal Umsätze falsch kategorisiert, da passiert ja nun nichts schlimmes. Oder-Regeln zu verwenden ist vermutlich aber dennoch robuster, leichter zu erweitern und schneller.

 

[CyborgBeta]

Weil es der einzige sinnvolle Ansatz ist.

Korrekterweise müsste dieser Ausdruck so aussehen:

BAECKER|BAECKEr|BAECKeR|BAECKer|BAECkER|BAECkEr|BAECkeR|BAECker|BAEcKER|BAEcKEr|BAEcKeR|BAEcKer|BAEckER|BAEckEr|BAEckeR|BAEcker|BAeCKER|BAeCKEr|BAeCKeR|BAeCKer|BAeCkER|BAeCkEr|BAeCkeR|BAeCker|BAecKER|BAecKEr|BAecKeR|BAecKer|BAeckER|BAeckEr|BAeckeR|BAecker|BaECKER|BaECKEr|BaECKeR|BaECKer|BaECkER|BaECkEr|BaECkeR|BaECker|BaEcKER|BaEcKEr|BaEcKeR|BaEcKer|BaEckER|BaEckEr|BaEckeR|BaEcker|BaeCKER|BaeCKEr|BaeCKeR|BaeCKer|BaeCkER|BaeCkEr|BaeCkeR|BaeCker|BaecKER|BaecKEr|BaecKeR|BaecKer|BaeckER|BaeckEr|BaeckeR|Baecker|bAECKER|bAECKEr|bAECKeR|bAECKer|bAECkER|bAECkEr|bAECkeR|bAECker|bAEcKER|bAEcKEr|bAEcKeR|bAEcKer|bAEckER|bAEckEr|bAEckeR|bAEcker|bAeCKER|bAeCKEr|bAeCKeR|bAeCKer|bAeCkER|bAeCkEr|bAeCkeR|bAeCker|bAecKER|bAecKEr|bAecKeR|bAecKer|bAeckER|bAeckEr|bAeckeR|bAecker|baECKER|baECKEr|baECKeR|baECKer|baECkER|baECkEr|baECkeR|baECker|baEcKER|baEcKEr|baEcKeR|baEcKer|baEckER|baEckEr|baEckeR|baEcker|baeCKER|baeCKEr|baeCKeR|baeCKer|baeCkER|baeCkEr|baeCkeR|baeCker|baecKER|baecKEr|baecKeR|baecKer|baeckER|baeckEr|baeckeR|baecker|<...>

Wie blind kann man eigentlich sein, um das einen "sinnvollen Ansatz" zu nennen? Sorry, aber diese Diskussion ist mir einfach zu dumm.

 

[BeBur]

Korrekterweise müsste dieser Ausdruck so aussehen:

Nicht wirklich, nein. Du hast doch sogar selber schon case-insensitive vorgeschlagen oder war das nur KI-generiert? Oder scheitert es grad am Begriff "Ansatz"?

 

[CyborgBeta]

@BeBur Hääääääääääääääääääääääääääää? Geht es hier noch um #13 oder meinen RegEx? Entscheide dich mal, was du willst.

 

[BeBur]

@CyborgBeta Wie schon gesagt und ich habe dann sogar auch noch den Grund weiter ausgeführt ist #13 der einzige sinnvolle Ansatz.

 

[CyborgBeta]

Du meinst, der einzige falsche Ansatz.

Aber bleib du ruhig bei deiner Meinung.

Ergänzung (31. März 2025)

Sorry @BeBur, ich bin sprachlich etwas ausfallend geworden ... entschuldige, das wollte ich nicht.

Ich denke, für @CaptainPighead s Einsatzzweck/Use Cases ist ein regulärer Ausdruck durchaus angebracht.

 

[Enurian]

@CyborgBeta Aus dir spricht die Unerfahrenheit. Student oder gerade erst angefangen zu arbeiten? Oder gar nicht professionell in dem Feld unterwegs?
Je einfacher, desto weniger Fehler.
Je einfacher, desto besser lesbar.
Einfach = gut.

Und hier ist es eben am einfachsten, die Anforderungen "exakt eines von vier vorgegebenen Wörtern" direkt umzusetzen statt eine bestmögliche Annäherung zu finden.

 

[CyborgBeta]

Student oder gerade erst angefangen zu arbeiten?

Weder noch, ich muss manchmal selber solche Aufgaben stellen, dann aber nicht so trivial wie hier.

Soweit ich das sehe, hat er nach einem regulären Ausdruck gefragt (auch aus Lernzwecken), und nicht nach einer Oder-Aufzählung.

 

[Marco01_809]

(bäcker|baecker|baeckerei|backshop) ist eine RegEx. Schon baecker ist eine RegEx. So sind die eben definiert. Wo steht geschrieben das man komplexere RegEx-Features nutzen muss? Keine RegEx wäre z.B. (b[äae weil Syntax-Fehler.

Für die Anforderung von "nur genau diese 4 Wörter" und "soll RegEx sein" ist dieser Ausdruck der Beste, weil er ganz ohne Kommentar noch klarstellt das nur genau diese 4 Worte gematched werden sollen und nicht alles Bäcker-ähnliche.

Es ist nur nicht der kürzeste Ausdruck der diese beiden Anforderungen erfüllt. Es ginge z.B.
b(äcker|aecker(ei)?|ackshop). Ist wohl kaum den Aufwand Wert ggü. der ausgeschriebenen Variante. Und wenn wir von Lernzwecken reden dann sollte das auch einschließen wann man RegEx nicht verwenden sollte oder das man seine Ausdrücke nicht unnötig verkompliziert; sind schwer genug zu lesen die Biester.

Die RegEx-Anforderung mag in diesem Fall vielleicht sinnlos erscheinen weil man ja auch startsWith/contains o.Ä. mit reinen Strings verwenden kann, aber wenn man sich eine Software vorstellt wo die Kategorien konfigurierbar oder anderswie abstrahiert sind macht es Sinn das dafür überall einheitlich RegEx verwendet werden. Und das Problem "Enthält einen von n Strings" ist eines für das RegEx bestens gerüstet ist.

 

[CyborgBeta]

(bäcker|baecker|baeckerei|backshop) ist eine RegEx.

Ist case-sensitive. Lies doch mal das ganze Thema.

Ergänzung (1. April 2025)

Und b(äcker|aecker(ei)?|ackshop) vs. b(ä|ae)cker(ei)?|backshop: 29 vs. 26 Zeichen, also 3 Zeichen zu viel ...