Um Regex que nunca será correspondido por nada

Pode parecer uma pergunta estúpida, mas tive uma longa conversa com alguns de meus colegas desenvolvedores e pareceu uma coisa divertida de se pensar.

Assim; Qual é o seu pensamento - como é um Regex, que nunca será correspondido por nenhuma string!

Edit : Por que eu quero isso? Bem, primeiro porque acho interessante pensar em uma expressão assim e, em segundo lugar, porque preciso dela para um script.

Nesse script eu defino um dicionário como Dictionary<string, Regex>. Isso contém, como você vê, uma string e uma expressão.

Com base nesse dicionário, crio métodos que todos usam esse dicionário apenas como referência sobre como devem fazer seu trabalho, um deles corresponde às expressões regulares em um arquivo de log analisado.

Se uma expressão for correspondida, outra Dictionary<string, long>será adicionada um valor retornado pela expressão. Portanto, para capturar quaisquer mensagens de log que não correspondam a uma expressão no dicionário, criei um novo grupo chamado "desconhecido".

A este grupo, tudo o que não corresponde a nada é adicionado. Mas, para evitar que a expressão "desconhecida" não corresponda (por acidente) a uma mensagem de log, eu tive que criar uma expressão que certamente nunca é correspondida, independentemente da string que eu fornecer.

Portanto, aí está minha razão para esta "não ser uma pergunta real" ...

Na verdade, isso é bastante simples, embora dependa da implementação / flags *:

$a

Combina um caractere aapós o final da string. Boa sorte.

AVISO:
Essa expressão é cara - ela varrerá a linha inteira, localizará a âncora de fim de linha e só então não encontrará a ae retornará uma correspondência negativa. (Veja o comentário abaixo para mais detalhes.)

^* Originalmente, não pensei muito no regexp no modo multilinha, onde $também corresponde ao final de uma linha. Na verdade, ele corresponderia à string vazia logo antes da nova linha , para que um caractere comum como anunca possa aparecer depois $.

Alavancagem negative lookahead:

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

este ER é uma contradição em termos e, portanto, nunca corresponderá a nada.

NOTA:
No Python, re.match () adiciona implicitamente uma âncora no início da string ( \A) ao início da expressão regular. Essa âncora é importante para o desempenho: sem ela, toda a cadeia será varrida. Aqueles que não usam Python vão querer adicionar a âncora explicitamente:

\A(?!x)x

Um que foi esquecido:

^\b$

Não pode corresponder porque a sequência vazia não contém um limite de palavras. Testado em Python 2.5.

olhar em volta:

(?=a)b

Para iniciantes em regex: o olhar positivo à frente (?=a)garante que o próximo caractere seja a, mas não altere o local da pesquisa (ou inclua o 'a' na sequência correspondente). Agora que o próximo caractere está confirmado a, a parte restante do regex ( b) corresponde apenas se o próximo caractere for b. Portanto, esse regex corresponde apenas se um caractere for ao mesmo tempo ae bao mesmo tempo.

a\bc, onde \bé uma expressão de largura zero que corresponde ao limite da palavra.

Não pode aparecer no meio de uma palavra, o que forçamos.

$.

.^

$.^

(?!)

Correspondência máxima

a++a

Pelo menos um aseguido por qualquer número de a's, sem retroceder. Em seguida, tente combinar mais um a.

ou subexpressão independente

Isso é equivalente a colocar a+uma subexpressão independente, seguida por outra a.

(?>a+)a

O Perl 5.10 suporta palavras de controle especiais chamadas "verbos", que são colocadas em (*...)seqüência. (Compare com a (?...)sequência especial.) Entre eles, inclui o (*FAIL)verbo que retorna da expressão regular imediatamente.

Observe que os verbos também são implementados no PCRE logo depois, para que você possa usá-los em PHP ou outras linguagens usando a biblioteca PCRE também. (No entanto, você não pode em Python ou Ruby. Eles usam seu próprio mecanismo.)

\B\b

\bcorresponde aos limites da palavra - a posição entre uma letra e uma não-letra (ou o limite da string).
\Bé seu complemento - ele corresponde à posição entre duas letras ou entre não letras.

Juntos, eles não podem corresponder a nenhuma posição.

Veja também:

• Limites de palavras
• Esse padrão não corresponde a algumas posições
• Inspiração

Isso parece funcionar:

$.

Que tal $^ou talvez (?!)? 

O mais rápido será:

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

'a' pode ser qualquer caractere não especial ('x', 'y'). A implementação do Knio pode ser um pouco mais pura, mas essa será mais rápida para todas as strings que não começarem com o caractere que você escolher, em vez de 'a', porque não corresponderá ao primeiro caractere, e sim ao segundo nesses casos.

O Python não aceita, mas o Perl:

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

Essa regex deve (teoricamente) tentar corresponder a um número infinito (par) de ws, porque o primeiro grupo ( ()s) se repete em si mesmo. O Perl parece não emitir nenhum aviso, mesmo use strict; use warnings;assim, portanto, suponho que seja pelo menos válido, e meu (mínimo) teste não corresponde a nada, então o envio para sua crítica.

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

