2010-12-03 33 views
2

Normalement le . ne correspond pas à la nouvelle ligne sauf si je spécifie le moteur pour le faire avec l'indicateur (? S). J'ai essayé sur mon rédacteur en chef regexp de (UltraEdit v14.10) moteur regexp en utilisant le mode regexp de style Perl:Expression régulière à l'aide du mode Dot-Matches-All

(?s).*i 

Le texte de recherche contient plusieurs lignes et chaque ligne contient beaucoup de caractères 'i'.

Je pense que le moyen regexp ci-dessus: la recherche autant de caractères (. Parce que le '? s la correspond maintenant à quoi que ce soit, y compris saut de ligne) possible (à cause de l'avidité pour *) jusqu'à atteindre le caractère' je'.

Cela devrait signifier "du premier caractère au dernier 'dans la phrase dernière" (la gourmandise devrait atteindre la dernière phrase, non?). Mais avec le test d'UltraEdit, il s'avère que "du premier caractère au dernier" i "dans la première phrase qui contient un i". Ce résultat est-il correct? Ai-je fait une mauvaise interprétation de mon expression reg?

par exemple. étant donné ce texte

aaa 
bbb 
aiaiaiaiaa 
bbbicicid 

il est

aaa 
bbb 
aiaiaiai 

assorti. Mais je pense:

aaa 
bbb 
aiaiaiaiaa 
bbbicici 

Répondre

5

Votre regex est correct, et sont donc vos attentes de ses performances.

Il s'agit d'un bogue connu depuis longtemps dans l'implémentation d'UltraEdit regex que j'ai écrit à plusieurs reprises à l'appui. Pour autant que je sache, il n'a toujours pas été réparé. Le problème semble résider dans le fait que l'implémentation de regex de UE est essentiellement basée sur des lignes, et que des lignes supplémentaires ne sont prises en compte que si nécessaire. Donc, .* correspondra avidement à la ligne en cours, mais il ne franchira pas une limite de saut de ligne si cela n'est pas nécessaire pour obtenir une correspondance.

Il existe d'autres bogues subtils avec des fins de ligne. Par exemple, lookbehind ne fonctionne pas non plus sur les nouvelles lignes.

Ecrivez sur le support IDM ou passez à un éditeur avec un support regex correct. J'ai fait les deux.

+0

Je ne connais pas le bug de lookbehind que vous avez mentionné. Mais pourrait-il être que la recherche avide dans l'ensemble du fichier d'entrée est trop lent qu'ils ont décidé de changer le comportement de cette façon? Rappelez-vous, UltraEdit permet d'éditer le fichier d'entrée de MB en taille. – JavaMan

+0

EditPadPro gère les fichiers de taille GB et ne possède pas ces restrictions regex. Si je construis une regex gourmande, je m'attends à ce qu'elle fonctionne correctement. Si cela signifie manquer de mémoire, alors c'est mon problème ou le système d'exploitation, mais l'éditeur ne devrait pas me deviner. –

1

Oui, vous avez raison, cela ressemble à un bug.

Votre interprétation est correcte. Si vous êtes en mode Perl et non Posix. Cependant, cela devrait également s'appliquer à posix.

Bien que la définition des modificateurs comme vous le faites est très rare.

La plupart du temps vous fournir une chaîne avec délimiteurs et le modificateur après comme /.*i/s

Mais cela n'a pas d'importance parce que votre chemin est correct aussi. Et s'il ne serait pas supporté, il ne correspondrait pas non plus à la première ligne.

Alors oui, c'est certainement un bug dans votre programme.

1

Vous avez raison de dire que cette expression rationnelle doit correspondre à la chaîne entière (les 4 lignes). Ma supposition est que UltraEdit essaye de faire une sorte d'optimisation en travaillant ligne par ligne, et en accumulant seulement de nouvelles lignes "si nécessaire".

+0

Si ce n'était pas un bug, je suppose que c'est la raison pour laquelle ils ont changé le comportement de cette façon. Probablement, pour un éditeur de texte, la recherche avide dans l'ensemble du fichier produit une mauvaise performance. – JavaMan