Un Regex qui ne sera jamais égalé par quoi que ce soit

Cela peut sembler une question stupide, mais j'ai eu une longue discussion avec certains de mes collègues développeurs et cela semblait être une chose amusante à penser.

Alors; quelle est votre pensée - à quoi ressemble un Regex, qui ne sera jamais égalé par aucune chaîne, jamais!

Edit : Pourquoi je veux ça? Eh bien, d'une part parce que je trouve intéressant de penser à une telle expression et d'autre part parce que j'en ai besoin pour un script.

Dans ce script, je définis un dictionnaire comme Dictionary<string, Regex>. Cela contient, comme vous le voyez, une chaîne et une expression.

Sur la base de ce dictionnaire, je crée des méthodes qui utilisent toutes ce dictionnaire comme référence uniquement sur la façon dont elles doivent faire leur travail, l'une d'elles compare les expressions régulières à un fichier journal analysé.

Si une expression correspond, une autre Dictionary<string, long>est ajoutée une valeur qui est renvoyée par l'expression. Donc, pour attraper tous les messages de journal qui ne correspondent pas à une expression dans le dictionnaire, j'ai créé un nouveau groupe appelé "inconnu".

À ce groupe, tout ce qui ne correspond à rien d'autre est ajouté. Mais pour éviter que l'expression "inconnue" ne corresponde (par accident) à un message de journal, j'ai dû créer une expression qui ne correspond certainement jamais, quelle que soit la chaîne que je lui donne.

Ainsi, là vous avez ma raison pour cette "pas une vraie question" ...

C'est en fait assez simple, bien que cela dépende de l'implémentation / flags *:

$a

Correspondra à un caractère aaprès la fin de la chaîne. Bonne chance.

AVERTISSEMENT:
cette expression est coûteuse - elle analysera toute la ligne, trouvera l'ancre de fin de ligne et ne trouvera alors pas le aet retournera une correspondance négative. (Voir le commentaire ci-dessous pour plus de détails.)

^* À l'origine, je n'ai pas beaucoup réfléchi à l'expression rationnelle en mode multiligne, où $correspond également à la fin d'une ligne. En fait, il correspondrait à la chaîne vide juste avant la nouvelle ligne , donc un caractère ordinaire comme ane peut jamais apparaître après $.

Effet de levier negative lookahead:

>>> import re
>>> x=r'(?!x)x'
>>> r=re.compile(x)
>>> r.match('')
>>> r.match('x')
>>> r.match('y')

cette ER est une contradiction dans les termes et ne correspondra donc jamais à rien.

REMARQUE:
en Python, re.match () ajoute implicitement une ancre de début de chaîne (\A ) au début de l'expression régulière. Cette ancre est importante pour les performances: sans elle, toute la chaîne sera scannée. Ceux qui n'utilisent pas Python voudront ajouter l'ancre explicitement:

\A(?!x)x

Celui qui a été manqué:

^\b$

Il ne peut pas correspondre car la chaîne vide ne contient pas de limite de mot. Testé en Python 2.5.

regardez autour de vous:

(?=a)b

