Osoby aktywnie udzielające się na programistycznych forach mają zapewne nawet kilka historyjek o próbujących stosować wyrażenia regularne wszędzie, gdzie się da. Osobiście widziałem propozycję wykorzystania funkcji preg_match() tylko do sprawdzenia, czy ciąg A pojawia się w tekście, zupełnie jakby nie istniał przeznaczony do tego celu strpos(). Drugi gatunek to ludzie traktujący wyrażenia regularne jak język programowania, co jest grubą przesadą. preg_match() nie jest w stanie obsłużyć co bardziej zaawansowanych dopasowań i w niektórych sytuacjach trzeba częściowy rezultat obróbki przekazać np. do PHP, by ten zajął się resztą.

Na bazie mego ostatniego doświadczenia chciałbym dołączyć teraz jeszcze jedną grupę: kiedy wyrażenie regularne działa, wygląda na poprawnie użyte, generuje prawidłowy rezultat, ale po pewnym czasie okazuje się, że lepiej, gdyby go nie było. Problem pojawił się w parserze Open Power Template niedługo po premierze wersji 1.1.1, która zawiera m.in. poprawiony błąd z obsługą przestrzeni nazw w atrybutach. Poprawka wymagała lekkiej przebudowy głównego wyrażenia regularnego dzielącego szablon na tokeny - chodziło o to, by była w nim na sztywno zapisana lista przestrzeni nazw, które OPT może parsować. Jednak po kilku dniach zacząłem odbierać wiadomości, że kompilator w trybie XML nie kończy pracy z powodu... przekroczenia 8-megabajtowego limitu pamięci. Ciężko uwierzyć? Mi również, ale okazało się to prawdą. Wyrażenie regularne zaczęło generować ogromną tablicę wynikową o wymiarze NxZ, gdzie N to w przybliżeniu ilość znaków, a Z to ilość grup w wyrażeniu (zależna oczywiście od liczby włączonych ograniczników). Każdy znak zrzucany był do tej tablicy jako pojedynczy wiersz, co dawało ogromne pustki w tablicy - jakieś 95% wszystkich pól zawierało puste wartości, więc ich deklaracja niepotrzebnie "zjadała" pamięć. System wyrażeń regularnych Perla zaimplementowany w PHP nie miał żadnego lekarstwa na tę bolączkę. Żadna z flag nie oferowała możliwości pozbycia się już na etapie przetwarzania pustych komórek, więc siłą rzeczy trzeba było poszukać innego rozwiązania. Podjąłem kolejną próbę zmuszenia OPT do wyłapywania statycznego tekstu jako pojedynczego bloku zamiast literka po literce. Jak zwykle zakończyła się ona niepowodzeniem.

Nie wszystko jednak stracone. Fragment wyrażenia przechwytujący statyczny tekst usunąłem całkowicie, przez co kompilator zaczął wychwytywać same znaczniki OPT we właściwej kolejności, ale bez otaczającego je tekstu. Pozornie taki wynik na nic się nam nie przyda, chyba że przy szablonach kompilacyjnych. Jednak przecież źródło dalej jest załadowane do pamięci, czemu więc by z niego nie skorzystać jakoś? Stąd już prosta droga do banalnego, ale skutecznego algorytmu wykorzystującego funkcję strpos() oraz substr():

1. Ustaw $offset na 0.
2. Pobierz pierwszy token z tablicy. Sprawdź funkcją strpos() jego położenie ($i).
3. Wytnij tekst od $offset do $i i zarejestruj jako węzeł tekstowy.
4. Wykonaj: $offset += $i + strlen($token) (czyli przesuwamy się za właśnie skopiowany tekst i przetworzony token.
5. Przetwórz token.
6. Jeśli są jeszcze tokeny, skocz do (2).
7. Jeśli nie ma, z pozostałego statycznego kodu w szablonie zrób ostatni węzeł tekstowy i zakończ.

Innymi słowy, wycinanie statycznego tekstu zrzucamy na barki PHP, wyrażeniom regularnym pozostawiając samo odnalezienie znaczników. Za skuteczność niech świadczy rezultat: zużycie pamięci na poziomie 20 kb zamiast kilku megabajtów. (dla co poniektórych nadmienię, że funkcja strpos() ma też trzeci parametr $offset oznaczający miejsce w tekście, od którego rozpocząć poszukiwanie - w powyższym algorytmie właśnie z tego korzystam).

Podsumowując: nie zawsze wyrażenie regularne okazuje się najskuteczniejszym sposobem wyciągnięcia z tekstu potrzebnych nam informacji. Niektóre znacznie lepiej jest uzyskać tradycyjnymi metodami, które choć mają nieco większą długość, nie wymagają nie wiadomo jakiej mocy/wiedzy pamięci. A tak na marginesie, skoro już jesteśmy przy OPT - dostępna jest nowa wersja (1.1.2), która usuwa problem z pamięcią.

Powrót

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.