[Ben]

Morgen,
ich habe folgendes Problem.

Ich möchte einen URL auf Korrektheit prüfen. Dabei soll natürlich auch berücksichtigt werden, dass sogenannte Umlaut-Domains ja mittlerweile erlaubt sind.

Ich habe hier den folgenden Ausdruck gefunden:

PHP-Code:

$pattern = "(?:https?://(?:(?:(?:(?:(?:[a-zA-Z\d](?:(?:[a-zA-Z\d]|-)*[a-zA-Z\d])?)\.)*(?:[a-zA-Z](?:(?:[a-zA-Z\d]|-)*[a-zA-Z\d])?))|(?:(?:\d+)(?:\.(?:\d+)){3}))(?::(?:\d+))?)(?:/(?:(?:(?:(?:[a-zA-Z\d$\-_.+!*'(),]|(?:%[a-fA-F\d]{2}))|[;:@&=])*)(?:/(?:(?:(?:[a-zA-Z\d$\-_.+!*'(),]|(?:%[a-fA-F\d]{2}))|[;:@&=])*))*)(?:\?(?:(?:(?:[a-zA-Z\d$\-_.+!*'(),]|(?:%[a-fA-F\d]{2}))|[;:@&=])*))?)?)"; 


Der Ausdruck wurde von einem Programm erstellt, welches die Erstellung anhand dieser Beschreibung (die Seite an sich scheint es nicht mehr zu geben?) realisiert.

Der scheint aber keine Umlaute mit zu berücksichtigen...
Kann mir jemand helfen?

Hier finde ich auch nicht wirklich das, was ich brauche. :-/
http://regexlib.com/RETester.aspx?regexp_id=1004

[Ben]

Okay, ich hab nun das hier:

PHP-Code:

