Квантификаторы в регулярных выражениях

«Окончательно разобраться», в контексте регулярок, это — фантастика :)

джеффри фридл с книгой «регулярные выражения» для этого предназначен

не уверен, но подумаю.

если nix то эфективнее сделать конвеером
grep «my.cool.site.com/forum/advertisement/..... » access | egrep -o "^[0-9\.]{8,16}"

Можно сделать негативным просмотром вперед и назад, но будет нещадно тормозить.
Лучше брать список адресов и выкидывать повторяющиеся.

Плюс, если ловим ботов, то пара обращений в период ротации и адрес проскочит, а если фильтрануть по времени, то можно случайно зацепить нормального юзера.

это я вно задача не для регулярок. точнее теоретически можно решить ими, но лучше не пробовать.
лучше за один проход по всему логу выберите уникальные IP + счетчик обращений к уникальным урлам, потом выкинте всех у кого урлов было больше одного. это потребует гораздо меньше мощностей чем танцевать с вокург ОГРОМНОГО лога с регулярками.

Не только. Хорошо бы повнимательнее относиться к собственным текстам. Опечаток огромное количество, с мягкими знаками совсем беда:

"… пЕрсер каждый раз, видя варианты, ставитЬ так называемые..."
"… то парсер ее разложитЬ на два символа..."
"… можно в правой частЬ описать..."

это — хабрачитатель ;)

Это очень похоже на меня, когда в очередной раз врубаешся в то, почему рекэксп работает так как работает :)

Ага и тебе привет!

Воспринимай регулярки как короткую запись условий в цикле. Я может быть еще в эту сторону копну, если руки дойдут в исходниках покопаться.

Продолжения будут, но как время появится, — эта статья где-то 3 полных дня.

На скриншотах — FF 3.5 c JS

labels = [
  /id="run_test"/,
  /id="\w+"/,
  /id=".*test"/,
  /id=".*.*test"/,
  /id="[^t]*test"/,
  /id=".{4}test"/,
  /id=".*?test"/,
  /id=".*u.*test"/
  ]
...

for (var j in labels) {
    
  timeStart=new Date();
  for(i=0;i<100000;i++) { str.search(labels[j]); }
  timeEnd=new Date();
  
  save_score(j,timeEnd.valueOf()-timeStart.valueOf());
}

* This source code was highlighted with Source Code Highlighter.

как-то неловко задача поставлена.

вместо того что написано можно использовать негативный просмотр назад /(?<!\\)"/, но сразу скажу что для \\" оно не сработает, хотя экранирован слэш. Что бы корректно отработать любое количество слэшей перед кавычками нужно просматривать вправо, что приводит нас к тому что условия задачи надо поменять.

1. Я вроде подробно описал.
Неоднозначность возникает если парсер не найдет простой кавычки и будет возвращаться обратно. Например в этом случае: "\" — строка не закрыта, выражение не должно на ней срабатывать.
Инструкция [^\"] совпадает со всем кроме \ и ". Кавычки экранированные покроются \. в выборе, также как и любые слеши, а неэкранированные — конец просмотра. Я не экранировал символы, что очевидно по абзацу.

2. Нет не выворачивает. И вообще при этом обычно скобки как (?: ) идут и так далее. Таковы уж регулярки.
К сожалению я все реже и реже пишу в перле, а другие языки таких конструкций не понимают. Иногда приходиться работать с двойным штакетником, поскольку в строке слеши приходиться экранировать дважды. А в некоторых нотациях все метасимволы идут со слешами и ничё! :)

Да пароль так лучше выглядит.

Специфика регулярных выражений в том что они пишутся для конкретных случаев, поэтому собирать регулярки в некий Cook book чревато ошибочным применением. Для популярных применений типа полного URL или e-mail есть в сети корректные варианты, но они все равно нуждаются в коррекции для используемого диалекта.