Zmiana znaczenia znaku ukośnika w przód w wyrażeniu regularnym

106

Moje pytanie jest proste i dotyczy ucieczki wyrażenia regularnego. Czy musisz unikać ukośnika /w wyrażeniu regularnym? A jak byś to zrobił?

regex perl escaping

— Zerobu
źródło

1

Jakiego języka / implementacji wyrażeń regularnych używasz?

— Gumbo

Co ciekawe, szukałem tego pytania dla Javascript. Ale wtedy moje IDE powiedziało, że używam niepotrzebnej ucieczki. Tak myStr.replace(/[/:.-]+/gi, '_')jest, ku mojemu zaskoczeniu. Myślałem, że będę potrzebować /[\/:.-]+/gi. Nie mogę się zdecydować, czy to fajne czy zagmatwane.

— Turbo

90

Jaki kontekst / język? Niektóre języki używają /jako separatora wzorca, więc tak, musisz go uciec, w zależności od języka / kontekstu. Uciekasz przed nim, umieszczając przed nim ukośnik w tył: w \/przypadku niektórych języków (takich jak PHP) możesz użyć innych znaków jako separatora i dlatego nie musisz go uciekać. Ale AFAIK we wszystkich językach, jedyne szczególne znaczenie, jakie /ma to to, że może to być wyznaczony ogranicznik wzoru.

— Crayon Violent
źródło

38

Oto kilka opcji:

W Perlu możesz wybrać alternatywne ograniczniki. Nie jesteś ograniczony m//. Możesz wybrać inny, taki jak m{}. Wtedy ucieczka nie jest konieczna. Prawdę mówiąc, Damian Conway w „Perl Best Practices” zapewnia, że m{}jest to jedyny alternatywny separator, który powinien być używany, i jest to wzmocnione przez Perl :: Critic (na CPAN). Chociaż możesz uciec przy użyciu różnych alternatywnych znaków ograniczających //i {}wydaje się, że są one najbardziej przejrzyste do rozszyfrowania później. Jeśli jednak którykolwiek z tych wyborów powoduje zbyt dużą ucieczkę, wybierz tę, która najlepiej nadaje się do czytelności. Typowymi przykładami są m(...), m[...]i m!...!.
W przypadkach, gdy nie możesz lub wolisz nie używać alternatywnych separatorów, możesz pominąć ukośniki w przód za pomocą ukośnika odwrotnego: m/\/[^/]+$/na przykład (używając alternatywnego separatora, który mógłby się stać m{/[^/]+$}, który może być czytelniejszy). Unikanie ukośnika za pomocą odwrotnego ukośnika jest na tyle powszechne, że zdobył imię i stronę Wikipedii: Syndrom krzywej wykałaczki . W wyrażeniach regularnych, w których jest tylko jedno wystąpienie, uniknięcie ukośnika może nie wzrosnąć do poziomu bycia uważanym za przeszkodę w czytelności, ale jeśli zacznie wymykać się spod kontroli i jeśli Twój język dopuszcza alternatywne separatory, tak jak robi to Perl, być preferowanym rozwiązaniem.

— David O
źródło

1

Czy możesz podać przykład? Mam to: perl -pi -e "s/chdir .*/chdir $ROBOT_PATH/g" startup_scripts/supervisord.confI dostaję konflikty z ukośnikami.

— CMCDragonkai

Zwróć uwagę, że używasz znaku s, a nie an m, kiedy wykonujesz zamianę (aka podstawienie) z wyrażeniami regularnymi. perlfect.com/articles/regex.shtml

— Mashmagar

2

@CMCDragonkai perl -pi -e "s{chdir .*}{chdir $ROBOT_PATH}g" startup_scripts/supervisord.conf... ale to jest prawdopodobnie lepsze: perl -pi -e 's/chdir .*/chdir $ENV{ROBOT_PATH}/g' startup_scripts/supervisord.confponieważ unika interpolacji powłoki.

— DavidO

1

Alternatywą dla zmiany znaczenia /znaku literału jest użycie funkcji regex polegającej na określaniu znaku za pomocą jego kodowania ASCII, szesnastkowo lub ósemkowo. Perl akceptuje formę \57

— ósemkową

Na stronie, do której prowadzi lukeuser (dziękuję), znajduje się również sekwencja ucieczki \ Q ... \ E. To zadziałało dla mnie.

— user3012857

11

Użyj ukośnika odwrotnego \lub wybierz inny separator, np. m#.\d#Zamiast /.\d/ "W Perlu, możesz zmienić / separator wyrażenia regularnego na prawie każdy inny znak specjalny, jeśli poprzedzisz go literą m (w celu dopasowania);"

6

Jeśli separatorem jest /, będziesz musiał uciec.

— fvox
źródło

0

Jeśli używasz języka C #, nie musisz go uciekać.

— ShrapNull
źródło

Może, ale tutaj używają perla.

— Toto,

0

W przypadku javy nie musisz.

eg: "^(.*)/\\*LOG:(\\d+)\\*/(.*)$" ==> ^(.*)/\*LOG:(\d+)\*/(.*)$

Jeśli umieścisz \ przed /. IDE powie Ci „Redundant Character Escape” \ / „in ReGex”

— Amzero
źródło