Prüfung einer E-Mail-Adresse auf Gültigkeit mittels RPG-Programm

[Asmalsky]

Ich möchte in einem RPG-Programm eine Prüfung einbauen:
Ist die in Feld FELB01 eingetragene E-Mail-Adresse formal zulässig?

Ich möchte dabei lediglich die Syntax prüfen, nicht die Erreichbarkeit der Adresse. Kann mir jemand Informationen geben, worauf dabei zu achten ist (z.B. gültige Zeichen im local part und im Domain part)? Noch besser: Hat jemand genau dies schon mal programmiert und wäre bereit, den Quellcode zu offenbaren?

Bin gespannt auf Eure Antworten :-)

[Fuerchau]

Inzwischen ist das ziemlich egal, aber:
Wichtig ist, dass du Sonderzeichen "@..." nicht per Konstante im Programm definierst sondern aus einer Tabelle (PF) lädst da diese von der CCSID zur Laufzeit abhängig ist.
http://www.web-toolbox.net/webtoolbo...validation.htm
Hier kannst du dir das Javascript (eingebettet auf de Seite) ansehen und nach ILERPG portieren.

[andreaspr@aon.at]

Falls du 7.2 im Einsatz hast kannst du mit Regex einen großteil der Prüfung durchführen lassen.
Da du ja auch in RPG einfach SQL Funktionen einbauen kannst.
Musst dir im Internet nur den richtigen Pattern holen und dann ist es ein 1-Zeiler.

lg Andreas

[Fuerchau]

Du meinst da wohl eher 7.3 (REGEXP_LIKE)?
Aber auch hier gilt, dass du den Ausdruck nach Möglichkeit aus einer Datei und nicht im Programm kodierst.
Helfen könnte da aber ggf. eine UCS2-Konstante, die ist ja CCSID-neutral.

[B.Hauser]

@Baldur
Die regular Expressions wurden via Technology Refresh in 2014 sowohl in Release 7.2 als auch 7.1 eingefügt. In 7.3 sind sie natürlich im Basis-Umfang enthalten.
SQL selber hat übrigens keine Konvertierungs-Probleme. Bei Verwendung von regular expressions erfolgt zunächst eine Konvertierung in double byte (UTF-16 DBCLOB).

Birgitta

[Fuerchau]

SQL hat da bestimmt die selben Probleme wie alle anderen auch, wenn man mit falschen CCSID's umgeht:
Es gilt nämlich immer noch die Aussage, dass Programmkonstanten und Felder selber keiner Codewandlung mehr unterliegen, da beim Laden eines Programmes dies eben nicht passiert.
Codewandlungen finden generell nur bei Zugriffen auf/von Objekten mit CCSID-Unterstützung statt.
Was im Jobspeicher liegt muss also der Job-CCSID entsprechen.

Also Quelle umgewandelt mit CCSID 273 => Hexwerte von Programmkonstanten in 273.
Solange der Job nun in 273 läuft ist auch alles gut.
Änderst du nun den Job auf z.B. 280 (Italien), nimmt auch SQL an, dass deine Hexwerte in 280 sind, was nun mal definitiv nicht stimmt.
Greifst du nun per SQL auf die Tabelle in 273 funktionierts nun nicht mehr.
Das hat auch nichts mit SQL zu tun, da die Codewandlung zwischen Job und DB auf der Schicht hinter SQL, nämlich auf der nativen Zugriffsschicht der PF, durchgeführt wird.

Deine Konvertierung erfolgt auf Basis der Job-CCSID zur Laufzeit und nicht auf Basis der Quell-CCSID zur Compilezeit. Die kann bei abweichender CCSID daher nicht korrekt sein.
Daher sollte man Konstanten generell nicht mit varianten Zeichen definieren (Umlaute, @, #, ...).

Wenn man allerdings sein System sowieso nur in einer Sprache und die Jobs in *HEX führt dem kann das letztlich egal sein. Sollte das System aber mal aus irgendwelchen Gründen mal mehrsprachig werden sollen darf man sich über die auftretenden Probleme dann nicht wundern.
Und da kenne ich nun genug, denen das dann passiert ist.

[BenderD]

... das Problem bei @,#,$,§ und Co ist, dass irgendwelche Deppen die im EBCDIC an verschiedene Stellen gelegt haben - und dann gibt's da noch die RPG Community, die dann solche Zeichen zum Standard für Variablennamen erklären, als ob man mit RPG selber nicht schon genug Probleme am Hals hätte, die kein Mensch braucht...

D*B

[Fuerchau]

Deshalb kann man sein System ja z.B. mit CCSID 500 (Westeuropäisch-International) fahren und für Osteuropa (Polen usw.) gibt es sowieso nur eine CCSID 870.
Ggf. stammt das mit der 273/280/... noch aus Vor-EU-Zeiten (so alt ist die AS/400 ja schon) wo jedes Land eben noch seine eigene CCSID bei der IBM durchgesetzt hat.

[andreaspr@aon.at]

Wie immer stellt jemand eine Frage und man erhälte mehr Probleme als Lösungen, die Teilweise mit der eigentlichen Frage nichts mehr zu tun hat (z.B. falsche Variablenbezeichnungen).
Man muss nicht immer den Teufel an die Wand malen und nach Problemen suchen wo es in diesem Fall keine gibt!
Und ich bin nicht der Einzige der das so sieht. Die User schreiben ja teilweise schon am Anfang, dass sie keine solche Diskussionen haben wollen!!

Also: Ball einfach etwas mehr flach halten.

[BenderD]

Wie immer stellt jemand eine Frage und man erhälte mehr Probleme als Lösungen, die Teilweise mit der eigentlichen Frage nichts mehr zu tun hat (z.B. falsche Variablenbezeichnungen).
Man muss nicht immer den Teufel an die Wand malen und nach Problemen suchen wo es in diesem Fall keine gibt!
Und ich bin nicht der Einzige der das so sieht. Die User schreiben ja teilweise schon am Anfang, dass sie keine solche Diskussionen haben wollen!!

Also: Ball einfach etwas mehr flach halten.

... der Beitrag war flach genug, wie so oft.

[Fuerchau]

Das ist wie mit den Beipackzetteln: Wollen tut die keiner, man bekommt sie trotzdem, das Lesen ist freiwillig.

[holgerscherer]

Das ist wie mit den Beipackzetteln: Wollen tut die keiner, man bekommt sie trotzdem, das Lesen ist freiwillig.

Aber meist ist der Inhalt der Zettel so schlimm, dass man sie auffressen mag

-h