ugrás a tartalomhoz

Tagadás regexben

Anonymous · 2006. Okt. 17. (K), 13.48
Sziasztok,

hosszas keresgeles utan teszem fel itt a kerdesemet:

hogyan lehet regexben tagadni?
azaz van egy peldaszovegem:
alma narancs korte
ebbol kellene megkeresni az olyan szavakat, amik nem alma.

Az eredeti problema a kovetkezo:
van egy adatbazisbol jovo szoveg, amik tartalmazhatnak linkeket es kepeket is a kovetkezo formaban:
link: [url=http://www.akarmi.hu]linkszoveg[url]
kep: [img=http://kephelye.hu/akarmi.jpg]Kepfelirat[/img]
illetve ohatatlanul tartalmazhatnak mondjuk 60 karakternel hosszabb szavakat, amelyek szettoljak a designt (css megoldast nem szeretnek, overflow: hidden; stb)
Olyan regexet szerettem volna irni, hogy adjon hozza egy szokozt minden 60. karakter utan - ez rendben is van, csakhogy a linkeket ez el fogja rontani!
Tehat a szabaly: adj hozza egy szokozt minden 60. karakter utan, kivetel ha az nem \[url=.*\].*\[url\] alaku.

Ti hogyan oldanatok meg ezt a problemat?

Elore is kosz a segitseget.
‹ xhtml+table+div=IE bug? IE duplázás hiba CSS float miatt? ›
 ■
1

RegExp look ahead

Török Gábor · 2006. Okt. 17. (K), 14.48
Negatív előre tekintéssel (negative lookahead assertion/lookahead negation) tudod talán ezt megoldani.

<?php
$str = "alma naracs korte";
preg_match_all('/\b(?!alma)\w+\b/i', $str, $matches);
print_r($matches[0]);
Eredmény:

Array
(
    [0] => naracs
    [1] => korte
)
2

Felkiáltójel

kerzo · 2006. Okt. 17. (K), 17.25
Ha jól tudom, akkor a !-lel lehet tagadni.
Valahogy így: !\[url=.*\].*\[url\]
Tehát olyan szövegrészt keressen, amiben nincs az általad felsorolt karakterlánc. Ezzel az a baj, ha végiggondolod, hogy a teljes link linkszöveggel együtt kiesik a feldolgozásból, mert azt mondod, hogy olyat keresel, amiben az url nyitó és záró része nincs benne. Mivel az általad kért adatban ez benne van, így nem kapsz eredményt.

A megoldás az lehet, hogy a karakterlánc elejétől nézve megkeresed az első ] jelet, a karakterlánc végéről pedig az első [ jelet. Ezekre két értéket kapsz, amelyek a ] és [ jel pozíciói a karakterláncban.

A két érték közötti különbség fogja megadni a linkszöveg hosszát. Ha ez nagyobb, mint 60, akkor valahova beszúrhatsz egy szóközt, vagy <br />-t, ügyelve arra, hogy a törés a linkszövegbe essen.
4

Nem tagadás

Török Gábor · 2006. Okt. 17. (K), 17.56
Tudtommal regexpben nincsen ilyenfajta tagadási módozat. Tudnál mutatni működő kódot az elgondolásodra?
6

egy kis kapkodás

kerzo · 2006. Okt. 17. (K), 20.01
Ugy gondolom, hogy egy kicsit elkapkodtam a válasznak ezt a részét. Az elképzelés azon alapult, hogy van egy AWK mintakereső és -feldolgozó program, ahol a negálás működik a !-lel. Meg használom ModRewrite-nál .htaccesben, ott működik, de gondolom az egy más szisztéma.
8

Egész regexp nem illeszkedik

Ajnasz · 2006. Okt. 17. (K), 21.57
A felkiáltójeles megoldás akkor lenne jó, ha a feltétel nem egyezése esetén végeznél műveletet:
<?php
$str = 'körte narancs almabor';
if(!preg_match('/\balma\b/i', $str, $matches)) { ... }
?>
3

mi ez?

kerzo · 2006. Okt. 17. (K), 17.34
Egyébként mi az a képfelirat? Most kép, vagy felirat?
7

a kepfelirat

Anonymous · 2006. Okt. 17. (K), 20.34
az img tag alt tagje.
9

alt != felirat

Táskai Zsolt · 2006. Okt. 18. (Sze), 11.19
az alt _alternatív_ szöveg, vagyis akkor jelenik meg, amikor a kép nem tud. IE félreérti, de az már más kérdés... a felirat a title.
5

off: CSS

Marcell · 2006. Okt. 17. (K), 18.06
Ezen én is sokat filóztam, és végül a CSS 
overflow: auto;
melett döntöttem, párhuzamosan tiltva az IE-nek a horizontális gördítősávot a 
overflow-y: hidden;
tulajdonsággal (conditional commentben, hogy validator ne szóljon be). Így csakis vízszintes van és csak akkor ha tényleg kell.

Hogy minek ajánlgatom és miért is csináltam végül így? Azért, mert nem tudtam egy értelmes karakterszámot kitalálni, ami megfelelt volna minden igénynek. Mert az M betű nem olyan széles, mint egy i és akkor a kiszámolt karakterérték máris ugrott. Nekem mondjuk egy vékonyabb dobozba kellett, tehát nem is volt ronda ha véletlenül betette a scrollt és szélességben is korlátozva voltam.

Akármilyen számot találtam ki, a gyakorlat azt mutatta, hogy a felhasználók ki tudtak találni olyan értelmes magyar szavakat (teljesen véletlenül), amit épp egy betű miatt tört meg a régi PHP-s megoldás, pedig még befért volna, csak hát a PHP értelmező ezt nem úgy gondolta.