Pisząc tę odpowiedź , musiałem dopasować wyłącznie na łamach linii zamiast używać opcji s
-flag ( dotall
- kropka odpowiada podziałom linii).
Witryny używane zwykle do testowania wyrażeń regularnych zachowują się inaczej, gdy próbują dopasować na \n
lub \r\n
.
Zauważyłem
Regex101 dopasowuje tylko podziały wierszy
\n
( przykład - usuń\r
i pasuje)RegExr dopasowuje podziały linii ani włączone,
\n
ani włączone\r\n
i nie mogę znaleźć czegoś, co pasowałoby do podziału linii, z wyjątkiemm
-flag i\s
( przykład )Debuggex zachowuje się jeszcze bardziej inaczej:
w tym przykładzie pasuje tylko do\r\n
, podczas gdy
tutaj pasuje tylko do\n
, z tymi samymi flagami i określonym silnikiem
W pełni zdaję sobie sprawę z opcji m
-flag (multiline - ^
dopasowuje początek i $
koniec wiersza), ale czasami nie jest to opcja. To samo \s
dotyczy również tabulatorów i spacji.
Moja myśl o użyciu znaku nowej linii Unicode ( \u0085
) nie powiodła się, więc:
- Czy istnieje bezpieczny sposób zintegrowania dopasowania w miejscu zakończenia wiersza (najlepiej niezależnie od używanego języka) z wyrażeniem regularnym?
- Dlaczego wyżej wymienione strony zachowują się inaczej (zwłaszcza Debuggex, dopasowywanie tylko
\n
raz i raz tylko\r\n
)?
źródło
[\r\n]+
- lub coś takiego\r?\n
aby dopasować zarówno sekwencje zakończenia linii, jak\r\n
i\n
sekwencje zakończenia linii. Nie działa dla starej\r
składni Maca, ale ta jest obecnie dość rzadka.Odpowiedzi:
Odpowiem w przeciwnym kierunku.
2) Aby uzyskać pełne wyjaśnienie
\r
i\n
muszę odnieść się do tego pytania, które jest o wiele bardziej kompletne niż to, które opiszę tutaj: Różnica między \ n i \ r?Krótko mówiąc, Linux używa
\n
nowej linii, Windows\r\n
i starych komputerów Mac\r
. Tak więc istnieje wiele sposobów na napisanie nowej linii. Twoje drugie narzędzie (RegExr) pasuje na przykład na singlu\r
.1),
[\r\n]+
jak sugerował Ilya, będzie działać, ale będzie również pasować do wielu kolejnych nowych linii.(\r\n|\r|\n)
jest bardziej poprawne.źródło
\r
/\n
zależą od systemu operacyjnego - to można wiedzieć (;)) - ale dlaczego dwa przykłady debuggex pasują do siebie raz w \ r \ n i raz na \ n? Przynajmniej nie ma różnicy (w przykładach) widocznej dla mnie.\r\n
w tekście (jeśli klikniesz prawym przyciskiem myszy i pokażesz źródło, znajdziesz{{Infobox XC Championships\r\n|Name =
gdzieś). Drugie narzędzie jest napisane we Flashu i podczas czytania strony z informacjami jest nieco błędne ze znakami nowej linii.(\r\n|\r|\n)
można napisać prościej jako\r\n?
\n
Masz różne zakończenia linii w przykładowych tekstach w Debuggex. Szczególnie interesujące jest to, że Debuggex zdaje się zidentyfikować styl zakończenia linii, którego użyłeś jako pierwszy i konwertuje wszystkie dodatkowe zakończenia linii wprowadzone na ten styl.
Użyłem Notepad ++ do wklejenia przykładowego tekstu w formacie Unix i Windows do Debuggex, a cokolwiek wkleiłem jako pierwsze, jest tym, z czym utknęła ta sesja Debuggex.
Dlatego przed wklejeniem go do Debuggex należy przepłukać tekst w edytorze tekstu. Upewnij się, że wklejasz żądany styl. Debuggex domyślnie ustawia styl uniksowy (\ n).
Poza tym NEL (\ u0085) to coś zupełnie innego: https://en.wikipedia.org/wiki/Newline#Unicode
(\r?\n)
obejmie systemy Unix i Windows. Będziesz potrzebować czegoś bardziej złożonego, na przykład(\r\n|\r|\n)
, jeśli chcesz dopasować również stary Mac.źródło
W PCRE
\R
pasuje\n
,\r
i\r\n
.źródło
(\r\n|\r|\n)
Dotyczy to tylko pytania 1.
Mam aplikację działającą w systemie Windows i używającą wieloliniowego edytora MFC.
Okno edytora oczekuje podziałów wierszy CRLF, ale muszę przeanalizować wprowadzony tekst za
pomocą kilku naprawdę dużych / paskudnych wyrażeń regularnych .
Nie chciałem się tym stresować podczas pisania wyrażenia regularnego, więc w
końcu normalizowałem tam iz powrotem między parserem a edytorem, aby
po prostu używać wyrażeń regularnych
\n
. Wklejam również operacje wklejania i konwertuję je na pola.Nie zajmuje to dużo czasu.
To jest to, czego używam.
źródło
W Pythonie:
lub bardziej rygorystyczne:
źródło