Pour les débutants en regex: Le regard positif vers l'avant (?=a)garantit que le caractère suivant est a, mais ne change pas l'emplacement de recherche (ou n'inclut pas le «a» dans la chaîne correspondante). Maintenant que le caractère suivant est confirmé a, la partie restante de l'expression régulière ( b) ne correspond que si le caractère suivant est b. Ainsi, cette expression régulière ne correspond que si un caractère est à la fois aet ben même temps.

a\bc, où \best une expression de largeur nulle qui correspond à la limite du mot.

Il ne peut pas apparaître au milieu d'un mot, ce à quoi nous le forçons.

$.

.^

$.^

(?!)

Correspondance maximale

a++a

Au moins un asuivi de n'importe quel nombre de a, sans retour en arrière. Ensuite, essayez de faire correspondre un autre a.

ou sous-expression indépendante

Cela équivaut à insérer a+une sous-expression indépendante, suivie d'une autre a.

(?>a+)a

Perl 5.10 prend en charge les mots de contrôle spéciaux appelés "verbes", qui sont placés en (*...)séquence. (Comparez avec (?...)une séquence spéciale.) Parmi eux, il comprend le (*FAIL)verbe qui revient immédiatement de l'expression régulière.

Notez que les verbes sont également implémentés dans PCRE peu de temps après, vous pouvez donc les utiliser en PHP ou dans d'autres langues en utilisant également la bibliothèque PCRE. (Vous ne pouvez pas en Python ou Ruby, cependant. Ils utilisent leur propre moteur.)

\B\b

\bcorrespond aux limites de mot - la position entre une lettre et une non-lettre (ou la limite de chaîne).
\Best son complément - il correspond à la position entre deux lettres ou entre des non-lettres.

Ensemble, ils ne peuvent correspondre à aucune position.

Voir également:

• Limites de mots
• Ce modèle ne correspond pas à quelques positions
• Inspiration

Cela semble fonctionner:

$.

Que diriez-vous $^ou peut (?!)- être ? 

Le plus rapide sera:

r = re.compile(r'a^')
r.match('whatever')

'a' peut être n'importe quel caractère non spécial ('x', 'y'). L'implémentation de Knio est peut-être un peu plus pure, mais celle-ci sera plus rapide pour toutes les chaînes ne commençant pas par le caractère que vous choisissez au lieu de «a» car il ne correspondra pas après le premier caractère plutôt qu'après le second dans ces cas.

Python ne l'acceptera pas, mais Perl:

perl -ne 'print if /(w\1w)/'

Cette regex devrait (théoriquement) essayer de faire correspondre un nombre infini (pair) de ws, parce que le premier groupe (les ()s) revient en lui-même. Perl ne semble pas émettre d'avertissements, même sous use strict; use warnings;, donc je suppose que c'est au moins valide, et mes tests (minimaux) ne correspondent à rien, donc je le soumets à votre critique.

[^\d\D]ou (?=a)bou a$aoua^a

Cela ne fonctionnera pas pour Python et de nombreux autres langages, mais dans une expression régulière Javascript, []c'est une classe de caractères valide qui ne peut pas être mise en correspondance. Ainsi, ce qui suit devrait échouer immédiatement, quelle que soit l'entrée:

var noMatch = /^[]/;

Je l'aime mieux que /$a/parce que pour moi, il communique clairement son intention. Et quant au moment où vous en auriez besoin, j'en avais besoin parce que j'avais besoin d'une solution de secours pour un modèle compilé dynamiquement basé sur l'entrée utilisateur. Lorsque le modèle n'est pas valide, je dois le remplacer par un modèle qui ne correspond à rien. Simplifié, cela ressemble à ceci:

try {
    var matchPattern = new RegExp(someUserInput);
}
catch (e) {
    matchPattern = noMatch;
}

Tous les exemples impliquant un correcteur de limites suivent la même recette. Recette:

1. Prenez l'un des concordants de limite: ^, $, \ b, \ A, \ Z, \ z

2. Faites le contraire de ce à quoi ils sont destinés

Exemples:

^ et \ A sont destinés au début donc ne les utilisez pas au début

^ --> .^
\A --> .\A

\ b correspond à une limite de mot donc utilisez-le entre

\b --> .\b.

$, \ Z et \ z sont destinés à la fin donc ne les utilisez pas à la fin

$ --> $.
\Z --> \Z.
\z --> \z.

D'autres impliquent l'utilisation d'anticipation et d'anticipation qui fonctionnent également avec la même analogie: si vous donnez une anticipation positive ou négative suivie de quelque chose de contraire

(?=x)[^x]
(?!x)x

Si vous donnez un regard positif ou négatif en arrière après quelque chose de contraire

[^x](?<=x)
x(?<!x)

Leur pourrait être plus un tel modèle et plus de telles analogies.

Tant de bonnes réponses!

Semblable à la réponse de @ nivk, j'aimerais partager la comparaison des performances de Perl pour différentes variantes de regex sans correspondance.

1. Entrée: chaînes ascii pseudo-aléatoires (25000 lignes différentes, longueur 8-16):

Vitesse Regex:

Total for   \A(?!x)x: 69.675450 s, 1435225 lines/s
Total for       a\bc: 71.164469 s, 1405195 lines/s
Total for    (?>a+)a: 71.218324 s, 1404133 lines/s
Total for       a++a: 71.331362 s, 1401907 lines/s
Total for         $a: 72.567302 s, 1378031 lines/s
Total for     (?=a)b: 72.842308 s, 1372828 lines/s
Total for     (?!x)x: 72.948911 s, 1370822 lines/s
Total for       ^\b$: 79.417197 s, 1259173 lines/s
Total for         $.: 88.727839 s, 1127041 lines/s
Total for       (?!): 111.272815 s, 898692 lines/s
Total for         .^: 115.298849 s, 867311 lines/s
Total for    (*FAIL): 350.409864 s, 285380 lines/s

2. Entrée: / usr / share / dict / words (100 000 mots anglais).

Vitesse Regex:

Total for   \A(?!x)x: 128.336729 s, 1564805 lines/s
Total for     (?!x)x: 132.138544 s, 1519783 lines/s
Total for       a++a: 133.144501 s, 1508301 lines/s
Total for    (?>a+)a: 133.394062 s, 1505479 lines/s
Total for       a\bc: 134.643127 s, 1491513 lines/s
Total for     (?=a)b: 137.877110 s, 1456528 lines/s
Total for         $a: 152.215523 s, 1319326 lines/s
Total for       ^\b$: 153.727954 s, 1306346 lines/s
Total for         $.: 170.780654 s, 1175906 lines/s
Total for       (?!): 209.800379 s, 957205 lines/s
Total for         .^: 217.943800 s, 921439 lines/s
Total for    (*FAIL): 661.598302 s, 303540 lines/s

(Ubuntu sur Intel i5-3320M, noyau Linux 4.13, Perl 5.26)

je crois que

\Z RE FAILS! \A

couvre même les cas où l'expression régulière comprend des indicateurs comme MULTILINE, DOTALL etc.

>>> import re
>>> x=re.compile(r"\Z RE FAILS! \A")
>>> x.match('')
>>> x.match(' RE FAILS! ')
>>>

Je crois (mais je ne l'ai pas comparé) que quelle que soit la longueur (> 0) de la chaîne entre \Zet \A, le temps de défaillance doit être constant.

(*FAIL)

ou

(*F)

Avec PCRE et PERL, vous pouvez utiliser ce verbe de contrôle de retour arrière qui force le modèle à échouer immédiatement.

Après avoir vu certaines de ces bonnes réponses, le commentaire de @ arantius (concernant le timing $xvs x^vs (?!x)x) sur la réponse actuellement acceptée m'a donné envie de chronométrer certaines des solutions données jusqu'à présent.

En utilisant la norme de ligne 275k de @ arantius, j'ai exécuté les tests suivants en Python (v3.5.2, IPython 6.2.1).

TL; DR: 'x^'et 'x\by'sont les plus rapides d'un facteur d'au moins ~ 16, et contrairement à la conclusion de @ arantius, (?!x)xétaient parmi les plus lents (~ 37 fois plus lents). La question de la vitesse dépend donc certainement de la mise en œuvre. Testez-le vous-même sur votre système prévu avant de vous engager si la vitesse est importante pour vous.

MISE À JOUR: Il y a apparemment un grand écart entre le timing 'x^'et 'a^'. Veuillez consulter cette question pour plus d'informations, et la modification précédente pour les timings plus lents avec aau lieu de x.

In [1]: import re

In [2]: with open('/tmp/longfile.txt') as f:
   ...:     longfile = f.read()
   ...:     

In [3]: len(re.findall('\n',longfile))
Out[3]: 275000

In [4]: len(longfile)
Out[4]: 24733175

In [5]: for regex in ('x^','.^','$x','$.','$x^','$.^','$^','(?!x)x','(?!)','(?=x)y','(?=x)(?!x)',r'x\by',r'x\bx',r'^\b$'
    ...: ,r'\B\b',r'\ZNEVERMATCH\A',r'\Z\A'):
    ...:     print('-'*72)
    ...:     print(regex)
    ...:     %timeit re.search(regex,longfile)
    ...:     
------------------------------------------------------------------------
x^
6.98 ms ± 58.4 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
------------------------------------------------------------------------
.^
155 ms ± 960 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
$x
111 ms ± 2.12 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
$.
111 ms ± 1.76 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
$x^
112 ms ± 1.14 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
$.^
113 ms ± 1.44 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
$^
111 ms ± 839 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
(?!x)x
257 ms ± 5.03 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
------------------------------------------------------------------------
(?!)
203 ms ± 1.56 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
(?=x)y
204 ms ± 4.84 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
------------------------------------------------------------------------
(?=x)(?!x)
210 ms ± 1.66 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
------------------------------------------------------------------------
x\by
7.41 ms ± 122 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
------------------------------------------------------------------------
x\bx
7.42 ms ± 110 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
------------------------------------------------------------------------
^\b$
108 ms ± 1.05 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
\B\b
387 ms ± 5.77 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
------------------------------------------------------------------------
\ZNEVERMATCH\A
112 ms ± 1.52 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
------------------------------------------------------------------------
\Z\A
112 ms ± 1.38 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

La première fois que j'ai exécuté ceci, j'ai oublié de raw les 3 dernières expressions, donc a '\b'été interprété comme '\x08', le caractère de retour arrière. Cependant, à ma grande surprise, 'a\x08c'c'était plus rapide que le résultat le plus rapide précédent! Pour être honnête, cela correspondra toujours à ce texte, mais je pensais que cela valait la peine de le noter car je ne sais pas pourquoi c'est plus rapide.

In [6]: for regex in ('x\by','x\bx','^\b$','\B\b'):
    ...:     print('-'*72)
    ...:     print(regex, repr(regex))
    ...:     %timeit re.search(regex,longfile)
    ...:     print(re.search(regex,longfile))
    ...:     
------------------------------------------------------------------------
y 'x\x08y'
5.32 ms ± 46.1 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
None
------------------------------------------------------------------------
x 'x\x08x'
5.34 ms ± 66.3 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
None
------------------------------------------------------------------------
$ '^\x08$'
122 ms ± 1.05 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
None
------------------------------------------------------------------------
\ '\\B\x08'
300 ms ± 4.11 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
None

Mon fichier de test a été créé en utilisant une formule pour "... Contenu lisible et aucune ligne en double" (sur Ubuntu 16.04):

$ ruby -e 'a=STDIN.readlines;275000.times do;b=[];rand(20).times do; b << a[rand(a.size)].chomp end; puts b.join(" "); end' < /usr/share/dict/words > /tmp/longfile.txt

$ head -n5 /tmp/longfile.txt 
unavailable speedometer's garbling Zambia subcontracted fullbacks Belmont mantra's
pizzicatos carotids bitch Hernandez renovate leopard Knuth coarsen
Ramada flu occupies drippings peaces siroccos Bartók upside twiggier configurable perpetuates tapering pint paralyzed
vibraphone stoppered weirdest dispute clergy's getup perusal fork
nighties resurgence chafe

Regex vide

Le meilleur regex pour ne jamais correspondre à quoi que ce soit est un regex vide. Mais je ne suis pas sûr que tous les moteurs de regex accepteront cela.

Regex impossible

L'autre solution est de créer une regex impossible. J'ai trouvé que le $-^calcul ne prend que deux étapes, quelle que soit la taille de votre texte ( https://regex101.com/r/yjcs1Z/1 ).

Pour référence:

• $^et $.prenez 36 étapes pour calculer -> O (1)
• \b\B prend 1507 étapes sur mon échantillon et augmente avec le nombre de caractères dans votre chaîne -> O (n)

Fil de discussion plus populaire sur cette question:

• Regex pour * ne * correspondre à aucun caractère

Peut être ça?

/$.+^/

'[^0-9a-zA-Z...]*'

et remplacez ... par tous les symboles imprimables;). C'est pour un fichier texte.

Qu'en est-il au lieu de regex, utilisez simplement une instruction if toujours fausse? En javascript:

var willAlwaysFalse=false;
if(willAlwaysFalse)
{
}
else
{
}

Une solution portable qui ne dépendra pas de l'implémentation de l'expression rationnelle consiste simplement à utiliser une chaîne constante dont vous êtes sûr qu'elle n'apparaîtra jamais dans les messages du journal. Par exemple, créez une chaîne basée sur les éléments suivants:

cat /dev/urandom | hexdump | head -20
0000000 5d5d 3607 40d8 d7ab ce72 aae1 4eb3 ae47
0000010 c5e2 b9e8 910d a2d9 2eb3 fdff 6301 c85f
0000020 35d4 c282 e439 33d8 1c73 ca78 1e4d a569
0000030 8aca eb3c cbe4 aff7 d079 ca38 8831 15a5
0000040 818b 323f 0b02 caec f17f 387b 3995 88da
0000050 7b02 c80b 2d42 8087 9758 f56f b71f 0053
0000060 1501 35c9 0965 2c6e 03fe 7c6d f0ca e547
0000070 aba0 d5b6 c1d9 9bb2 fcd1 5ec7 ee9d 9963
0000080 6f0a 2c91 39c2 3587 c060 faa7 4ea4 1efd
0000090 6738 1a4c 3037 ed28 f62f 20fa 3d57 3cc0
00000a0 34f0 4bc2 3067 a1f7 9a87 086b 2876 1072
00000b0 d9e1 6b8f 5432 a60e f0f5 00b5 d9ef ed6f
00000c0 4a85 70ee 5ec4 a378 7786 927f f126 2ec2
00000d0 18c5 46fe b167 1ae6 c87c 1497 48c9 3c09
00000e0 8d09 e945 13ce 7da2 08af 1a96 c24c c022
00000f0 b051 98b3 2bf5 4d7d 5ec4 e016 a50d 355b
0000100 0e89 d9dd b153 9f0e 9a42 a51f 2d46 2435
0000110 ef35 17c2 d2aa 3cc7 e2c3 e711 d229 f108
0000120 324e 5d6a 650a d151 bc55 963f 41d3 66ee
0000130 1d8c 1fb1 1137 29b2 abf7 3af7 51fe 3cf4

Bien sûr, ce n'est pas un défi intellectuel, mais plutôt une programmation de ruban adhésif .

new Regex(Guid.NewGuid().ToString())

Crée un modèle contenant uniquement des caractères alphanumériques et ' -' (dont aucun n'est des caractères spéciaux regex) mais il est statistiquement impossible que la même chaîne soit apparue n'importe où auparavant (car c'est tout l'intérêt d'un GUID).