Pergunta

Ok, eu mal compreender conceitos básicos RegEx, mas por que eles não podiam projetá-lo para usar palavras-chave (como SQL) em vez de alguns caracteres curinga enigmáticas e símbolos?

É para desempenho desde o RegEx é interpretado / analisado em tempo de execução? (Não compilado)

Ou talvez para a velocidade de escrita? Considerando-se que quando você aprender algumas combinações de caracteres "simples" torna-se mais fácil de digitar um caractere em vez de uma palavra-chave?

Foi útil?

Solução

Você realmente quer este ?

Pattern findGamesPattern = Pattern.With.Literal(@"<div")
    .WhiteSpace.Repeat.ZeroOrMore
    .Literal(@"class=""game""").WhiteSpace.Repeat.ZeroOrMore.Literal(@"id=""")
    .NamedGroup("gameId", Pattern.With.Digit.Repeat.OneOrMore)
    .Literal(@"-game""")
    .NamedGroup("content", Pattern.With.Anything.Repeat.Lazy.ZeroOrMore)
    .Literal(@"<!--gameStatus")
    .WhiteSpace.Repeat.ZeroOrMore.Literal("=").WhiteSpace.Repeat.ZeroOrMore
    .NamedGroup("gameState", Pattern.With.Digit.Repeat.OneOrMore)
    .Literal("-->");

Ok, mas é a sua funeral, homem.

Faça download da biblioteca que faz isso aqui:
http://flimflan.com/blog/ReadableRegularExpressions.aspx

Outras dicas

As expressões regulares têm um fundo matemática (na verdade, a teoria da linguagem) e codificadas com um pouco como um fórmula matemática . Você pode defini-los por um conjunto de regras, por exemplo

  • cada personagem é uma expressão regular, o que representa em si
  • se a e b são expressões regulares, então a?, a|b e ab são expressões regulares, também
  • ...

Usando uma linguagem baseada em palavra-chave seria um grande fardo para expressões regulares simples. Na maioria das vezes, você só vai usar uma cadeia de texto simples como padrão de pesquisa:

grep -R 'main' *.c

ou talvez padrões muito simples:

grep -c ':-[)(]' seidl.txt

Uma vez que você se acostumar com expressões regulares, esta sintaxe é muito clara e precisa. Em situações mais complicadas você provavelmente vai usar outra coisa desde uma grande expressão regular é, obviamente, difícil de ler.

Perl 6 está dando um passo revolucionário bastante para a frente na legibilidade regex. Considere um endereço da forma: 100 E Main St Springfield MA 01234

Aqui está um moderadamente-readable Perl 5 regex compatível para analisar que (muitos casos de canto não tratados):

 m/
     ([1-9]\d*)\s+
     ((?:N|S|E|W)\s+)?
     (\w+(?:\s+\w+)*)\s+
     (ave|ln|st|rd)\s+
     ([:alpha:]+(?:\s+[:alpha:]+)*)\s+
     ([A-Z]{2})\s+
     (\d{5}(?:-\d{4})?)
  /ix;

Esta Perl 6 regex tem o mesmo comportamento:

grammar USMailAddress {
     rule  TOP { <addr> <city> <state> <zip> }

     rule  addr { <[1..9]>\d* <direction>?
                  <streetname> <streettype> }
     token direction { N | S | E | W }
     token streetname { \w+ [ \s+ \w+ ]* }
     token streettype {:i ave | ln | rd | st }
     token city { <alpha> [ \s+ <alpha> ]* }
     token state { <[A..Z]>**{2} }
     token zip { \d**{5} [ - \d**{4} ]? }
  }

Um Perl 6 gramática é uma classe, e as fichas são todos métodos invokable. Usá-lo como este:

if $addr ~~ m/^<USMailAddress::TOP>$/ {
     say "$<city>, $<state>";
}

Este exemplo vem de um falar apresentei no Frozen Perl 2009 Workshop . A implementação Rakudo de Perl 6 é suficiente completa que este exemplo funciona hoje.

Bem, se você tivesse palavras-chave, como você facilmente diferenciá-los de texto realmente combinado? Como você lidaria com espaços em branco?

text Fonte Empresa: A Dept .: B

