Bei Email: FW / AW... - Hilfe bei String suche

Hallo,

ich möchte folgendes realisieren:
- Ich überwache mein Emailpostfach, ob neue Emails hereinkommen.
- Gibt es es zu einem Betreff und einer Emailadresse keinen Eintrag in meiner DB wird ein Ticket in der DB - Tabelle angelegt
- Gibt es zu einem Betreff und der Sender-Emailadresse einen Eintrag, wird nur ein Kommentar angelegt.

Soweit so gut.
Nun habe ich aber das Problem, dass bei verschiedenen Emailclients beim Antworten der Betreff geändert wird.
Aus: "1234567 - Mein Problem" wird dann "AW: 1234567 - Mein Problem".
Heißt selbst, wenn ich mit Wildcards suche, dann finde ich kein Match zu "AW: 1234567 - Mein Problem".

Wie könnte ich das lösen?
 
Naja, kann es so machen - aber geht bestimmt auch besser?

Java:
     String subject = message.getSubject();
        subject = subject.replace("AW:", "");
        subject = subject.replace("Aw:", "");
        subject = subject.replace("FW:", "");
        subject = subject.replace("Fw:", "");
        subject = subject.replace("FWD:", "");
        subject = subject.replace("Fwd:", "");
 
subject.endsWith("1234567 - Mein Problem") liefert dann aber immer noch true.
Hier sehe ich nur das Problem, dass ein Betreff angeschnitten sein kann. Daher ist das endsWith ungünstig.

Wirklich effektiv dürfte daher wirklich rein die Prüfung einer ID sein.

Und entgegen EINER einzelnen Meinung: Reguläre Ausdrücke sind extrem mächtig und bieten sich hier förmlich an. Hintergrund ist ja, dass man ja bei einer beliebigen Email dann den Suchbegriff oder die ID finden möchte. Daher ist die Abfrage eines konkreten Falles ja weniger das Anwendungsgebiet (dann würde man die Datenbank durchgehen und für alle Datensätze einen String Compare machen?) sondern es ist eben:
- sinnvolle Verdichtung der Information (daher ist die eine Antwort für mich generell unverständlich. Informationen gehen nicht wirklich verloren, denn der Betreff ist weiter vorhanden. Es gab nur eine notwendige Verdichtung.)
- eine Abfrage auf der Datenbank, ob es da einen Datensatz zu gibt. (Mit index sehr optimiert)

Wenn man nicht nur auf eine ID zugreifen kann, dann sollte man neben dem Entfernen von typischen Ergänzungen überlegen:
- Filter Sonderzeichen - da kann ggf bei den Codierungen etwas schief gelaufen sein
- Längenbegrenzung falls etwas angeschnitten wird ...
Aber da kommt man dann auch evtl. in ein eigenes Spezialgebiet - ähnliche Texte finden .... SQL Server hätte da z.B. NEAR bei der Textsuche um da nur eine Sache aufzuzeigen.
Generell sehe ich da aber immer mögliche Probleme, die eine reine ID Suche evtl. weniger haben sollte (abhängig von den genauen Umständen, die noch nicht beschrieben sind.)
 
Reguläre Ausdrücke sind extrem mächtig und bieten sich hier förmlich an.
Sehe ich auch so. Ich würde die ID mit einem RegEx aus dem Betreff extrahieren und beim Erzeugen der IDs bereits darauf achten, dass die möglichst einfach erkennbar sind und eine geringe Wahrscheinlichkeit zur Verwechsung mit anderen Nummern besteht (z.B. durch ein Präfix wie im Beispiel von @thecain). Manchmal kommt es ja vor, dass eine IT-Abteilung selbst ein Ticket-System nutzt und im Zuge der Bearbeitung eine Anfrage an ein Systemhaus stellt, das ebenfalls ein Ticketsystem einsetzt. Dann hat man bald zwei Ticketnummern im Betreff, von denen nur eine relevant ist. In der DB stützt man sich ja sowieso im Wesentlichen auf die IDs, so dass es keine Performance-Probleme o.Ä. geben sollte.
 
hm, also dann sowas wie:
Wie müsste dann solch ein Audruck aussehen, wenn er so aussehen soll:
[REQ12345]

Ggf. kann er auch so aussehen (prefix + suffix):
[REQ12345TEST]

