Jak debugować wyrażenie regularne? [Zamknięte]

Wyrażenia regularne mogą stać się dość złożone. Brak spacji utrudnia ich odczytanie. Nie mogę przejść przez wyrażenie regularne z debugerem. Jak więc eksperci debugują złożone wyrażenia regularne?

Kupujesz RegexBuddy i korzystasz z wbudowanej funkcji debugowania . Jeśli pracujesz z wyrażeniami regularnymi więcej niż dwa razy w roku, w mgnieniu oka odzyskasz te pieniądze w zaoszczędzonym czasie. RegexBuddy pomoże Ci również tworzyć proste i złożone wyrażenia regularne, a nawet wygenerować kod w różnych językach.

Ponadto, według autora, narzędzie to działa prawie bezbłędnie w systemie Linux, gdy jest używane z WINE .

Z Perl 5.10 use re 'debug';. (Lub debugcolor, ale nie mogę poprawnie sformatować danych wyjściowych w przypadku przepełnienia stosu).

$ perl -Mre = debuguj -e '"foobar" = ~ / (.) \ 1 /'
Kompilowanie REx "(.) \ 1"
Program końcowy:
   1: OTWARTE 1 (3)
   3: REG_ANY (4)
   4: ZAMKNIJ1 (6)
   6: REF1 (8)
   8: KONIEC (0)
minlen 1
Dopasowanie REx "(.) \ 1" do "foobar"
   0 <> <foobar> | 1: OTWARTE 1 (3)
   0 <> <foobar> | 3: REG_ANY (4)
   1 <f> <oobar> | 4: ZAMKNIJ1 (6)
   1 <f> <oobar> | 6: REF1 (8)
                                  nie powiodło się ...
   1 <f> <oobar> | 1: OTWARTE 1 (3)
   1 <f> <oobar> | 3: REG_ANY (4)
   2 <fo> <obar> | 4: ZAMKNIJ1 (6)
   2 <fo> <obar> | 6: REF1 (8)
   3 <foo> <bar> | 8: KONIEC (0)
Mecz udany!
Uwalnianie REx: „(.) \ 1”

Ponadto, można dodać białe znaki i komentarze do regexes, aby były bardziej czytelne. W Perlu odbywa się to za pomocą /xmodyfikatora. Ze pcreistnieje PCRE_EXTENDEDflaga.

"foobar" =~ /
    (.)  # any character, followed by a
    \1   # repeat of previously matched character
/x;

pcre *pat = pcre_compile("(.)  # any character, followed by a\n"
                         "\\1  # repeat of previously matched character\n",
                         PCRE_EXTENDED,
                         ...);
pcre_exec(pat, NULL, "foobar", ...);

Dodam jeszcze jeden, żeby go nie zapomnieć: debuggex

To jest dobre, ponieważ jest bardzo wizualne:

Kiedy utknę na wyrażeniu regularnym, zwykle przechodzę do tego: https://regexr.com/

Jest idealny do szybkiego testowania, gdy coś jest nie tak.

Używam Kodos - Debuggera wyrażeń regularnych Pythona:

Kodos to narzędzie GUI w języku Python do tworzenia, testowania i debugowania wyrażeń regularnych dla języka programowania Python. Kodos powinien pomóc każdemu programiście w wydajnym i łatwym tworzeniu wyrażeń regularnych w Pythonie. Ponieważ implementacja wyrażeń regularnych w Pythonie jest oparta na standardzie PCRE , Kodos powinien przynosić korzyści programistom korzystającym z innych języków programowania, które również są zgodne ze standardem PCRE (Perl, PHP itp.).

(...)

Działa na systemach Linux, Unix, Windows, Mac.

Myślę, że nie. Jeśli Twoje wyrażenie regularne jest zbyt skomplikowane i problematyczne do tego stopnia, że ​​potrzebujesz debuggera, powinieneś utworzyć określony parser lub użyć innej metody. Będzie znacznie bardziej czytelny i łatwiejszy w utrzymaniu.

Istnieje doskonałe darmowe narzędzie Regex Coach . Najnowsza wersja jest dostępna tylko dla systemu Windows; jego autor, dr Edmund Weitz, przestał utrzymywać wersję Linuksa, ponieważ pobrało ją zbyt mało osób, ale na stronie pobierania znajduje się starsza wersja dla Linuksa.

Właśnie zobaczyłem prezentację Regexp :: Debugger autorstwa jego twórcy: Damiana Conwaya. Bardzo imponujące rzeczy: uruchamianie w miejscu lub za pomocą narzędzia wiersza poleceń (rxrx), interaktywnie lub na "zalogowanym" pliku wykonawczym (przechowywanym w JSON), krok do przodu i do tyłu w dowolnym momencie, zatrzymywanie na punktach przerwania lub zdarzeniach, kolorowe wyjście (konfigurowalne przez użytkownika ), mapy cieplne na wyrażeniach regularnych i ciągach znaków w celu optymalizacji itp.