Isso não funcionará no Python, e em muitos outros idiomas, mas em um regex Javascript, []é uma classe de caractere válida que não pode ser correspondida. Portanto, o seguinte deve falhar imediatamente, independentemente da entrada:

var noMatch = /^[]/;

Gosto mais do que /$a/porque, para mim, comunica claramente sua intenção. E quanto a quando você precisaria, eu precisava disso porque precisava de um fallback para um padrão compilado dinamicamente com base na entrada do usuário. Quando o padrão é inválido, preciso substituí-lo por um padrão que não corresponda a nada. Simplificado, fica assim:

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

Todos os exemplos que envolvem um correspondente de limites seguem a mesma receita. Receita:

1. Escolha qualquer um dos correspondentes de limite: ^, $, \ b, \ A, \ Z, \ z

2. Faça o oposto do que eles significam

Exemplos:

^ e \ A são destinados ao início, portanto, não os use no início

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

\ b corresponde a um limite de palavras, portanto, use-o entre

\b --> .\b.

$, \ Z e \ z são destinados ao fim, portanto, não os use no final

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

Outros envolvem o uso de lookahead e lookbehind, que também funcionam com a mesma analogia: se você der lookahead positivo ou negativo seguido de algo oposto

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

Se você der uma olhada positiva ou negativa atrás de algo oposto

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

O seu poderia ser mais esse padrão e mais analogias.

Tantas boas respostas!

Semelhante à resposta do @ nivk, eu gostaria de compartilhar a comparação de desempenho do Perl para diferentes variantes do regex que nunca combina.

1. Entrada: seqüências pseudo-aleatórias ascii (25.000 linhas diferentes, comprimento 8-16):

Velocidade 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. Entrada: / usr / share / dict / words (100.000 palavras em inglês).

Velocidade 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 no Intel i5-3320M, kernel do Linux 4.13, Perl 5.26)

eu acredito

\Z RE FAILS! \A

abrange até os casos em que a expressão regular inclui sinalizadores como MULTILINE, DOTALL etc.

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

Acredito (mas ainda não a comparei) que, independentemente do comprimento (> 0) da cadeia entre \Ze \A, o tempo até a falha deve ser constante.

(*FAIL)

ou

(*F)

Com PCRE e PERL, você pode usar esse verbo de controle de retorno que força o padrão a falhar imediatamente.

Depois de ver algumas dessas ótimas respostas, o comentário de @ arantius (sobre timing $xvs x^vs(?!x)x ) sobre a resposta atualmente aceita me fez querer cronometrar algumas das soluções fornecidas até agora.

Usando o padrão de linha de 275k do @ arantius, executei os seguintes testes no Python (v3.5.2, IPython 6.2.1).

TL; DR: 'x^'e 'x\by'são os mais rápidos por um fator de pelo menos ~ 16, e ao contrário da descoberta de @ arantius, (?!x)xestava entre os mais lentos (~ 37 vezes mais lento). Portanto, a questão da velocidade certamente depende da implementação. Teste você mesmo no sistema pretendido antes de confirmar se a velocidade é importante para você.

ATUALIZAÇÃO: Aparentemente, há uma grande discrepância entre tempo 'x^'e tempo 'a^'. Consulte esta pergunta para obter mais informações e a edição anterior para tempos mais lentos com em avez 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)

A primeira vez que executei isso, esqueci de rexibir as três últimas expressões, então '\b'fui interpretada como '\x08'o caractere de backspace. No entanto, para minha surpresa, 'a\x08c'foi mais rápido que o resultado mais rápido anterior! Para ser justo, ele ainda corresponderá a esse texto, mas achei que ainda valia a pena notar, porque não sei por que é mais rápido.

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

Meu arquivo de teste foi criado usando uma fórmula para "... Conteúdo legível e sem linhas duplicadas" (no 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 vazio

A melhor regex para nunca corresponder a nada é uma regex vazia. Mas não tenho certeza de que todos os mecanismos de regex aceitem isso.

Regex impossível

A outra solução é criar uma regex impossível. Descobri que são $-^necessárias apenas duas etapas para calcular, independentemente do tamanho do seu texto ( https://regex101.com/r/yjcs1Z/1 ).

Para referência:

• $^e $.execute 36 etapas para calcular -> O (1)
• \b\B toma 1507 etapas na minha amostra e aumenta com o número de caracteres na sua string -> O (n)

Tópico mais popular sobre esta questão:

• Regex para * não * corresponde a qualquer caractere

Talvez isto?

/$.+^/

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

e substitua ... por todos os símbolos imprimíveis;). Isso é para um arquivo de texto.

E em vez de regex, basta usar uma declaração if sempre falsa? Em javascript:

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

Uma solução portátil que não dependerá da implementação do regexp é usar apenas uma cadeia constante que você tem certeza de que nunca aparecerá nas mensagens de log. Por exemplo, faça uma string com base no seguinte:

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

Claro, isso não é um desafio intelectual, mas mais como a programação de fita adesiva .

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

Cria um padrão que contém apenas alfanuméricos e ' -' (nenhum dos quais são caracteres especiais de expressão regular), mas é estatisticamente impossível que a mesma sequência tenha aparecido em qualquer lugar antes (porque esse é o objetivo de um GUID).