En écrivant cette réponse , j’ai dû faire correspondre exclusivement des sauts de ligne au lieu d’utiliser le s
-flag ( dotall
-dot correspond à des sauts de ligne).
Les sites généralement utilisés pour tester les expressions régulières se comportent différemment lors de la tentative de correspondance sur \n
ou \r\n
.
j’ai remarqué
Regex101 correspond aux sauts de ligne uniquement sur \n
( exemple – supprimer \r
et il correspond)
RegExr correspond à des sauts de ligne sur \n
ni sur \r\n
et je ne peux pas trouver quelque chose pour le faire correspondre à un saut de ligne, sauf pour le m
-flag et \s
( exemple )
Debuggex se comporte encore plus différemment:
dans cet exemple, il correspond uniquement à \r\n
, tandis que
ici il ne correspond que sur \n
, avec les mêmes drapeaux et moteur spécifiés
Je suis parfaitement conscient du m
-flag (multiline – make ^
correspond au début et $
la fin de la ligne), mais parfois ce n’est pas une option. Même chose avec \s
, car elle correspond également aux tabulations et aux espaces.
Ma pensée d’utiliser le caractère de nouvelle ligne unicode ( \u0085
) n’a pas réussi, alors:
\n
et une seule fois à \r\n
)? Je vais répondre dans la direction opposée;)
2) Pour une explication complète sur \ r et \ n, je dois me référer à cette question, qui est beaucoup plus complète que ce que je vais poster ici: Différence entre \ n et \ r?
En bref, Linux utilise \ n pour une nouvelle ligne, Windows \ r \ n et les anciens Macs \ r. Il existe donc plusieurs façons d’écrire une nouvelle ligne. Votre deuxième outil (RegExr) correspond par exemple au single \ r.
1) [\r\n]+
comme Ilya l’a suggéré, fonctionnera, mais correspondra également à plusieurs nouvelles lignes consécutives. (\r\n|\r|\n)
est plus correct.
Vous avez des fins de ligne différentes dans les textes d’exemple de Debuggex. Ce qui est particulièrement intéressant, c’est que Debuggex semble avoir identifié le style de fin de ligne que vous avez utilisé en premier, et il convertit toutes les fins de ligne supplémentaires entrées dans ce style.
J’ai utilisé Notepad ++ pour coller un exemple de texte au format Unix et Windows dans Debuggex, et ce que j’ai collé en premier est ce que cette session de Debuggex a bloqué.
Donc, vous devriez laver votre texte via votre éditeur de texte avant de le coller dans Debuggex. Assurez-vous que vous collez le style que vous souhaitez. Debuggex utilise par défaut le style Unix (\ n).
En outre, NEL (\ u0085) est totalement différent: https://en.wikipedia.org/wiki/Newline#Unicode
(\r?\n)
couvrira Unix et Windows. Vous aurez besoin de quelque chose de plus complexe, comme (\r\n|\r|\n)
, si vous souhaitez également faire correspondre l’ancien Mac.
Cela ne s’applique qu’à la question 1.
J’ai une application qui fonctionne sous Windows et utilise une boîte d’édition multi-lignes MFC.
La boîte de l’éditeur attend les sauts de ligne CRLF, mais je dois parsingr le texte introduit
avec des regexs vraiment grandes / méchantes ».
Je ne voulais pas insister là-dessus en écrivant la regex, donc
J’ai fini par normaliser entre le parser et l’éditeur pour que
les regex utilisent juste \n
. Je piège également les opérations de collage et les convertis pour les boîtes.
Cela ne prend pas beaucoup de temps.
C’est ce que j’utilise.
boost::regex CRLFCRtoLF ( " \\r\\n | \\r(?!\\n) " , MODx); boost::regex CRLFCRtoCRLF ( " \\r\\n?+ | \\n " , MODx); // Convert (All style) linebreaks to linefeeds // --------------------------------------- void ReplaceCRLFCRtoLF( ssortingng& strSrc, ssortingng& strDest ) { strDest = boost::regex_replace ( strSrc, CRLFCRtoLF, "\\n" ); } // Convert linefeeds to linebreaks (Windows) // --------------------------------------- void ReplaceCRLFCRtoCRLF( ssortingng& strSrc, ssortingng& strDest ) { strDest = boost::regex_replace ( strSrc, CRLFCRtoCRLF, "\\r\\n" ); }
En Python:
# as Peter van der Wal's answer re.split(r'\r\n|\r|\n', text, flags=re.M)
ou plus rigoureux:
# https://docs.python.org/3/library/stdtypes.html#str.splitlines str.splitlines()
Dans notepad ++ \ R correspond à la fois à \ n et \ r \ n.