-> Wobei dann REQ12345 oder REQ12345TEST sein kann
 
Dann bauen wir das mal schrittweise auf:
1) Wir wollen die Daten, die "matchen" ja zurück bekommen, d.h. wir benötigen eine "capturing group". Dies sind einfach ( ) oder wenn man die mit ID will eben (?'ID'....) oder (?<ID>....) Damit haben wir schon einmal (?'ID')
2) Wir wollen die Zeichen REQ - die können wir 1:1 übernehmen: (?'ID'REQ)
3) Dann kommen Ziffern. Eine Ziffer kann ma n als \d oder als [0-9] angeben. Das aber genau 5 Mal: \d{5} Somit erhalten wir: (?'ID'REQ\d{5})
4) Nun wollen wir nichts oder TEST: (TEST|) - wobei das keine Capturing Gruppe sein muss, also (?:TEST|) so dass wir erhalten:

(?'ID'REQ\d{5}(?:TEST|))

Das kann man dann z.B. unter https://regex101.com/ testen.
 
am liebsten wäre mir:
[a) 12345 b) ]

a) Kann jede Buchstabenfolge sein
b) nur Zahlen, maximal 10 Stück
c) Kann jede Buchstabenfolge sein

+ drumherum die Klammern
 
Ahh ja: Die Eckigen Klammern fehlen bei mir auch ... also (?'ID'\[REQ\d{5}(?:TEST|\]))

Da dann noch die Erläuterungen zu dem, was Du noch findest:
Das Fragezeichen bei (TEST)? besagt: TEST einmal oder keinmal.
Die Backslash bei [ und ] sind Escape Zeichen. Mit [] werden eine Menge Zeichen zusammengefasst, also z.B. [a.z0-9] wäre ein Zeichen von a bis z oder 0-9.

am liebsten wäre mir:
[a) 12345 b) ]

a) Kann jede Buchstabenfolge sein
b) nur Zahlen, maximal 10 Stück
c) Kann jede Buchstabenfolge sein

+ drumherum die Klammern
Da sehe ich kein c) - aber das geht natürlich auch. Wobei die Frage ist, ob Du Buchstabenfolge bei a) noch eingrenzen kannst oder willst (mindestens 1 Zeichen, Maximal x Zeichen oder so?) Ansonsten wäre das dann:
a) Die Capturing Gruppe um die ID zurück zu bekommen: (?'ID')
b) Die eckigen Klammern (?'ID'\[\])
c) Beliebige Anzahl Buchstaben: (?'ID'\[[A-Za-z]*\]) *steht für kein bis beliebig viele.
d) 1-10 Ziffern: (?'ID'\[[A-Za-z]\d{1,10}*\]) die {} geben die Anzahl wieder, also {5} hatten wir schon {1,10} wären 1 bis 10 von dem vorhergehenden (hier Ziffern)

Falls ich das nicht richtig verstanden habe, dann kannst Du es evtl. noch anpassen.
 
Sorry, meinte
[a) b) c) ]
-> Also a) und c) können Buchstaben sein.
-> b) ist die eindeutige Nummer aus der DB (Primary Key) , kann nur eine Zahl sein
a) und c) müssen nicht zwingend gefüllt sein. Also es könnte auch nur b) sein

Was ist daran falsch?
(\[[A-Za-z]*\d{1,10}*[A-Za-z]*\])

Als Beispiel:
[REQ1234RE]

Edit: das sollte passen:
(\[[A-Za-z]*\d{1,10}[A-Za-z]*\])

?
 
Zuletzt bearbeitet:
Ja, sieht gut aus. Ich gebe den capturing groups nur gerne ids. Wenn man bei complexen Ausdrücken dann weitere Gruppen einfügt stimmt sonst hinterher die Nummerierung nicht mehr.
Und der Fehler war das * hinter der Anzahl der Ziffern, aber das hattest Du ja selbst erkannt.
 
OK, danke..

Bekomme hier allerdings noch einen Fehler. Wie lautet das richtig dann?

Java:
    String ticketId = "";

        String regex = "(\\[[A-Za-z]*\\d{1,10}[A-Za-z]*\\])";

        Matcher matcher = Pattern.compile(regex).matcher(subject);

        matcher.find();

        if (matcher != null)

            ticketId = matcher.group(0);
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben