Poprawienie funkcji wyłapującej adresy w postach

Jak wiemy, automagiczne wyłapywanie adresów nie zawsze działa dobrze.
Przykład:

Za wyłapywanie adresów odpowiada funkcja url() w pliku parser.php.

Jest tam 5 wyrażeń regularnych, z czego 4 odpowiadają za URL.
Nie analizując ich, napisałem całkiem nowe wyrażenie, które radzi sobie dobrze.. prawie.. stąd ten post.

Problemem jest funkcja strip_html() wywoływana przed url(). Niestety, wywołanie jej po url() sprawi, że zobaczymy znaczniki jako tekst zamiast linków.

Więc należy pomyśleć.. albo jakoś sprytnie zmienić strip_html() albo - co powinno być spróbowane w pierwszej kolejności - poprawić moje wyrażenie. Problem pojawia się tylko przy takich linkach:

aaaaaaa<www.adres.pl>bbbbb
aaaaaaa<www.adres.pl<bbbbb
gdyż > oraz < są wcześniej zamieniane na < i > i to właśnie jest problemem :/

Moja wersja zastępująca 4 obecne wyrażenia:

$patterns[] = "@\b(?<!<image>|<url>|<url=|href=\")(?:(http(?:s)?://|ftp://)|(www\.))([a-z0-9_-]+
(?:(?:/|\.)[][(){}^/$,?+#*:;%~=&a-z0-9ęóąśłżźćńĘÓĄŚŁŻŹĆŃ_-]+)+)@ie";
$replacements[] = "'<a href=\"' . ('\\1' == ''?'http://\\2':'\\1') . '\\3\">' . cut_url('\\1\\2\\3', 70) . '</a>'";

[dodałem enter w wyrażeniu aby nie rozwalało strony]

Zapraszam do dyskusji, do swoich propoycji [szybko je mogę sprawdzić na lokalnym kojocie] - bo obecna wersja na pewno wymaga zmian.</url></url></image>

Nie łatwiej zapewnić poprawną konstrukcję tagów, jak pozwalał na to mój kod?

Ale co to ma do rzeczy?
Przeczytaj jeszcze raz post - totalnie inny problem!

Napisałeś na początku, że miałeś już kod, ale nie radził sobie z linkami, gdy struktura kodu nie była prawidłowa [jak w przykładzie]. Mój kod może jest na to rozwiązaniem.

Chodzi mi o to: gdyby zapewnić, że wysyłany tekst [czyli np.: post] (przez javascript - tak jak robi to mój kod) lub odbierany (przez php - można się ograniczyć wyłącznie do analizy przez php, zamiast javascript) gwarantował (!) poprawną budowę posta: eliminował nieprawidłową budowę tagów, nieznane tagi zamieniał na encje, itp; część późniejszej analizy byłaby o wiele łatwiejsza - tak, jak z powyższym problemem. Miałbyś gwarancję, że link znajduje się między < url> a < /url> i tą część problemu mógłbyś przyjąć za pewnik. Kombinowanie z wyrażeniami regularnymi na tym poziomie byłoby o wiele łatwiejsze. Popraw mnie, gdy coś przeoczam, ale tak widzę ten problem.

Co do nowej wersji kodu, przyznaję, że nie mam jeszcze rozwiązania. Jak coś mi przyjdzie do głowy to napiszę.

Hmm.. Ale kod jest poprawny.
Powiedzmy, że ktoś napisze tak:

Ok.. sorry. Dziś wolno kojarzę, a właśnie skojarzyłam co to za funkcja url(). Głupio mi i postaram się coś pokombinować - może podsunę jakieś rozwiązanie, jak coś wymyślę.

to nie wolne kojarzenie, po prostu częściej pisz przydatne rzeczy bo jak napiszesz raz na rok to później wszędzie chcesz to wsadzać ;P
a na serio to może w tym wyrażeniu nie wypisywać jakie znaczki mogą być w linku, bo będzie ciągłe dopisywanie, tylko zastanowić się jakich znaczków w linku być nie może - ja myślę że wystarczy dać wszystko poza : \s > < i tyle, dwukropek może być tylko na początku przy protokole i ew. po hoście oznaczając port, a potem jest chyba niedozwolony, no bo tak to ciągle będzie - A: "och, ucięło mi linka, przekopiujcie sobie adres do browsera" B: "oj, chyba trzeba dopisać kolejny znaczek do wyrażenia regularnego" C: "o mateczko, kurka wodna, a to peszek, to już trzeci dzisiaj"

// aha, bo to <> jest zamieniane ... to gorzej</span>

a nie można po prostu nie ładować tego w tylko odpowiednio w < url > i < email > i wtedy można stip_html wywołać po url ...

no właśnie.. 'aha'..
problemem jest tylko ta zamiana <> na encje

a jaka jest przeszkoda przed tym co nie "poszarzyłem", żeby po prostu nie zamieniało na html, tylko na bbCode - wtedy przesunąć "magic url" (<- hehe, kto tak nazwał) przed strip_html i strip_html nie usunie tego tylko zostawi, aż na końcu inne wyrażenia regularne się tym zajmie

i przy okazji nie będzie problemów że link napisany normalnie jest inaczej traktowany niż ten zamknięty w url