Błąd w parsowaniu artykułów?

Taki dziwny trochę błąd w artykułach... Wczoraj @Artur Protasewicz popełnił artykuł:

Ekstrakcja reguł z danych

Podejrzewam, że popełnił literówkę l/ł w temacie/ścieżce (po zapisaniu artykułu normalny użytkownik nie ma możliwości przeniesienia lub zmiany ścieżki artykułu). Z tego też powodu założył nowy temat z poprawnym tematem:

Ekstrakcja reguł z danych. / Extraction of rules from data.

Problem w tym, że po wprowadzeniu tekstu do nowego artykułu i jego edycji próba wyświetlenia artykułu powoduje 500 Error wywalając serwer. Taki sam skutek powodowały próby jego podglądu przy edycji...

Po takim krótkim przejrzeniu artykułu umieściłem jedną linijkę tekstu w apostrofach - z tym fragment zaapostrofowanym artykuł wyświetla się już poprawnie. Zaznaczyłem w artykule obok na czerwono, które to dokładnie miejsce:

Jakość zbioru reguł jest wyznaczana po jego znalezieniu według podanego wzoru (patrz B.3). - TO ZDANIE BEZ APOSTROFÓW WYWALA SERWER!!!

Jeśli usuniecie apostrofy i ten mój dopisek to dostaniecie 500 Error :] - nie grzebałem przy nim więcej, żeby nie zniszczyć możliwości ew. znalezienia przyczyny tego błędu, tylko doprowadziłem do możliwości wyświetlenia artykułu.

Samo zdanie nie ma jakiegoś wielkiego znaczenia, raczej może któryś z nawiasów, kropek czy wtf wchodzi w reakcję z czymś wcześniej... ;)

Podsumowując:
Ekstrakcja reguł z danych | Do usunięcia
Ekstrakcja reguł z danych. / Extraction of rules from data. | Do obadania dlaczego bez odznaczenia tego jednego zdania serwer się wywala

Miłego weekendu ;)

Hmm, mega dziwna sprawa :| Na localu to dziala ok.

Debugowaliśmy niedawno trochę podobny problem z parserem.

Problemem są regexy, które przy odpowiedniej kolejności/ustawieniu znaków i odpowiednio dużych tekstach potrafią przepełnić stos i ubić serwer.

msm napisał(a):

Problemem są regexy, które przy odpowiedniej kolejności/ustawieniu znaków i odpowiednio dużych tekstach potrafią przepełnić stos i ubić serwer.

Tylko, że coś takiego jest prawie nie do wychwycenia - trzeba by chyba przy parsowaniu artykułów/postów logować sam proces parsowania w kawałkach (czy też mieć możliwość takiego logowania awaryjnie), żeby wyłapać ten jeden przypadek na ileś tam tysięcy.

Tak przy okazji:
np. zmiana zapisu w tamtym artykule reguł użytych przed tym feralnym zdaniem z pogrubionych:
Jeżeli (A > B oraz C > D oraz E > F oraz G > H) to (X < Y lub Y < 0)

na pseudokodowe:
Jeżeli (A > B oraz C > D oraz E > F oraz G > H) to (X < Y lub Y < 0)

już sama w sobie zmienia diametralnie sposób parsowania i pozostawianie tamtego kłopotliwego zdania w oryginalnej formie nie powoduje "walenia się" serwera... tak, że szukanie konkretnego regexpa, konkretnego kawałka tekstu powodującego ubicie php może być niesamowitą męką :|

a nie lepiej byłoby przysiąść trochę przy tym przy mocnej kawie (bądź piwku, jak kto woli) i zrobić to porządnie? Regexpy rzeczywiście potrafią robić jaja, wg mnie lepiej by było zrobić to nieco trudniej, ale o niebo optymalniej, to znaczy napisać parser od nowa, ale nie przy użyciu regexpów, ale analizować tekst znak po znaku.

Ogólnie to już n-ty bug związany z backtickami, a ja mam kolejny: http://i.imgur.com/6Alv9Mb.jpg - prywatne wiadomości w połączeniu z backtickami. Regexpy są fajne, ale nie do parsowania wielu kombinacji tagów, które w dodatku mogą być wyzamykane (lub nie) losowo...

dzek69 napisał(a):

ja mam kolejny: http://i.imgur.com/6Alv9Mb.jpg

Nie wiem czy to akurat jest błąd, po prostu parsowanie <kbd> w pm-kach nie jest udostępnione... Tu to co jest dostępne w postach, artach i pm-kach jest różnie ustawione, zobacz, że np. w pm-kach działa ustawianie nagłówków tytułów == Tytuł == tak jak w artach, a to znowu nie działa w postach. Tak, że to zależy od tego co Adam uznał za stosowne do włączenia ;)

Niejako przy okazji pm-ek, backticków itp. W treści pm-ek tekst w podwójnych apostrofach wyświetla się fajnie:

Za to na podglądzie listy pm-ek wygląda nieładnie:

Ot, taki drobiazg...

@madmike - ale ja tam nie wpisywałem <kbd>! - backticki coś takiego wynegerowały. Dolar chyba nie ma specjalnego znaczenia, więc to raczej nie to, ale pod spodem wkleiłem link (jako tekst, który został przeparsowany na link) - może znowu w połączeniu z backtickami tak się psuje?

był sobie tutaj link do wątku - to nie jako złośliwość, ale takie małe pokazanie "ułomności" parsera...

tam jest tylko dostatecznie długi tekst w rodzaju:
``ABABABABABA...

a skutek taki, że strona się nie wyświetla, bo czas obróbki takiego czegoś jest niewiarygodnie długi...

Przyciąłem ilość znaków w tamtym poście, żeby się jednak wyświetlał, co i tak zajmuje ponad 20s... backticki rządzą... ;)

dzek69 napisał(a)

ale ja tam nie wpisywałem <kbd>! - backticki coś takiego wynegerowały

Ha, we wcześniejszym poście nie załapałem z tymi pm-kami, backtickami i <kbd>

Teraz zachciało mi się w tamtym moim poście, gdzie jest tylko:

``ABABABABABA...
obejrzeć historię zmian... i co widzę?

co akurat tłumaczy tamto zachowanie w pm-kach...

Tak się zastanawiam, czy nie ma jakiegoś otwartego projektu takiego parsera, który można łatwo konfigurować listą obsługiwanych wyrażeń?
Luźne kuknięcie w neta zwraca albo parser DOM, albo php Tokenizer albo regexy.
Są też generatory parserów, ale nie miałem z nimi styczności i nie wiem czy ich użycie do parsowania takich danych ma w ogóle sens.

Mamy tutaj tęgie umysły. Zachęcam do wspólnego rozwiązania tego problemu :)

@madmike: W serwisie mozna uzywac zarowno backtickow w postaci ` oraz `. Jeden z nich generuje znaczniki <kbd> a drugi <tt></code>. Parsowanie znacznikow <code><kbd> bylo wylaczone w tym miejscu. Teraz zrobilem tak, aby bylo tak samo przy wyswietlaniu zarowno posta jak i wyswietleniu historii zmian.