padrão regex:

Company:\s+(.+)\s+Dept.:\s+(.+)

Ou mesmo:

Company: (.+) Dept. (.+)

Palavra-chave regex (tentando muito difícil não ter uma strawman ...)

"Company:" whitespace.oneplus group(any.oneplus) whitespace.oneplus "Dept.:" whitespace.oneplus group(any.oneplus)

Ou simplificado:

"Company:" space group(any.oneplus) space "Dept.:" space group(any.oneplus)

Não, provavelmente não é melhor.

Porque corresponde a teoria da linguagem formal e sua notação matemática.

é a culpa do Perl ...!

Na verdade, mais especificamente, expressões regulares vêm de desenvolvimento precoce Unix, e sintaxe concisa era muito mais valorizado então. Armazenamento, tempo, terminais físicos, etc processamento foram todos muito limitado, em vez ao contrário de hoje.

A história do expressões regulares na Wikipedia explica mais.

Existem alternativas para Regex, mas eu não tenho certeza que qualquer que realmente pegou.

Editar: corrigido por John Saunders: Expressões Regulares eram popularizado por Unix, mas primeiro implementado pelo editor QED . As mesmas restrições de design aplicado, mais ainda, aos sistemas anteriores.

Na verdade, não, o mundo não começou com o Unix. Se você ler o artigo Wikipedia, você verá que

Na década de 1950, o matemático Stephen Cole Kleene descrito esses modelos usando sua notação matemática chamado conjuntos regulares. A linguagem SNOBOL foi uma rápida implementação de correspondência de padrões, mas não idêntico ao expressões regulares. Ken Thompson construído notação de Kleene no editor QED como um meio para combinar padrões em arquivos de texto. Mais tarde, ele acrescentou esta capacidade ao ed editor Unix, o que eventualmente levou ao uso da popular do grep ferramenta de busca de expressões regulares

Este é muito mais cedo do PERL. A entrada da Wikipedia sobre Expressões Regulares atribui as primeiras implementações de expressões regulares para Ken Thompson de UNIX fama, que os implementada no QED e então o rel="nofollow noreferrer"> ed editor Mastering Expressões Regulares é um grande livro sobre expressões regulares, que oferece a opção de anotar uma expressão regular (com o / x flag) para torná-lo mais fácil de ler e entender.

Porque a idéia de expressões regulares - como muitas coisas que se originam de UNIX - é que eles são concisa, favorecendo brevidade sobre a legibilidade. Esta é realmente uma coisa boa. Eu acabei escrevendo expressões regulares (contra o meu melhor julgamento) que são 15 linhas. Se isso tivesse um detalhado sintaxe não seria um regex, seria um programa.

É realmente muito fácil de implementar uma forma "verborrágico" de regex - por favor, veja a minha resposta aqui . Em poucas palavras:. Escrever um punhado de funções que as cordas retorno regex (e receber parâmetros se necessário)

Eu não acho que palavras-chave daria qualquer benefício. As expressões regulares, como tal, são complexas, mas também muito poderosa.

O que eu acho que é mais confuso é que cada suporte inventa biblioteca sua própria sintaxe em vez de usar (ou extensão) da regex clássico Perl (por exemplo, \ 1, $ 1, {1}, ... para substituições e muitos mais exemplos) .

Eu sei que é respondendo à sua pergunta da forma errada, mas RegexBuddy tem uma característica que explica o seu regexpression Em inglês simples. Isso pode torná-lo um pouco mais fácil de aprender.

Se o idioma que você está usando oferece suporte Posix regexes , você pode usá-los.

Um exemplo:

\d

seria o mesmo que

[:digit:]

A notação suporte é muito mais clara sobre o que está combinando. Eu ainda iria aprender os "caracteres curinga enigmáticas e símbolos, desde que você ainda vai vê-los no código de outras pessoas e necessidade de entendê-los.

Há mais exemplos na tabela na página do regular-expressions.info .

Por alguma razão, minha resposta anterior foi deletado. Enfim, coisa que eu rubi máquina regexp caberia a conta, em http://www.rubyregexp.sf.net . É meu próprio projeto, mas eu acho que ele deve funcionar.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top