(http|https:(//[a-zäöü0-9]+([-.]{1}[a-zäöü0-9]+)*.[a-z]{2,5}(:-)[0-9]{1,5})?/.*)?$/i 


Ist vielleicht nicht unfehlbar, aber für den 0815-Gebrauch wahrscheinlich(?) in Ordnung.

Meinungen?


Am Rande:
Sind eigentlich Umlaute in Subdomains möglich?

[Ben]

Und nochmal ich, weil hier so viel los ist.

Hat nur bedingt etwas mit obigem Problem zu tun, aber manchmal braucht man auch nur pragmatisch zu sein.

Ich möchte überprüfen, ob ein String mit http oder https beginnt und ob mindestens ein Punkt vorhanden ist.
Bestenfalls sollten hinter dem letzten Punkt nur eine begrenzte Anzahl von Zeichen erlaubt sein.

Danke

[MrNiceGuy]

Also erstmal: Es scheint, als würden auch Subdomains damit funktionieren, allerdings sollte man dann schon wissen, wie die Konvertierung abläuft, damit man das im DNS-Server entsprechend einstellen kann (sofern notwendig).

Zur Abfrage selbst habe ich in meinen scripten folgenden RegEx genutzt:

'°(^|\s)((?:http|https|ftp)\://(?:[\w]+\.)+[\w]+(?:\:[\d]+)?(?:/[\S]*)*)(\s|$)°is'

Dieser RegEx ist sicher nicht perfekt, arbeitet aber bislang sehr zuverlässig. Ich denke, dass man das \w einfach durch die entsprechenden Umlaute erweitern könnte, ohne dass es zu Problemen kommt. Allerdings sind die IDNs je nach TLD unterschiedlich, wie im Artikel auf Wikipedia zu sehen.

Achso, noch etwas: Die Seite zum RFC 1793 ist folgende: ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt

[pago]

Hmmm... das naheliegende geht nicht, weil?

^https?://.*?\.\w{2,4}

Ungetestet, aber irgendwie so sollte es sein...

Ansonsten: Ich hab zwar selbst auch noch keinen, aber bei URLs und E-Mail-Adressen sollte für die Verifikation echt kein Regex zum Einsatz kommen. Kann doch kein Mensch warten sowas.

Edit: Das kommt davon, wenn man nebenher noch was anderes tut.

[Ben]

Danke, aber ich werde es so machen
Bräuchte da aber nochmal Hilfe. Komme irgendwie nicht damit zu Recht, dass es "mindestens" einen Punkt geben muss.


Als Nachtrag zur Ausgangsfrage bzw. deiner Antwort.
Durch die neue Sonderzeichenregel (so nenn ich das jetzt mal) wird es eben relativ komplex.
Siehe: http://de.wikipedia.org/wiki/Interna...chens.C3.A4tze

.at = 34 neue Zeichen
.de = 92 neue Zeichen
.ch/.li = 32 neue Zeichen

Das nur als Beispiel.
Da ist der Kosten-Nutzen-Faktor bei einer pragmatischen Implementierung definitiv am größten.

[Ben]

Zitat von pago

Hmmm... das naheliegende geht nicht, weil?

^https?://.*?\.\w{2,4}

Ungetestet, aber irgendwie so sollte es sein...

Explizit dieser Ausdruck geht nicht.

Beispiel: http://www.regex-tester.de/uc_402_de.html

[FloB]

Dann brauchst du einen Greedy-Modifier bzw. musst den Ungreedy abstellen.

Da ja nahezu alle Sonderzeichen erlaubt sind (also nicht nur Umlaute), wäre diese Lösung die richtige. Zusätzlich sollten noch Unterverzeichnisse erlaubt sein - also hintendran eine Überprüfung auf beliebig viele Slashs und weitere Zeichen. Außerdem sind bei der Prüfung fünfstellige TLDs nicht zugelassen - z.B. .travel oder .museum .

Hier: http://www.regex-tester.de/uc_403_de.html (ohne Unterverzeichnis-Pattern).

[Ben]

Zitat von FloB

Außerdem sind bei der Prüfung fünfstellige TLDs nicht zugelassen - z.B. .travel oder .museum

Kosten-Nutzen ..
Wie oft wird so etwas auf einer Seite, wo sich private Leute aufhalten eingegeben? Ich glaube nicht, dass es sich da um mehr als 0,1% handelt.
Demnach beschränke ich es einfach auf 4 (.info) und gut ist.

Ich habe es aktuell nun so gemacht

PHP-Code:

$pattern = '^https?:\/\/(.*){2,}\.\w{2,4}'; 


Danke für die Antworten.

[MrNiceGuy]

Ich bedenkt aber schon, dass es mit dem . auch möglich wäre Leerzeichen, Zeilenumbrüche, etc. in due URL einzubauen? Das darf man nämlich nicht (und macht auch keinen Sinn soetwas zuzulassen).

[MrNiceGuy]

Zitat von pago

[...]
Ansonsten: Ich hab zwar selbst auch noch keinen, aber bei URLs und E-Mail-Adressen sollte für die Verifikation echt kein Regex zum Einsatz kommen. Kann doch kein Mensch warten sowas.
[...]

Ähm, wieso sollte es das NICHT? Es macht sogar sehr viel Sinn, dass man gerade für so dynamische Verifikationen einen RegEx nutzt. Mal ganz ehrlich: Wie häufig hat sich der Aufbau von URLs in den letzten 20 Jahren geändert?!

Ich frage mich übrigens, warum meinem RegEx niemand Beachtung zu schenken scheint, ist der zu kompliziert?

[Ben]

Solange man keinen Schadcode einfügen kann ..

EDIT:
Ich habe ihn mir nicht angeschaut, weil er imho auf den ersten Blick nicht die Angaben aus Post#6 berücksichtigt. Da genau das aber in meinem speziellen Fall sehr wichtig ist .. ist eben die pragmatische Lösung rausgesprungen.

[MrNiceGuy]

Nunja, da der Punkt JEDES beliebige Zeichen repräsentieren kann, stellt der RegEx zumindest keinen Schutz vor Schadcode dar. Eine SQL-Injection ist damit durchaus denkbar / möglich, wenn der Rest des Codes nicht passt. Ansonsten würde mich der Gedanke trotz Allem stören, dass der RegEx so "greedy" ist...

[FloB]

Ja, zählen sollte man können

Edit: Alternativ überprüft man auf die TLD + Endung und zusätzlich optionale Subdomains. Das erhöht die Sicherheit vor möglichen Injections. Das Whitespace-Problem sollte natürlich ausgeschlossen werden.

[Ben]

Bevor das weggeschrieben wird, wird sowieso noch mit stripslashes und Konsorten gearbeitet. Ich sehe aktuell nicht, wie mehr "Schaden", als ein "kaputter" Link entstehen sollte.

Wenn jemand http://test_blubb mist.de eingibt .. jo, und?

[Ben]

Ich werd noch wahnsinnig!

Habe noch etwas weitergemengt und habe nun das hier als RegExp

https?:\/\/.{2,}\.\w{2,}

Kleine Testreihe sieht man hier: http://www.regex-tester.de/uc_406_de.html

Mich stört das \w am Ende, da es ja alphanumerische Zeichen durchlässt. Eine Domainendung kann aber ja nur aus Buchstaben bestehen, oder? Bei dem ganzen TLD-Hickhack weiß ich mittlerweile gar nichts mehr bestimmt!

Ich habe versucht das \w einfach gegen ein \D oder ein [a-z] auszutauschen, aber das bringt dann bei der oben verlinkten Testreihe nicht die gewünschten Ergebnisse.
Danke für die weitere Hilfe

[MrNiceGuy]

Meinst du, weil der RegEx auch auf "http://www.ichbineineurlohnekorrektetld.tld123" passt? Dann müsstest du folgendes ans Ende einfügen:

(?:/|\s|$|:[\d]+)

Damit hast du in Verbindung mit [a-z] die Gewissheit, dass sich am Ende der URL entweder das Ende des Strings befindet, ein Leerzeichen die URL vom restlichen Text trennt (sofern vorhanden), ein Slash folgt oder eine Port-Angabe vorhanden ist. Allerdings hast du dann wieder ein Problem mit URLs bei denen ein Port angegeben wird.

[Jann Hendrik]

Zitat von MrNiceGuy

eine Port-Angabe vorhanden ist. Allerdings hast du dann wieder ein Problem mit URLs bei denen ein Port angegeben wird.

das widerspricht sich!

[Ben]

Erklär mir das Pattern bitte mal mit Worten. Danke.
Der Port ist schnuppe .. braucht nicht berücksichtigt zu werden.

[CIX88]

@Ben

Ich möchte einen URL auf Korrektheit prüfen

Mich wundert jetzt ein wenig, dass du dies mit Regex machen willst.
Geht es um URLs die noch nicht vorhanden sind?
Ansonsten würde ich die URL mit einer CURL-Abfrage einfach testen.