Dostępne bezpłatnie w CPAN: http://search.cpan.org/~dconway/Regexp-Debugger/lib/Regexp/Debugger.pm

Używam tego narzędzia online do debugowania mojego wyrażenia regularnego:

https://www.regextester.com/

Ale tak, to nie może pokonać RegexBuddy.

Debuguję moje wyrażenia regularne na własne oczy. Dlatego używam /xmodyfikatora, piszę do nich komentarze i dzielę je na części. Przeczytaj książkę Jeffrey Friedl Mastering Regular Expressions, aby dowiedzieć się, jak tworzyć szybkie i czytelne wyrażenia regularne. Różne narzędzia do debugowania regex po prostu prowokują programowanie voodoo.

Jeśli chodzi o mnie, zwykle używam narzędzia pcretest, które może zrzucić kod bajtowy dowolnego wyrażenia regularnego i zwykle jest znacznie łatwiejsze do odczytania (przynajmniej dla mnie). Przykład:

PCRE version 8.30-PT1 2012-01-01

  re> /ab|c[de]/iB
------------------------------------------------------------------
  0   7 Bra
  3  /i ab
  7  38 Alt
 10  /i c
 12     [DEde]
 45  45 Ket
 48     End
------------------------------------------------------------------

Używam:

http://regexlib.com/RETester.aspx

Możesz także wypróbować Regex Hero (używa Silverlight):

http://regexhero.net/tester/

Jeśli czuję, że utknąłem, lubię cofać się i generować wyrażenie regularne bezpośrednio z przykładowego tekstu za pomocą txt2re (chociaż zwykle w końcu poprawiam wynikowy regex ręcznie).

Jeśli jesteś użytkownikiem Maca, właśnie natknąłem się na ten:

http://atastypixel.com/blog/reginald-regex-explorer/

Jest darmowy i prosty w użyciu, a także bardzo pomogło mi opanować ogólne wyrażenia regularne.

Spójrz na (niewolne) narzędzia na regular-expressions.info . W szczególności RegexBuddy . Oto post Jeffa Atwooda na ten temat .

Pisanie reg exes przy użyciu notacji takiej jak PCRE jest jak pisanie asemblera: jest w porządku, jeśli widzisz w głowie odpowiadające mu automaty skończone, ale może to być trudne do bardzo szybkiego utrzymania.

Powody, dla których nie używasz debuggera są takie same, jak w przypadku nieużywania debugera z językiem programowania: możesz naprawić lokalne błędy, ale nie pomogą one w rozwiązaniu problemów projektowych, które doprowadziły do ​​popełnienia lokalnych błędów w pierwszym miejsce.

Bardziej refleksyjnym sposobem jest użycie reprezentacji danych do generowania wyrażeń regularnych w języku programowania i posiadanie odpowiednich abstrakcji do ich tworzenia. Wprowadzenie Olina Shivera do jego notacji wyrażeń regularnych schematu daje doskonały przegląd problemów napotykanych podczas projektowania tych reprezentacji danych.

Często używam pcretest - nie jest to „debugger”, ale działa na połączeniach SSH zawierających tylko tekst i analizuje dokładnie dialekt wyrażenia regularnego, którego potrzebuję: mój kod (C ++) łączy się z libpcre, więc nie ma trudności z subtelnymi różnicami w tym, co jest magiczne i co nie jest itp.

Ogólnie zgadzam się z facetem powyżej, dla którego potrzeba debuggera wyrażeń regularnych to zapach kodu. Dla mnie najtrudniejsze w używaniu wyrażeń regularnych zwykle nie są same wyrażenia regularne, ale wiele warstw cytowania potrzebnych do ich działania.

Często używam testera regexp opartego na Rubim Rubular

a także w Emacsie użyj M-x re-builder

Firefox ma również przydatne rozszerzenie

Używam zestawu narzędzi Rx dołączonego do ActiveState Komodo .

Możesz wypróbować ten http://www.pagecolumn.com/tool/regtest.htm

Dla mnie, po przejrzeniu wyrażenia regularnego (ponieważ jestem dość biegły i prawie zawsze używam / x lub odpowiednika), mógłbym debugować zamiast testować, jeśli nie jestem pewien, czy trafiłbym w jakieś zdegenerowane dopasowanie (tj. Coś, co nadmiernie się cofa) aby sprawdzić, czy uda mi się rozwiązać takie problemy, na przykład modyfikując zachłanność operatora.

Aby to zrobić, użyłbym jednej z wyżej wymienionych metod: pcretest, RegexBuddy (jeśli moje obecne miejsce pracy ma na to licencję) lub podobnej, a czasami mierzę czas w Linqpadzie, jeśli pracuję w regexach C #.

(Sztuczka z Perlem jest dla mnie nowa, więc prawdopodobnie dodam ją również do mojego zestawu narzędzi regex.)